GELÖST: Maschinencode aus Payload.exe auslesen

crypt_Sig565 · Dez 19, 2016

Hallo Leute.
Bin auf den folgenden Artikel gestoßen

https://www.linkedin.com/pulse/bypa...mohammadbagher?trk=hp-feed-article-title-like

Der Autor gibt an mit Hilfe eines Verschlüsselungsalgorithmus seinen Payload so verschlüsseln zu können dass auf Virustotal kein Scanner ihn erkennt.
Alles soweit klar. Der Autor benutzt Kali Linux msfvenom um sich einen Payload
zu generieren und kann da den hex code mittels cat Befehl ausgeben.
Bin relativ unwissend was Maschienensprache usw angeht.
Mein Problem:
Ich habe einen eigenen Payload in C# geschrieben den ich gerne mal zu testzwecken auf die Art verschlüsseln will. (Meiner besteht aus einem rat und einem intigrierten keylogger.) Wenn ich das tun will brauch ich aber genau wie bei seinem msfvenom payload den ausführbaren Maschienencode um ihn in das Verschlüsselungsprogramm einfügen zu können. Bei einer Google suche wie z.B
"Maschienencode aus .exe auslesen" bin ich leider nicht fündig geworden. Es heisst immer was von Hex-Editoren. Doch öffnet man eine .exe damit ist das ja nicht der richtige Maschienencode der angezeigt wird, sondern auch eine reihe Hexadezimalzahlen mit einer Reihe ASCII Zeichen an der rechten Seite. Irgendwie gibt es da ja einen Unterschied. In der Schule arbeiten wir mit Atmel Mikrocontrollern. Dort verwenden wir auch eine IDE in welcher wir den Assemblercode zu Maschienencode umwandeln. öffnet man so eine Datei dann im integrierten Hex Editor ist das was ganz anderes wie das was im eigentlichen ausführbaren Code drin steht.??????????X( Mein Lehrer wusste auch nicht was es mit diesen ASCII Zeichen auf sich hat:::HEUL
Kann mir mal einer den Unterschied erklären?
Hab mir jetzt extra mal den Immunity Debugger besorgt aber auch da!
Immer nur diese komischen Hexzahlen mit den Ascii Zeichen an der Seite!!!
Wie bekomm ich das was in dem Artikel gefordert wird? Also den reinen Maschienencode? Bitte um Hilfe das macht mich echt fertig langsamX(
Danke schonmal für die Antworten.

CDW · Dez 19, 2016

zu generieren und kann da den hex code mittels cat Befehl ausgeben.

Nein. Mittels cat gibt er den Inhalt der generierten "backdoor.c" aus. Das ist ein kleiner, aber feiner Unterschied.

Mein Problem:
Ich habe einen eigenen Payload in C# geschrieben den ich gerne mal zu testzwecken auf die Art verschlüsseln will. (Meiner besteht aus einem rat und einem intigrierten keylogger.) Wenn ich das tun will brauch ich aber genau wie bei seinem msfvenom payload den ausführbaren Maschienencode um ihn in das Verschlüsselungsprogramm einfügen zu können. Bei einer Google suche wie z.B
"Maschienencode aus .exe auslesen" bin ich leider nicht fündig geworden.

Aus einer Binary (Executable, Exe) ausgelesener Maschinencode bringt i.d.R. nichts, da dieser sich auf Daten, Коnstanten und Resourcen der Exe bezieht, von verschiedenen Bibliotheken aka SO (Shared Object) bzw. DLL (Dynamic Link Library) ganz zu schweigen.
D.h. der Maschinencode an sich ist (in der Regel) ohne den Kontext in Form von Daten&Co nicht lauffähig.
Und bei C# haben wir auch noch Bytecode für NET, statt Maschienencode

D.h. Du müsstest entweder einen _passenden_ Payload benutzen (wie der Autor) ODER den C#-Launcher etwas umschreiben, denn das Laden und Ausführen von kompletten NET-Exen ist möglich und machbar (google Assembly.Load, siehe sowas wie Load an EXE File and Run It from Memory - CodeProject).

Doch öffnet man eine .exe damit ist das ja nicht der richtige Maschienencode der angezeigt wird,
sondern auch eine reihe Hexadezimalzahlen mit einer Reihe ASCII Zeichen an der rechten Seite.

Ich glaube, Du verwechselst hier etwas. Maschinencode (es ist keine Schiene!

) ist das, was die "Maschine" (CPU) direkt ausführen kann. Eine ebene höher ist Assembly - die Sprache a la (ADD REGISTER; VALUE), die (zumindest theoretisch) 1:1 in Maschinencode übersetzt wird.

Da wir keine Maschinen sind, können wir den Maschinencode nur mit Hilfsmitteln betrachten. Z.B mittels Hexeditor.
Das, was wir im Hexeditor sehen, ist reine Darstellung der Daten im anderen Format. Ob jetzt binär, octal oder eben im Hexadezimalformat. Dateninhalt und Datendarstellung sind jetzt zwei verschiedene paar Schuhe:
Z.B sehen wir hier

elf Smileys. Oder in hexadezimaler Darstellung 0x0B. Oder octal 013. Oder dezimal 11.
Egal wie man es dreht, es bleiben zwei Händer und 1 Finger Smileys.

Und dieses "ASCII-Zeug" ist auch nur ein weiteres Format, nichts mehr. Da Exen keine ASCII-Text-Dateien sind, muss man sich nicht wundern, falls die Darstellung als ASCII-Text keinen Sinn ergibt

crypt_Sig565 · Dez 19, 2016

Okay danke für die schnelle Antwort!

Werde mir mal den Link anschauen den du reingestellt hast.
Also der Zusammenhang von Assembler und Maschinensprache ist mir schon geläufig. Ein Assembler Befehl entspricht 1-3 Bytes und besteht aus einem Op-Code und einem oder mehreren Operanden, z.B Register, Konstanten, Adressen usw. Was mir aber Kopfzerbrechen bereitet ist diese Doppelansicht in den Hexeditoren.
ganz links immer die Speicheradressen, soweit klar.
Dann in der Mitte die Hexzahlen in entweder 32bit oder 64 Bit pro Zeile. Berichtige mich Bitte wenn ich falsch liege. Was nützt einem aber dann diese wirre ASCII Übersetzung an der Seite? Wie du sagst, macht ja eigentlich keinen großen Sinn...
Außerdem verwirrt mich in der Ansicht schon in den Hexzahlen dass da teilweise ewige Sequenzen auftretten nur mit 00 00 00 00 00 00 00 00 00 00 00 00 00....
welche dann rechts wieder nur auf ......................... zurückführen.
Das sind ja werder Opcodes noch operanden. Versteh jetzt den Zusammenhang noch nicht ganz. Um mal auf das einzugehen was du gesagt hast:
Diese mehr oder weniger für den Prozessor sinnfreien hexzahlen die beim öffnen einer .exe im hex-Editor auftreten werden dann erstmal von den .exe internen .dll etc. verwendet und vom .NET Framework interpretiert bevor ein für den Prozessor verständlicher Maschinencode erzeugt wird?
Falls ja, gibt es eine Möglichkeit diesen erzeugten Code mitzuschneiden und ihn so in das Programm zu übernehmen? (Denke eher nicht aus Kompatiblitätsgründen??)

CDW · Dez 19, 2016

crypt_Sig565 hat gesagt.:
Was nützt einem aber dann diese wirre ASCII Übersetzung an der Seite? Wie du sagst, macht ja eigentlich keinen großen Sinn...

Tradition, nehme ich an. Es ist ja nicht so, dass man mit einem Hexeditor unbediengt nur Exen betrachten muss oder dass es keine spezialisierteren Werkzeuge für Exe-Betrachtung gibt. PE-View, CFF-Explorer, FileAlizer usw.

Außerdem verwirrt mich in der Ansicht schon in den Hexzahlen dass da teilweise ewige Sequenzen auftretten nur mit 00 00 00 00 00 00 00 00 00 00 00 00 00....
welche dann rechts wieder nur auf ......................... zurückführen.
Das sind ja werder Opcodes noch operanden. Versteh jetzt den Zusammenhang noch nicht ganz.

Eine ist Exe in verschiedene Sectionen unterteilt - Code, Daten, Resourcen, häufig deutlich mehr.
Die Sectionen dürfen nicht an jeder beliebierer Adresse a|nfangen, sondern nur an einem Vielfachen von 512. Mittlerweile wird von moderenen Compilern eher 4096 bevorzugt. D.h. es können mal eben paar tausend 00 zwischen den Sectionen zum Auffüllen benutzt werden, von irgenwelchen großen, vorinitialisierten Datensturkturen mit vielen Nullen ganz abgesehen

Um mal auf das einzugehen was du gesagt hast:
Diese mehr oder weniger für den Prozessor sinnfreien hexzahlen die beim öffnen einer .exe im hex-Editor auftreten werden dann erstmal von den .exe internen .dll etc. verwendet und vom .NET Framework interpretiert bevor ein für den Prozessor verständlicher Maschinencode erzeugt wird?

Prinzipiell richtig, auch wenn ziemlich wild zusammengewürfelt.
Die DLLs werden nicht in der Exe versteckt. Stattdessen gibt es in der Exe eine Liste mit DLLs sowie zu jeder DLL eine Liste mit Funktionen, die aus dieser DLL benutzt werden (sollen).

Beim Starten der Exe wird vom Windows-PE-Loader eine spezielle Tabelle mit diesen Adressen gefüllt (und die DLLs in den Adressraum der Exe geladen).
Der Code, der die Funktionen der DLLs nutzt, macht dies i.d.R. über indirekte Calls:

Code:

call [mytable+some_offset_xxx]

D.h. ohne eine Vorinitialisierung mittels Win-PE-Loader und auch noch entsprechender Tabelle, die i.d.R in der Daten-Section liegt, ist dieser Code schon mal nicht lauffähig.
Der Code kann natürlich die Funktionen auch dynamisch laden (LoadLIbrary, GetProcAddress), ist aber immer noch erstmal auf diese zwei Funktionen angewiesen (sofern man dies nicht selbst erledigt, d.h. den Speicher nach DLLs durchsucht, diese parst und die Adressen so ermittelt, was nicht unbedingt ganz einfach ist

)

Falls ja, gibt es eine Möglichkeit diesen erzeugten Code mitzuschneiden und ihn so in das Programm zu übernehmen? (Denke eher nicht aus Kompatiblitätsgründen??)

Du kannst z.B mit einem PE-Editor die Codesection ausschneiden. Generell macht das aber aus oben genannten Gründen keinen Sinn, denn ohne "Verrenkungen" ist solcher Code "as is", ohne das "drumherum", nicht lauffähig. Shellcodes/Payloads werden halt nicht umsonst "extra" geschieben.

Thunder11 · Dez 19, 2016

crypt_Sig565 hat gesagt.:
Also der Zusammenhang von Assembler und Maschinensprache ist mir schon geläufig. Ein Assembler Befehl entspricht 1-3 Bytes und besteht aus einem Op-Code und einem oder mehreren Operanden, z.B Register, Konstanten, Adressen usw.

Schon mal die x86-Extension Befehlsätze angeschaut? (Bsp: PUNPCKHQDQ aus SSE2)

crypt_Sig565 hat gesagt.:
Das sind ja werder Opcodes noch operanden.

Ein Hex-Editor ist kein Disassembler. Das Ding ist dazu da, den Inhalt aller möglicher Dateien in Hex darzustellen. Daneben steht einfach ASCII. Das ist oft nützlich. Mach mal eine TXT-Datei mit Unicode Zeichen in einem Hex-Editor auf, oder eine rtf-Datei.

Und bzgl. ausführbare Dateien, wenn ich C++ schreibe:

Code:

int main(){
    cout << "Hallo Welt!" << endl;
}

Und das kompiliere, dann steht irgendwo in der .exe-Datei "Hallo Welt!". Und das sehe ich dann im Hex-Editor.

Diese mehr oder weniger für den Prozessor sinnfreien hexzahlen die beim öffnen einer .exe im hex-Editor auftreten werden dann erstmal von den .exe internen .dll etc. verwendet und vom .NET Framework interpretiert bevor ein für den Prozessor verständlicher Maschinencode erzeugt wird?

Du musst hier wirklich sehr stark zwischen exe-Datei mit Maschinencode und .NET exe-Datei unterscheiden. Erstere enthält tatsächlich den Code, der 1:1 auf dem Prozessor läuft. Deine .NET exe wird entweder interpretiert (also anderer Code tut das, was dein Code tun soll) oder eventuell just-in-time kompiliert (so genau weiß ich das bei .NET nicht).
So: wenn der Code interpretiert wird, dann wird NIE Maschinencode aus deinem Code erzeugt. NIE. Das was er tun soll, wird vom Interpreter getan.
Wenn er just-in-time kompiliert wird, dann wird schon Maschinencode für deinen Code erzeugt, aber nicht für den ganzen, sondern nur für Teile.

Falls ja, gibt es eine Möglichkeit diesen erzeugten Code mitzuschneiden und ihn so in das Programm zu übernehmen? (Denke eher nicht aus Kompatiblitätsgründen??)

Wenn ich dich richtig verstanden habe, möchtest du den Maschinencode, der aus der .NET executable erzeugt wird (falls das passiert), in eine Payload für eine andere executable verwandeln?
Das wird an so vielen Stellen scheitern. Nicht dass ich dir nicht helfen will, aber ich habe doch einige Erfahrung mit Maschinencode, Assembler etc. aber das würde ich mir nicht antun. .NET ist vergleichbar schlecht für eine Payload, weil es von den .NET Bibliotheken abhängt, die installiert sein müssen, damit das ganze funktioniert. Auch wenn es funktioniert, gibt es da ASLR...

crypt_Sig565 · Dez 20, 2016

Danke für die Hilfe

Aaaalso habe das Problem gelöst. War eigentlich viel einfacher als gedacht. Der Tipp mit CodeProject war super. Habe den Payload Verschlüsselungsalgorithmus einfach angepasst dann hats auch auf Anhieb funktioniert

Code:

static byte[] GetPayloadBytes(string payloadPath)
		{
			FileStream fs = new FileStream (payloadPath, FileMode.Open);
			BinaryReader br = new BinaryReader (fs);
			byte[] bin = br.ReadBytes (Convert.ToInt32 (fs.Length));
			fs.Close ();
			br.Close ();
			return bin;
		}

		static void Main(string[] args)
		{
			byte[] payload = GetPayloadBytes ("C:\\users\\cryptSIG\\payload.exe");

			for (int i=0; i<payload.Length; i++) {
				Console.Write ("0x{0}, ", payload [i]);
			}
		}

GELÖST: Maschinencode aus Payload.exe auslesen

crypt_Sig565

0

CDW

0

crypt_Sig565

0

CDW

0

Thunder11

0

crypt_Sig565

0