Grundlagen von Reversing und Pwn

Zwei eng verwandte CTF-Kategorien beschäftigen sich mit kompilierten Programmen:

• Reverse Engineering (Rev) — Sie analysieren ein Binary, um zu verstehen, was es tut, häufig um eine Passwortprüfung oder verborgene Logik zu finden, die das Flag ausgibt.
• Pwn (Binary-Exploitation) — Sie finden eine Schwachstelle in der Speichersicherheit eines laufenden Binaries und nutzen sie aus, um die Ausführung zu übernehmen, oft mit dem Ziel, eine Shell auf einem entfernten Dienst zu starten, der das Flag enthält.

Bei Rev geht es ums Verstehen, bei Pwn ums Übernehmen. Für beides benötigen Sie einen sicheren Umgang mit Low-Level-Konzepten.

Öffnen Sie ein Binary niemals unvorbereitet in einem Disassembler. Untersuchen Sie es zunächst mit schnellen Befehlszeilen-Tools, um seinen Typ, seine Architektur und offensichtliche Zeichenketten zu ermitteln.

Sie analysieren Binaries auf zwei sich ergänzende Arten:

• Statische Analyse — lesen Sie den Code, ohne ihn auszuführen, und verwenden Sie dazu einen Disassembler oder Decompiler wie Ghidra oder eine Disassembler-Ansicht. Sie sehen den vollständigen Kontrollfluss, müssen Laufzeitwerte jedoch erschließen.
• Dynamische Analyse — führen Sie das Programm unter einem Debugger wie GDB aus und beobachten Sie die tatsächlichen Werte in Registern und im Speicher. Sie sehen genau, was geschieht, aber nur entlang des ausgeführten Pfads.

Erfahrene Spieler wechseln zwischen beiden Methoden: Sie lesen statisch, um eine Theorie aufzustellen, und bestätigen sie dynamisch, indem sie die Ausführung schrittweise verfolgen.

Für das Reverse Engineering lesen Sie Assembler. Sie müssen ihn nicht fließend schreiben können, aber Sie müssen bestimmte Muster erkennen:

• cmp / test gefolgt von einem Sprung (je, jne) ist ein Vergleich mit Verzweigung – oft die Passwortprüfung.
• call ruft eine Funktion auf; die Argumente wurden unmittelbar davor in Registern oder auf dem Stack abgelegt.
• mov verschiebt Daten zwischen Registern, Speicher und Konstanten.

Wenn Sie ein cmp gegen Ihre Eingabe finden, auf das eine Verzweigung zu einer Erfolgsmeldung folgt, haben Sie die Prüfung gefunden. Ermitteln Sie nun den erwarteten Wert oder umgehen Sie die Prüfung.

Moderne Decompiler wandeln Assembler wieder in annäherndes C um, das sich wesentlich schneller lesen lässt als rohe Befehle. Eine dekompilierte Passwortprüfung könnte so aussehen:

Pwn-Challenges nutzen Programme aus, die Eingaben in einen Puffer fester Größe einlesen, ohne deren Länge zu prüfen. Der Stack speichert lokale Variablen und die gespeicherte Rücksprungadresse, die der CPU vorgibt, wohin sie beim Beenden einer Funktion springen soll.

Wenn eine Eingabe einen lokalen Puffer überlaufen lässt, kann sie diese gespeicherte Rücksprungadresse überschreiben. Wer die Rücksprungadresse kontrolliert, kontrolliert das nächste Ausführungsziel.

Der einfachste Pwn-Exploit besteht darin, die Rücksprungadresse zu überschreiben und zu einer Funktion zu springen, die das Programm niemals aufrufen sollte – etwa zu einem versteckten win(), das das Flag ausgibt.

Der Ablauf:

• Ermitteln Sie den genauen Offset vom Anfang des Puffers bis zur Rücksprungadresse. Ein Tool für zyklische Muster liefert ihn schnell.
• Ermitteln Sie die Adresse der Zielfunktion.
• Senden Sie zunächst Padding bis zum Offset und überschreiben Sie dann die Rücksprungadresse mit dem Ziel.

Echte Binaries aktivieren Schutzmechanismen, die naive Buffer-Overflows verhindern. Sie müssen diese mit checksec erkennen:

• Stack-Canaries — ein geheimer Wert wird vor der Rücksprungadresse platziert. Wenn er sich ändert, wird das Programm abgebrochen. Sie müssen ihn zuerst auslesen.
• NX (No-eXecute) — der Stack ist nicht ausführbar, daher können Sie dort abgelegten Shellcode nicht ausführen.
• ASLR / PIE — die Adressen werden bei jedem Lauf randomisiert, daher benötigen Sie vor dem Anvisieren eines Ziels zunächst ein Adressleck.
• RELRO — schützt die Global Offset Table vor Überschreibungen.

Jeder Schutzmechanismus führt Sie zu fortgeschritteneren Techniken.

Wenn NX Sie daran hindert, eigenen Code auszuführen, nutzt Return-Oriented Programming bereits im Binary vorhandenen Code wieder.

Sie verketten kurze Befehlssequenzen, sogenannte Gadgets, die jeweils mit ret enden, um Schritt für Schritt Aktionen auszuführen – beispielsweise ein Register zu laden und eine Bibliotheksfunktion aufzurufen, die eine Shell startet. Sie bauen die Kette auf dem Stack auf, sodass jedes ret zum nächsten Gadget springt.

ROP bildet die Brücke von anfängerfreundlichen Overflows zur Exploitation in der Praxis, bei der Angreifercode nur selten direkt ausführbar ist.

Ein weiteres klassisches Pwn-Grundelement ist die Format-String-Schwachstelle, bei der Benutzereingaben direkt als Formatargument an eine Ausgabefunktion übergeben werden.

Sie lernen, Speicherfehler präzise auszunutzen, gerade damit Sie sie verhindern können. Die defensiven Erkenntnisse sind konkret:

• Verwenden Sie niemals unbeschränkte Eingabefunktionen wie gets oder strcpy, sondern Alternativen mit Längenprüfung.
• Halten Sie Schutzmechanismen aktiviert: Canaries, NX, vollständiges ASLR/PIE und vollständiges RELRO.
• Bevorzugen Sie speichersichere Sprachen, sofern das Bedrohungsmodell dies zulässt.
• Behandeln Sie jeden benutzerkontrollierten Wert, der eine Format-String-Verarbeitung oder eine Pufferkopie erreicht, im Code-Review als ernsthaften Befund.

Sie verfügen nun über einen Überblick zu Reverse Engineering und Pwn:

• Führen Sie bei jedem Binary zunächst mit file, strings und checksec eine Triage durch, bevor Sie es eingehend analysieren.
• Kombinieren Sie statische Analysen mit Disassembler oder Decompiler und dynamische Analysen mit einem Debugger, um die Logik zu verstehen.
• Pwn beginnt mit dem Stack-Buffer-Overflow, der eine Rücksprungadresse überschreibt; Schutzmechanismen wie Canaries, NX, ASLR/PIE und RELRO erhöhen die Hürde.
• ROP umgeht NX, indem vorhandene Gadgets wiederverwendet werden; Format-String-Schwachstellen entstehen durch nicht vertrauenswürdige Formatargumente.
• Jede Technik vermittelt zugleich eine defensive Lektion für das Schreiben und Überprüfen sichereren Codes.

Als Nächstes stellen Sie ein Toolkit zusammen und lernen, Ihre Lösungen zu dokumentieren.