Assembler - OllyDbg falsche Anzeige

Hallo, ich habe ein Problem mit Olly. Wenn ich z.b. eine freie Stelle in der .text binär editiere und was hineinschreibe, wird es nach dem erneuten Analysieren
(STRG + A) nicht richtig angezeigt. Das gleiche bei Befehlen. Wie kann ich das ändern?

Hier kurz Beispiel:
http://s1.directupload.net/images/131009/xs8ring6.jpg

rkhb

ich hab ne Frage schrieb:

Hier kurz Beispiel:
http://s1.directupload.net/images/131009/xs8ring6.jpg

Besser ist, das Beispiel als Text zu kopieren und hier hineinzustellen, damit spätere Generationen auch noch wissen, was das Problem war.

Dein erstes Beispiel kann ich nicht nachvollziehen. Ich habe mein OllyDbg nicht dazu gebracht, dasselbe Verhalten zu zeigen.

Beim zweiten Beispiel hast Du dem JMP-Befehl so verändert, dass nun mitten in einen anderen Befehl hingesprungen wird. Das durfte Steve Wozniak beim Apple-II-Betriebssystem machen, aber wenn Du das machst, ist das bestimmt ein Fehler. Der Analyzer weigert sich jetzt, so etwas als richtigen Befehl darzustellen (er wüsste auch nicht, wie er das Sprungzeiel darstellen soll) und zeigt es stattdessen als eine Folge von Bytes (DB = Data Byte = Datenbyte).

viele grüße
ralph

Dein erstes Beispiel kann ich nicht nachvollziehen. Ich habe mein OllyDbg nicht dazu gebracht, dasselbe Verhalten zu zeigen.

Kannst du bei dir vielleicht mal kurz ausprobieren?

Beim zweiten Beispiel hast Du dem JMP-Befehl so verändert, dass nun mitten in einen anderen Befehl hingesprungen wird.

Sorry, darauf habe ich jetzt nicht geachtet, aber egal. Das auf dem Bild habe ich nur kurz zu demonstrationszwecken gemacht. Auch wenn ich die Sprungadresse
richtig gesetzt hätte, bei mir zeigt er es nach STRG+A nicht richtig an.

Kannst du das erste Beispiel bei dir mal testen, ich hab das so gemacht(falls du es vielleicht anders gemacht hast):

1.Leere Stelle finden und mit NOP füllen
2.Markieren -> Rechtsklick -> Edit -> Binary Edit -> Hallo bei UCode eingegeben.
3.STRG + A -> Es wird nicht richtig angezeigt.

Normal müsste da ja nur eine Zeile stehen mit dem Befehl UNICODE... und bei den Kommentarten Unicode "Hallo", oder ähnliches.

rkhb

Ich habe also eine EXE-Datei und öffne sie mit OllyDbg (v. 2.01). Ich suche dann nach einer Stelle, die unbenutzt aussieht und finde schon eine ein paar Bytes später:

...
004012D0      A1 3C614000   mov     eax, dword ptr ds:[<&msvcrt._onexit>]
004012D5      FFE0          jmp     eax
004012D7      90            nop
004012D8      90            nop
004012D9      90            nop
004012DA      90            nop
004012DB      90            nop
004012DC      90            nop
004012DD      90            nop
004012DE      90            nop
004012DF      90            nop
004012E0      55            push    ebp
004012E1      89E5          mov     ebp, esp
004012E3      83EC 18       sub     esp, 18
...

Mit nops's brauche ich sie ja nicht mehr zu füllen. Ich setze den Cursor, dann auf 004012D7, drücke Strg-E (Binary Edit) und gebe bei UNICODE 'Hallo' ein:

004012D5      FFE0          jmp     eax
004012D7      48            dec     eax
004012D8      0061 00       add     byte ptr ds:[ecx], ah
004012DB      6C            insb                                                ; I/O command
004012DC      006C00 6F     add     byte ptr ds:[eax+eax+6F], ch
004012E0      0089 E583EC18 add     byte ptr ds:[ecx+18EC83E5], cl

Nun drücke ich Strg-A:

004012D5      FFE0          jmp     eax
004012D7      48            db      48                                          ; char 'H'
004012D8      00            db      00
004012D9      61            db      61                                          ; char 'a'
004012DA      00            db      00
004012DB      6C            db      6C                                          ; char 'l'
004012DC      00            db      00
004012DD      6C            db      6C                                          ; char 'l'
004012DE      00            db      00
004012DF      6F            db      6F                                          ; char 'o'
004012E0      00            db      00
004012E1      89E5          mov     ebp, esp
004012E3      83EC 18       sub     esp, 18

