Problem mit Buffer Overflow

Hallo an alle Forenmitglieder,

ich beschäftige mich derzeit mit Bufferoverflows doch jetzt bin ich auf ein Problem gestossen. Ich habe die Stelle an der der EIP ueberschrieben wird gefunden. Wenn ich nun AAAA übergebe steht der EIP nachher bei 41414141 was ja korrekt ist. Nun wollte ich die Adresse meines Shellcodes uebergeben, die wie folgt lautet:

0022FEF8

--> \xF8\xFE\x22\x00

Übegebe ich diese Adresse nun so steht der EIP irgendwo ganz anderst und ich weiß nicht warum. (Ich weiß dass x00 ein terminator für strcpy ist aber deswegen sollte der vordere Teil trotzdem stimmen). Der EIP steht nun bei 30318732 und ich weiß nicht warum. Das ganze teste ich unter Winxp ohne servicespacks installed wegen DEP.


Wäre echt super wenn ihr mir helfen könntet!


Grüße & Danke!
 
Ohne jetzt konkret das Programm, deine Konfiguration oder deine Eingaben zu kennen, würde ich vorschlagen, dass du dir den Ablauf im Debugger Schritt für Schritt anschaust und so den Fehler suchst. Unter Windows gibts hierfür beispielsweise die kostenlose Version von IDA oder den OllyDbg.
 
Danke

Hallo,

also natürlich bin ich da dran mit olly, ich hatte gehofft dass vielleicht jemand das selbe Problem gehabt hat und mir direkt sagen kann woran es liegt....

Trotzdem Danke!
 
Wie sieht denn dein Stack vor und nach dem Aufruf von strcpy aus? Wie sieht dein Shellcode aus? Wie sieht die betreffende Stelle im Code aus?
 
Danke

Hallo,

also natürlich bin ich da dran mit olly, ich hatte gehofft dass vielleicht jemand das selbe Problem gehabt hat und mir direkt sagen kann woran es liegt....

Trotzdem Danke!
 
RE

Hi,

also ich hab mal nachgeschaut was er macht, also aus nem A macht er ne 41 was ja stimmt. Aus einer 1 macht er ne 32 und aus ner 2 ne 31. Was gibt es da für einen mathematischen Zusammenhang?


Grüße
 
RE

Hallo,

Danke für deine Antwort, aber laut der Tabelle muesste ich für eine 1 eine 21 kriegen tu ich aber nicht wie oben geschrieben. Sonst noch ne Idee oder bin ich einfach zu dumm?
Ich überschreibe den SEH handler könnte es was damit zu tun haben? Aber warum steht dann bei AAAA korrekt 41414141?

Gruß
 
Zuletzt bearbeitet:
Ne Idee warum es mit
\x41

nicht geht?
Ja, ganz viele ;)
Deswegen erstmal:
1)
Wenn ich nun AAAA übergebe steht der EIP nachher bei 41414141 was ja korrekt ist.
Wie kommst Du darauf? Also im Sinne, ob Du einen BP im Debugger gesetzt hast, die übliche "Accessviolation" Meldung siehst oder andere Methoden?
2)
Der EIP steht nun bei 30318732 und ich weiß nicht warum.
Wie gesagt, Debugger. Mach einen "while(1)" nach strcpy in den Code rein - dann "hängt" die Exe und lässt sich im Debugger attachen, so dass man die nötigen Werte (bzw. den Stack) einsehen kann.
Oder öffne die Executable im Debuger und setze einen BP nach dem strcpy, bevor Du diese ausführst.

3) Wie sieht der Shellcode aus? Wie groß überhaupt? Ausreichender NOP-Sled?

Ich hätte jetzt darauf getippt:
a) Die Länge des Shellcodes bzw. die Stelle, an der die Rücksprungadresse eingefügt wird, wurde "rechnerisch" ermittelt (also die Buffergröße aus dem Code genommen) - und schnell mit "AAAAAAAAAAAAA" getestet.
Muss allerdings nicht stimmen, da jeder halbwegs moderner Compiler den Buffer größer macht und diesen auch noch ggf. "aligned". Sprich => die Rücksprungadresse im Stack befindet sich nicht an der "berechneten" Stelle.

