[OllyDbg] SaveToExe

[theredvex]

Nabend.

Ich bin gerade dabei ein Programm dazu zu nötigen eine von mir erstellte DLL durch eine CodeCave zu laden.
Die CodeCave ist nicht das Problem, auch nicht das zurückspringen zum normalen Code - Solange ich nichts verändere.

Erstelle ich in der Startfunktion die JMP in meine CodeCave, starte da wie gewollt das GUI Funktionierts. Will ich aber noch eine MessageBox mit einem Text alla "Test" - Or Whatever dazu starten, zerstört mir Olly beim saven der Exe mein Assemblercode. aus JMP wird DB 00 bzw DB "t" oder was auch immer.
Die Exe ist danach völlig Wertlos.

Nebenbei erwähnt, wenn ich das DIREKT ausm Pausemodus im selben Thread/PID/Debugged Program starte funktioniert mein Code Einwandfrei (nur kann die Außenwelt ziemlich wenig damit anfangen)

Kann mir das mal jemand erklören?

Edit1 : Beim Analysieren nachm bearbeiten des Assemblers passiert das Selbe

Edit2 : Hier ein Screenshot
Normalerweise stand in 0004CA97 ASCII "test"

[irrenhaus]

Hast du mal probiert STRG + A zu drücken?

[theredvex]

ich sag ja, dass das ExportToExe/SaveToExe Tool bzw Funktion Oder das analysieren meinen Code zerstört

[link]

Wenn nach dem Speichern einfach Werte zu anderen Werten wurden, wird dir wohl keiner helfen können, hört sich nämlich ziemlich seltsam an.
Naja, vllt. auch doch, mir sagt dein Problem aber nichts.

Lad dir OllyDbg halt nochmal neu herunter und versuch es ohne Plugins oder benutz eine andere Version (also entweder 1.10 oder 2).
Oder versuch den Immunity Debugger bzw. benutz einfach einen Hexeditor.

Hast du die Exe nach dem Speichern erneut in OllyDbg geladen und dort gesehen, dass da dann andere Werte stehen?
Wenn ja, hast du vorher die Datei in einem Hexeditor geöffnet, um sicherzustellen, dass die gleichen Werte auch vor dem Laden dort stehen?
Evtl. wird die Stelle, an der dein Code steht, z.B. durch Relocs verändert.

"test" steht ja noch da, nur anscheinend in Unicode.

[theredvex]

So Ich hab mir das ganze dann nochmal zu herzen genommen und den Text "test.dll" direkt ins HEX geschrieben und in die Exe gespeichert. dann mit der Editieren Exe weiter gearbeitet. nun ist das Problem, dass sich das Programm ja nun nicht immer aufm selben speicher einnistet - ich glaube das nennt sich DMA - undzwar steht mein Text JETZT auf 041091D0 lade ich das programm nun einmal neu ist es zbsp auf 13D9AD0. ich weiß, dass ich hier mit Offsets arbeiten muss nur wie benutze ich in ASM nen Offset?

Genauso mit dem CALL LoadLibraryW... die Addresse der Funktion wechselt auch hier.

Jemand Infos? Tipps?

Danke schoneinmal im Vorraus

[link]

Du meinst also, dass die ImageBase des Programmes, das du in Olly lädst, immer anders ist? Oder die Adresse einer geladenen Dll?
Exen müssen nämlich eigentlich nicht reloziert werden, da sie immer zuerst alloziiert werden. Eine Ausnahme ist ASLR, das soweit ich weiß aber standardmäßig nicht aktiviert ist. Ein paar mehr Informationen, was genau du lädst/betrachtest, wären ganz gut.

Mit dem folgenden Code bekommst du EIP, also die absolute Adresse der derzeitigen Instruktion:

call x
x: pop eax

