Erstellen Sie EXE

Selbstisolation ist eine großartige Zeit, um etwas zu beginnen, das viel Zeit und Mühe kostet. Also habe ich beschlossen, das zu tun, was ich immer wollte - meinen eigenen Compiler zu schreiben.



Jetzt kann er Hello World kompilieren, aber in diesem Artikel möchte ich nicht über das Parsen und die interne Struktur des Compilers sprechen, sondern über einen so wichtigen Teil wie die byteweise Zusammenstellung der exe-Datei.

Start

Willst du einen Spoiler? Unser Programm wird 2048 Bytes sein.



Normalerweise besteht die Arbeit mit exe-Dateien darin, deren Struktur zu untersuchen oder zu ändern. Die ausführbaren Dateien selbst werden von den Compilern gebildet, und dieser Prozess scheint für Entwickler etwas magisch.



Aber jetzt werden wir versuchen, es zu beheben!



Um unser Programm zu erstellen, benötigen wir einen HEX-Editor (ich persönlich habe HxD verwendet).



Nehmen wir zunächst den Pseudocode:





Die ersten beiden Zeilen geben Funktionen an, die aus WinAPI- Bibliotheken importiert wurden . Die MessageBoxA- Funktion zeigt ein Dialogfeld mit unserem Text an und ExitProcess informiert das System über das Ende des Programms.

Es macht keinen Sinn, die Hauptfunktion separat zu betrachten, da sie die oben beschriebenen Funktionen verwendet.

DOS-Header

Zunächst müssen wir den richtigen DOS-Header generieren. Dies ist ein Header für DOS-Programme und sollte den Start von exe unter Windows nicht beeinflussen.



Ich habe mehr oder weniger wichtige Felder notiert, der Rest ist mit Nullen gefüllt.





Am wichtigsten ist, dass dieser Header das Feld e_magic enthält, was bedeutet, dass dies eine ausführbare Datei ist, und e_lfanew, das den Versatz des PE-Headers vom Anfang der Datei angibt (in unserer Datei beträgt dieser Versatz 0x80 = 128 Byte).



Großartig, jetzt, da wir die DOS-Header-Struktur kennen, schreiben wir sie in unsere Datei.

, , .



, (Offset) .



, 0x00000000, 64 (0x40 16- ), 0x00000040 ..

Fertig, die ersten 64 Bytes wurden geschrieben. Jetzt müssen Sie 64 weitere hinzufügen, dies ist der sogenannte DOS-Stub (Stub). Beim Start unter DOS muss der Benutzer benachrichtigt werden, dass das Programm nicht für die Ausführung in diesem Modus ausgelegt ist.



Im Allgemeinen ist dies jedoch ein kleines DOS-Programm, das eine Zeile druckt und das Programm beendet.

Schreiben wir unseren Stub in eine Datei und betrachten ihn genauer.





Und jetzt der gleiche Code, aber in zerlegter Form





Das funktioniert so: Zuerst druckt der Stub eine Zeile, die besagt, dass das Programm nicht gestartet werden kann, und beendet dann das Programm mit Code 1. Dies unterscheidet sich von der normalen Beendigung (Code 0).



Der Stub-Code kann sich geringfügig unterscheiden (von Compiler zu Compiler). Ich habe gcc und delphi verglichen, aber die allgemeine Bedeutung ist dieselbe.



Es ist auch lustig, dass die Stichleitung mit \ x0D \ x0D \ x0A $ endet. Der Grund für dieses Verhalten ist höchstwahrscheinlich, dass C ++ die Datei standardmäßig im Textmodus öffnet. Infolgedessen wird das Zeichen \ x0A durch die Sequenz \ x0D \ x0A ersetzt. Als Ergebnis erhalten wir 3 Bytes: 2 Bytes Wagenrücklauf (0x0D), was bedeutungslos ist, und 1 für Zeilenvorschub (0x0A). Im Binärmodus (std :: ios :: binary) tritt diese Ersetzung nicht auf.