Da ich mich in einer Code-Page im Speicher befinde, hat der Analyzer versucht, Assembler-Code zu generieren und ist gescheitert. Dann wird das Ganze eben als Daten-Bytes (DB) angezeigt. Bedenke, dass DB ein gültiger Assembler-Befehl ist. Eine Möglichkeit, den Block als DW oder DD (auch gültige Assembler-Befehle) anzeigen zu lassen, habe ich nicht gefunden. Normalerweise stört das einen Programmierer, der tatsächlich Daten im Code-Segment verstaut, nicht. Mit IDA (anderer Disassembler, den ich dann für solche Fälle benutze) könntest Du manuell die Daten zusammenfassen lassen, bzw. Befehlsanfänge manuell setzen.

Anders, wenn Du Dich in einer Daten-Page befindest. Dann versucht der Analyzer die Bytes als Daten (Zahlen,Text,o.ä.) zu interpretieren, weswegen Du mit der Eingabe eines Assembler-Befehls scheiterst.

Zweiter Schritt: Ich setze den Cursor auf 004012D5 und gebe bei Binary Edit - HEX ein: EB FE:

004012D5      EB FE         jmp     short test.004012D5
004012D7      48            db      48                                          ; char 'H'
004012D8      00            db      00
004012D9      61            db      61                                          ; char 'a'
004012DA      00            db      00
004012DB      6C            db      6C                                          ; char 'l'
004012DC      00            db      00
004012DD      6C            db      6C                                          ; char 'l'
004012DE      00            db      00
004012DF      6F            db      6F                                          ; char 'o'
004012E0      00            db      00
004012E1      89E5          mov     ebp, esp
004012E3      83EC 18       sub     esp, 18

Klappt also.

Wo liegt also das Missverständnis? Wahrscheinlich darin, dass Du nicht bedenkst, dass für das Programm von Windows verschiedene Speicherbereiche angefordert werden, die manchmal als Code und manchmal als Daten gekennzeichnet werden. Manche Adressen aus dem 4GB-Adressenraum sind auch gar nicht in echt vorhanden. Und in den Speicherbereichen sind bestimmte Aktionen nicht zulässig, z.B. Code in einem Datenbereich ausführen zu lassen. Wenn das auch sooo einfach wäre, gäb's ja auch viel mehr Viren, gelle?

viele grüße
ralph

Wo liegt also das Missverständnis? Wahrscheinlich darin, dass Du nicht bedenkst, dass für das Programm von Windows verschiedene Speicherbereiche angefordert werden, die manchmal als Code und manchmal als Daten gekennzeichnet werden.

Doch, das habe ich im Hinterkopf. Es muss doch irgendwie gehen. Ich habe in nem Video(Youtube) gesehen, das der es genau so macht und es bei ihm klappt,
wie er/ich es möchte.

Hier, in diesem Video macht er es so(fängt bei ca. 7:30 an):
http://www.youtube.com/watch?v=S7LgmdoEo3s

rkhb

ich hab ne Frage schrieb:

Hier, in diesem Video macht er es so(fängt bei ca. 7:30 an):
http://www.youtube.com/watch?v=S7LgmdoEo3s

Abgesehen davon, dass er nicht OllyDbg, sondern Immunity benutzt, fügt er Assemblerbefehle mittels 'Assemble' und nicht mit 'Edit Binary' ein. Seine Lücke (Kot-Käff) befindet sich direkt hinter der IAT, somit noch im erlaubten Code-Bereich. Dort kann man auch konstante Daten unterbringen, sie werden dann eben als DB-Befehle angezeigt.

Ansonsten schau ich mir das Gestotter nicht weiter an.

viele grüße
ralph

Abgesehen davon, dass er nicht OllyDbg, sondern Immunity benutzt, fügt er Assemblerbefehle mittels 'Assemble' und nicht mit 'Edit Binary' ein.

Ok, aber er meinte am Anfang oder so, das es mit OllyDbg nahezu identisch ist, soweit ich mich noch richtig erinnere. Ansonsten, ich habe Befehle auch mittels
"Assemble" eingefügt, doch bei mir ist es nicht so, naja.

Seine Lücke (Kot-Käff) befindet sich direkt hinter der IAT, somit noch im erlaubten Code-Bereich.

Ist vielleicht ne dumme Frage, aber woran erkennt man das?

rkhb

ich hab ne Frage schrieb:

Ok, aber er meinte am Anfang oder so, das es mit OllyDbg nahezu identisch ist,

"Tschulljung, Versehen", sagte der Igel und stieg von der Bürste.

OllyDbg 2.01 zeigt hier anderes Verhalten als Immunity. Aber OllyDbg 1.10 (gibt's auch auf dessen Website) zeigt das gleiche Verhalten. Immunity kann ich nicht empfehlen. Es handelt sich um Adware, die fleißig nach hause in die USA telephoniert.

Die IAT zu erkennen, ist eigentlich ganz einfach: Lauter Funktionen im Klartext und zum Schluss der Name der dazugehörigen DLL-Datei.

viele grüße
ralph