pic - wie aus hex-file asm code machen?

[uli (Gast)]

Hallo,
Ich habe von einem Pic den code als hex-file.
Jetzt die grosse frage an die pic freunde:
Wie kann man daraus ein compilierbaren asm code machen?

Viele grüsse, uli

[Teo D. (teoderix)]

Das Hexfile ist bereits ein compilierter Assembler Code.
Disasembling geht (irgend wie) im MPLAB X.....

[tommy (Gast)]

Mit einem Disassembler

Google: Pic Disassembler

[michael_ (Gast)]

Bin zwar kein Pic-Freund.

Aber das macht man mit einem Reassembler.
Wenn er in Assembler programmiert wurde, hast du reale  Chancen.

[c-hater (Gast)]

michael_ schrieb:

> Aber das macht man mit einem Reassembler.
> Wenn er in Assembler programmiert wurde, hast du reale  Chancen.

Auch wenn das Teil in in einer Hochsprache programmiert wurde, kann ein 
richtiger Assemblerprogrammierer natürlich mit dem Disassemblat etwas 
anfangen.

Lustig ist: der Code wirklicher Assemblerprogrammierer ist in vielen 
Aspekten genau so "unleserlich" wie der angeblich "optimierte" Code der 
Compiler. Nur eben trotzdem deutlich schneller...

[W.S. (Gast)]

uli schrieb:
> Wie kann man daraus ein compilierbaren asm code machen?

Garnicht. Assemblercode wird assembliert und nicht compiliert. Das ist 
ein Unterschied im Grundsatz: zu jedem Assemblerbefehl gibt es genau 
einen Maschinenbefehl - bei allem, was compiliert wird, gibt es so eine 
Zuordnung nicht.

Und um aus einem Hexfile einen Assembler-Quellcode zu machen, schreibst 
du dir einfach einen Disassembler. Sind ja nur etwa 35 verschiedene 
Befehle.

Ja, als Programmierer sollte man sowas können - jedenfalls für eine 
übersichtliche Architektur wie die der kleinen PIC's (vorausgesetzt, du 
meinst PIC16xxx oder PIC18xxx und keine PIC32...)

W.S.

[uli (Gast)]

Hat der wirklich nur 35 befehle? Ist der aber mal einfachgebaut!

Da könnte ich mir wirklich einen disasembler schreiben.
Wenn ich es jetzt richtig gesehen habe dann kostet das teil für die  pic 
18 ja was, nicht schön.
Wenn es keine andere möglichkeit gibt ist selber schreiben angesagt.
Habe zumglück sowas für einen 8048 oder 8051 mal gemacht, nur wo das 
ganze ist?  Wird eine nette suche.
Vg, uli

[uli (Gast)]

Mist habe doch die freien tools übersehen.
Muss nun einige davon testen.

[Wolfgang (Gast)]

W.S. schrieb:
> Garnicht. Assemblercode wird assembliert und nicht compiliert. Das ist
> ein Unterschied im Grundsatz: zu jedem Assemblerbefehl gibt es genau
> einen Maschinenbefehl - bei allem, was compiliert wird, gibt es so eine
> Zuordnung nicht.

Sagt wer? Steht irgendwo geschrieben, dass ein Compiler keine 1:1 
Umsetzung des Codes in Maschinenbefehle machen darf?

[Ömer (Gast)]

Wolfgang schrieb:
> W.S. schrieb:
>> Garnicht. Assemblercode wird assembliert und nicht compiliert. Das ist
>> ein Unterschied im Grundsatz: zu jedem Assemblerbefehl gibt es genau
>> einen Maschinenbefehl - bei allem, was compiliert wird, gibt es so eine
>> Zuordnung nicht.
>
> Sagt wer? Steht irgendwo geschrieben, dass ein Compiler keine 1:1
> Umsetzung des Codes in Maschinenbefehle machen darf?

Was schreibst du jetzt von Code - Maschinenbefehl? W.S.  schrieb von 
Assemblerbefehl- Maschinenbefehl.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

