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.
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.
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?
>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.
>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.
