Neues Whitepaper:
Shellcode Entwicklung
Viel Spaß... Bei Ideen, einfach hier posten.
Druckbare Version
Neues Whitepaper:
Shellcode Entwicklung
Viel Spaß... Bei Ideen, einfach hier posten.
Ansich ne gute Sache, aber ich glaube das Shellcode schreiben ist beim BoF exploiten, eher der einfachere Vorgang, (so vermute ich), als überhaupt in der Applikation selbst eine verwundbare Eingabe zu finden, und analog dazu eine schöne Stelle im Stack wo man den Code letztendlich reinschreibt.
Hast dazu noch ein paar Hints? (Vllt erstmal zum Stack Overflow, der ist berechenbarer)
Das Whitepaper ansich sieht aber gut aus, einiges kannte ich schon.
Wie siehts mit meiner Frage aus?
Im allgemeinen finde ich das auch sinnvoll, soetwas zu posten, und sei es nur, weils selber geschrieben ist. Es gibt auch tausende SQL Injection Tutorials, dennoch haben meine 3 einige viele Hits @ c0x.
Habe deine Frage nicht ganz verstanden...?
Ob ich noch ein paar Hints hab zum Thema BOFs? Was meinst du? Ein paar Tipps, ein paar Links?
Jedenfalls finde ich überhaupt nicht, dass das Finden einer speicherorientierten Sicherheitslücke schwieriger ist als Shellcode schreiben. Ich finde ersteres sehr einfach, wogegen ich mir an so manchem polymorphen Shellcoderoutinen schon den Kopf zerbrochen habe.
Na gut, möglicherweise wird es daran liegen, dass ich bisher auch keine gefunden hab, und die ASM Kenntnisse vielleicht nur zu rudimentär sind.
Was sinnig ist, dass ich natürlich Ausschau halte nach gefährlichen Libs/Apis, für Befehle wie printf oder strcpy.
Aber dann gehen die Schwierigkeiten auch schon los - Zwar wären PUSH Aufrufe potenziell interessant, aber ich kann ja nicht jeden PUSH überprüfen, bzw. es wäre verschwendete Zeit nehme ich an.
Bei einigen Versuchen konnte ich zwar teilweise den EIP überschreiben, aber nicht mit dem gewünschten Code.
Verwendeteter Disassembler: OllyDBG
Das im Paper verwendete Tool objdump ist immer wieder ein praktischer Helfer, genau wie gdb (kann man imho nicht drauf verzichten). Aber das ist ja im Prinzip schon wieder ein anderes Thema, vielleicht schreib ich da ja auch mal was drüber.
gute tut sehr gut erklärt ....
5****
bitte schoen :
http://hackerwiki.org/index.php/Erst...ines_Shellcode
-- bloeder kommentar, ist eh nicht wichtig --
edit : mir faellt noch ein, forbidden code ist noch ausfuehrlicher und ebenfalls auf deutsch, jedoch nicht kostenlos erhaeltlich.
Wunder dich doch nicht, wenn die Admins dein unnötiges Gespamme löschen... Schreib doch mal was gescheites, dann brauchst du hier auch nicht einen Scheiss von "Stasi 2.0" erzählen.Zitat:
Zitat von c0x
Forbidden Code lohnt sich auf jeden Fall, weil es einfach umfangreich an Themen ist, und neben den klassischen BoF's auch die Format String Exploitation erläutert.
Dazu noch ein wenig Netzwerktechnisches.
Naja ich sollte mir einfach nochmal ASM reinziehen.
Jepp, Forbidden Code ist ohne Zweifel die "IT Security Bibel". Gehört auch definitiv zu meinen Lieblingslektüren.
heheh was für ein zufall. diese Buch hab ich am 24 dezember bekommen.Zitat:
Zitat von kat23
ist sehr ausführlich
@Topic
Tut ist nicht schlecht nun eben nicht so ausführlich
EIP mit Code überschreiben? EIP mit der Adresse zum eigenen Code überschreiben wohl eher. Solange es kein File Stream Pointer Overflow ist oä, ist das doch kein Problem, wenn man erstmal die Lücke im Code gefunden hat.Zitat:
Zitat von Lidloses_Auge
Naja aber unter Windows hab ich mich noch nie richtig mit Bofs beschäftigt. Da nehm ich lieber gdb unter Linux <3
Ah, sicher. Verschrieben, ich meinte auch die Adresse.
Na vllt wars auch ein Overflow Schutz, ich muss mir das ganze mal unter Linux anschauen, da ist das mitm compilieren nicht so stressig.