Um die Richtigkeit des Schreibens der Werte zu überprüfen, verwende ich Far mit dem ImpEx-Plugin:

NT-Header

Nach 128 (0x80) Bytes gelangten wir zum NT-Header (IMAGE_NT_HEADERS64), der auch den PE-Header (IMAGE_OPTIONAL_HEADER64) enthält. Trotz des Namens ist IMAGE_OPTIONAL_HEADER64 erforderlich, jedoch unterschiedlich für x64- und x86-Architekturen.





Mal sehen, was in dieser Struktur gespeichert ist:





Nachdem wir uns nun angesehen haben, woraus der NT-Header besteht, werden wir ihn analog zu den anderen bei 0x80 auch in eine Datei schreiben.





Als Ergebnis erhalten wir diese Art von IMAGE_FILE_HEADER-, IMAGE_OPTIONAL_HEADER64- und IMAGE_DATA_DIRECTORY-Headern:















Als Nächstes beschreiben wir alle Abschnitte unserer Anwendung gemäß der IMAGE_SECTION_HEADER-Struktur







In unserem Fall haben wir 3 Abschnitte.



Warum Virtual Address (VA) bei 1000 beginnt und nicht bei Null, weiß ich nicht, aber alle Compiler, die ich in Betracht gezogen habe, tun dies. Als Ergebnis sind 1000 + 3 Abschnitte * 1000 (SectionAlignment) = 4000, die wir in SizeOfImage geschrieben haben. Dies ist die Gesamtgröße unseres Programms im virtuellen Speicher. Wird wahrscheinlich verwendet, um Speicherplatz für ein Programm im Speicher zuzuweisen.

 Name	| RAW Addr	| RAW Size	| VA	| VA Size | Attr
--------+---------------+---------------+-------+---------+--------
.text	| 200		| 200		| 1000	| 3D	  |   CER
.rdata	| 400		| 200		| 2000	| 13	  | I   R
.idata	| 600		| 200		| 3000	| B8	  | I   R

Dekodierung von Attributen:



I - Initialisierte Daten, initialisierte Daten

U - Nicht initialisierte Daten, nicht initialisierte Daten

C - Code, enthält ausführbaren Code

E - Ausführen, ermöglicht die Ausführung von

R - Lesecode, ermöglicht das Lesen von Daten aus Abschnitt

W - Schreiben, ermöglicht das Schreiben von Daten in Abschnitt



.text (.code) - speichert ausführbaren Code (das Programm selbst), CE-Attribute

.rdata (.rodata) - speichert schreibgeschützte Daten, z. B. Konstanten, Zeichenfolgen usw., IR-Attribute

.data - speichert Daten, die gelesen und geschrieben werden können, z. B. statische oder globale Variablen. IRW-Attribute

.bss - Speichert nicht initialisierte Daten wie statische oder globale Variablen. Darüber hinaus hat dieser Abschnitt normalerweise eine RAW-Größe von Null und eine VA-Größe ungleich Null, sodass kein Speicherplatz in der Datei belegt wird. URW

.idata- Attribute - Ein Abschnitt mit Funktionen, die aus anderen Bibliotheken importiert wurden. IR-Attribute



Ein wichtiger Punkt, die Abschnitte müssen aufeinander folgen. Darüber hinaus sowohl in der Datei als auch im Speicher. Zumindest als ich ihre Reihenfolge willkürlich änderte, wurde das Programm nicht mehr ausgeführt.



Nachdem wir wissen, welche Abschnitte unser Programm enthalten wird, werden wir sie in unsere Datei schreiben. Hier endet der Versatz bei 8 und die Aufnahme beginnt in der Mitte der Datei.