W.S. schrieb:
> zu jedem Assemblerbefehl gibt es genau einen Maschinenbefehl - bei
> allem, was compiliert wird, gibt es so eine Zuordnung nicht.
Dann sind Makroassembler also eigentlich Compiler...

@uli: ein Disassembler macht aus dem Hexfile zwar wieder einen 
Assemblertext, aber den kann dann nur ein langjähriger 
Assemblerprogrammierer mit Aufwand wieder entschlüsseln,  weil natürlich 
alle lesbaren und klingenden Namen für Variablen, Unterprogramme, 
Sprungmarken usw. durch nichtssagende Buchstaben-Zahlen-kombinationen 
ersetzt wurden.
Und das mag noch gehen, wenn ein Mensch das programmiert hat. Wenn es 
aber das Ergebnis eines Compiliers ist: vergiss es.

[Klaus (Gast)]

Lothar M. schrieb:
> Dann sind Makroassembler also eigentlich Compiler...

Wenn man es so nennen will, ja. So auf dem Niveau Bascom. Am Anfang war 
C++ auch nur Preprozessor Macros

MfG Klaus

[Wolfgang (Gast)]

Ömer schrieb:
> Was schreibst du jetzt von Code - Maschinenbefehl?

Nenn es von mir aus Assembler-Code. Das sind human-readable 
Bezeichnungen für die (binären) Maschinenworte mit einer Syntax für 
Adressierungsart, Argumente, Sprungziele, Einsprungstellen usw. ;-)
Auch stehen im Assembler Code eher keine absouluten Adressen, d.h. 
zwischen Assembler-Code und in den Programmspeicher des Prozessor 
geladene Binärdaten passiert noch ein bisschen was.

Sprachlich wird "assemble" auch als Synonym für "compile" angegeben
http://www.thesaurus.com/browse/compile

[Wolfgang (Gast)]

W.S. schrieb:
> Das ist ein Unterschied im Grundsatz: zu jedem Assemblerbefehl gibt es
> genau einen Maschinenbefehl

Wo hast du das gelesen oder was meinst du mit "Maschinenbefehl"?

Je nach Adressierungsart kann der Binärcode zu ein und dem selben 
Assemblerbefehl deutlich unterschiedlich aussehen.

Beispiel 6502:
Assemblerbefehl LDA,
Binärcode je nach Adressierungsart
$A9, $A5, $B5, $AD, $BD, $B9, $A1 oder $B1)

http://www.6502.org/tutorials/6502opcodes.html#LDA

[nopic-noanswer (Gast)]

Guten Morgen,

ich entschuldige mich für die offenen Worte, aber ihr, die bisherigen 
Antworter, habt ein ganz schönes Ding an der Klatsche, wenn ich das mal 
so sagen darf! Nur Selbstdarsteller!

Statt hier einfach den Namen eines vorzugsweise kostenlosen 
pic-Dissassemblers zu nennen, mit dem ihr vielleicht gute Erfahrungen 
gemacht habt, oder dessen Fehlleistungen, Schwächen ihr kennt und 
benennen könnt, kommt hier nur nutzloses geschwurbel.

Ulli hat

uli schrieb:
> zumglück sowas für einen 8048 oder 8051 mal gemacht

damit wird er wohl wissen was er tut und die Fragestellung war nur 
anfangs etwas unspezifisch formuliert.

Mit Wortklauberei, die letztendlich zu der richtungweisenden Erkenntnis 
führt, daß ein Makroassembler so etwas wie ein Bascomcompiler ist, ist 
doch wirklich niemandem geholfen, oder was?


ps ja ich habe schlecht geschlafen, die Nacht war schliesslich viel zu 
kurz...

[Ömer (Gast)]

Wolfgang schrieb:
> Sprachlich wird "assemble" auch als Synonym für "compile" angegeben
> http://www.thesaurus.com/browse/compile

