Obfusk8: C++17-basierte Obfuskationsbibliothek

Obfusk8 ist eine leichtgewichtige, header-only C++17 Bibliothek, die entwickelt wurde, um die Obfuskation Ihrer Anwendungen erheblich zu verbessern und Reverse Engineering zu einer deutlich anspruchsvolleren Aufgabe zu machen. Dies wird durch eine vielfältige Reihe von Compilezeit- und Laufzeittechniken erreicht, die darauf abzielen, die Logik und Daten Ihres Codes zu schützen.

---

Inhaltsverzeichnis

1. Kern-Obfuskationsstrategien
2. Abhängigkeiten
3. Visualisierung
4. Engine-Analyse und Erkennungsprofil
5. Strukturelle und forensische Eigenschaften
6. Verwendung
7. Erstellung
8. Demo
9. Mitwirkung & Feedback

---

Kern-Obfuskationsstrategien

1. main-Funktionsumhüllung (_main-Makro)

Der Einstiegspunkt Ihrer Anwendung (main) wird in eine komplexe, mehrschichtige Obfuskations-Engine transformiert:

• Virtuelle Maschinen (VM)-Ausführung (konzeptionell): Bevor Ihr eigentlicher main_body-Code ausgeführt wird, führt eine Mini-VM (simulierte CPU) eine Sequenz von „verschlüsselten" Instruktionen aus. Dies verbirgt den wahren Einstiegspunkt und die anfänglichen Operationen. Der Zustand der VM (Register, Programmzähler, Dispatch-Schlüssel) wird mit Laufzeit-zufällig initialisierten Werten belegt.
• Indirekte Kontrollflussglättung (ICFF): Kritische Schleifen innerhalb des _main-Makros (sowohl im Prolog als auch im Epilog) werden in komplizierte Zustandsautomaten umgewandelt. Der Kontrollfluss ist nicht direkt, sondern wird durch stark „verschlüsselte" Zustandsvariablen bestimmt. Die Kodierungs-/Dekodierungsschlüssel für diese Zustandsvariablen sind dynamisch und werden aus VM-Zustand, Schleifenzählern, Compilezeit-Zufallswerten (wie __COUNTER__, __LINE__, __TIME__) und einem globalen opaken Seed abgeleitet. Dies macht die statische Analyse des Kontrollflusses außergewöhnlich schwierig.
  • Es werden zwei unterschiedliche ICFF-Engines (obf_icff_ns_dcff und obf_icff_ns_epd) mit unterschiedlicher Zustandsübergangslogik und Schlüsselerzeugung verwendet, was die Analyse weiter erschwert.
• Blinder Kontrollfluss (OBF_BOGUS_FLOW_*-Makros): Zahlreiche irreführende Sprungmuster und verworrene bedingte Strukturen werden in _main eingefügt. Diese verwenden goto-Anweisungen in Kombination mit opaken Prädikaten (Bedingungen, die immer zu true oder false ausgewertet werden, aber rechnerisch aufwändig oder schwer statisch zu bestimmen sind). Dies erzeugt ein Labyrinth von falschen Pfaden für Disassembler und Decompiler.
  • Beinhaltet OBF_BOGUS_FLOW_LABYRINTH, OBF_BOGUS_FLOW_GRID, OBF_BOGUS_FLOW_SCRAMBLE, OBF_BOGUS_FLOW_WEAVER, OBF_BOGUS_FLOW_CASCADE und OBF_BOGUS_FLOW_CYCLONE, um vielfältige und komplexe blinde Abläufe zu erzeugen.
• Anti-Analyse & Anti-Debug-Tricks (Runtime-Makro, SEH):
  • Erzwungene Ausnahmen & SEH: Die Strukturierte Ausnahmebehandlung (SEH) wird verwendet, um Pfade zu erzeugen, die erzwungene Ausnahmen beinhalten. Die __except-Blöcke können den Programmzustand ändern, was es schwierig macht, dem Debugger zu folgen, wenn dieser Ausnahmen überspringt.
  • Debugger-Prüfungen (konzeptionell): Das Runtime-Makro enthält Bedingungen, die, falls sie erfüllt sind (aufgrund bestimmter VM-Zustände oder Timing), __debugbreak() auslösen oder Ausnahmen werfen können, was darauf ausgelegt ist, Debugging-Sitzungen zu stören.