Die nächste Eintragsadresse ist 00000200, was dem Feld SizeOfHeaders des PE-Headers entspricht. Wenn wir einen weiteren Abschnitt hinzufügen würden, und dies sind plus 40 Bytes, würden unsere Header nicht in 512 (0x200) Bytes passen und müssten 512 + 40 = 552 Bytes verwenden, die durch FileAlignment ausgerichtet sind, dh 1024 (0x400) Bytes. Und alles, was von 0x228 (552) bis zur Adresse 0x400 übrig bleibt, muss mit etwas gefüllt werden, besser natürlich mit Nullen.



Werfen wir einen Blick darauf, wie ein Block von Abschnitten in Far aussieht:







Als Nächstes schreiben wir die Abschnitte selbst in unsere Datei, aber es gibt eine Nuance.



Wie Sie dem SizeOfHeaders-Beispiel entnehmen können, können wir nicht einfach den Header schreiben und mit dem nächsten Abschnitt fortfahren. Da wir zum Aufzeichnen einer Überschrift wissen müssen, wie lange alle Überschriften zusammen dauern werden. Daher müssen wir entweder im Voraus berechnen, wie viel Speicherplatz benötigt wird, oder leere (Null-) Werte schreiben und nach dem Schreiben aller Header ihre tatsächliche Größe zurückgeben und notieren.



Daher werden Programme in mehreren Durchgängen kompiliert. Beispielsweise folgt der Abschnitt .rdata nach dem Abschnitt .text, während die virtuelle Adresse der Variablen in .rdata nicht ermittelt werden kann. Wenn der Abschnitt .text um mehr als 0x1000 (SectionAlignment) Bytes wächst, belegt er die Adressen 0x2000 des Bereichs. Dementsprechend befindet sich der Abschnitt .rdata nicht mehr bei 0x2000, sondern bei 0x3000. Und wir müssen zurückgehen und die Adressen aller Variablen im Abschnitt .text, der vor .rdata steht, neu berechnen.



Aber in diesem Fall habe ich bereits alles berechnet, sodass wir die Codeblöcke sofort aufschreiben werden.

Textabschnitt

Speziell für dieses Programm sind die ersten 3 Zeilen, genau wie die letzten 3, optional.

Die letzten 3 werden nicht einmal ausgeführt, da das Programm bei der zweiten Aufruffunktion beendet wird.



Aber sagen wir mal, wenn es nicht die Hauptfunktion, sondern eine Unterfunktion wäre, sollte es so gemacht werden.



Die ersten 3 sind in diesem Fall zwar wünschenswert, aber wünschenswert. Wenn wir beispielsweise nicht MessageBoxA, sondern printf verwenden würden, würden wir ohne diese Zeilen einen Fehler erhalten.



Gemäß der Aufrufkonvention für 64-Bit-MSDN-Systeme werden die ersten 4 Parameter in den Registern RCX, RDX, R8, R9 übergeben. Wenn sie dort passen und beispielsweise keine Gleitkommazahl sind. Und der Rest wird durch den Stapel geleitet.



Wenn wir theoretisch zwei Argumente an eine Funktion übergeben, müssen wir sie durch Register führen und zwei Stellen im Stapel für sie reservieren, damit die Funktion die Register bei Bedarf auf den Stapel schieben kann. Wir sollten auch nicht erwarten, dass diese Register in ihrem ursprünglichen Zustand an uns zurückgegeben werden.



Das Problem mit der printf-Funktion ist also, dass, wenn wir nur 1 Argument an sie übergeben, immer noch alle 4 Stellen im Stapel überschrieben werden, obwohl anscheinend nur eine um die Anzahl der Argumente überschrieben werden muss.



Wenn Sie nicht möchten, dass sich das Programm seltsam verhält, reservieren Sie immer mindestens 8 Byte * 4 Argumente = 32 (0x20) Byte, wenn Sie mindestens 1 Argument an die Funktion übergeben.



Betrachten Sie einen Codeblock mit Funktionsaufrufen

MessageBoxA(0, 'Hello World!', 'MyApp', 64)
ExitProcess(0)

Zuerst übergeben wir unsere Argumente:



rcx = 0

