Codierungs-Form

SUID:root

SUID:root

Member of Honour
Habe mir grad den Jpeg-Exploit angesehen.
Was ich mich aber frag, ist, welche Art von Codierung das ist:

\xFF\xD8\xFF\xE0\x00\x10\x4A\x46\x49\x46\x00\x01\x02\x00\x00\x64"
"\x04\x00\x00\x00\x0A\x00\x00\xFF\xEE\x00\x0E\x41\x64\x6F\x62\x65"


Sieht nach Hex-Code aus. Aber ich kenne das nur in der Form von FF D8 FF E0...
Warum beinhaltet der Code diese x x x?

Gruss

root
 
servuz,

dazu hab ich auch mal ne frage... - wieso werden in sehr vielen exploits teile des codes als hex werte - und nicht als reiner c/asm code code geschrieben?
wäre ja verständlich, wenn das ziel irgendwelche exotischen prozessoren hat - aber x86 ??

cya, hants
 
evtl. weil z.B. das JPEG-Format nix mit ASM/C zu tun hat. Der Exploit produziert ja lediglich nen Fehler in dem Programm, das das Bild aufruft.
 
Original von hants
wieso werden in sehr vielen exploits teile des codes als hex werte - und nicht als reiner c/asm code code geschrieben?
Zum Vergrößern anklicken....
Das hat in erster Linie diese 2 Gründe:
1. Man benötigt ja den ganzen Code als Maschinen-Code und nicht als ASM-Code (welcher ja noch assembliert werden müsste), weil dieser Code z.B. nach einem Buffer-Overflow direkt in den Stack/RAM geschrieben wird um dann ausgeführt zu werden. Mit ASM kannste da dann nicht viel anfangen...
2. Um Script-Kiddies das Leben etwas schwerer zu machen - die meissten Exploits werden als ja nur als "Proof-of-Concept" geschrieben...
 
servuz,

edit wegen sinnentstellendem grammatikfehler :D :das problem, dass asm code erst compiliert werden müsste tritt aber nur auf, wenn es sich um gescriptete exploits handelt.

die häufigsten exploits sind aber in c/++ geschrieben und verwenden hexcodes anstelle von c oder asm code.
diese müssen auch erst compiliert werden. bei strcpy artigen overflow exploits argumentieren einige damit, dass man so null-bytes vermeiden könnte. das ist aber schwachsinn, da man komplett anders programmieren muss - und das kann man schließlich auch mit inlineasm oder c.

kein compiler(zumindest keiner den ich kenne) kennt alle opcodes - dan ist man gezwungen mit hexcodes zu programmieren - aber ich hab noch kein exploit gesehen, das so aufwendig war, dass man die "underground opcodes" verwenden musste.

und script kiddies das leben schwer machen halte ich auch für keine echte begründung, da die fehler(normalerweise) im c code - und nicht in diesem bytecode versteckt werden.

ich kenne immernoch keinen sinnvollen grund dafür, code in hex zu schreiben, wenn ich nicht gerade spezialviren oder betriebssystheme ohne compiler schreibe. aber wenn ich schon nicht dazu gezwungen bin auf compiler zu verzichten - wieso dan code in hex schreiben ?!

cya, hants
 
Original von hants
wieso werden in sehr vielen exploits teile des codes als hex werte - und nicht als reiner c/asm code code geschrieben?
Zum Vergrößern anklicken....
das man bei einem buffer overflow exploit wie diesem jpeg exploit, maschinencode in form von hexcodes verwendet liegt in der natur der sache

maschinencode, welchen der computer intern verwendet, besteht nur aus zahlenwerten bzw den sogenannten opcodes
und maschinencode in hexwerten ist im prinzip die noch am besten lesbare form (besser als x nullen oder einsen), wenn mann nicht grad programmiersprachen wie assembler oder C verwendet, welche aber wie ntoythi schon sagte erst kompiliert werden müssten damit am ende wieder ausführbarer maschinencode dabei rauskommt

bei einem buffer overflow exploit wird nun der speicher, welcher bereits maschinencode/daten enthält, mit anderem maschinencode (unseren hexcode string) überschrieben, damit dieser von dem bereits laufendem programm ausgeführt wird

ich glaube das was du falsch verstehst, ist das man hier nicht mit hexcodes wie im stile von inline-assembler in einem C-programm arbeitet, sondern eigentlich nur nen hexcode-STRING hat, welcher später durch den exploit in den speicher geschrieben wird
 
Original von hants
das asm code erst compiliert werden müsste trifft aber nur zu, wenn es sich um gescriptete exploits handelt.
Zum Vergrößern anklicken....
Ähm LoL "Gescriptete Exploits" :D

Also das ganze funktioniert folgendermaßen:
1. Zunächst schreiben wir den Maschinen-Code, welcher nach dem Exploit von dem Ziel-Programms in dessen Kontext ausgeführt werden soll irgendwo in den RAM
2. Der eigentliche Exploit überschreibt beim Buffer-Overflow irgendeine Rücksprungadresse des Ziel-Programms mit der Speicheradresse des Maschinen-Codes
3. Das Ziel-Programm springt aufgrund der modifizierten Rücksprungadresse zu der Stelle wo unser Code steht und führt ihn aus.

So und nun erklär mir mal was du mit ASM-Code genau anfangen willst? Wir können ihn so und so nicht ausführen (können schon aber es bringt uns nichts)! Wir brauchen den Code genau in der Form wie wir ihn in den RAM schreiben wollen damit er dann von dem anderen Programm ausgeführt werden kann!