Wenn du jetzt noch add eax,4 hinzufügst, hast du bei der nächsten Instruktion die Adresse derselben in eax.
Ziehst du 5 ab, hast du die Adresse von call x.
Dann ziehst du manuell die Adresse von call x von der Adresse deines Strings ab und hast das Offset, das du auf EAX-5 addierst, um zur Laufzeit die Adresse deines Strings zu erhalten, ohne statische Adressen zu benutzen.

Du könntest auch die Adresse deines Strings nehmen, die momentane ImageBase abziehen und die ImageBase aus dem PE Header draufaddieren und für die Stelle, an der du die Adresse benutzt, einen Relocation-Eintrag hinzufügen, sodass die Adresse beim Laden des Moduls korrigiert wird, was allerdings etwas aufwendiger ist (s. unten).

Wenn LoadLibrary nicht in den Imports des Moduls, das du bearbeitest, nicht vorhanden ist, fügst du es hinzu (manuell (falls du Spaß mit dem Hex-Editor willst) oder via LordPE/IIDKing), holst dir die Adresse des IAT-Eintrages, in dem nach dem Laden des Moduls die Adresse der Funktion steht (wird dir von LordPE/IIDKing angezeigt), und hast dann wieder die beiden gleichen Optionen wie oben.


So fügst du mit LordPE eine Relocation-Tabelle mit einem Eintrag hinzu (vorrausgesetzt dass im PE Header noch genug Platz ist):

Angenommen im PE Header steht als ImageBase 400000h, das Modul wurde aber auf 500000h reloziert und an der Adresse 501000h möchtest du die Adresse deines Strings haben:

501000h - B8 00 20 50 00 - mov eax,502000h
//...
502000h - 74 65 73 74 ... - ASCII "test.dll"

Damit die Relocations richtig angewandt werden, musst du die statische Adresse des Strings erst einmal auf die Standard-ImageBase anpassen:
Du subtrahierst die momentane ImageBase und addierst die aus dem PE Header: 502000h - 500000h + 400000h = 402000h. Du änderst das mov eax,502000h also zu mov eax,402000h und speicherst die Exe ab.
An 501000h befindet sich die Instruktion, die mit der statischen Adresse des Strings arbeiten möchte. Exakter steht die Adresse des Strings an 501001h (B8h = mov-Opcode; 00 20 50 00 => 502000h).
Die RVA dieser Stelle ist 1001h (Adresse - momentane ImageBase).

Jetzt muss für diese Adresse (1001h) ein Relocation-Eintrag vorhanden sein, sodass an der Adresse die Adresse des Strings angepasst wird:

Damit die Relocs richtig aligned sind, muss zuerst Folgendes sichergestellt werden:
(LordPE öffnen und PE Datei laden -> Directories -> Relocation -> '...'-Button)
Wenn die letzte Relocation-Tabelle eine ungerade Anzahl an Relocations hat, muss sie um IMAGE_REL_BASED_ABSOLUTE erweitert werden.
Dafür zählst du zuerst alle Elemente der vorhergehenden Reloc-Tabellen zusammen:

