Shellcode um in Datei zu schreiben
-
Hallo freecrac,
du musst den Unterschied zwischen Assemblercode (kann man als Mensch lesen, aber nicht der x86 Prozessor) und Maschinencode (x86 Prozessor versteht das, als Mensch hingegen nur sehr schwer lesbar) verstehen, dann hast du gewonnen.
Hier ein einfaches Beispiel:
Ich möchte folgende Assembler Befehle in Maschinensprache (x86) übersetzen:
mov eax,0xAABBCCDD mov ebx,eaxAlso rufe ich das Programm nasm auf, das erledigt das für mich.
Der Output ist nun folgender Maschinencode in HEX Darstellung, erkennst du z.B. den Wert 0xAABBCCDD wieder (little endian byte order - daher findet er sich als ccdd aabb wieder).b866 ccdd aabb 8966 00c3Man kann sich den Machinencode auch als ASCII ansehen, nur wird das halt nicht sehr vernünfig sein, aber siehe selbst:
f???f??Der letzte Teil des Maschinencodes fehlt in der ASCII Darstellung. Überleg dir mal warum.
Aber bedenke, dass es egal ist ob du den Maschinencode im HEX Editor ansiehst, oder ihn dir im ASCII Format in einem Texteditor ansiehst, oder ihn dir binär ansiehst - es ist und bleibt Maschinencode, und der x86 Prozessor kann damit umgehen.
Da du aber mit den Basics anfangen solltest, würde ich dir empfehlen, lad dir das Programm nasm runter, und schreibt ein paar einfache Programme in Assembler. Ich denke, damit wird das alles viel klarer als wenn wir hier weiter herum theoretisieren.
-
freecrac schrieb:
Deine Frage lautet doch eigentlich, wofür gibt es überhaupt genaue Definitionen?
Nein. Mir gehts nur konkret um diesen Fall hier. Zum einen ist Shellcode einfach ein Begriff, den irgendwann paar Hacker/Programmierer benutzt haben und der sich etabliert hat. Der hat für mich keine formale Definition, selbst wenn jemand später versucht haben sollte, den Begriff genau zu definieren. Ist vielleicht so ähnlich wie mit "Software". Das ist ein recht schwammiger Begriff (der sich irgendwie definiert ist), der je nach Kontext verschiedene Bedeutungen haben kann. Ich kann die Binaries von MySql als Software bezeichnen, genauso aber auch den Quellcode davon. Das macht jetzt nicht den Kern des Begriffs Software aus.
Das wollte ich damit jetzt eigentlich nur sagen. Deine Fragen waren etwas schwammig formuliert, und ich wollte dich nur darauf hinweisen, dass ich die Unterscheidung hier für das Verständnis des Begriffs Shellcode für nicht besonders relevant halte.
-
gdgfdgdgdfg schrieb:
Hallo freecrac,
du musst den Unterschied zwischen Assemblercode (kann man als Mensch lesen, aber nicht der x86 Prozessor) und Maschinencode (x86 Prozessor versteht das, als Mensch hingegen nur sehr schwer lesbar) verstehen, dann hast du gewonnen.
Hier ein einfaches Beispiel:
Ich möchte folgende Assembler Befehle in Maschinensprache (x86) übersetzen:
mov eax,0xAABBCCDD mov ebx,eaxAlso rufe ich das Programm nasm auf, das erledigt das für mich.
Vorschlag: Weil wir eh im Internet zugange sind, da bietet es sich an anstelle von nasm einen Online-assembler zu verwenden, der für uns objdump zum disassemblieren verwendet.
https://defuse.ca/online-x86-assembler.htm#disassembly
(Architecture: x86 für den 32 Bit Adressmode)0: b8 dd cc bb aa mov eax,0xaabbccdd 5: 89 c3 mov ebx,eaxDer Output ist nun folgender Maschinencode in HEX Darstellung, erkennst du z.B. den Wert 0xAABBCCDD wieder (little endian byte order - daher findet er sich als ccdd aabb wieder).
Ja stimmt, das ist mir bekannt.
So auch das Maschinencode direkt ausführbar ist und alles Andere eben kein Maschinencode ist. Auch wenn der Begriff Maschinencode in manchen Anworten nach dieser Definition falsch verwendet wurde und es somit auch deutlich wird, wie wichtig es ist eine allgemeingültige Definition zu verwenden, wenn wir grundlegende Missverständnisse vermeiden möchten. So ist es eben nicht besonders sinnvoll, wenn von einer allgemeingültigen Definition abgewichen wird und jeder etwas Anderes damit meint.
Man kann sich den Machinencode auch als ASCII ansehen, nur wird das halt nicht sehr vernünfig sein, aber siehe selbst:
f???f??Der letzte Teil des Maschinencodes fehlt in der ASCII Darstellung. Überleg dir mal warum.
Da brauche ich nicht lange zu überlegen, weil mit ASCII-Zeichen lassen sich nicht alle Bytes darstellen und wenn man z.B. einen Machinencode in eine Batchdatei verwenden möchte, dann muss man eben nur solche Bytes verwenden die als ASCIIs dargestellt werden können.
Aber bedenke, dass es egal ist ob du den Maschinencode im HEX Editor ansiehst, oder ihn dir im ASCII Format in einem Texteditor ansiehst, oder ihn dir binär ansiehst - es ist und bleibt Maschinencode, und der x86 Prozessor kann damit umgehen.
Ja das ist mir auch bekannt.
Da du aber mit den Basics anfangen solltest, würde ich dir empfehlen, lad dir das Programm nasm runter, und schreibt ein paar einfache Programme in Assembler. Ich denke, damit wird das alles viel klarer als wenn wir hier weiter herum theoretisieren.
Ich selber verwende schon viele Jahre Assembler und habe x86-Befehle zum ersten Mal schon auf einem 80286 zusammen mit Debug.exe unter DOS ausprobiert. Danach hat es auch nicht so lange gedauert, bis ich zu einem 80386 wechselte, um auch dessen Befehle und Möglichkeiten kennen zu lernen. Ich meine die Basics der Assembler-Programmierung sind mir damit schon klar genug geworden.
DarkShadow44 schrieb:
Der Shellcode selber sind einfach nur Bytes die zusammengenommen lauffähigen Maschinencode bilden.
Lauffähigen Maschinencode bedeutet das eine CPU genau diesen Code auch ausführen kann.
Ob diese Bytes jetzt direkt binär in einer Datei stecken, Hexkodiert in einen string eingebunden, percent-encoded sind, oder einfach zur Laufzeit aus einem bild reconstruiert werden ist doch egal ?
Nö das ist nicht egal, sondern es entscheidet darüber, ob es ein Maschinencode ist, oder ob zur Laufzeit dieses Maschinencode erst erzeugt wird, weil es vorher noch kein Maschinencode war.
Bitte was ?
Shellcode ist letztlich >immer< Maschinencode. Und Maschinencode sind Bytes. ASCII-Zeichen sind Bytes. Das heißt du kannst jede ASCII Zeichenfolge auch als Maschinencode interpretieren.Bei Maschinencode kommt es eigentlich nur darauf an, ob eine CPU die Bytefolge ausführen kann, oder nicht. Ob und wie wir Menschen es interpretieren ist dafür eigentlich völlig irrelavant und Assemblerbefehle und percent-encoded bytes sind selber noch kein Maschinencode, sondern werden erst später dazu gemacht. Genau darin unterscheiden sich Maschinencode und andere Bytes die in ihrer Form noch nicht von einer CPU direkt ausführbar sind.
Weil es für den Begriff Maschinencode schon eine allgemeingültige Definition gibt wäre es überaus sinnvoll auch nur diese Definition zu verwenden und eben nicht etwas Abweichendes davon hinein zu interpretieren, weil das nur grundlegende Missverständnisse erzeugt, die nur wenig hilfreich sind.
Es mag ja sein das es für den Begriff "Shellcode" immer noch keine allgemeingültige Definition gibt, aber für den Begriff Maschienencode gibt es bereits eine allgemeingültige Definition, womit nur von einer CPU direkt ausführbarer Code gemeint ist und nichts anderes.
Doch bisher habe ich immer noch keinen Shellcode gesehen, der selber auch wirklich Maschinencode enthält, der von einer CPU genauso in dieser (noch) unveränderten Form auch ausgeführt werden kann. Bisher habe ich nur Shellcode gesehen, der selber gar keinen Maschinencode enthält und dessen Bytes nicht direkt und unverändert von einer CPU ausgeführt werden können.
Im Falle in einem Shellcode aber niemals von einer CPU direkt ausführbarer Maschinencode enthalten ist, dann wäre es ja nicht so schwer eine allgemeingültige Definition dafür zu finden, wenn man sagt dass bestimmte in einem Schellcode sich befindende Bytes erst zur Laufzeit in einen direkt ausführbaren Maschinencode umgewandelt werden.
@Mechanics: Ich hoffe ich habe mich nun etwas weniger schwammig ausgedrückt.
Kann nun jemand von euch auch mal einen Shellcode zeigen, der direkt ausführbaren Maschinencode enthält, oder gibt es so etwas doch nicht?
Dirk
-
Sag mal meinst du das ernst oder willst du nur provozieren ?
Assemblerbefehle und percent-encoded bytes sind selber noch kein Maschinencode, sondern werden erst später dazu gemacht. Genau darin unterscheiden sich Maschinencode und andere Bytes die in ihrer Form noch nicht von einer CPU direkt ausführbar sind.
Deine Logik hinkt. Demnach müsste auch ein Bild das komprimiert oder verschlüsselt ist kein Bild mehr sein.. Weil es erst beim entschlüsseln/dekomprimeiren dazu gemacht wird.
Natürlich ist es Maschinencode wenn es Prozentkodiert angeben ist, nur in anderer Form!Doch bisher habe ich immer noch keinen Shellcode gesehen, der selber auch wirklich Maschinencode enthält, der von einer CPU genauso in dieser (noch) unveränderten Form auch ausgeführt werden kann.
Da könnte man sich jetzt drüber streiten ob Hexkodierung/Prozentkodierung als "Veränderte Form" zählt.. Ich meine letztlich gibtst du direkt die Bytes an, die Umwandlung ist ja wohl trivial.
Doch bisher habe ich immer noch keinen Shellcode gesehen, der selber auch wirklich Maschinencode enthält, der von einer CPU genauso in dieser (noch) unveränderten Form auch ausgeführt werden kann.
Weil Shellcode eben meist in Form von source vorliegt. Also damit meine ich z.B. ein C Programm in dem der Shellcode in Form eines char-Arrays eingebunden ist. Diese Art der Einbindung ist nunmal die leichteste die ich kenne. In den Binaries liegt der Shellcode dan wieder in der "reinen" Form vor (binär als Bytes). D.h. nach deiner Definition enthält das Binary Shellcode die Source aber nicht... ?
-
Sone schrieb:
So auch das Maschinencode direkt ausführbar ist und alles Andere eben kein Maschinencode ist.
Und ausführbar ist er nur, wenn er gerade im Prozessor ist oder wenigstens auf dem Bus. Ausgedruckt oder auf dem Monitor ist es natürlich kein Maschinencode mehr, sondern das sind nur textuelle Repräsentationen. Nichtmal das Magnet-Zeug auf der Platte kann Maschinencode sein, da isses ja gar nicht ausführbar.
-
Moin.
DarkShadow44 schrieb:
Sag mal meinst du das ernst oder willst du nur provozieren ?
Moment mal, dich kann man schon mit einer allgemeingültige Definition provozieren?
Ich suche eigentlich immer noch nach einer Definition für den Shellcode, aber nicht für den Maschienencode. Weil für den Maschienencode gibt es bereits eine eindeutige und allgemeingültige Definition. Und diese Definition ist nicht nur meine Definition, auch wenn ich es selber für zweckmäßig halte, genau diese Definition auch eigenständig zu verwenden. Es wäre auch eine Form der Höflichkeit, wenn du dich der allgemein üblichen Verwendung von bereits definierten Begriffen halten könntest. Danke.
Assemblerbefehle und percent-encoded bytes sind selber noch kein Maschinencode, sondern werden erst später dazu gemacht. Genau darin unterscheiden sich Maschinencode und andere Bytes die in ihrer Form noch nicht von einer CPU direkt ausführbar sind.
Deine Logik hinkt.
Demnach müsste auch ein Bild das komprimiert oder verschlüsselt ist kein Bild mehr sein.. Weil es erst beim entschlüsseln/dekomprimeiren dazu gemacht wird.
Natürlich ist es Maschinencode wenn es Prozentkodiert angeben ist, nur in anderer Form!
Der Begriff "Bild" hat seine eigene Definition und diese ist mit der Definition vom "Maschienencode" nicht mal im entferntesten verkuppelt. Was du hier zu konstruieren versuchst hat keine gemeinsame Basis. Verschone mich bitte mit so einer Logik von dir und halte dich lieber an die allgemeingültige Definition, anstelle mir ein unlogisches Verhalten anzudichten. Welche Logik nun mehr hinkt, das hast du nun mit diesem Tanz auf zwei völlig unterschiedlichen Hochzeiten ja schon recht eindrucksvoll genug zeigen können.
Es gibt nach der allgemeingültigen Definition keine andere Form von Manschienecode. Begreife das nun endlich auch einmal. Mir es dann auch noch vorzuhalten ich würde provozieren. Sag mal gehts dir noch gut? Halte dich gefälligts an die allgemeingültige Definition und laber mich hier nicht mit deinem davon abweichenden Stuss voll. Ich bin hier nicht deine Fussmatte für deine absonderlichen Spinnereien darüber.
Doch bisher habe ich immer noch keinen Shellcode gesehen, der selber auch wirklich Maschinencode enthält, der von einer CPU genauso in dieser (noch) unveränderten Form auch ausgeführt werden kann.
Da könnte man sich jetzt drüber streiten ob Hexkodierung/Prozentkodierung als "Veränderte Form" zählt.. Ich meine letztlich gibtst du direkt die Bytes an, die Umwandlung ist ja wohl trivial.
Man kann sich eben nicht darüber streiten, wie die Definition von Maschienencode ist. Halte dich an die allgemeingültige Definition und höre damit auf den Begriff falch zu verwenden, bzw. anders zu definieren und eine davon abweichende Bedeutung anzudichten.
Doch bisher habe ich immer noch keinen Shellcode gesehen, der selber auch wirklich Maschinencode enthält, der von einer CPU genauso in dieser (noch) unveränderten Form auch ausgeführt werden kann.
Weil Shellcode eben meist in Form von source vorliegt.
Meistens, oder immer nur? Wie wäre es einmal ein konkretes Statement darüber zu äussern, anselle das du die allgemeingültige Definition von Maschinencode immer wieder in Abrede stellst und den Begriff davon abweichend verwendest?
..
@volkard: Entscheidend ist doch nur, ob die unveränderten Bytes so ausgeführt werden können, oder nicht. Wenn diese Bytes unverändert ausgeführt werden können, dann ist es nicht so wichtig wie diese Bytes zu einer CPU gelangen, um dort ausgeführt zu werden. So kann auch ein Maschienencode eingebettet in einer Batchdatei und auch auf einer Festplatte sich befinden und von dort in unveränderten Form zur Ausführung gebracht werden. Mit direkt von der CPU ausführbar bedeutet in diesem Zusammenhang doch nur, dass die Bytes selber für die Ausführung nicht verändert werden brauchen, also auch wenn diese Bytes erst zu einer CPU noch befördert werden müssen, ist danach die direkte Ausführung solcher unveränderten Bytes möglich.
Wenn jedoch die Bytes erst verändert werden müssen, um ausführbar zu werden, z.B wenn diese Byte vorher komprimiert wurden, dann sind die Byte in dieser Fom nicht ausführbar und damit auch noch kein Maschinencode, sondern diese Bytes müssen erst wieder ausgepackt und damit verändert werden, um ausgeführt werden zu können.
Dirk
-
Der Begriff "Bild" hat seine eigene Definition und diese ist mit der Definition vom "Maschienencode" nicht mal im entferntesten verkuppelt.
Das war ein Vergleich...
halte dich lieber an die allgemeingültige Definition
Also an gar nichts ? Weil es keine allgemeingültige Definition gibt ??
Woher stammt deine heilige Definition von Maschinencode ?So kann auch ein Maschienencode eingebettet in einer Batchdatei und auch auf einer Festplatte sich befinden und von dort in unveränderten Form zur Ausführung gebracht werden
Und wenn z.B. die Festplatte verschlüsselt ist ? Dann können die Bytes nicht unverändert ausgeführt werden. Das bedeutet wenn die Festplatte verschlüsselt ist und ich dort Maschinencode ablege ist es danach keiner mehr
Meistens, oder immer nur? Wie wäre es einmal ein konkretes Statement darüber zu äussern, anselle das du die allgemeingültige Definition von Maschinencode immer wieder in Abrede stellst und den Begriff davon abweichend verwendest?
Immer natürlich nicht. Irgendwann muss man sie ja in Binaries verwandeln um sie einzusetzen. Wenn du den Shellcode nur einsetzen willst brauchst du keine Asm Source, da reichen die Binaries. Wenn du es aber verstehen willst machts ein kommentierter Quelltext einfacher.
-
freecrac schrieb:
@volkard: Entscheidend ist doch nur, ob die unveränderten Bytes so ausgeführt werden können, oder nicht. Wenn diese Bytes unverändert ausgeführt werden können, dann ist es nicht so wichtig wie diese Bytes zu einer CPU gelangen, um dort ausgeführt zu werden. So kann auch ein Maschienencode eingebettet in einer Batchdatei und auch auf einer Festplatte sich befinden und von dort in unveränderten Form zur Ausführung gebracht werden. Mit direkt von der CPU ausführbar bedeutet in diesem Zusammenhang doch nur, dass die Bytes selber für die Ausführung nicht verändert werden brauchen, also auch wenn diese Bytes erst zu einer CPU noch befördert werden müssen, ist danach die direkte Ausführung solcher unveränderten Bytes möglich.
Also sind die Bitmuster auf der Festplatte definitiv KEIN Maschinencode.
http://de.wikipedia.org/wiki/Run_Length_Limited
Da finde ich so eine einfache Hex-Codierung wie im C-Quelltext aber doch viel einfacher als das, was die Festplatte da codiert.freecrac schrieb:
Wenn jedoch die Bytes erst verändert werden müssen, um ausführbar zu werden, z.B wenn diese Byte vorher komprimiert wurden, dann sind die Byte in dieser Fom nicht ausführbar und damit auch noch kein Maschinencode, sondern diese Bytes müssen erst wieder ausgepackt und damit verändert werden, um ausgeführt werden zu können.
Tja, mir reicht es auch, wenn die Codierung ausreichend trivial und eindeutig ist.
Als Purist müßtest Du sagen, daß nur die Folge von Nullen und Einsen als Maschinencode gelten kann. Bereits die Spannungslevel auf dem Bus sind eine Codierung. Man müßte zum Beispiel dazusagen, ob 0=LO 1=HI oder 0=HI 1=LO gilt, um es überhaupt decodieren zu können.
-
tgdgdgd schrieb:
der name shellcode kommt daher, dass diese codes oft dazu verwendet werden, ein programm welches mit root rechten läuft dazu zu bekommen, eine shell (terminal, konsole) zu starten, welche auch mit root rechten läuft.
dann hat man plötzlich als otto normal user root rechte, kann also so ziemlich alles mit dem system anstellen.Sehr schon gesagt. Das Wort "shellcode" läuft uns davon! Muss jetzt keine shell mehr aufmachen, muss nur irgendwie was Nettes machen und per Pufferüberlauf-Exploit oder Ähnliches ausführbar sein, nichtmal erhöhte Rechte erzeugen.
Nu kommen sogar Leute her und assemblieren den Code nicht mehr, und tragen ihn in eine shellcode-Datenbank ein, wie gemein von ihnen!
http://www.shell-storm.org/shellcode/files/shellcode-146.phpIch fürchte, der Unterscheidung zwischen Assembler-Code und Maschinen-Code geht es irgendwann auch an den Kragen. Hat ja auch nicht gerade mehr die Praxisrelevanz heute.
Das macht natürlich die allgemeingültigen Definitionen ein wenig schwierig.
-
Hallo freecrac,
ich kann ja verstehen, dass man genaue Definitionen zu gewissen Begriffen haben möchte.
Aber ich denke, in dem Thread ist jetzt alles geklärt.
Und verschiedene Leute haben halt leicht unterschiedliche Erklärungen zu bestimmten Begriffen. Diese Schwammigkeit ist in der Praxis einfach vorhanden, damit muss man wohl oder übel leben.Wenn du dich näher mit Shellcode, Hacking sowie 'Reversen' auseinandersetzen möchtest, so lerne es. Nur durchs Rumspielen erhältst du ein gutes Gefühl, wie das ganze funktioniert. Und dann brauchst du auch keine genaue Definition von irgendeinem Begriff mehr.
Wenn du kein Geld für Bücher ausgeben möchtest, lies z.B. das hier:
Smashing The Stack For Fun And Profit
http://insecure.org/stf/smashstack.htmlWriting Shellcode
http://staff.ustc.edu.cn/~sycheng/sst/exp_bof/Writing_shellcode.htmlWenn du dich näher mit dem Thema auseinandersetzen möchtest, so kann ich dir folgendes Buch empfehlen. Es hat eine vorbereitete Linux CD dabei, welche du in einer virtuellen Maschine installieren kannst. Damit kannst du alle Beispiele des Buches probieren (gesamter Sourcecode ist dabei).
**Hacking - Art of Exploitation von Jon Erickson
**