Hallo zusammen Ich wollte mal hier nachfragen ob jemand mit den 8051 disassemblern erfahrung hat. Konkret geht es um folgendes projekt: http://wp.visuanetics.nl/oled-display-for-alpha-juno-2/ ich habe aber die Alpha Juno 1 Version, daher müsste ich das selbe mit meiner Firmware machen um ein OLED Display verwenden zu können. Das EEprom hab ich bereits eingelesen in ein bin file. Dieses habe ich dann versucht mit dem d52 zu disassemblen. Jedoch habe ich dann weder richtige labels oder sonst was. Gibt es da einen einfacheren weg um die #0C0h Sprünge zu entfernen ? Gruss, Thomas
Thomas W. schrieb: > Jedoch habe ich dann weder richtige labels Woher soll der Disassembler auch wissen, wie die heißen sollen?
Thomas W. schrieb: > weg um die #0C0h Sprünge zu entfernen Seit Jahrzehnten programmiere ich mit dem MCS51, aber ich gestehe, dass ich mit deiner Aussage nichts anfangen kann. Was ist ein #0c0h Sprung? Generell gilt, dass nach dem ersten Disassembler Lauf etwa 0.1% der Arbeit erledigt sind. Das Rückwandeln in lesbaren Quelltext kostet viel Geduld und Einfühlungsvermögen.
Viele Disassembler können keine konstanten Daten im Code erkennen, d.h. Werte und Texte werden in ein Befehlschaos umgewandelt, wobei die Synchronisation verloren gehen kann (8051: 1..3 Byte je Befehl).
Ein alternativr Weg wäre gewesen, das BIN-File hier zu posten, damit ein
Mitleser "seinen" Disassembler darauf loslassen kann.
Es gibt Disassembler, die mehrere Durchläufe machen und damit interaktiv
ein Steuerfile aufbauen, in dem diese "Stolperfallen" passend definiert
werden. Disassemblieren ist immer ein mehrstufiger Prozess. Einfach mal
ein Programm auf den Code loslassen und fertig ist Träumerei.
Beispiel "GD8051":
:The 'controlfile' consists of entries of the form:-
:# any line beginning with a '#' is a comment
:Hd 1234 'header' -or- title of a subroutine
:Cc 1234 this comment is tagged onto the line with this address
:Cb 1234 this comment is written before the line with this address
:Wc 1234:26 # defines word data, start address and count
:Wo 1234 # defines word data
:Wo 1234-1288 # defines range of word data
:Lb 1234[,3456] # user defined label
:Tx 1234,12 # defines text string and its length
:Az 1234 # defines ascii zero terminated string
:En 1234 # defines code entry address
:En 1234[,2345] # defines list of code entry addresses
:Er 1234;1256;3 # defines range of code entry addresses
:Nw 1234 Word_Count # defines name of ROM/external RAM address
:Ni 56 Byte_Count # defines internal RAM address name
Alles, was einen textlichen Bezug hat: Also Die Namen von Funktionen, Bezeichnungen von Variablen und Konstanten oder auch von Sprungadressen sind nicht im Programm enthalten. Oft muss (viel) von Hand noch nachgearbeitet werden, da nicht immer klar ist, ob der Teil, der gerade disassembliert wurde, überhaupt Code ist, oder textliche bzw. numerische Konstanten enthält. Sisyphos lässt grüßen.
Ok, vielen Dank für all eure Antworten. Ich sehe schon, ich hab mir das wohl etwas zu einfach vorgestellt. Ich dachte man könne einfach aus dem dissasemblierten code die werte entfernen, welche den Zeilensprung auf dem Display ausgeben und den code dann wieder assemblieren. Ich habe sonst mal das BIN file angehängt. Gruss, Thomas
Anderer Vorschlag: Zunächst das BIN nach HEX konvertieren: srec_cat JU-1_1-1.bin -binary -offset 0 -o JU-1_1-1.hex -intel http://srecord.sourceforge.net/ Dann in einem Simulator ansehen: Scheint ja kein langes Programm zu sein http://www.edsim51.com/
Georg G. schrieb: > Das Rückwandeln in lesbaren Quelltext kostet viel > Geduld und Einfühlungsvermögen. Alternative: Die Einsprungstellen für den zu ändernden Code finden und auf den neuen Code in einem bisher ungenutzen Bereich vom ROM umleiten. Dann muss man den bestehenden Code nur so weit analysieren können, dass man diese Stellen findet. Zu echtem Quellcode umständlich rückzuübersetzen ist unnötig, im Binary patchen können reicht.
Ich habe das mal durch den IdaPro geschoben und ihm dabei ein wenig auf die Sprünge geholfen. Sieht schon ganz gut aus, wobei es bestimmt noch Stellen gibt, bei denen Daten/Code zugeordnet sein können. Kann man durch viel Arbeit noch leserlicher machen, aber das hier hat schon lange genug gedauert.
Mist, zu früh abgeschicket: ...bei denen Daten/Code falsch zugeordnet sein können.... Im Anhang ist das gezippte Listing, ich hoffe, es erleichtert die Arbeit etwas
reas schrieb: > Mist, zu früh abgeschicket: Wenn du keine Antworten bekommst liegt es wahrscheinlich daran, dass hier niemand gern ein fremdes ".ZIP" öffnet!
Route 6. schrieb: > Wenn du keine Antworten bekommst liegt es wahrscheinlich daran, dass > hier niemand gern ein fremdes ".ZIP" öffnet! Oh Gott, mir kommen gleich die Tränen. Selbst wenn es ein Virus wäre, hast du nach dem Entpacken dann nur den entpackten Virus. Der tut, solange du ihn nicht ausführst, erstmal überhaupt nichts. Wenn man allerdings nicht in der Lage ist, diese Zusammenhänge richtig zu verstehen, hat man allerdings ein Problem. Entpackt sind es über 600kB, das muss man dem Server nicht antun
Rufus Τ. F. schrieb: > Route 6. schrieb: >> dass hier niemand gern ein fremdes ".ZIP" öffnet! > > Blödsinn. O.K. ich habe mich getraut, obwohl ich reas (Gast) nicht kenne. Thomas W. schrieb: > Dieses habe ich dann versucht mit dem d52 zu disassemblen. Jedoch habe > ich dann weder richtige labels oder sonst was. Gibt es da einen > einfacheren weg um die #0C0h Sprünge zu entfernen ? Das Binary ist ein BASCOM8051 Kompilat. Was ist jetzt genau deine Aufgabenstellung? Was verstehst du unter "#0C0h Sprünge"? Der 8051 macht bei 0C0h einen PUSH ,bei Adresse 00C0h steht nicht wirklich ein sinnvoller Einsprungpunkt und wird auch nirgends im Binary augerufen. Was willst du statt dessen? gerade erst gesehen: > Wenn man allerdings nicht in der Lage ist, diese Zusammenhänge richtig > zu verstehen, hat man allerdings ein Problem. Ich würde meine Hilfe gern zurückziehen, du A... (Eigenzensur)
:
Bearbeitet durch User
Thomas W. schrieb: > Dieses habe ich dann versucht mit dem d52 zu disassemblen. Jedoch habe > ich dann weder richtige labels oder sonst was. Gibt es da einen > einfacheren weg um die #0C0h Sprünge zu entfernen ? Du musst schon selbst identifizieren, was welche Funktion hat. Dann kannst du ein *.ctl-File schreiben und dem d52 übergeben, z.b. Zeilen wie:
1 | l 193e tramp_dyn |
lösen dir in der Disassembly die Labels auf und machen die Dinge lesbarer. Google sonst mal nach 'dpf-ax', da wurde einiges an Reverse-Engineering betrieben (uinkl. Beispiele).
Route 6. schrieb: > Das Binary ist ein BASCOM8051 Kompilat. Korrektur: Stimmt nicht. Ich weiss jetzt auch, was das #0C0h Problem ist. Ich hätte es anders, nämlich genau einmal gelöst, und nicht überall im Quelltext verstreut.
:
Bearbeitet durch User
Das Original-Display ist HD44780 kompatibel und dort ist #C0h der Befehl zum Adressieren der zweiten Zeile. Der TO möchte aber ein neues Display verwenden, bei dem die Adressen anders sind. Deshalb muss er jetzt bei allen Text-Ausgaben den Befehl in #88h ändern. Erschwerend kommt hinzu, dass teilweise auch andere Koordinaten über Berechnungen adressiert werden. Also muss man das Programm disassemblieren und verstehen, die entsprechenden Stellen finden und dann das Binary patchen oder auch das Disassemblat ändern und zurückübersetzen.
Hi zusammen, Vielen Dank für eure Antworten. Ich habs jetzt mit der Hilfe von Georg hinbekommen, das binary mit dem GD8051 zu disassemblieren und mit dem as31 wieder zu assemblieren, das binary auf das Eeprom zu brennen und es läuft wieder. Jedoch ist es genau so wie Mario schreibt... es ist wirklich Pain pur... das zeug ist über den ganzen code verstreut. Ich habe schon beides probiert... einfach mal alle #C0h mit #88h zu ändern und auch die anderen Werte die #C0h überschreiten anzupassen um #38h kleiner. Oder systematisch der Funktion für die Displayausgabe nachzugehen. Das wäre hier O1153 und nur dort die werte anzupassen. Mit der 1. Variante bin ich am weitesten gekommen, jedoch weiss ich nicht wirklich was ich sonst noch alles geändert habe ;-) mit der 2. funktioniert nur die hälfte der Displayausgabe richtig. Ich finde das ist extrem verstreut. Ich hab das ASM file mal angehängt... die Änderungen sind mit ;-- kommentiert.
Mal noch eine andere Frage dazu, wüsste ev. jemand von euch ein mit dem originalen HD44780A00 kompatibles OLED welches ja auch ein 16x1 sein müsste aber wie ein 16x2 angesteuert wird ? Dann würde ich nämlich einfach ein anderes Display nehmen. Gruss, Thomas
Thomas W. schrieb: > müsste aber wie ein 16x2 angesteuert wird ? Sorry ich meine natürlich ein 8x2...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.