***Edit***
Ok ich nehm alles zurück, hab dein Post zu schnell gelesen. Du meinst warum Leute Hexcode-Strings verwenden selbst wenn der Code in unserem Kontext (des Exploit-Programmes) ausgeführt werden soll?
 
servuz,

so schauts aus - compiliert werden muss das exploit so oder so - dan kann man auch auf hexcodes verzichten^^

selbst bei einem jpeg oder mp3 exploit würde ich eher ein programm in c&asm schreiben, das die gepackte file so modifiziert, dass ein bestimmter code ausgeführt wird. Es fällt nämlich weniger auf, wenn das bild auch angezeigt - oder der film abgespielt wird(und die datei größer als ein paar bytes ist) - und so ist es wahrscheinlicher, dass das exploit zb. zur erneuten ausführung kommen kann(was oftmals ziemlich nütztlich ist). Ausserdem spart man sich so eine menge arbeit - und ich glaube nicht daran, dass jemand eine jpeg sozusagen von hand mit dem hexeditor bearbeitet.

mit der funktionsweise von exploits und ähnlichen programmen bin ich schon einigermaßen vertraut ;).

ausserdem ist das mit gescripteten exploits gar nicht so weit hergeholt - gibts alles - sogar batch und vbs exploits\viren(ja ich meine viren - nicht würmer).^^

der unterschied von quellcode und maschinencode - nunja danke für eure mühe ;) - aber ihr versteht mein problem nicht: wozu maschinencode schreiben, wenn man das selbe um einiges einfacher mit quellcode erreicht ?!

und damit keine missverständnisse mehr aufkommen - ich habe in meinem leben noch nicht behauptet, dass quellcodes ohne interpreter/compiler direkt ausgeführt werden können.

die frage ist: wieso werden in vielen exploits, obwohl sie erst compiliert werden müssen, teile des codes (quasi precompiled) als (wie ihr sie nennt - aber falsch ist) hex-strings geschrieben, obwohl man das selbe mit inline assembler oder c code lösen könnte ??

hoffe ihr versteht mich jetzt (ich hab wohl noch nie ne frage so unverständlich formuliert, wie die vor ein paar posts :P)

cya, hants
 
ja natürlich muss auch ein exploit erst kompiliert werden, aber das ist nicht der punkt
bei nem buffer overflow exploit geht es doch wohl darum dass code in ein ANDERES programm gebracht und dann dort ausgeführt wird
d.h. der hexcode selber wird garnicht vom exploit ausgeführt sondern von dem "verwundbarem" programm
deswegen ist das argument dass der exploit code sowieso kompiliert wird, gar nicht relevant weil das im prinzip 2 voneinander getrennte codes sind
und da im speicher maschinencode verarbeitet wird, muss ich eben auch maschinencode einschleusen
 
servuz,

ja natürlich muss auch ein exploit erst kompiliert werden, aber das ist nicht der punkt
Zum Vergrößern anklicken....

eben DAS ist der punkt^^

wenn ich ein programm schreibe in sagen wir c++ - dan starte ich den compiler, den linker usw. - und am ende kommt eine datei raus, die nennt sich beispielsweise eid.exe .

vom ursprünglichen quellcode ist in der datei nichts zu sehen, unter dem hexeditor betrachtet sehe ich nur noch den header, einen kurzen unter msdos ausführbaren teil und dan das programm selbst(unter *nix ist das ganze analog) - alles in hexcodes. - aha

das programm - nach dem ich es compiled habe besteht also nur noch aus nur für prozessoren, debugger, disassembler usw. verständlichen hexcode(=der maschinencode) - nichts mehr vom ursprünglichen c code ist vorhanden.

und den teil der schon vor dem compilieren als hexcode geschrieben war bleibt natürlich der selbe hexcode.
ich könnte mich aber genauso gut hinsetzen und den teil, den ich so umständlich als hexcode geschrieben habe, als asm oder c code im programm schreiben - herauskommt nach dem compilen immernoch derselbe gottverdammte hexcode.

wozu machen sich also viele exploits schreibende menschen die mühe - und schreiben mit opcodelisten usw. das programm zur hälfte compilerfrei, wo sie doch das selbe(!?) ergebnis bekommen würden, wenn sie es komplett in für menschen verständlichen programmiersprachen geschrieben hätten??

die funktionsweise von overflow exploits werde ich an dieser stelle nicht erläutern, da ich keine tutorials zu themen schreibe von denen es bereits terrabytes im netz gibt, eg. ist eins der besten das hier: http://www.phrack.org/phrack/49/P49-14

und in diesem tutorial wird neben meiner methode auch dieser krampf mit den hexcodes gemacht - wozu??

cya, hants
 
bei buffer overflows dreht es sich im prinzip immer um fehlinterpretation bzw ungewollte interpretation von daten
oftmals ist das ein string oder auch mal bilddaten wie im jpeg exploit oder was auch immer
und in diesen strings oder daten schreiben wir unseren code der dann im speicher des verwundabren programms landet und dann ausgeführt werden soll

angenommen du hast nen remote-exploit bei dem ein zulanger string nen buffer overflow erzeugt?
wie stellst du dir das nun vor wenn dein "shellcode" irgenwo als kompilierte funktion in deinem exploit programm steckt?
sendData( "exploitetString" + evilFunction() ); oder wie willst du das umsetzen? :rolleyes:
dir bleibt doch gar nichts anderes übrig als den maschinencode direkt in den string bzw in die daten zu schreiben
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben