Frage zu Opcodes und verhalten von OllyDebugger

Rechtsklick -> Search for -> Name in all modules

Dort habe ich dann nach IsDebuggerPresent gesucht und folgendes gefunden:

All names
774B132C ole32 .text Import ( KERNEL32.IsDebuggerPresent

774B132C > 3331                  XOR ESI,DWORD PTR DS:[ECX]           ; <-- da müsste das IsDebuggerPresent sein
774B132E   817C8F BA 807CB100    CMP DWORD PTR DS:[EDI+ECX*4-46],0B17C80
774B1336   837CB5 08 83          CMP DWORD PTR SS:[EBP+ESI*4+8],-7D

Wenn ich jetzt einmal kurz mit dem Mausrad runter scroll (ich hab nur eine Stufe zurück gescrollt)
dann lande ich sofort bei Offset: 774B132A

Also 2 Byte weiter und wenn ich dann wieder 1 Stufe nach oben Scrolle sehe ich folgendes:

774B132A   817C33 31 817C8FBA    CMP DWORD PTR DS:[EBX+ESI+31],BA8F7C81
774B1332   807CB1 00 83          CMP BYTE PTR DS:[ECX+ESI*4],83
774B1337  ^7C B5                 JL SHORT ole32.774B12EE

Ist Etwas in dem Befehl CMP DWORD PTR DS:[EBX+ESI+31],BA8F7C81 der Befehl XOR ESI,DWORD PTR DS:[ECX] "enthalten" ?

CMP DWORD PTR DS:[EBX+ESI+31],BA8F7C81
Opcodes zu dem Befehl: 817C33 31 817C8FBA

XOR ESI,DWORD PTR DS:[ECX] 
Opcodes zu dem Befehl: 3331

Oder wie soll ich das verstehen ?

Und warum sieht es auf einmal anderes aus nachdem ich einmal gescrollt habe ?
Zerlegt der OllyDebugger den Code in mehrere Teile oder so ?

Bei dem CMP DWORD PTR DS:[EBX+ESI+31],BA8F7C81 Befehl ist mir halt aufgefallen das bei den Opcodes 3331 enthalten ist.
817C da ist es >> 33 31 << da ist es 817C8FBA

CMP DWORD PTR DS:[EBX+ESI+31],BA8F7C81
Opcodes zu dem Befehl: 817C33 31 817C8FBA

Ach sry da fehlte ja noch was _{_}

Hallo,

ich habe mit C++ ein Hello World Programm geschrieben und dann mit ASPack gepackt und jetzt wollte ich mal versuchen den OEP (Original Entrypoint) zu finden.

Normalerweise sieht IsDebuggerPresent intern doch so aus:

7C813133 > 64:A1 18000000        MOV EAX,DWORD PTR FS:[18]
7C813139   8B40 30               MOV EAX,DWORD PTR DS:[EAX+30]
7C81313C   0FB640 02             MOVZX EAX,BYTE PTR DS:[EAX+2]
7C813140   C3                    RETN

Aber Olly zeigt mit das hier als IsDebuggerPresent an:
Ich vermute das ist etwas vom ASPack zumal das echte IsDebuggerPresent in der Kernel32.dll enhalten ist. Olly zeigt mir an der Stelle auch das ich in der ole32.dll bin und laut Google hat die auch was mit ASPack zu tun.
Anscheind eine DLL von den ASPack leuten.

774B132C > 3331                  XOR ESI,DWORD PTR DS:[ECX]

Folgendes habe ich zu erst gemacht.( Weiter gehts in meinem ersten Post ... )

OllyDbg listet dir alle Referenzen auf, d.h. auch alle Funktionszeiger – in deinem Beispiel währe die Andresse der Funktion 0x7C813133 (->kernel32.dll), und du befindest dich vermutlich in einer der Import-Tabellen der ole32.dll (OLE)?
Wenn du den Eintrittspunkt finden willst, musst du dich durch den Packer steppen. Allerdings gibt es für die meisten Packer schon fertige Scripte, die dies erledigen (->google).
Alternativ kannst du eine INT3 in deinen Code einfügen, so dass OllyDbg dort hält.

Zum testen:
Rechtsklick -> Search for -> Name in all modules -> funktion auswählen
Rechtsklick -> folow in dump -> selection
Im Dump-Fenster: Rechtsklick -> Long -> Address

Okay aber was macht Olly da wenn ich einmal nur mit dem Mausrad scrolle (steht in meinem ersten Post was ich da genau meine).

newbReverse schrieb:

Okay aber was macht Olly da wenn ich einmal nur mit dem Mausrad scrolle (steht in meinem ersten Post was ich da genau meine).

Wenn du die Adresse aus dem Suchfenster auswählst, wird zunächst einmal davon ausgegangen, dass ab dieser Adresse (Sinnvoller) Code zu finden ist. Wenn du hoch scrollst, wird auch vor der aktuellen Adresse analysiert und festgestellt, das dort ungültige OpCodes vorliegen. Olly verschiebt in einer solchen Situation das Offset solange, bis ein einigermaßen sinnvoller Code-Pfad gefunden wird, bei dem sowohl vor als auch nach der von dir ausgewählten Adresse keine ungültigen OpCodes auftauchen.
Da es sich in deinem Fall aber definitiv nicht um Code handelt, solltest du keine Wunder erwarten.

BTW: Ctrl+A schon mal versucht?: die Import Adressen sollte er dann auch erkennen.

Was sollen den ungültige Opcodes sein ?
Opcodes die die CPU gar nicht kennt ?

Was mir auch mal aufgefallen ist wenn ich z.b. in ein Codecave gehe ein paar Offsets makiere dann Rechtsklicke mache Binary->Edit und da z.b. eingebe: abc
Dann steht danach in Olly:

00401E8D   61               POPAD
00401E8E   6263 00          BOUND ESP,QWORD PTR DS:[EBX]

Wenn ich aber dann CTRL + A drücke dann sehe ich: ASCII "abc",0

Aber wieso zeigt der erst das hier an ?

00401E8D   61               POPAD
00401E8E   6263 00          BOUND ESP,QWORD PTR DS:[EBX]

Btw. kennst du zufällig eine gute Quelle wo man sich genauer über soetwas Informieren kann ?

Btw. weiss jemand ob man mit IDA Pro bzw. IDA Free auch Assembler Befehle ändern kann ?

z.b.

mov eax,29
in mov ebx,4

Bei Olly da reicht ja ein doppelklick auf den Befehl dann kann man schon einen neuen Assembler Befehl einfügen.

newbReverser schrieb:

Was sollen den ungültige Opcodes sein ?
Opcodes die die CPU gar nicht kennt ?

so ist es.

newbReverser schrieb:

Was mir auch mal aufgefallen ist wenn ich z.b. in ein Codecave gehe ein paar Offsets makiere dann Rechtsklicke mache Binary->Edit und da z.b. eingebe: abc
Dann steht danach in Olly:
00401E8D   61               POPAD
00401E8E   6263 00          BOUND ESP,QWORD PTR DS:[EBX]
Wenn ich aber dann CTRL + A drücke dann sehe ich: ASCII "abc",0

Aber wieso zeigt der erst das hier an ?

Was gibst du den in die Eingabemaske beim Editieren genau ein? - Ich bin davon überzeugt, dass du dieses kleine Rätsel selber lösen kannst.

Debugger, wie OllyDbg, setzen voraus, das man zumindest ein wenig Ahnung von Assemblerprogrammierung hat – vielleicht solltest du dir erst einmal ein entsprechendes Tutorial durchlesen?

Hallo, ich hatte jetzt mal etwas Zeit mir das ganze genauer anzuschauen.

Etwas Assembler Erfahrung habe ich.(Ich hab ein Assembler Buch von Joachim Rhode
[http://www.joachimrohde.com/cms/xoops/modules/wfsection/article.php?articleid=53 Die zweite Auflage ] aber da wurde so etwas leider nicht behandelt.)

Aber ich glaube ich habe es verstanden.

Hier geht es ja anscheind nur um die Opcodes.

Zum test habe ich mal in einem Code Cave einen NOP Befehl angelegt, und das Offset wo das NOP steht gepusht und mit StdOut mir das Ergebniss ausgeben lassen.

Dabei kam ein E mit so einem Strich oben dran raus das habe ich in C++ schonmal gesehen als ich mit Buffer Overflows rum experimentiert habe.
Und der Opcode 41 ergibt den Assembler Befehl inc ecx

004010E7  41 inc ecx   ; 41 Hex = A Ascii

push 004010E7 
call StdOut   ; Gibt ein A aus

Die Opcodes werden auf den Stack gepusht und StdOut wandelt die Opcodes in Ascii Zeichen um, kann man das so sagen?

Oder gibt es dafür noch eine bessere Erläuterung oder ist meine Erläuterung sowieso falsch?