Hallo Leute, ich möchte gerne ein wenig Reverse-Enginnering betreiben. Dazu möchte ich ein Hex-Dump wieder in Assembler konvertieren. Konkret möchte ich das für einen ATtiny1634 machen! Wenn ich einen Hex-Dump habe scheine ich mit dem folgenden Befehl an den Assemble-Code zu kommen: avr-objdump -m avr -j .sec1 -d hex_dump.hex > hex_converted.asm (http://rn-wissen.de/wiki/index.php/Assembler-Dump_erstellen_mit_avr-gcc) Dazu hätte ich ein paar Fragen. Ist als Architektur "avr" richtig?? Ich habe auch schon Beispiele gesehen bei dehnen avr4 oder avr2 standen? Gibt es eine vergleichsweise bequeme Möglichkeit aus dem Assembler-Code wieder C-Code zu bekommen? (Mir ist klar, dass ein Compiler schon viel Optimert und deswegen der C-Code nicht gerade schön ausehen wird). Ich möchte IDA Pro für eine weitere Analyse benutzen. Das Tool unterstützt ja grundsätzlich die AVR Architektur. Leider gibt es den µC nicht zu Auswahl! Ist dass ein Problem, weil ich immer angenommen habe, dass das Instruction Set bei allen Atmegas, Attinys gleich ist? Außerdem, nach welchen kriterien teilt der Compiler den Code in Sektionen auf? (-j .sec1)
Patrick L. schrieb: > Dazu hätte ich ein paar Fragen. Ist als Architektur "avr" richtig?? Ich > habe auch schon Beispiele gesehen bei dehnen avr4 oder avr2 standen? Ok, ierzu habe ich schon selber eine Antwort gefunden: http://www.nongnu.org/avr-libc/user-manual/using_tools.html
>Gibt es eine vergleichsweise bequeme Möglichkeit aus dem Assembler-Code >wieder C-Code zu bekommen? Schon mal versucht aus Hamburgern wieder eine Kuh zu machen?
holger schrieb: > Schon mal versucht aus Hamburgern wieder eine Kuh zu machen? Hehe, neh. Mir ist schon klar, dass der C-Code nicht besonders lesbar dadurch wird.... Aber ist zumindest schonmal ein Anfang!
Patrick L. schrieb: > holger schrieb: >> Schon mal versucht aus Hamburgern wieder eine Kuh zu machen? > > Hehe, neh. Mir ist schon klar, dass der C-Code nicht besonders lesbar > dadurch wird.... Aber ist zumindest schonmal ein Anfang! Naja. "Nicht besonders lesbar" dürfte - vorläufig - die Untertreibung des Jahres sein. Es gibt dabei ein prinzipielles Problem, dass unlösbar ist. Als einfach(st)es Beispiel wähle ich mal folgendes: Angenommen, Du siehst im Assemblercode, das zwei 8-Bit-Werte addiert werden und bei Überlauf dieser in eine weitere Addition einfliesst. Ist das nun im Quellcode eben diese Addition von zwei uint_8 gewesen, die aus einem Grund, der in der Anwendung liegt, bei Überlauf die zweite Addition von zwei uint_8 um eins erhöht oder handelt es sich um eine 16-Bit-Addition? Das ist - maschinell jedenfalls - nicht entscheidbar. Gerade bei Entscheidungsstrukturen ist prinzipiell nicht entscheidbar ob diese ganz oder zum Teil - und im letzteren Fall, zu welchem Teil - diese eine in der Anwendung liegende Struktur abbilden oder eine, die sich (bzw, der Compiler) aus der "Emulation" der Datentypen herleitet. Mehr noch, gibt es Fälle in denen eine Entscheidung an sich oft als Arithmetische oder logische Operation formuliert wird. Ob das nun schon im Quelltext so war oder erst durch Optimierung entstanden ist, lässt sich auch nicht - maschinell, wie gesagt - nicht entscheiden. D.h. man muss schon ungefähr wissen, was man sucht bzw. herausfinden will und vor allem, nach welchem Entwurf die SW - wenn auch nur möglicherweise - implementiert wurde. Und dieses "ungefähr wissen" kann eben nur der Mensch.
Klaus schrieb: > Und dieses "ungefähr wissen" kann > eben nur der Mensch. Oder eine ziemlich ausgefuchste Anwendung mit einer Riesen-Datenbank im Hintergrund, für die der normale Arbeitnehmer erst einmal - unter Verzicht auf Komfort wie Essen, Wohnung, Familie etc. - so schlappe 500 Jahre arbeiten muss. :-)
nennt sich disassemblieren (spielen mit kleinen weißen Fretchen die auf dem Teppich tanzen) Nein ,man benutze einen Disassembler dazu ... zBsp. http://www.johannes-bauer.com/mcus/avrdisas/ Viel Spass damit
Klaus schrieb: > Naja. "Nicht besonders lesbar" dürfte - vorläufig - die Untertreibung > des Jahres sein. Ja gut; einfach ist es nicht gerade dass ist schon wahr. > Es gibt dabei ein prinzipielles Problem, dass unlösbar ist. Als > einfach(st)es Beispiel wähle ich mal folgendes: > > Angenommen, Du siehst im Assemblercode, das zwei 8-Bit-Werte addiert > werden und bei Überlauf dieser in eine weitere Addition einfliesst. Ist > das nun im Quellcode eben diese Addition von zwei uint_8 gewesen, die > aus einem Grund, der in der Anwendung liegt, bei Überlauf die zweite > Addition von zwei uint_8 um eins erhöht oder handelt es sich um eine > 16-Bit-Addition? Das ist - maschinell jedenfalls - nicht entscheidbar. Verstehe ich, da natürlich viel von der Optimerung des Compilers anhängt. > Gerade bei Entscheidungsstrukturen ist prinzipiell nicht entscheidbar ob > diese ganz oder zum Teil - und im letzteren Fall, zu welchem Teil - > diese eine in der Anwendung liegende Struktur abbilden oder eine, die > sich (bzw, der Compiler) aus der "Emulation" der Datentypen herleitet. [...] > Mehr noch, gibt es Fälle in denen eine Entscheidung an sich oft als > Arithmetische oder logische Operation formuliert wird. Ob das nun schon > im Quelltext so war oder erst durch Optimierung entstanden ist, lässt > sich auch nicht - maschinell, wie gesagt - nicht entscheiden. [...] > D.h. man muss schon ungefähr wissen, was man sucht bzw. herausfinden > will und vor allem, nach welchem Entwurf die SW - wenn auch nur > möglicherweise - implementiert wurde. Und dieses "ungefähr wissen" kann > eben nur der Mensch. Naja die Adressen der Interrupt-Vekoren sind ja zumindest schonmal fest. Da wird dann je nach umfang des Codes in der ISR in entsprechenden Funktionen gesprungen. Nach Best-Practice sollten ISRs ja möglichst kopakt sein. Das wäre ja schonmal eine Stelle sein an der man ansetzen könnte, oder nicht? Außerdem sich ja auch die Hardwareregister mit denen Komponenten konfiguriert werden bekannt (SPI, USART, TIMER, WD, ...). Dann weiß man ja schonmal grob wie Peripherie konfiguriert ist.
Dr.PillePalle schrieb: > nennt sich disassemblieren > > (spielen mit kleinen weißen Fretchen die auf dem Teppich tanzen) > > Nein ,man benutze einen Disassembler dazu ... > > zBsp. http://www.johannes-bauer.com/mcus/avrdisas/ Macht dass nicht auch schon avr-objdump? (http://ccrma.stanford.edu/planetccrma/man/man1/avr-objdump.1.html) Beim Hex-Dump habe ich auch keine Debug-Informationen was die ganze Sache erschwert! Gibt es eine möglichkeit herauszufinden, aus wo welche Sections beginnen? http://rn-wissen.de/wiki/index.php?title=Avr-gcc/Interna#Speicherverwaltung
Patrick L. schrieb: > Dr.PillePalle schrieb: >> nennt sich disassemblieren >> >> (spielen mit kleinen weißen Fretchen die auf dem Teppich tanzen) >> >> Nein ,man benutze einen Disassembler dazu ... >> >> zBsp. http://www.johannes-bauer.com/mcus/avrdisas/ > > Macht dass nicht auch schon avr-objdump? > (http://ccrma.stanford.edu/planetccrma/man/man1/avr...) > > Beim Hex-Dump habe ich auch keine Debug-Informationen was die ganze > Sache erschwert! > > Gibt es eine möglichkeit herauszufinden, aus wo welche Sections > beginnen? > > http://rn-wissen.de/wiki/index.php?title=Avr-gcc/I... Manno das ist kein Quantencomputer sondern ein kleiner AVR. Disassemblieren, Code lesen, Stück für Stück verstehen, Dabei Registernamen durch sinnvolle Variablennamen ersetzen und so irgendwann zur Gesamtfunktion kommen. Und bei einem AVR ist es auch von Vorteil, wenn man den Schaltplan rund um den AVR in den Händen hält. Um mal ein Beispiel für zu lösende Fragen zu geben: Ob die Software auf 0x0000 oder 0x0018 wegen davor liegender interruptvektoren beginnt oder ob bei 0x1c00 ein Bootloader liegt, Lässt sich auch von weniger geübten Assembler-Programmierern durch einen scharfen Blick auf den disassemblierten Code beantworten.
Andy P. schrieb: > Manno das ist kein Quantencomputer sondern ein kleiner AVR. > Disassemblieren, Code lesen, Stück für Stück verstehen, Dabei > Registernamen durch sinnvolle Variablennamen ersetzen und so irgendwann > zur Gesamtfunktion kommen. Da stimme ich voll und ganz mit dir überein. > Und bei einem AVR ist es auch von Vorteil, > wenn man den Schaltplan rund um den AVR in den Händen hält. Hab ich; und so komplex ist die Beschaltung auch nicht. Ein bisschen PWM, USART ein Paar Taster + Leds. > Um mal ein Beispiel für zu lösende Fragen zu geben: > Ob die Software auf 0x0000 oder 0x0018 wegen davor liegender > interruptvektoren beginnt oder ob bei 0x1c00 ein Bootloader liegt, Lässt > sich auch von weniger geübten Assembler-Programmierern durch einen > scharfen Blick auf den disassemblierten Code beantworten. Jop, das denke ich auch!
>Hab ich; und so komplex ist die Beschaltung auch nicht. Ein bisschen >PWM, USART ein Paar Taster + Leds. Dann kann man das Programm auch neu schreiben. Wird weniger Zeit benötigen als der Hirnpfurz den du da gerade hast.
holger schrieb: > Dann kann man das Programm auch neu schreiben. > Wird weniger Zeit benötigen als der Hirnpfurz den > du da gerade hast. Darum geht es ja gar nicht. Es geht um die Herausforderung möglichst viel über den Code herauszufinden. Seh es als eine akademische Aufgabe an!
>Darum geht es ja gar nicht. Es geht um die Herausforderung möglichst >viel über den Code herauszufinden. Seh es als eine akademische Aufgabe >an! Dummerweise hast du von tuten und blasen keine Ahnung. Das wird also nix.
Beitrag "Re: Gerät mit AT90S4414 retten" da wird ein Beispiel gezeigt, wie so ein re-assemblierter Text aussieht Das Programm heisst ReAVR von Johannes Assenbaum, ist leider nur noch auf einer wenig vertrauenswürdigen Downloadseite zu finden. 3.5 war wohl die letzte Version. Andere empfehlen IDA https://www.hex-rays.com/products/ida/processors.shtml Die Freeware-Version IDA 5.0 kann auch AVR, so steht es im Hilfetext. Auf der Webseite habe ich diese Info nicht gefunden, ich musste es erst installieren. Die Demoversion kann nur x86. Dann hab ich noch ein Java-Programm gefunden http://community.atmel.com/projects/simple-avr-disassembler
:
Bearbeitet durch User
Christoph K. schrieb: > ReAVR von Johannes Assenbaum Die Version 3.2-beta habe ich hier, funktioniert fehlerfrei. Bei Bedarf PM.
Patrick L. schrieb: > Klaus schrieb: >> Naja. "Nicht besonders lesbar" dürfte - vorläufig - die Untertreibung >> des Jahres sein. > > Ja gut; einfach ist es nicht gerade dass ist schon wahr. > [...] > Naja die Adressen der Interrupt-Vekoren sind ja zumindest schonmal fest. > Da wird dann je nach umfang des Codes in der ISR in entsprechenden > Funktionen gesprungen. > > Nach Best-Practice sollten ISRs ja möglichst kopakt sein. Das wäre ja > schonmal eine Stelle sein an der man ansetzen könnte, oder nicht? Mit dem RETI-Befehl ist das Ende ohnehin einfach zu erkennen. > Außerdem sich ja auch die Hardwareregister mit denen Komponenten > konfiguriert werden bekannt (SPI, USART, TIMER, WD, ...). Dann weiß man > ja schonmal grob wie Peripherie konfiguriert ist. Das weiß man dann sogar ganz genau. Witzig wird es wenn die Konfiguration geändert wird. Das sind Ansatzpunkte. Ohne Zweifel sind das nützliche Ansatzpunkte. So macht das jeder, der dazu Anlass hat. Bis dahin ist die Sache trivial. Aber damit fängt der Spaß überhaupt erst an. Ich sage ja nicht, dass es gar nicht geht oder das es extrem schwierig ist. Es hat eben nur seine Eigenheiten. Und mir schien, dass man jemanden warnen sollte, der danach fragt wie man den C-Code wieder herstellen kann. Viel Erfolg.
Interessanter würde ein C-Code noch, wenn das ursprüngliche Programm schon in Assembler geschrieben wurde.
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.