Neben 28 anderen Möglichkeiten.

Wolfgang schrieb:
> Je nach Adressierungsart kann der Binärcode zu ein und dem selben
> Assemblerbefehl deutlich unterschiedlich aussehen.
>
> Beispiel 6502:
> Assemblerbefehl LDA,
> Binärcode je nach Adressierungsart
> $A9, $A5, $B5, $AD, $BD, $B9, $A1 oder $B1)

Genau und mit unterschiedlichen Adressen gibt es noch viel mehr 
Binärcodes, oder?

nopic-noanswer schrieb:
> Mit Wortklauberei, die letztendlich zu der richtungweisenden Erkenntnis
> führt, daß ein Makroassembler so etwas wie ein Bascomcompiler ist, ist
> doch wirklich niemandem geholfen, oder was?

Wortklauberei hilft Wolfgang den Tag zu überstehen. Ich halte mich an

https://de.wikipedia.org/wiki/Compiler oder
https://de.wikipedia.org/wiki/Assembler_(Informatik) bzw
https://de.wikipedia.org/wiki/Assemblersprache

[Volker S. (vloki)]

Teo D. schrieb:
> Disasembling geht (irgend wie) im MPLAB X.....

File->Import Hex
dann
Window->PIC Memory Views->Program Memory

[Bernd K. (prof7bit)]

Lothar M. schrieb:
> durch nichtssagende Buchstaben-Zahlen-kombinationen
> ersetzt wurden.
> Und das mag noch gehen, wenn ein Mensch das programmiert hat. Wenn es
> aber das Ergebnis eines Compiliers ist: vergiss es.

Das hängt immer vom Skill-Level des Reverse-Engineers ab und den 
Werkzeugen die er zur Verfügung hat, es gibt extrem mächtige 
Softwaretools die einen dabei unterstützen auch aus einem 
undurchdringlich scheinenden Dickicht aus asm wieder Schritt für Schritt 
die Struktur der Abläufe herauszuarbeiten, die interessanten Stellen zu 
finden, Funktionen und Variablen mit sinnvollen Namen zu dokumentieren 
und sogar teilweise wieder sowas ähnliches wie lesbaren äquivalenten 
C-Code daraus zu generieren.

[Heinz V. (heinz_v)]

Wolfgang schrieb:
> Auch stehen im Assembler Code eher keine absouluten Adressen, d.h.
> zwischen Assembler-Code und in den Programmspeicher des Prozessor
> geladene Binärdaten passiert noch ein bisschen was.

Der Assembler übersetzt die Opcodes und hartcodierten Werte/Konstanten 
und generiert ein Objekt File (manche Assembler können auch direkt .bin 
(Startaddresse 0h) oder auch .com (Startaddresse 0100h) Files 
schreiben), die Addressen sind im .obj noch Symbole, im Linker werden 
die zu absoluten Addressen umgerechnet.

zum Thema:

http://www.chip.de/downloads/IDA-Pro-Free-Letzte-Freeware-Version_29744270.html

schau da mal rein.

[B. P. (skorpionx)]

http://www.sprut.de/electronic/soft/usburn/usburn.htm

Mit usburn vom sprut geht das auch.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Bernd K. schrieb:
> Das hängt immer vom Skill-Level des Reverse-Engineers ab
Schrieb ich ja auch schon. Und einer wie uli, der fragt "ob das geht" 
hat überaus wahrscheinlich nicht die nötige Erfahrung...

[Thomas E. (picalic)]

B. P. schrieb:
> Mit usburn vom sprut geht das auch.

Daran hatte ich auch gleich gedacht - nur kann man damit ohne eine 
angeschlossenen Brenner-Hardware offenbar nichts machen, nicht mal ein 
Hex-File einladen! Oder habe ich was übersehen?

[B. P. (skorpionx)]