2. Virtuelle ISA-Engine (obf_vm_engine)

Eine Kernkomponente der Obfuskation des _main-Makros:

• Benutzerdefinierte Mini-CPU-Simulation: Simuliert eine CPU mit flüchtigen Registern (r0, r1, r2), einem Programmzähler (pc) und einem dispatch_key. Sie führt benutzerdefinierte „Instruktionen" (Handler) aus.
• Obfuskierte Instruktionen: VM-Instruktionshandler führen Operationen aus, die durch Mixed Boolean-Arithmetic (MBA) und Bitmanipulationen stark getarnt sind. Handler umfassen Arithmetik, Bitlogik, Schlüsselverschleierung, Junk-Sequenzen, bedingte Aktualisierungen, Speichersimulation und PC-Verschleierung.
• Dynamischer Dispatch: Die Auswahl des nächsten VM-Instruktionshandlers wird durch mehrere Dispatch-Mechanismen randomisiert:
  • Registerbasierter Dispatch (reg_dispatch_idx).
  • Speichertabellenbasierter Dispatch (verschleierte Funktionszeigertabelle get_mem_dispatch_table).
  • Gemischter Dispatch (mixed_dispatch_idx). Der dispatch_key wird ständig mutiert, wodurch die Sequenz der ausgeführten Handler hochgradig unvorhersehbar ist.
• Mutation der Handlertabelle: Die Tabelle der VM-Instruktionshandler (vm_handler_table) wird selbst zur Laufzeit innerhalb des _main-Prologs und -Epilogs mutiert, was das Verhalten der VM weiter verschleiert.

3. Compilezeit-Zeichenkettenverschlüsselung (OBFUSCATE_STRING aus AES8.hpp)

• Versteckte Zeichenketten: Verschlüsselt alle String-Literale zur Compilezeit mit einem modifizierten AES-Chiffre.
• Dynamische Schlüssel: Die Verschlüsselungsschlüssel sind pro String-Instanz eindeutig und werden aus String-Inhalt, Dateiposition (__FILE__, __LINE__) und Build-Zeit (__DATE__, __TIME__) abgeleitet.
• Just-In-Time-Entschlüsselung: Zeichenketten werden nur bei Zugriff zur Laufzeit auf dem Stack entschlüsselt, wodurch ihre Klartextlebensdauer im Speicher minimiert wird.
• (Optional) Täuschende PE-Sektionen: Kann verschlüsselte Zeichenketten in benutzerdefinierten PE-Sektionen speichern, die dazu entwickelt wurden, gängige Packer-Signaturen nachzuahmen, was möglicherweise Analysten in die Irre führt (MSVC-spezifische Funktion aus AES8.hpp).

4. Verdecktes Windows-API-aufrufen (STEALTH_API_OBFSTR / STEALTH_API_OBF aus Resolve8.hpp)

• IAT-Verschleierung: Vermeidet direkte, leicht identifizierbare Einträge für Windows-APIs in der Import Address Table (IAT).
• PEB-basierte Auflösung: Findet dynamisch die Basisadressen geladener DLLs und die Adressen von API-Funktionen durch direktes Parsen von PEB-Datenstrukturen (Process Environment Block) zur Laufzeit. Dies umgeht die standardmäßige GetModuleHandle- und GetProcAddress-Auflösung für die anfängliche Resolution, falls diese selbst nicht bereits durch diesen Mechanismus aufgelöst wurden.
• Gehashte Namen: Verwendet Compilezeit-Hashing (benutzerdefinierter Algorithmus CT_HASH) von DLL- und API-Namen für Lookups. Dies verhindert, dass Klartext-DLL- und API-Namen in den importbezogenen Daten oder Zeichenkettentabellen der Binärdatei erscheinen, wenn diese Makros verwendet werden.