Unterschied Debugger - Disassembler

[Ernst Baumann]

Hallo allerseits
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]

Post by Ernst Baumann
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_.

[...]

Post by Ernst Baumann
a)
Wenn man z.B. mit dem Turbodebugger (habe ich unter DOS-Zeiten schon
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.

Post by Ernst Baumann
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.

Post by Ernst Baumann
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

[Ernst Baumann]

Post by 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 ?

Post by Stefan Reuther
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.

Doch, siehe (***)

Post by Stefan Reuther
Aber ein Debugger "wie Turbo Debugger" ist definitiv möglich.

Post by Ernst Baumann
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.

Post by Stefan Reuther

Post by Ernst Baumann
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.

Brauch ich(siehe (***)) jetzt eigentlich aber nicht mehr, oder ?

mfg
Ernst

[Stefan Reuther]

Post by Ernst Baumann

Post by 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

[Sebastian Biallas]

Post by Ernst Baumann
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/

[Spiro Trikaliotis]

Post by Sebastian Biallas

Post by Ernst Baumann
Kennt jemand ein gutes, kostenloses Tool, um Programme zu analysieren
(das nicht nur eine bestimmte Frist, z.B. 30 Tage lang funktioniert)?

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.

[Heiko Nocon]

Post by Ernst Baumann
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.

Post by Ernst Baumann
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.

Post by Ernst Baumann
Mir wurde gesagt, dass man "einen Prozess der nicht mehr im Speicher
liegt auch nicht mehr debuggen, aber disassemblieren kann".

Man disassembliert schlicht nicht das Programm im Arbeitsspeicher,
sondern das Binärimage des Programmes auf der Platte. Sprich: die
*.exe-Datei.

Post by Ernst Baumann
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.

Post by Ernst Baumann
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]

Post by Heiko Nocon
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.

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

[Ernst Baumann]

Post by Heiko Nocon

Post by Ernst Baumann
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.

ich habe wenig Erfahrung und mit "analysieren" wollte ich nicht das
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.

Post by Heiko Nocon

Post by Ernst Baumann
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.

Ich habe jetzt entdeckt (siehe Posting an Stefan), das es auch mit MS
VC++ Vers. 6.0 geht.

Post by Heiko Nocon

Post by Ernst Baumann
Mir wurde gesagt, dass man "einen Prozess der nicht mehr im Speicher
liegt auch nicht mehr debuggen, aber disassemblieren kann".

Man disassembliert schlicht nicht das Programm im Arbeitsspeicher,
sondern das Binärimage des Programmes auf der Platte. Sprich: die
*.exe-Datei.

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

Post by Heiko Nocon

Post by Ernst Baumann
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 ?
mfg
Ernst

[Heiko Nocon]

[...]

Post by Ernst Baumann
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.

Post by Ernst Baumann
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.

[Ernst Baumann]

Post by Heiko Nocon

Post by Ernst Baumann
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.

Post by Ernst Baumann
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.

Ok.
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
(habe dort z.B. eine paar Befehle des newsreaders agent.exe
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]

Post by Ernst Baumann
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.

Post by Ernst Baumann
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]

Post by Ernst Baumann
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.

Post by Ernst Baumann

Post by Heiko Nocon

Post by Ernst Baumann
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.
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.

[Stefan Reuther]

Post by Martin Wodrich
Und btw: Eines der wichtigsten Unterschiede zwischen einem
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]

Post by Martin Wodrich
Man sagt disassembliert.
Und btw: Eines der wichtigsten Unterschiede zwischen einem
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.

Was sind Rateroutinen ?
Welchen Sinn haben sie ?

mfg
Ernst

[Martin Wodrich]

Post by Ernst Baumann

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.

Post by Ernst Baumann
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).