Thomas E. schrieb:
> Daran hatte ich auch gleich gedacht - nur kann man damit ohne eine
> angeschlossenen Brenner-Hardware offenbar nichts machen, nicht mal ein
> Hex-File einladen! Oder habe ich was übersehen?

Das Programm kann man mit mehrere Optionen starten. Du muss in der
Beschreibung vom Brenner nachschauen. Vielleicht geht das dann ...

[Thomas E. (picalic)]

B. P. schrieb:
> Du muss in der
> Beschreibung vom Brenner nachschauen.

Muss ich nicht - Du hast behauptet, daß es mit USBURN geht, also musst 
Du auch schreiben, wie... ;)

[B. P. (skorpionx)]

Thomas E. schrieb:
> Muss ich nicht - Du hast behauptet, daß es mit USBURN geht, also musst
> Du auch schreiben, wie... ;)

Du kannst den Brenner bauen...

[Thomas E. (picalic)]

B. P. schrieb:
> Du kannst den Brenner bauen...

Könnte ich, muss ich aber auch nicht, weil ich den schon habe. Nützt 
aber dem TO nichts...

[Uli (Gast)]

Oh Leute was soll das ganze hier?

Ja ein Assembler Code wird nicht durch einen C Compiler gejagt sondern 
durch einen Assembler. Mal abgesehen das ich nie was von C oder so 
gesagt hatte ist das eigentlich nur eine Haarspalterei und absolut 
unnütz.

Warum stellt man eine Frage nach einem Konverter, logischerweise weil 
man einen fertigen sucht und nicht viel Zeit investieren will noch einen 
zu machen.

Es wird schon schwer genug im Code einen Fehler zusuchen, da muss ich 
nicht noch erst den Disassembler bauen.

VG, Uli

[Volker S. (vloki)]

Uli schrieb:
> Es wird schon schwer genug im Code einen Fehler zusuchen, da muss ich
> nicht noch erst den Disassembler bauen.

Kleine Ergänzung zu der MPLABX Lösung. Da kann man dann sogar den 
Simulator benutzen...

[Pandur S. (jetztnicht)]

So ganz nebenbei.. das Disassemblat besteht nur aus kryptischem Zeug. 
Also zB

 Label0 :
     LD   Reg0,#123
     MOV  $X,Reg0

Es sind keine Variablennahmen dabei, woher auch. Dh man muss eine sehr 
gute Idee haben worum's geht.

[Volker S. (vloki)]

Sapperlot W. schrieb:
> So ganz nebenbei.. das Disassemblat besteht nur aus kryptischem Zeug.

Das steht jetzt wirklich schon zur genüge weiter oben.
Lasst ihn doch einfach mal machen.
Der Aufwand ist gering und man sieht sofort das Ergebnis.

Volker S. schrieb:
> Window->PIC Memory Views->Program Memory

[Helfer (Gast)]

Ich veruch hier mal mein Vorgehen zu beschreiben:
- Mit MPLabX über FILE->IMPORT->Hex/ELF das Hex-File mit dem 
dazugehörigen µC importieren
- Mit WINDOW->PIC-MemoryViews->ProgramMemory den Speicherinhalt aufrufen
- In dem "ProgramMemory"-Fenster rechte Maustaste -> "OutputToFile" 
erzeugt ein Assembler-Ähnliches Textfile
- Mit einem passenden Editor deiner Wahl (Notepad++ geht da z.B.) die 
ersten Spalten löschen und man hat den rohen Assenblercode
- Ab hier viel Spass beim "verstehen" des Codes

Gruß Helfer

[W.S. (Gast)]

Uli schrieb:
> Es wird schon schwer genug im Code einen Fehler zusuchen, da muss ich
> nicht noch erst den Disassembler bauen.

OK. Wenn das so ist, dann schreib einen Brif an Ilfak Gulfanov und kaufe 
dir ne Vollversion von IDA.