Angenommen es gibt 3 Reloc-Tabellen, die erste hat 322d (d = dezimal), die zweite 22d und die dritte hat 55d Elemente.
Dann endet die letzte Tabelle mit einer ungeraden Anzahl. Also nimmst du die Anzahl der Elemente der Tabellen davor (322+22=344) mal 2 und addierst 8 mal Anzahl der Tabellen - 1 und nochmal 4 dazu. Macht (344 * 2) + (8 * (3 - 1)) + 4 = 708d / 2C4h.
Dann lässt du dir die Relocs in LordPEs Hex-Editor anzeigen ('H'-Button) und gehst vom Anfang der Relocs 2C4h Bytes weiter.
Da die letzte Reloc-Tabelle 55d Elemente hat, ist sie 8 + (55 * 2) = 118d / 76h Bytes groß. Du siehst daher im Hex-Editor an der errechneten Stelle "76 00 00 00", 76h in Little Endian. Diesen Wert erhöhst du um 2, macht "78 00 00 00".
Nun gehst du an das Ende der Relocs (Fenster schließen und erneut den 'H'-Button drücken und dann an das Ende der selektierten Bytes gehen):
An diese Stelle kommt der neue letzte Eintrag der letzten Reloc-Tabelle, sodass sie auf 56d Elemente kommt und aligned ist, nämlich IMAGE_REL_BASED_ABSOLUTE (Null-WORD), also einfach zwei Nullen.
Jetzt folgt die RVA der Adresse, die korrigiert werden soll (also 1001h) als DWORD (macht "01 10 00 00"), was eine neue Reloc-Tabelle einleitet, danach folgt deren Größe als DWORD "0C 00 00 00" (8 + (2 * 2)), dann kommt der eigentliche Eintrag für 401001h bzw. 501001h "00 30" (ein IMAGE_REL_BASED_HIGHLOW-Eintrag mit dem Offset 0) und zum Schluss wieder IMAGE_REL_BASED_ABSOLUTE ("00 00").
(IMAGE_REL_BASED_ABSOLUTE ist optional, falls die Reloc-Tabelle die letzte Tabelle in den Relocations ist, und notwendig, wenn dem nicht so ist und eine ungerade Anzahl an Einträgen enthalten ist.)

Insgesamt hängst du also an das Ende der Relocs Folgendes an:
00 00 01 10 00 00 0C 00 00 00 00 30 00 00 (14d / 0Eh Bytes)

Nun muss noch der Header angepasst werden:
Das Size-Member des Relocation-DataDirectory muss also um 0Eh erhöht werden, ebenso die RawSize der Sektion, in der die Relocs vorhanden sind (meistens gibt es eine eigene Sektion für Relocations ".reloc" (LordPE passt nach dem Vergrößern einer Sektion SizeOfImage automatisch an)).

Falls du es einfacher haben möchtest, hol' dir EIP über das Call-Pop-Konstrukt und addiere die statischen Offsets (zu deinem String, zu dem IAT-Eintrag von LoadLibrary, etc.) darauf.

Edit:
Also mit call x | x: pop eax ist gemeint, dass du direkt die nächste Adresse aufrufst (call $+5), wodurch die Rücksprungadresse (auch $+5) auf den Stack gepusht wird, sodass man sie dann poppen kann und praktisch den Inhalt von EIP hat.

[theredvex]

Ich danke dir.
Das mit dem CALL X || POP EAX, hat wunderbar geklappt. nun habe ich aber das problem, dass er mir den CALL DWORD PTR SS:[LoadLibraryW.ImportAdresse], vollkommen zerlegt. er denkt ich meine einen UniCodestring dabei habe ich den CALL aus einer vorhandenen Funktion geklaut. wie kann ich das nun ändern?

aus

013FCA48 CALL DWORD PTR SS:[LoadLibraryW.ImportAdresse]

wird

013FCA48     FF             DB FF
013FCA49   . 15 24D22101    ADC EAX,121D224
013FCA4E   . 01E9           ADD ECX,EBP

EDIT 1 : das komische ist. er zerstört es erst wenn ich versuche es zu Analysieren... Starten lässt es sich auch nicht d.h das problem besteht weiterhin.

EDIT 2 : Hat das evtl. was damit zutun, dass ich den EntryPoint verlegt habe - ne oder?

Edit 3 : Ich glaube ich habe das Verstanden was er macht, aber nicht warum er das macht.

Aus

00D1CA50 FF15 24D206 Call Dword Ptr DS:[<&Kernel32.LoadLibraryW>]

macht er

00D1CA50     FF             DB FF
00D1CA51     15             DB 15
00D1CA52     24             DB 24                                    ;  CHAR '$'
00D1CA53     D2             DB D2
00D1CA54     06             DB 06
00D1CA55     00             DB 00