Wie kann ich eine .exe Datei in Maschinensprache betrachten ?

Tail11Gunner

Hi,

bin noch ziemlicher Anfänger würde gerne wissen wie das aussieht was mein Compiler erzeugt. Soweit ich weis bedeutet das kompilieren einer Datei die Umwandlung von Hochsprachen Code in Maschinensprache, die von der jeweiligen Maschine ausgeführt werden kann.

Danke schonmal

MS Visual c++ 10
Win xp

Nobuo T

Wenn du das echte Zeug sehen willst -> mit Hexeditor oeffnen. Nach den ersten paar 100 Byte kommt dann irgendwo der Maschinencode. Kannst du aber sehr wahrscheinlich nichts mit anfangen.
Fuer die menschenlesbare Form (Assembler) gibt es Disassembler oder Debugger.
Zumindest letzteres incl. Disassembly muesste auch das VS mitbringen. Starte auf einem deiner Programme mal Debugging. Dann muesstest du irgendwo auch die Option haben, dir den Assemblercode anzeigen zu lassen ("Disassembly").
Alternativ benutze einen Debugger wie z.B. OllyDbg.

Bashar

Wenn du nur wissen willst, was dein Compiler ausgibt, brauchst du nicht unbedingt die fertige exe zu disassemblieren. Die meisten Compiler haben eine Option, mit der sie zusätzlich zu den Objektfiles ein Assemblerlisting ausgeben. Beim MSVC heißt die sinnigerweise "Generate Assembly Listing".

*rant*

Wenn es dein eigenes Programm ist: Beim MSVC kannst du auch einen Breakpoint setzen und dann den Disassembler zuschalten. Dann siehst du den produktiven Code praktisch live disassembliert. Das sollte in beschränktem Umfang auch im Release Modus funktionieren und hilft, wenn du nur eine kleine Funktion anschauen willst. Dann musst du dich nicht durch ganze Assembly Files kämpfen

MfG

bastl

Ich glaube der .exe debugger Befehl heißt debug.
Damit kannst du auch assembler programmieren.
.exe ist komplizierter aber .com fängt bei 100 an.

OllyDebugger, Immunity Debugger, IDA Pro, Soft ICE