rdx = die absolute Adresse der Zeichenfolge im Speicher ImageBase + Sections [". Rdata"]. VirtualAddress + Versatz der Zeichenfolge vom Anfang des Abschnitts, die Zeichenfolge wird auf Byte Null gelesen

r8 = ähnlich der vorherigen

r9 = 64 (0x40) MB_ICONINFORMATION , Informationssymbol



Und dann gibt es einen Aufruf der MessageBoxA-Funktion, mit der nicht alles so einfach ist. Der Punkt ist, dass Compiler versuchen, die kürzestmöglichen Befehle zu verwenden. Je kleiner die Befehlsgröße ist, desto mehr solche Befehle passen in den Cache des Prozessors, desto weniger Cache-Fehler, Überladungen und desto schneller ist das Programm. Weitere Informationen zu Befehlen und zum Innenleben des Prozessors finden Sie in den Entwicklerhandbüchern für Intel 64- und IA-32-Architekturen.



Wir könnten die Funktion an der vollständigen Adresse aufrufen, aber das würde mindestens dauern (1 Opcode + 8 Adresse = 9 Bytes), und bei einer relativen Adresse dauert der Aufrufbefehl nur 6 Bytes.



Schauen wir uns diese Magie genauer an: rip + 0x203E ist nichts anderes als ein Funktionsaufruf an der durch unseren Offset angegebenen Adresse.



Ich schaute ein wenig nach vorne und fand die Adressen der Offsets heraus, die wir brauchen. Für MessageBoxA ist es 0x3068 und für ExitProcess ist es 0x3098.



Es ist Zeit, Magie in Wissenschaft zu verwandeln. Jedes Mal, wenn ein Opcode auf den Prozessor trifft, berechnet er seine Länge und fügt ihn der aktuellen Befehlsadresse (RIP) hinzu. Wenn wir RIP in einem Befehl verwenden, gibt diese Adresse daher das Ende des aktuellen Befehls / den Beginn des nächsten an.

Beim ersten Aufruf zeigt der Versatz das Ende des Aufrufbefehls an, dies ist 002A. Vergessen Sie nicht, dass sich diese Adresse im Speicher in den Versatzabschnitten [". Text"] befindet. VirtualAddress, d. H. 0x1000. Daher beträgt der RIP für unseren Anruf 102A. Die Adresse, die wir für MessageBoxA benötigen, lautet 0x3068. Betrachten Sie 0x3068 - 0x102A = 0x203E . Für die zweite Adresse ist alles dasselbe wie 0x1000 + 0x0037 = 0x1037, 0x3098 - 0x1037 = 0x2061 .



Es sind diese Offsets, die wir in den Assembler-Befehlen gesehen haben.

0024	call QWORD PTR [rip + 0x203E]
002A	mov rcx, 0x0
0031	call QWORD PTR [rip + 0x2061]
0037	add rsp, 0x20

Schreiben wir den Textabschnitt in unsere Datei und fügen der Adresse 0x400 Nullen hinzu:

Abschnitt Daten

Dies ist vielleicht der einfachste Abschnitt. Wir werden hier nur zwei Zeilen einfügen und 512 Bytes mit Nullen versehen.

.Idatenabschnitt

Nun, hier ist der letzte Abschnitt, der importierte Funktionen aus Bibliotheken beschreibt.



Das erste, was uns erwartet, ist die neue Struktur IMAGE_IMPORT_DESCRIPTOR







Zuerst müssen wir 2 importierte Bibliotheken hinzufügen. Erinnern:

func MessageBoxA(u32 handle, PChar text, PChar caption, u32 type) i32 ['user32.dll']
func ExitProcess(u32 code) ['kernel32.dll']

Wir verwenden 2 Bibliotheken und sagen, dass wir die Auflistung abgeschlossen haben. Die letzte Struktur ist mit Nullen gefüllt.

 INT	| Time	 | Forward  | Name   | IAT
--------+--------+----------+--------+--------
0x3058	| 0x0    | 0x0      | 0x303C | 0x3068
0x3088	| 0x0    | 0x0      | 0x3048 | 0x3098
0x0000	| 0x0    | 0x0      | 0x0000 | 0x0000

