Hallo zusammen, wenn ich mit GDB debuggen möchte, sieht das übliche Vorgehen wohl so aus, dass man mit GCC seinen Quellcode compiliert und die dabei gebaute ELF-Datei in GDB lädt. Für mein Vorhaben muss der Weg jedoch umgekehrt sein: Ich habe lediglich einen Memory Dump (Binärdaten) von einem MC68k System. Dieses möchte ich reverse engineeren und um es besser zu verstehen, mit GDB durch den Assemblercode steppen. Mein erster Ansatz war, GDB direkt mit den Binärdaten zu füttern. Jedoch habe ich keinen Hinweis gefunden, dass das funktioniert. Dann habe ich versucht, per "objdump -b binary -D <filename.bin>" ein Disassembly zu erzeugen, um das dann zu debuggen. Leider bekomme ich die Fehlermeldung "architecture unknown". Wenn ich "--target=elf32-M68k" eingebe, erhalte ich "File format not recognized"... Ich möchte doch nur die Binärdaten debuggen! Mit IDA Pro bspw. kann ich sie wunderbar disassemblieren. Aber eben nicht debuggen. Das muss doch mit GNU irgendwie gehen? Was mache ich falsch, wie mache ich es richtig? Grüße Steffen P.s.: Ich verwende diese Toolchain: http://gnutoolchains.com/m68k-elf/ in einer Windows-Umgebung.
Und wo ist deine CPU die du mit GDB steuerst? Hast du einen Simulator dazu?
Ist der gdb eh von einer Toolchain für den 68K? Weil mit eine i686 gdb oder so wird es nicht gehen.
m68k-elf-objdump -D -b binary --architecture m68k:68000 <raw binary> (oder eben ein anderer, unterstützter Prozessor der M68K-Familie) müsste dir ein brauchbares Disassembly liefern. Allerdings ist da noch etwas Arbeit und Hirnschmalz reinzustecken. Das raw binary hat keine Section-Informationen mehr und der Disassembler kann zwischen Code und Daten nicht unterscheiden. Für gdb brauchst Du irgendeine Verbindung zum Targetsystem. Entweder läuft gdb direkt dort drauf oder es gibt irgendeine Art von Remote-Kommunikation (gdbserver seriell oder z.B. BDM).
Meine CPU ist über ein Interface am Parallelport angeschlossen. Mit einem anderen Tool (BD32) kann ich damit, recht unkomfortabel, debuggen. Der GDB, den ich mir heruntergeladen habe, ist für den M68k gebaut. Das ist also schon die richtige Architektur. Danke für den Link, ich kannte ihn noch nicht. Aber selbst wenn ich meinen Header manuell entferne, klappt es mit GDB nicht. Gibt es irgendwo ein funktionierendes Beispiel, wo jemand ein Binary mit GDB debuggt? Ich finde immer nur solche, wo jemand einen beispielhaften C-Code schreibt und dann erklärt, mit welchen Parametern man GCC aufruft, damit man komfortabel mit Symbolen debuggen kann... Genau das brauche ich aber nicht.
Nachtrag: Im Grunde so wie hier http://www.mikrocontroller.net/articles/GCC_M68k. Nur ist das eben auch wieder vom Source-Code zum Debugger - und nicht umgekehrt vom Binärcode dorthin.
Du brauchst gar kein Disassembly und auch kein Image. Disassemblieren kann jeder Debugger selber. Einfach mit dem Target connecten, PC setzen und Single-steppen. Es gibt auch ein vernünftiges GDB Manual, das Du nützlicherweise mal studieren solltest.
Tsca k schrieb: > Einfach mit dem Target connecten, PC setzen und Single-steppen. ... das ist bei m68k unter Umständen nicht ganz so einfach wie heutzutage ...
... wenn es sich allerdings (was ich aufgrund von BD32 vermute) um einen 683xx handelt, dann hat der ein BDM interface. Und das wiederum wird hier: https://sourceforge.net/projects/bdm/ bestens unterstützt (nicht die tar-files runterladen, sondern aus git latest holen, das funzt).
Markus F. schrieb: > m68k-elf-objdump -D -b binary --architecture m68k:68000 <raw > binary> > Das klappt wunderbar! Vielen Dank! (Zu meiner Schande muss ich eingestehen, dass die möglichen Architekturen nach Aufruf von "objdump --help" ja aufgeführt werden - das hatte ich gestern komplett übersehen.) Der nächste Schritt wäre jetzt, dieses Disassembly in GDB zu laden. Als ich gestern das Binary laden wollte, sagte er mir "not in executable format", was ich verstehen konnte. Aber wenn ich jetzt das Disassembly lade, sagt er mir das Gleiche!? Markus F. schrieb: > Allerdings ist da noch etwas Arbeit und Hirnschmalz reinzustecken. Das > raw binary hat keine Section-Informationen mehr und der Disassembler > kann zwischen Code und Daten nicht unterscheiden. Ich schätze mal, das hier ist der benötigte Trick, oder? Oder bin ich mit dem Disassembly auf dem Holzweg? Wie erzeuge ich denn eine Datei, die ich mit gdb laden kann? GDB erwartet eine ELF Datei, oder? Dann muss ich vielleicht doch "objcopy" verwenden, so wie im Link von Beitrag von klausr? Damit bekomme ich eine Datei, die GDB ohne Fehlermeldung schluckt. Der Befehl "x/i <address>" klappt auch. Und den BDM Treiber (Prozessor ist eine CPU32) muss ich ja auch noch irgendwie laden. Puh, ich stehe gerade wie ein Ochs vorm Berg.
Nachtrag: Die Readme in den "BDM Tools" beziehen sich immer auf Linux. Das macht es für mich als Klicki-Bunti Windows Benutzer auch nicht unbedingt einfacher. Ist das Ganze überhaupt unter Windows lauffähig?
Alternativ mal das Image mit radare2 öffnen: http://rada.re/r/ (Achtung: Bedienung noch kryptischer als bei gdb :-)
>Ich schätze mal, das hier ist der benötigte Trick, oder? Oder bin ich >mit dem Disassembly auf dem Holzweg? Ja. Hab' ich Dir gestern schon gesagt. Liest Du auch die Antworten?
Steffen Hausinger schrieb: > Der nächste Schritt wäre jetzt, dieses Disassembly in GDB zu laden. Als > ich gestern das Binary laden wollte, sagte er mir "not in executable > format", was ich verstehen konnte. Aber wenn ich jetzt das Disassembly > lade, sagt er mir das Gleiche!? Du kannst kein Disassembly in gdb laden. gdb ist ein Debugger, kein Assembler (und schon gar kein Simu-/Emulator). Um mit gdb etwas Sinnvolles anzustellen, brauchst Du dein Binary auf dem Target und eine Verbindung dazu. Wenn das funktioniert, kannst Du gdb das Binary auf dem Target im Einzelschrittmodus ausführen lassen und dazwischen die Register- und Memoryinhalte auslesen. Genau das machen die oben verlinkten bdm-tools für den m68k (ob man die z.B. mit cygwin auf Windows zum Laufen bringen kann, weiß ich nicht). Möglicherweise brauchst Du das aber gar nicht. Es gibt kaum einfacher zu verstehenden Assemblercode als den der m68k-Familie. Setz' dich mit Papier und Bleistift vor dein Disassembly und mach' "Debugging zu Fuß". So hat man das früher auch gemacht. Mit genug Übung brauchst Du gar keinen Disassembler mehr. Was soll überhaupt das Ziel der ganzen Aktion sein?
Beim GDB kann man doch auch als target nen eingebauten Simulator nehmen "target sim" Ansonsten das Binary mal in einen QEMU oder sonstigen Simulator reinladen und dann per GDB drauf zugreifen?
Mw E. schrieb: > Beim GDB kann man doch auch als target nen eingebauten Simulator nehmen > "target sim" > ... wenn man auf einer Plattform sitzt, die so was unterstützt. CPU32 gehört da nach meiner Kenntnis nicht dazu. > Ansonsten das Binary mal in einen QEMU oder sonstigen Simulator > reinladen und dann per GDB drauf zugreifen? ... einen QEMU für CPU32 zu finden dürfte auch nicht ganz einfach sein.
Ich bin seit gestern Abend dabei, die BDM Tools bei mir zum Laufen zu bringen. Bisher noch erfolglos. Ich wollte Euch trotzdem Rückmeldung geben und mich natürlich für Euren Rat bedanken! Tsca k schrieb: > Ja. Hab' ich Dir gestern schon gesagt. Liest Du auch die Antworten? Natürlich tue ich das. Du hast beispielsweise geschrieben: "Einfach mit dem Target connecten, PC setzen und Single-steppen." Genau das ist aber Quatsch. "Einfach" ist es für Leute, die sich auskennen oder bei denen eines der zahlreichen Tutorials passt. Das ist bei mir nicht so. Diese Antwort war daher, genau wie Deine letzte leider auch, überhaupt nicht hilfreich und ich habe sie dementsprechend beachtet. Markus F. schrieb: > Was soll überhaupt das Ziel der ganzen Aktion sein? Ich möchte den Code verstehen und später anpassen. Kein debugging. Ich habe ~100 kB Programmcode, die ich (in monatelanger Handarbeit) in Pseudo-C decompiliert habe. Jetzt bin ich bei der Interpretation. Bis zur der Treiberschicht bin ich auch gut voran gekommen. Jetzt wird es aber so komplex, dass ich einfach nicht mehr weiterkomme. Ich finde einfach keinen Bezugspunkt mehr, ab dem ich mich weiterhangeln kann.
Es gibt einen Qemu für m68k, den müsstest du mit einem m68k-gdb als Simulator verknoten können. Vielleicht hilft das ja.
>Natürlich tue ich das. Du hast beispielsweise geschrieben: "Einfach mit >dem Target connecten, PC setzen und Single-steppen." Genau das ist aber >Quatsch. "Einfach" ist es für Leute, die sich auskennen oder bei denen >eines der zahlreichen Tutorials passt. Wenn Du Schwierigkeiten hast, den GDB an das Target anzuschliessen, musst Du das auch so beschreiben. Das hat mit Deinem so unsinnigen wie verzweifelten Versuch aus einem Binary ein debugbares Image zu erzeugen gar nix zu tun! Der GDB braucht ein Image nur, um Zugriff auf den Sourcecode und die Symbole zu haben. Da Du aber keinen Sourcecode hast... >Das ist bei mir nicht so. Diese >Antwort war daher, genau wie Deine letzte leider auch, überhaupt nicht >hilfreich und ich habe sie dementsprechend beachtet.
Tsca k schrieb: > Der GDB braucht ein Image nur, um Zugriff auf den Sourcecode und die > Symbole zu haben. Da Du aber keinen Sourcecode hast... ...kann er auch gleich mit rarade2 loslegen. Das ist nämlich genau dafür gemacht.
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.