Nimm einfach den Immunity Debugger.
- Ist Kostenlos
- Hat von Haus aus das Graph Plugin
- Hat von Haus aus colored Syntax
- Ist einfacher zu bedienen als IDA Pro (IDA Pro hat auch alles diesen kram ich glaub die kostenlose Version hat auch diesen Graph View kram (Ist ganz praktisch)

nachtfeuer

Ich würde vorschlagen, erstmal die intergrierten Werkzeuge vom Visual Studio zu nutzen, Debugger, Disassembler, Profiler usw.
Wenn man mehr sehen will, also den ganzen Execode inclusive Header und mitgeschleppte Bibliothek usw., dann muss man sich einen Hexeditor zu Anschauen schreiben.

In Windows xp steht das Windowsinterne(bis 32 Bit) Systemwerkzeug "debug" zur Verfügung. Debug ist eine Assemblerentwicklungsumgebung(mit Assembler) für 16 Bit, aber der Hexcode bleibt ja der gleiche, kann man also für Hexediting und Assemblerlernen mißbrauchen(und man kann auch kleine 64/256 Bit Programme mit Debug schreiben bzw. 128 Bit SSE programme für 32Bit). Aber es gibt auch einen sehr guten Debug-Clone für 32 Bit von Paul Vojta
http://math.berkeley.edu/~vojta/
den hatte er für das OS Free Dos geschrieben.

Versuch aber erstmal zu gucken, wie weit du mit den VS Tools kommst, und schreib den Hexeditor selber.

nachtfeuer schrieb:

(bis 32 Bit) Systemwerkzeug "debug" zur Verfügung. Debug ist eine Assemblerentwicklungsumgebung(mit Assembler) für 16 Bit, aber der Hexcode bleibt ja der gleiche, kann man also für Hexediting und Assemblerlernen mißbrauchen(und man kann auch kleine 64/256 Bit Programme mit Debug schreiben bzw. 128 Bit SSE programme für 32Bit).

Da hast du wohl mal wieder einen Troll-Anfall erlitten

EOP

Tail11Gunner schrieb:

Hi, bin noch ziemlicher Anfänger...

nachtfeuer schrieb:

... und schreib den Hexeditor selber.

Das ist ja mal ein suuuper Tip für einen Anfänger.

nachtfeuer

masm schrieb:

nachtfeuer schrieb:

(bis 32 Bit) Systemwerkzeug "debug" zur Verfügung. Debug ist eine Assemblerentwicklungsumgebung(mit Assembler) für 16 Bit, aber der Hexcode bleibt ja der gleiche, kann man also für Hexediting und Assemblerlernen mißbrauchen(und man kann auch kleine 64/256 Bit Programme mit Debug schreiben bzw. 128 Bit SSE programme für 32Bit).

Da hast du wohl mal wieder einen Troll-Anfall erlitten

Nein, jetzt habe eher ich einen Lachanfall erlitten. Geht deine panische Angst vor Dos/16 Bit nicht ein bißchen weit, wenn sie schon anfängt, die Wahrnehmung oder das Assembler Grundwissen zu verzerren?

@EOP
Ein Hexeditor setzt sich aus mehreren einfachen Elementen zusammen, die zum Grundwissen der Programmierung gehören. Der Hexeditor ist schnell geschrieben und darüberhinaus recht nützlich, also eine sehr praktische (begleitende) Anfängeraufgabe.

nachtfeuer schrieb:

Nein, jetzt habe eher ich einen Lachanfall erlitten. Geht deine panische Angst vor Dos/16 Bit nicht ein bißchen weit, wenn sie schon anfängt, die Wahrnehmung oder das Assembler Grundwissen zu verzerren?

- "Debug ist eine Assemblerentwicklungsumgebung"
- "[...]256 Bit Programme mit Debug schreiben bzw. 128 Bit SSE programme[...]"

nachtfeuer

Dass man daraus so ein Theater machen muss, wirkt merkwürdig. Willst du vorgeben, du wüßtest nicht, wie das geht? Oder weiß du es nicht besser? Mal angenommen, du weißt es nicht besser, könnte sein, dann könnte man in etwa so anfangen:

C:\Users\nachtfeuer>debug
-a
1A04:0100 dw 0
1A04:0102 dw 0
1A04:0104 db 0
1A04:0105 mov ax,1
1A04:0108 dw 0
1A04:010A mov bx,200
1A04:010D dw 0
1A04:010F mov cx,16
1A04:0112 dw 0
1A04:0114 db "hallo",24
1A04:011A
-d 100
1A04:0100  00 00 00 00 00 B8 01 00-00 00 BB 00 02 00 00 B9   ................
1A04:0110  16 00 00 00 68 61 6C 6C-6F 24 00 00 34 00 F3 19   ....hallo$..4...
1A04:0120  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A04:0130  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A04:0140  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A04:0150  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A04:0160  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
1A04:0170  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
-

Man kann dann z.B., um Daten zu füllen, statt Assemblerdirektiven direkt Assemblerbefehle benutzen. Und wie oben gezeigt, kann man Platzhalter für Maschinenbefehle wie movdqa xmm0,[Word](z.B. = 0F6F061401) benutzen. Man muß allerdings darauf achten, die Operandengrößen-Präfixe richtig zu setzen.

Fassen wir doch mal Zusammen: Debug ist keine Entwicklungsumgebung (wie der Name schon impliziert) und man kann damit weder 32 noch 64 Bit Programme schreiben, geschweigen den das man damit irgendwelche SIMD Befehlsätze benutzen kann.
Es ist lächerlich beim eingeben beim opcodes von Programmieren zu reden!
Und ganz neben bei, debug.exe war und ist ganz sich kein Windows-internes Systemwerkzeug - es ist ein Überbleibsel aus DOS Zeiten.

nachtfeuer

Lächerlich ist allenfalls zu sehen wie du versuchst, anderen Leuten einzureden, was geht, und was nicht. Lächerlich sind die Versuche, Grundlagen Know How zu negieren. Es kommt der Verdacht auf, das geschieht nur um entweder A: Von gewissen Wissenslücken abzulenken, oder B: um lediglich herumzuprollen oder zu trollen.

Und du brauchst hier auch gar nicht groß mit Smilies und Emoticons um dich werfen, um zu versuchen, (in Richtung Offtopic) Stimmung zu machen. Letztlich vermute ich mal, du hast gar keine andere Zielsetzung. Und das nennt man, glaube ich, trollen.

Nobuo T

Bleibt mal friedlich Jungs...

...
dennoch muss ich hier masm ausnahmsweise zustimmen: debug ist ein olles DOS-Relikt, das man nach landlaeufiger Definition nicht ernsthaft als "Entwicklungsumgebung" bezeichnen kann und bestenfalls die gleiche "Unterstuetzung" fuer auch nur annaehernd als aktuell zu betrachtende Befehlssaetze des x86 bietet wie jeder 0815-Hexeditor auch.

...Wie hing das nun noch gleich mit der Ursprungsfrage zusammen? Nur marginal... Da die "Diskussion" ohnehin keinen Wert hat, denke ich, die Sache ist damit erledigt.

nachtfeuer

Letztlich ist das eine Meinung. masm dabei zu bestärken, unsachlich und offtopic herumzuprollen, ist nicht gerade der Sinn eines Forenmoderators.
Wenn man anfängt mit dem Programmieren, braucht man Editor + Compiler, eventuell einen Debugger und einen Disassembler oder einen Linker. Debug hat Asminterpreter, Asmeditor, Compiler, (Linker...?)Debugger, Disassembler, Assembler zum Speicherfüllen, Rip-Mode und einiges mehr, und man kann Programme und Assembleralgorithmen damit entwickeln. Und debug ist nun mal bei allen Windowsversionen bis 32 Bit mit an Board.
Ob oll oder nicht, das spielt hier tatsächlich keine Rolle.

Nobuo T

Wer hier trollt ist Ansichtssache (im Zweifel erstmal meine Ansicht ) und was hier der Sinn eines Moderators ist, lass mal meine Sorge sein. Weitere Diskussion ab vom Thema werde ich ab jetzt kommentarlos entfernen.

nachtfeuer

Du Scherzkeks.
Eigentlich wurde die Frage des TEs schon ausreichend bis üppig beantwortet. Man könnte den Thread also schließen und ab {unsachlich offtopic} alle Postings löschen. Nun, und wäre ich Moderator und hätte die Einstellung, dass Dos alter vergammelter Quark ist und debug eine miese müffelnde Mumie, nun, dann wüßte ich schon, welchen Beitrag ich noch..., so ganz versehentlich... Huch!?

volkard

Tail11Gunner schrieb:

bin noch ziemlicher Anfänger würde gerne wissen wie das aussieht was mein Compiler erzeugt.

Tail11Gunner schrieb:

MS Visual c++ 10
Win xp

Dazu mach Folgendes:
Geh mit dem Cursor auf die interessante Stelle.

Drück Strg+F10.
Das compiliert und bindet bei Bedarf Dein Programm, setzt auf der Cursorposition einen Breakpoint, startet den Debugger, startet darin Dein Programm, und wenn das Programm endlich auf den Breakpoint läuft, wird es angehalten und der Breakpoint automatisch entfernt.

Drück Alt+F8.
Das zeigt im Debugger den Assemblercode an, der zu Deinem Sourcecode gehört.

Das sieht dann ungefähr so aus:
http://img830.imageshack.us/img830/654/asmx.png
Also immer die C++-Zeile und drunter der daraus entstandene (und disassemblierte) Maschinencode. Hier (im Debugmodus) haut er gerne Variablen in den Speicher. Viel Aussagekraft hat das dann nicht, wenn man abschätzen mag, wie schnell sich was anfühlt.

Manchmal wird die Zuordnung von C++ zu Maschinencode ein wenig durcheinandergewürfelt, weil der Compiler Optimierungen macht. Das ist normal, anfangs verwirrend, und kein Bug.

Im Release-Modus wird übrigens das hier draus:
http://img846.imageshack.us/img846/1121/asm2.png

Wie man sieht, liegt i in EAX.

xor ecx,ecx setzt ECX auf 0. ECX ist also s.

Außerdem hat der Optimierer die Schleife vierfach entrollt.
Also

int s=0;
for(int i=0;i<=100;i+=4){
   s+=i;
   s+=i+1;
   s+=i+2;
   s+=i+3;
}

draus gemacht. Schlauer Compiler.

Das nop dient dazu, daß das Spungziel auf einer gut ausgerichteten Adresse liegt. Das könnte den Sprung beschleunigen. Netter Compiler.

Im Prinzip schau immer nur den Release-Code an.

Zum Vergleich: gcc macht frecherweise das da draus:
(Achtung, AT&T-Syntax: mov und Konsorten tragen einen Postfix, der den Typ angibt, "movl" heißt "move long", außerdem sind bei zwei Parametern die Parameter vertauscht)

movl	$5050, %esi
	movl	$_ZSt4cout, %edi
	call	_ZNSolsEi

abc.w

volkard schrieb:

Zum Vergleich: gcc macht frecherweise das da draus:
(Achtung, AT&T-Syntax: mov und Konsorten tragen einen Postfix, der den Typ angibt, "movl" heißt "move long", außerdem sind bei zwei Parametern die Parameter vertauscht)
movl	$5050, %esi
	movl	$_ZSt4cout, %edi
	call	_ZNSolsEi

Die komischen Zeichen "$_ZSt4cout" und "_ZNSolsEi" lassen sich mit dem Tool c++filt "filtern". Interessanterweise, ich bin grade unter Windows und nutze mingw 3.4.5, musste ich zwei Unterstriche setzen, damit c++filt lesbare Strings liefert:
D.h. aus diesem Code:

movl	$5050, %esi
	movl	$__ZSt4cout, %edi
	call	__ZNSolsEi

wird mit c++filt das hier:

movl    $5050, %esi 
     movl    std::cout, %edi 
     call    std::basic_ostream<char, std::char_traits<char> >::operator<<(int)

und das ist in C++ so was hier:

cout << 5050;

abc.w

volkard schrieb:

int s=0;
for(int i=0;i<=100;i+=4){
   s+=i;
   s+=i+1;
   s+=i+2;
   s+=i+3;
}

Darf ich fragen, warum Du keine Leerzeichen benutzt Wenn keine Leerzeichen und so einfache Schleife, warum dann nicht gleich so:

int s=0;
for(int i=0;i<=100;s+=i,s+=i+1,+=i+2,s+=i+3,i+=4);

man hat damit dem Compiler einen ganzen Block mit Leerzeichen gespart... und - damit es noch mehr hackermäßig aussieht - gleich das hier einbauen für gcc:

int s=0;
for(int i=0;__builtin_expect(i<=100,true);s+=i,s+=i+1,+=i+2,s+=i+3,i+=4);