b)die Stelle, an der die Rücksprungadresse eingefügt wurde, ist korrekt, aber die Rückksprungadresse stimmt nicht. Liegt an einer Stackverschiebung - die kann z.B auch daraus resultieren, dass die Exe im Debugger geöffnet wurde.

D.h bei AAAAAA übergabe ist EIP = 0x41414141 => nette Fehlermeldung usw => schaut auf den ersten Blick ok aus.
Bei einer konkreter Adresse 0x0022FEF8 wird aber an diese Stelle gesprungen - und da ist nicht der erwartete Shellcode drin, sondern "Müll", alte Werte oder einfach um ein paar Bytes "verschobener" Shellcode - da kann es auch noch ganz andere lustige Meldungen geben.

Als Gegentest könnte man nun statt Shellcodeadresse die Adresse eine Funktion aus der Executable selbst/DLL übergeben (Stichworte:ROP, return-to-libc attack).
Oder den Debugger anwerfen ;).
Der Shellcode selbst sollte erstmal aus NOPs + einem \xEB\xFE" ( = while(true)-Schleife) am Ende bestehen. Die Exe "hängt" dann und lässt sich ohne weiteres im Debugger attachen und pausieren (wobei dann EIP = Shellcodeadresse sein sollte).
Erst dann sollte man damit anfange, "komplexeren" Shellcode einzufügen.
 
RE

Hallo,
also danke erstmal fuer die Antworten. Ich habe mein programm doch via debugger geöffnet und nen breakpoint direkt da gesetzt wo mein input dann im speicher landet.
Ich weiß also was ich wohin schreibe, denn da zeigt der EIP dann hin, weil ich ja den SEH handler überschreibe. Lasse ich den programm nun weiterlaufen kommt von ollydbg ne Meldung "EIP=41414141 Dont't know how to... ". Mein Problem oder besser gesagt frage is halt, warum ich nicht mit dem \x.. parameter arbeiten kann und wenn ich es tue er mir dann totale scheiße bringt...
Ich habe noch kein exploit gesehen, wo die ruecksprungadresse dann irgendwie mit chars gehaendelt wird...

Grüße
 
Ich weiß also was ich wohin schreibe
ja, was landet denn im Input, wenn Du statt AAA die Adresse übergibst?

Mein Problem oder besser gesagt frage is halt, warum ich nicht mit dem \x.. parameter arbeiten kann und wenn ich es tue er mir dann totale scheiße bringt...
\x ist kein Parameter, sondern eine Escape-Sequenz, die nicht unbedingt von allen Programmiersprachen oder gar der CMD "verstanden" wird.
Wie wird der Shellcode bzw die Adresse nun übergeben?
Kommandozeile mit Perl, ein extra Progrämmchen oder direkt a la "myprogram.exe \x0B\xAD\xC0\xDE ?
Ich habe noch kein exploit gesehen, wo die ruecksprungadresse dann irgendwie mit chars gehaendelt wird...
Es geht schon - man hat dann nur viel Spass mit Encoding/Decoding-Geschichten ;)
 
RE

Hallo zusammen,

Danke für die Antwort erstmal.

Ich übergebe die parameter direkt per console also test.exe blabla. Habe schon versucht ob sich was ändert wenn ich die in ollydbg direkt mitgebe beim starten der test.exe aber is genau das selbe.


So habe gerade mal \x0B\xAD\xC0\xDE getestet und nun schreibt er folgendes:

4230785C

Gruß
 
Zuletzt bearbeitet:
Die Kommandozeile kann nichts mit "\x" anfangen.
Btw: 4230785C = B0x\ in ASCII Darstellung. Es findet eben keine Konvertierung statt.
Entweder konvertierst Du es in selbst in ASCII (unter Beachtung der Codepage der Konsole) und übergibst diesen String oder schreibst Dir ein kleines Programm/Script welches den Aufruf übernimmt.
Zum testen reicht es aber auch allemal, den Shellcode erstmal im Code des jeweiligen Programms direkt zu platzieren.
 
Zurück
Oben