Ach, ist dir etwa zu teuer? Dann schreib dir was selber, ist ja nicht 
gar so schwer. Aber denke nicht, daß die Straßen der Stadt voll sind von 
Programmierern, die speziell das Schreiben und Veröffentlichen von 
PIC-Reassemblern zu ihrem Lebensinhalt gemacht haben.

Mit anderen Worten: Das ist zu exotisch.

Und nochwas zu dem Falsch-Verständnis einiger Leute hier betreffend 
Assembler versus Compiler:

Ein Compiler ist etwas, das aus einer maschinenunabhängigen Sprache ein 
zu einer Zielplattform geeignetes Maschinenprogramm macht. Das bedeutet, 
daß der Input eben NICHT den Maschinen-Befehlssatz der Zielplattform 
widerspiegelt - im Gegensatz zum Assembler.

Nun klaro? Wenn jeder die Begriffe nach seinem momentanen Gusto und 
Tagesform mißverwendet, dann gibt es nur noch babylonische 
Sprachverwirrung und keiner versteht mehr, was der andere eigentlich 
sagen wollte.

W.S.

[Volker S. (vloki)]

W.S. schrieb:
> und keiner versteht mehr, was der andere eigentlich
> sagen wollte.

Manchmal ist es sogar schon schwer zu verstehen, warum so viele 
überhaupt unbedingt was sagen wollen/müssen ;-)

[Bernd K. (prof7bit)]

W.S. schrieb:
>> nicht noch erst den Disassembler bauen.
>
> OK. Wenn das so ist, dann schreib einen Brif an Ilfak Gulfanov und kaufe
> dir ne Vollversion von IDA.

Eine flüchtige Google-Suche nach "PIC Disassembler" liefert viele 
Treffer, ich glaube nicht daß IDA der einzige ist. Es ist zwar 
unstrittig der beste (und teuerste) aber ich kann nicht glauben daß es 
der der einzige.ist, so exotisch ist diese Plattform ja nun auch wieder 
nicht.

Ich sehe nicht wo das Problem liegt.

[c-hater (Gast)]

Bernd K. schrieb:

> Ich sehe nicht wo das Problem liegt.

Bei der Kompetenz des TO natürlich.

[Marcus H. (Firma: www.harerod.de) (lungfish)]

Huhu Uli,
hast Du Lust das Thema nochmal anzugehen?

Wir wissen mittlerweile, dass wir das HEX-File in eine 
Entwicklungsumgebung laden können und dort das Disassembly anzeigen 
lassen können.

Alles entscheidende Frage, deren Antwort ich hier im Rauschen nicht 
finden konnte: welcher PIC und wie groß ist das HEX-File?

Cheerio,
 marcus

[Pic Assemblant (Gast)]

Lothar M. schrieb:

> weil natürlich
> alle lesbaren und klingenden Namen für Variablen, Unterprogramme,
> Sprungmarken usw. durch nichtssagende Buchstaben-Zahlen-kombinationen
> ersetzt wurden.

hast du jemals ein Pic asm disassembliert?

deine "nichtssagende" Buchstaben-Zahlen-kombinationen sind 
Speicherzellen.
Im Falle vom Pic also von $20 - $xxx (RAM)
Der Rest sind Sprungmarken zu Speicherstellen bzw. PC bei indirekter 
Adressierung.
Wer also Disassembliert weiß ganz genau was er wo findet.
Und nachdem man den Aufbau einigermaßen Verstanden hat 
(Init,ISR,Start,Routinen) geht man an die Bennennung der Identifizierten
Speicherstellen, so das man es im weiteren Verlauf einfacher hat.
Das ist alles eine Frage des Fleiß und Verständniss.
One Klick oder Arduino Schlau Lib "Copy and Paste" führen natürlich 
nicht zum Ziel. UND es hilft auch nicht beim erlernen (!) es macht die 
Benutzer
nur noch mehr Abhängig von Arduino, weshalb ich das auch nicht so dolle 
finde.


Und zum Fragesteller, hier mal eine möglichkeit:
http://www.hagi-online.org/picmicro/picdisasm_en.html