Unterschied Debugger - Disassembler
Ernst Baumann
Eigentlich will ich was ganz einfaches:
1)
Analysieren, was irgendeine exe-Datei macht.
Mit MS VC++ Vers. 6.0 kann ich zwar ein exe-Programm im Maschinencode
anschauen und schrittweise ablaufen lassen, doch muss die exe-Datei
mit MS VC++ Vers. 6.0 erstellt worden sein, d.h, durch Compilierung
des C++ Programms.
2)
Man kann zwar in MS VC++ Vers. 6.0 jeden Prozess (mit dem Debugger
debuggen: Start >Debug -> Attach to Process), doch das geht aber nur,
wenn dieser Prozess noch _läuft_.
Wenn ich aber ein Programm schreibe, das z.B. nur "Hallo Welt" ausgibt
und dann beendet wird, kann ich dies nicht debuggen.
Mir wurde gesagt, dass man "einen Prozess der nicht mehr im Speicher
liegt auch nicht mehr debuggen, aber disassemblieren kann".
Das verstehe ich nicht:
a)
Wenn man z.B. mit dem Turbodebugger (habe ich unter DOS-Zeiten schon
mal gemacht), ein Programm startet, also z.B:
td mytest.exe
dann war ich überzeugt, dass mytest.exe in den Arbeitsspeicher geladen
wird und das Programm dann auch jeweils durch Tastendruck F10 (glaube
ich) schrittweise abgearbeitet wird, oder täusche ich mich da ?
Ich kann mir ein anderes Szenario gerade nicht vorstellen (oder wird
da nur simuliert) ?
b)
Kann ich mit MS VC++ Vers. 6.0 (oder anderen Produkten diese
Produktreihe) nicht _disassemblieren_ ?
Wenn nicht, welchen Sinn soll das haben ?
3)
Kennt jemand ein gutes, kostenloses Tool, um Programme zu analysieren
(das nicht nur eine bestimmte Frist, z.B. 30 Tage lang funktioniert) ?
mfg
Ernst
Stefan Reuther
> 2)
> Man kann zwar in MS VC++ Vers. 6.0 jeden Prozess (mit dem Debugger
> debuggen: Start >Debug -> Attach to Process), doch das geht aber nur,
> wenn dieser Prozess noch _läuft_.
> a)
> Wenn man z.B. mit dem Turbodebugger (habe ich unter DOS-Zeiten schon
> mal gemacht), ein Programm startet, also z.B:
> td mytest.exe
> dann war ich überzeugt, dass mytest.exe in den Arbeitsspeicher geladen
> wird und das Programm dann auch jeweils durch Tastendruck F10 (glaube
> ich) schrittweise abgearbeitet wird, oder täusche ich mich da ?
Der Turbo Debugger macht das tatsächlich so. Prinzipiell ist das auch
mit modernen Betriebssystemen möglich. Es funktioniert nur anders.
Unter DOS war das ja einfach. Ein .exe-Parser ist eine Bildschirmseite
Code, und dank fehlendem Speicherschutz kann man das Ding auch mal eben
schnell laden. Unter Windows brauchst du Betriebssystemfunktionen dazu.
Du musst beim Erstellen des Prozesses dazusagen, dass du ihn debuggen
willst. Wenn VC6 diese Funktion nicht bietet, kannst du sie eben nicht
nutzen. Aber ein Debugger "wie Turbo Debugger" ist definitiv möglich.
> b)
> Kann ich mit MS VC++ Vers. 6.0 (oder anderen Produkten diese
> Produktreihe) nicht _disassemblieren_ ?
Doch. Es gibt definitiv ein Disassembler-Fenster, frag mich aber nicht, wo.
> 3)
> Kennt jemand ein gutes, kostenloses Tool, um Programme zu analysieren
> (das nicht nur eine bestimmte Frist, z.B. 30 Tage lang funktioniert) ?
Such mal nach ida37fw.zip.
Stefan
Sebastian Biallas
> 3)
> Kennt jemand ein gutes, kostenloses Tool, um Programme zu analysieren
> (das nicht nur eine bestimmte Frist, z.B. 30 Tage lang funktioniert) ?
Wenn's nicht ganz so bunt sein muss:
http://hte.sourceforge.net/
--
Gruß,
Sebastian
Heiko Nocon
>Eigentlich will ich was ganz einfaches:
>1)
>Analysieren, was irgendeine exe-Datei macht.
Das ist alles andere als einfach. Es gehört eine Menge Erfahrung dazu,
Programme zu analysieren, von denen man nur das Binary hat. Man muß
nicht nur gute Assemblerkenntnissen haben, sondern auch die Architektur
des ausführenden Betriebsystems ziemlich gut kennen.
>Mit MS VC++ Vers. 6.0 kann ich zwar ein exe-Programm im Maschinencode
>anschauen und schrittweise ablaufen lassen, doch muss die exe-Datei
>mit MS VC++ Vers. 6.0 erstellt worden sein, d.h, durch Compilierung
>des C++ Programms.
Das stimmt nicht. Man muß sich nur ein kleines Starterprogramm
schreiben, dann kann man mit dem Debugger von VC6 auch fremde Programme
debuggen. Das ist schon das erste Beispiel für das, was ich oben
schrieb. Man muß nämlich das Win32-API beherschen, um die für das
Starterprogramm nötigen Mechanismen überhaupt erstmal zu kennen und
zweitens sinnvoll einsetzen zu können.
>Mir wurde gesagt, dass man "einen Prozess der nicht mehr im Speicher
>liegt auch nicht mehr debuggen, aber disassemblieren kann".
>Das verstehe ich nicht:
Man disassembliert schlicht nicht das Programm im Arbeitsspeicher,
sondern das Binärimage des Programmes auf der Platte. Sprich: die
*.exe-Datei.
>Kann ich mit MS VC++ Vers. 6.0 (oder anderen Produkten diese
>Produktreihe) nicht _disassemblieren_ ?
Doch. Aber eben nur den Code, der sich im Arbeitsspeicher befindet.
>Kennt jemand ein gutes, kostenloses Tool, um Programme zu analysieren
>(das nicht nur eine bestimmte Frist, z.B. 30 Tage lang funktioniert) ?
Im Nasm-Paket findet sich auch ein Disassembler, allerdings ein sehr
rudimentärer. Um damit effizient reverse engineering betreiben zu
können, muß man erstmal einen ganzen Haufen Zeug drumrum programmieren.
TS
>Programme zu analysieren, von denen man nur das Binary hat. Man muß
>nicht nur gute Assemblerkenntnissen haben, sondern auch die Architektur
>des ausführenden Betriebsystems ziemlich gut kennen.
Nicht zu vergessen, die Struktur typischer kompilierter Programme
(Stack-Frames, Sprungtabellen, Alignment-Füllbytes, Layout von Code
und Daten) und die Handhabung von dynamisch ladbaren und relozierbaren
Programmteilen...
Spiro Trikaliotis
> Ernst Baumann wrote:
>> Kennt jemand ein gutes, kostenloses Tool, um Programme zu analysieren
>> (das nicht nur eine bestimmte Frist, z.B. 30 Tage lang funktioniert)?
>
> Wenn's nicht ganz so bunt sein muss:
> http://hte.sourceforge.net/
... oder auch bei MS selbst:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Für den Anfänger vielleicht etwas gewöhnungsbedürftig, aber sehr
leistungsfähig und erweiterbar (mit "Plugins", sogenannten "Debugger
Extensions").
Gruß,
Spiro.
--
Spiro R. Trikaliotis http://cbm4win.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
Ernst Baumann
>
>Ein .exe-Parser ist eine Bildschirmseite Code,
>
"Ein .exe-Parser ist eine Bildschirmseite Code"
Was meinst du damit ?
>
>und dank fehlendem Speicherschutz kann man das Ding auch mal eben
>schnell laden. Unter Windows brauchst du Betriebssystemfunktionen dazu.
>Du musst beim Erstellen des Prozesses dazusagen, dass du ihn debuggen
>willst. Wenn VC6 diese Funktion nicht bietet, kannst du sie eben nicht
>nutzen.
>
>Aber ein Debugger "wie Turbo Debugger" ist definitiv möglich.
>
>
>> b)
>> Kann ich mit MS VC++ Vers. 6.0 (oder anderen Produkten diese
>> Produktreihe) nicht _disassemblieren_ ?
>
>Doch. Es gibt definitiv ein Disassembler-Fenster, frag mich aber nicht, wo.
>
Du hast recht.
Nachdem ich dein Posting gelesen habe, habe ich es nochmals probiert:
Datei öffnen --- Erstellen --- Debug straten -- In Aufruf springen
Ich habe dies desdwegen nicht geschafft, da ich bei Öffen im Modus
bisher immer "binär" geöffent habe. Dank deiner Hilfe klappt es jetzt,
super.
>
>> 3)
>> Kennt jemand ein gutes, kostenloses Tool, um Programme zu analysieren
>> (das nicht nur eine bestimmte Frist, z.B. 30 Tage lang funktioniert) ?
>
>Such mal nach ida37fw.zip.
>
mfg
Ernst
Ernst Baumann
>>Analysieren, was irgendeine exe-Datei macht.
>
>Das ist alles andere als einfach. Es gehört eine Menge Erfahrung dazu,
>Programme zu analysieren, von denen man nur das Binary hat. Man muß
>nicht nur gute Assemblerkenntnissen haben, sondern auch die Architektur
>des ausführenden Betriebsystems ziemlich gut kennen.
>
Maul recht voll nehmen, sondern einfach mal prinzipiell testen, ob es
einfach ist, in einem Programm festszustellen, ob dort z.B. mit strcpy
nicht reservierter Speicher überschrieben wird.
Wenn ich z.B. in einem ganz einfachen, seblstgeschriebenen C-Programm
mit strcpy(lok1, lok2) nicht reservierten Speicher überschreibe, und
dann nachher dieses debugge und mit Ansicht ---Debugfenster ---
Disassembler durchgehe, wird mir die Stelle, wo strcpy(lok1, lok2)
gemacht wird, auch in der Tat durch die symbolische Überschrift
strcpy(lok1, lok2) auch angezeigt. Deswegen kann man in dieser
Darstellung auch einfach erkennen, dass nicht reservierter Speicher
überschrieben wird. Das geht aber nur, weil ich dieses Programm, in
dem strcpy(lok1, lok2) vorkommt in C (C++) geschrieben habe und sich
dort symbolische Information befindet, die dann der Debugger benutzen
kann.
Aber was passiert, wenn sich in einer exe-Datei keine symbolische
Information befindet ?
Dann muss man einen Disassembler benutzen,
Wie kann man dann dort festsstellen, ob dort z.B. mit strcpy nicht
reservierter Speicher überschrieben wurde ?
Ist dies einfach ? (ich glaube nicht)
Kann man dies überhaupt feststellen ?
Irgendwelche Hacker schaffen es ja auch,
Haben diese dann genügend Erfahrung bzw. was benötigen die an Wissen ?
Bem:
Unter DOS habe ich gelernt, wie ein Mikroprozessor funktioniert. Man
konnte verstehen lernen, wie ein Hardware-Interrupt funktioniert, wie
man mit den Schnittstellen kommuniziert, usw.
Unter Windows läuft die CPU im protected Mode und da ist dann Schluss.
>
>>Mit MS VC++ Vers. 6.0 kann ich zwar ein exe-Programm im Maschinencode
>>anschauen und schrittweise ablaufen lassen, doch muss die exe-Datei
>>mit MS VC++ Vers. 6.0 erstellt worden sein, d.h, durch Compilierung
>>des C++ Programms.
>
>Das stimmt nicht. Man muß sich nur ein kleines Starterprogramm
>schreiben, dann kann man mit dem Debugger von VC6 auch fremde Programme
>debuggen. Das ist schon das erste Beispiel für das, was ich oben
>schrieb. Man muß nämlich das Win32-API beherschen, um die für das
>Starterprogramm nötigen Mechanismen überhaupt erstmal zu kennen und
>zweitens sinnvoll einsetzen zu können.
>
VC++ Vers. 6.0 geht.
>
>>Mir wurde gesagt, dass man "einen Prozess der nicht mehr im Speicher
>>liegt auch nicht mehr debuggen, aber disassemblieren kann".
>>Das verstehe ich nicht:
>
>Man disassembliert schlicht nicht das Programm im Arbeitsspeicher,
>sondern das Binärimage des Programmes auf der Platte. Sprich: die
>*.exe-Datei.
>
Das zu debuggende Programm wird in den _Arbeitsspeicher_ geladen und
dann schrittweise ausgeführt (debuggt).
Das zu disassemblierende Programm, also die exe-Datei wird doch auch
in den _Arbeitsspeicher_ geladen und dann schrittweise ausgeführt
(debuggt, oder sagt man disassembliert ?)
>
>>Kann ich mit MS VC++ Vers. 6.0 (oder anderen Produkten diese
>>Produktreihe) nicht _disassemblieren_ ?
>
>Doch. Aber eben nur den Code, der sich im Arbeitsspeicher befindet.
>
Deswegen:
Was ist der Unterschied zwischen Debuggen und Disassemblieren ?
>
mfg
Ernst
Heiko Nocon
>Ich habe immer noch nicht verstanden, was der Unterschied ist:
[...]
>Das zu disassemblierende Programm, also die exe-Datei wird doch auch
>in den _Arbeitsspeicher_ geladen und dann schrittweise ausgeführt
Nein. Disassemblieren hat nichts mit Ausführen von Code zu tun. Es
bedeutet einfach nur, daß Maschinencode aus irgendeiner Quelle in einer
(halbwegs) menschenlesbare Form ausgegeben wird, nämlich als
Assemblertext.
>Was ist der Unterschied zwischen Debuggen und Disassemblieren ?
Ein Debugger läßt ein Programm unter seiner Kontrolle laufen und liefert
dem Benutzer Informationen über dieses Programm. So eine Information
kann z.B. das Disassemblat des Programmcodes sein. Will ein Debugger dem
Benutzer das liefern, muß er einen Disassembler enthalten, ansonsten
nicht.
Stefan Reuther
>>Unter DOS war das ja einfach.
>>Ein .exe-Parser ist eine Bildschirmseite Code,
>
> "Ein .exe-Parser ist eine Bildschirmseite Code"
> Das habe ich leider nicht verstanden.
> Was meinst du damit ?
Dass der Programmcode, den man benötigt, um eine DOS-.exe-Datei zu
interpretieren und irgendwas nützliches damit anzustellen (zum Beispiel
in den Speicher laden) kaum mehr als eine Bildschirmseite einnimmt.
Stefan
Ernst Baumann
>>in den _Arbeitsspeicher_ geladen und dann schrittweise ausgeführt
>
>Nein. Disassemblieren hat nichts mit Ausführen von Code zu tun. Es
>bedeutet einfach nur, daß Maschinencode aus irgendeiner Quelle in einer
>(halbwegs) menschenlesbare Form ausgegeben wird, nämlich als
>Assemblertext.
>
>>Was ist der Unterschied zwischen Debuggen und Disassemblieren ?
>
>Ein Debugger läßt ein Programm unter seiner Kontrolle laufen und liefert
>dem Benutzer Informationen über dieses Programm. So eine Information
>kann z.B. das Disassemblat des Programmcodes sein. Will ein Debugger dem
>Benutzer das liefern, muß er einen Disassembler enthalten, ansonsten
>nicht.
>
Dann ist es aber auch mit MS VC++ Vers. 6.0 möglich eine reine
exe-Datei nicht nur zu disassemblieren, sondern auf Assemblerebene
(und auf Maschinencodeebene) zu debuggen, nämlich mit:
Datei öffnen --- Erstellen --- Debug straten -- In Aufruf springen
ausgeführt).
Deswegen nochmals meine Frage:
Kann man in einer nicht selbst programmierten exe-Datei (ohne
symbolische Informationen, wie z.B.agent.exe, da ich diese nicht
programmiert habe) ohne weiteres festsstellen, ob dort z.B. mit strcpy
nicht reservierter Speicher überschrieben wurde ?
Ist dies einfach ? (ich glaube nicht)
Kann man dies überhaupt feststellen ?
Irgendwelche Hacker schaffen es ja auch.
mfg
Ernst
Heiko Nocon
>Deswegen nochmals meine Frage:
>Kann man in einer nicht selbst programmierten exe-Datei (ohne
>symbolische Informationen, wie z.B.agent.exe, da ich diese nicht
>programmiert habe) ohne weiteres festsstellen, ob dort z.B. mit strcpy
>nicht reservierter Speicher überschrieben wurde ?
>Ist dies einfach ? (ich glaube nicht)
Ich würde mal so formulieren: Man kann es ohne weiteres feststellen,
wenn man das entsprechende Wissen und Erfahrung beim reverse engineering
hat.
>Irgendwelche Hacker schaffen es ja auch.
Ja. Wobei denen aber meist scheißegal ist, welche Funktion genau da
einen Stack- oder Heapüberlauf zuläßt. Die brauchen erstmal nur das
Auftreten an sich festzustellen, um einen möglichen Einstiegspunkt für
ihre Aktivitäten zu finden. Für sowas gibt es spezialisierte Tools, die
automatisiert nach solchen Schwachstellen suchen können.
Das Disassemblieren kommt bei denen erst dann, wenn sie solche Stellen
gefunden haben.
Martin Wodrich
> Ich habe immer noch nicht verstanden, was der Unterschied ist:
> Das zu debuggende Programm wird in den _Arbeitsspeicher_ geladen und
> dann schrittweise ausgeführt (debuggt).
> Das zu disassemblierende Programm, also die exe-Datei wird doch auch
> in den _Arbeitsspeicher_ geladen und dann schrittweise ausgeführt
> (debuggt, oder sagt man disassembliert ?)
Man sagt disassembliert.
Und btw: Eines der wichtigsten Unterschiede zwischen einem
Debugger und einem Disassembler ist:
Der Debugger kann dir durch in die EXE eingebaute Zusatzinformationen
genau den Code deiner Programmiersprache anzeigen, und durch das
schrittweise Ausführen kann man auch sehen, wie sich z.B. Variablen
verändern. Und damit eben ob das gewünschte passiert.
Ein Disassembler führt nichts aus, sondern erstellt nur eine
Rückübersetzung des Maschinencodes nach Assemblertext. Dieses
Ergebnis enthält keinerlei Kommentare oder sonstige Anhaltspunkte.
Diese muß man sich erst durch Nacharbeiten gewinnen.
Dabei können diverse Rateroutinen helfen, es bleibt aber viel
Handarbeit.
>>> Kann ich mit MS VC++ Vers. 6.0 (oder anderen Produkten diese
>>> Produktreihe) nicht _disassemblieren_ ?
>> Doch. Aber eben nur den Code, der sich im Arbeitsspeicher befindet.
> Ja, genau wie beim debuggen: In den Arbeitsspeicher laden.
> Deswegen:
> Was ist der Unterschied zwischen Debuggen und Disassemblieren ?
Ein Debugger führt ein Programm schrittweise aus, und ermöglicht
das Erkennen ob ein Programm wie gewpnscht arbeitet. Ein Disassembler
erstellt nur unkommenentierten Assemblertext.
--
Mit freundlichen Gruessen,
Martin Wodrich
Stefan Reuther
> Und btw: Eines der wichtigsten Unterschiede zwischen einem
> Debugger und einem Disassembler ist:
> Der Debugger kann dir durch in die EXE eingebaute Zusatzinformationen
> genau den Code deiner Programmiersprache anzeigen, und durch das
> schrittweise Ausführen kann man auch sehen, wie sich z.B. Variablen
> verändern. Und damit eben ob das gewünschte passiert.
> Ein Disassembler führt nichts aus, sondern erstellt nur eine
> Rückübersetzung des Maschinencodes nach Assemblertext. Dieses
> Ergebnis enthält keinerlei Kommentare oder sonstige Anhaltspunkte.
> Diese muß man sich erst durch Nacharbeiten gewinnen.
> Dabei können diverse Rateroutinen helfen, es bleibt aber viel
> Handarbeit.
IBTD. Es gibt auch Disassembler mit eingebauten Rate-Routinen, die dir
eine Menge über das Originalprogramm verraten, inkl. Erkennung von
Sprungtabellen, Routinen aus bekannten Laufzeitbibliotheken, Cross-
Referencing, etc.
Der Hauptunterschied zwischen Disassembler und Debugger ist meiner
Meinung nach nicht, welche Symbolinformationen er verwertet, sondern
einfach die Tatsache, dass der Debugger das Programm ausführen und zu
jeder Zeit anhalten kann. Ein Programm, das sich selbst ver-/ent-
schlüsselt (z.B. die beliebten EXE-Packer) kannst du also mit einem
Debugger in Klartext verwandeln. Ein Disassembler sieht da alt aus, wenn
er nicht gerade genau dieses Verschlüsselungsverfahren erkennt und
"off-line" decodieren kann.
Stefan
Ernst Baumann
>Und btw: Eines der wichtigsten Unterschiede zwischen einem
>Debugger und einem Disassembler ist:
>Der Debugger kann dir durch in die EXE eingebaute Zusatzinformationen
>genau den Code deiner Programmiersprache anzeigen, und durch das
>schrittweise Ausführen kann man auch sehen, wie sich z.B. Variablen
>verändern. Und damit eben ob das gewünschte passiert.
>Ein Disassembler führt nichts aus, sondern erstellt nur eine
>Rückübersetzung des Maschinencodes nach Assemblertext. Dieses
>Ergebnis enthält keinerlei Kommentare oder sonstige Anhaltspunkte.
>Diese muß man sich erst durch Nacharbeiten gewinnen.
>Dabei können diverse Rateroutinen helfen, es bleibt aber viel
>Handarbeit.
>
Welchen Sinn haben sie ?
mfg
Ernst
Martin Wodrich
>> Dieses Ergebnis enthält keinerlei Kommentare oder sonstige
>> Anhaltspunkte. Diese muß man sich erst durch Nacharbeiten gewinnen.
>> Dabei können diverse Rateroutinen helfen, es bleibt aber viel
>> Handarbeit.
> Was sind Rateroutinen ?
Heuristiken, die eben versuchen zu erkennen, was ein String
ist u.v.m.
> Welchen Sinn haben sie ?
Den Quelltext lesbarer auszugeben.
Ein Disassembler ohne Rateroutinen (Heuristiken) liefert
ziemouch unlesbares Zeuch (eben Assemblertext ohne Kommentare
oder sonstige Anhaltspunkte für Strukturen).