Fügen wir nun die Namen der Bibliotheken selbst hinzu:







Als nächstes beschreiben wir die user32-Bibliothek:





Das Feld Name der ersten Bibliothek zeigt auf 0x303C. Wenn wir etwas höher schauen, sehen wir, dass sich unter der Adresse 0x063C eine Bibliothek "user32.dll \ 0" befindet.



Hinweis: Denken Sie daran, dass der Abschnitt .idata dem Dateiversatz 0x0600 und dem Speicherversatz 0x3000 entspricht. Für die erste Bibliothek ist INT 3058, was bedeutet, dass es in der Datei um 0x0658 versetzt wird. An dieser Adresse sehen wir den Eintrag 0x3078 und die zweite Null. Das Ende der Liste kennzeichnen. 3078 bezieht sich auf 0x0678 Dies ist die RAW-Zeichenfolge



"00 00 4D 65 73 73 61 67 65 42 6F 78 41 00 00 00"



Die ersten 2 Bytes sind für uns nicht von Interesse und gleich Null. Und dann gibt es eine Zeile mit dem Namen der Funktion, die mit Null endet. Das heißt, wir können es als "\ 0 \ 0MessageBoxA \ 0" darstellen.



In diesem Fall bezieht sich der IAT auf eine Struktur ähnlich der IAT-Tabelle, in die jedoch nur die Funktionsadressen geladen werden, wenn das Programm gestartet wird. Beispielsweise hat der erste Eintrag 0x3068 im Speicher einen anderen Wert als 0x0668 in der Datei. Es wird die Adresse der MessageBoxA-Funktion geben, die vom System geladen wird, auf die wir über den Aufruf im Programmcode verweisen.



Und das letzte Puzzleteil, der Kernel32. Und vergessen Sie nicht, SectionAlignment Nullen hinzuzufügen.





Wir überprüfen, ob Far die von uns importierten Funktionen korrekt identifizieren konnte:







Großartig! Alles war in Ordnung, jetzt kann unsere Datei ausgeführt werden.

Trommelwirbel…

Das endgültige

Herzlichen Glückwunsch, wir haben es geschafft!



Die Datei belegt 2 KB = Header 512 Bytes + 3 Abschnitte mit 512 Bytes.



Die Nummer 512 (0x200) ist nichts anderes als die FileAlignment, die wir im Header unseres Programms angegeben haben.



Zusätzlich:

Wenn Sie etwas tiefer gehen möchten, können Sie die Aufschrift "Hello World!" Vergessen Sie nicht, die Adresse der Zeile im Programmcode (Abschnitt .text) zu ändern. Die Adresse im Speicher lautet 0x00402000, aber die Datei hat die umgekehrte Bytereihenfolge 00 20 40 00.



Oder die Suche ist etwas komplizierter. Fügen Sie dem Code einen weiteren MessageBox-Aufruf hinzu. Dazu müssen Sie den vorherigen Anruf kopieren und die relative Adresse (0x3068 - RIP) darin neu berechnen.

Fazit

Der Artikel erwies sich als ziemlich zerknittert, er würde natürlich aus 3 separaten Teilen bestehen: Überschriften, Programm, Importtabelle.



Wenn jemand seine Exe zusammengestellt hat, war meine Arbeit nicht umsonst.



Ich denke darüber nach, bald eine ELF-Datei auf ähnliche Weise zu erstellen. Wäre ein solcher Artikel interessant?)



Links:

• Intel 64- und IA-32-Architekturen Software-Entwicklerhandbücher
  
  Befehls- und Prozessorarchitekturhandbuch.
  
  
• PE (Portable Executable): On Stranger Tides
  
  Ausgezeichneter Artikel zur exe-Dateistruktur.
• Microsoft Documentation Repository
  
  Hier finden Sie Informationen zu Headern, Strukturen, Typen und deren Beschreibung