Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
Obfusk8 — Obfusk8: leichtgewichtige Obfuskationsbibliothek basierend auf C++17 / Nur-Header für Windows-Binärdateien | Kitploit
Tools/GitHubGitHub/x86byte/obfusk8
Exploit-FrameworksReverse EngineeringShellcodeKryptographiePenetrationstestsRed TeamingPayload-Entwicklung
GitHubx86byte/obfusk8

Obfusk8

Obfusk8: leichtgewichtige Obfuskationsbibliothek basierend auf C++17 / Nur-Header für Windows-Binärdateien

Repository anzeigen
79382vor 1 MonatVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

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.

banner


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 -Anweisungen in Kombination mit opaken Prädikaten (Bedingungen, die immer zu oder ausgewertet werden, aber rechnerisch aufwändig oder schwer statisch zu bestimmen sind). Dies erzeugt ein Labyrinth von falschen Pfaden für Disassembler und Decompiler.

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 -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.

5. Indirekte Syscall-Engine (K8_SYSCALL)

Obfusk8 integriert nun eine hochmoderne Indirekte Syscall-Mechanik, um User-Mode-Hooks (EDRs/AVs) und statische Analyse-Prüfungen zu umgehen.

  • „Der sprechende Hut"-Auflösung: Anstatt den .text-Abschnitt von ntdll.dll zu lesen (der oft gehooked oder überwacht wird), parst die Engine das Exportverzeichnis. Es filtert Funktionen, die mit Zw beginnen, sortiert sie nach Speicheradresse und leitet die Systemaufrufnummer (SSN) basierend auf ihrem Index ab. Dies ermöglicht die SSN-Auflösung, ohne jemals ausführbaren Code zu berühren.
  • Laterale Gadget-Ausführung: Die Engine enthält nicht die Syscall-Instruktion (0F 05) in ihrer eigenen Binärdatei. Stattdessen findet sie zur Laufzeit ein gültiges syscall; ret-Gadget innerhalb des ntdll.dll-Speichers.
  • Saubere Aufrufstapel: Ein benutzerdefinierter Thunk wird allokiert, der zum ntdll-Gadget springt. Für den Betriebssystemkern und Sicherheitssensoren scheint der Systemaufruf legitim von ntdll.dll zu stammen, was einen sauberen Aufrufstapel bewahrt.
  • Verwendung: Verwenden Sie einfach K8_SYSCALL("ZwOpenProcess", ...) anstelle von NtOpenProcess.

6. Methodenbasierte Obfuskation mit (OBF_METHOD)

Obfusk8 bietet jetzt eine granulare Kontrolle über die Sicherheit Ihrer Binärdatei durch methodenbasierte Obfuskation. Anstatt Ihr gesamtes Projekt zu obfuskieren (was die Leistung beeinträchtigen kann), können Sie jetzt selektiv spezifische, hochwertige Funktionen oder Klassenmethoden schützen.


Verwendung

  1. Binden Sie den Pass ein
    Stellen Sie sicher, dass Sie die Methoden-Obfuskationslogik in Ihr Projekt einbinden: ```cpp #include "../transform/PASSES/obf_cmethods.cxx"
    root@kitploit:~
  2. Die Makro-Syntax
    Definieren Sie Ihre Methode mit dem OBF_METHOD-Makro: ```cpp OBF_METHOD(ret_type, func_name, params, method_body)
    root@kitploit:~
  • ret_type: Der Rückgabetyp Ihrer Funktion (z.B. bool, int, void*).
  • func_name: Der Name der Methode.
  • params: Die Funktionsparameter (müssen in Klammern eingeschlossen sein).
  • method_body: Die eigentliche Logik Ihrer Funktion, eingeschlossen in { }.

Beispiel: Standard- vs. obfuskierte Methoden

In diesem Beispiel ist PrintStatus eine normale, lesbare Funktion. Obfusk8_PrintStatus wird durch Obfusk8 geschützt.```cpp #include "../Instrumentation/materialization/state/Obfusk8Core.hpp" #include "../Instrumentation/materialization/transform/K8_UTILS/k8_utils.hpp" // for the printf_, u can change the printf_ with anything else...

class Obfusk8_C { public: // standard method which is visible to reverse engineers void PrintStatus(void) { printf_("method\n"); }

root@kitploit:~
// Obfuscated method protected by Obfusk8
OBF_METHOD_(void, Obfusk8_PrintStatus, (void),
{
    printf_("same method but Obfuscated\n");
})

};

_main({ Obfusk8_C *pp = new Obfusk8_C; pp->PrintStatus(); pp->Obfusk8_PrintStatus(); delete pp; })

root@kitploit:~
*Sie können das vollständige Beispiel hier einsehen: [obfusk8_methods.cpp](https://github.com/x86byte/Obfusk8/blob/main/Obfusk8/EXAMPLES/obfusk8_methods.cpp)*

---
### 6. API-Abstraktionsklassen mit integrierter Tarnung
Obfusk8 bietet Hilfsklassen, die gängige Mengen von Windows-APIs kapseln. Diese Klassen nutzen bei ihrer Konstruktion automatisch den verdeckten API-Auflösungsmechanismus (`STEALTH_API_OBFSTR`), sodass die zugrunde liegenden Windows-Funktionen aufgelöst werden, ohne offensichtliche statische Importspuren zu hinterlassen.

   - **`K8_ProcessManipulationAPIs::ProcessAPI` (`k8_ProcessManipulationAPIs.hpp`)**:
     *   Bietet bequemen Zugriff auf Windows-APIs für die Prozessmanipulation, wie `OpenProcess`, `TerminateProcess`, `CreateRemoteThread`, `VirtualAllocEx`, `WriteProcessMemory`, `ReadProcessMemory`, `GetProcAddress`, `GetModuleHandleA`, `NtQueryInformationProcess`, `SuspendThread` und `GetCurrentProcessId`.
     *   **Automatische verdeckte Auflösung**: Löst notwendige Funktionen aus `kernel32.dll` und `ntdll.dll` auf verdeckte Weise auf.
     *   Vereinfacht die Durchführung von prozessbezogenen Operationen mit reduziertem Fußabdruck für die statische Analyse. Enthält das `PROCESSINFOCLASS`-Enum für die Verwendung mit `NtQueryInformationProcess`.

   - **`k8_CryptographyAPIs::CryptographyAPI` (`k8_CryptographyAPIs.hpp`)**:
     *   Bietet Wrapper für gängige Windows Cryptography API (CAPI/CNG)-Funktionen. (Die Funktionalität hängt von der tatsächlichen Implementierung dieser Datei ab – das bereitgestellte Snippet war ein Duplikat. Angenommen werden typische CAPI-Funktionen wie `CryptAcquireContextA`, `CryptCreateHash` usw.)
     *   **Automatische verdeckte Auflösung**: Löst notwendige Funktionen hauptsächlich aus `advapi32.dll` (und `kernel32.dll` für Kernfunktionen) auf verdeckte Weise auf.
     *   Erleichtert kryptografische Operationen, während die Offenlegung der Nutzung von Krypto-APIs minimiert wird.

   - **`k8_NetworkingAPIs::NetworkingAPI` (`k8_NetworkingAPIs.hpp`)**:
     *   Bietet einfachen Zugriff auf eine breite Palette von Netzwerkfunktionen aus `wininet.dll` (z.B. `InternetOpenA`, `HttpOpenRequestA`, `FtpPutFileA`), `urlmon.dll` (z.B. `URLDownloadToFileA`), `ws2_32.dll` (z.B. `socket`, `connect`, `WSAStartup`), `shell32.dll` (z.B. `ShellExecuteA`), `dnsapi.dll` (z.B. `DnsQuery_A`) und `mpr.dll` (z.B. `WNetOpenEnumA`).
     *   **Automatische verdeckte Auflösung**: In seinem Konstruktor verwendet es `STEALTH_API_OBFSTR` und `OBFUSCATE_STRING`, um alle erforderlichen Funktionen aus ihren jeweiligen DLLs (und `kernel32.dll` für `LoadLibraryA`/`GetLastError`) aufzulösen, ohne offensichtliche Importspuren zu hinterlassen.
     *   Vereinfacht das Tätigen verschleierter Netzwerkanfragen und die Durchführung anderer netzwerkbezogener Aufgaben.

   - **`RegistryAPIs::RegistryAPI` (`k8_RegistryAPIs.hpp`)**:
     *   Kapselt häufig verwendete Windows-Registrierungsfunktionen wie `RegSetValueExA`, `RegCreateKeyExA`, `RegOpenKeyExA`, `RegQueryValueExA`, `RegCloseKey` usw.
     *   **Automatische verdeckte Auflösung**: Löst Funktionen aus `advapi32.dll` (und `kernel32.dll`) während der Konstruktion auf verdeckte Weise auf.
     *   Hilft bei der Durchführung von Registrierungsoperationen mit weniger nachverfolgbaren API-Aufrufen.

### 7. Kern-Verschleierungsprimitiven (Makros in `Obfusk8Core.hpp`)
Dies sind die Bausteine, die in der gesamten Bibliothek häufig verwendet werden, insbesondere im `_main`-Makro und der VM-Engine:
*   **Mixed Boolean-Arithmetic (MBA)**: Transformiert einfache mathematische und logische Operationen (ADD, SUB, XOR, NOT, MUL) in komplexe, aber äquivalente Folgen von bitweisen und arithmetischen Formeln (z.B. `OBF_MBA_ADD`, `OBF_MBA_XOR`). Sie sind so konzipiert, dass es für Decompiler sehr schwierig ist, sie wieder in ihre ursprüngliche Form zu vereinfachen.
*   **Undurchsichtige Prädikate (Opaque Predicates)**: Fügt bedingte Verzweigungen ein, bei denen die Bedingung immer wahr (z.B. `OBF_OPAQUE_PREDICATE_TRUE_1`) oder immer falsch (z.B. `OBF_OPAQUE_PREDICATE_FALSE_1`) ausgewertet wird. Diese Bedingungen werden aus komplexen, schwer statisch auswertbaren Ausdrücken unter Verwendung von `__COUNTER__`, `__LINE__`, `__TIME__` und dem `_obf_global_opaque_seed` konstruiert. Sie erzeugen irreführende Codepfade und können verwendet werden, um toten Code zu schützen oder spezifische Ausführungsflüsse zu erzwingen.
*   **Müllcode-Injektion (Junk Code Injection)**:
    *   `OBF_CALL_ANY_LOCAL_JUNK`: Ruft eine von vielen kleinen, zufälligen Müllfunktionen auf, die in `obf_junk_ns` definiert sind. Diese Funktionen führen triviale, flüchtige Operationen aus und werden zur Kompilierzeit zufällig ausgewählt. Ihr Zweck ist es, die Code-Entropie zu erhöhen, einfache Codemuster zu durchbrechen und möglicherweise signaturbasierte Erkennungs- oder Analysetools in die Irre zu führen.
    *   `NOP()`: Ein Makro, das flüchtige Operationen einfügt, die darauf ausgelegt sind, eine einfache Entfernung durch Optimierer zu verhindern und subtil einen globalen Seed zu modifizieren.
*   **Anti-Disassembly- & Anti-Analyse-Tricks**:
    *   **Verschleierte Sprünge (`OBF_JUMP_*`-Makros)**: Erzeugt `goto`-Anweisungen, deren Bedingungen oder Ziele verschleiert sind, oft unter Verwendung undurchsichtiger Prädikate oder MBA.
    *   **Verschleierte Zustandsübergänge (`OBF_SET_NEXT_STATE_*`-Makros)**: Werden in ICFF verwendet; diese Makros setzen die nächste Zustandsvariable für den abgeflachten Kontrollfluss-Dispatcher unter Verwendung ähnlicher Verschleierungstechniken wie die verschleierten Sprünge.
    *   **Stapel-Manipulation (`OBF_STACK_ALLOC_MANIP`, `OBF_FAKE_PROLOGUE_MANIP`)**: Allokiert variabel große Blöcke auf dem Stack und führt sinnlose Manipulationen an ihnen durch. Gefälschte Prologe versuchen, die Stack-Analyse zu verwirren.
    *   **Verschleierte Funktionsaufrufe (`OBF_CALL_VIA_OBF_PTR`)**: Funktionszeiger werden vor und nach der Verwendung mit einem dynamischen Schlüssel XOR-verknüpft, wodurch das wahre Aufrufziel verschleiert wird.
    *   `K8_ASSUME(0)`: Wird in toten Codepfaden verwendet, um dem MSVC-Compiler mitzuteilen, dass diese Pfade unerreichbar sind, was möglicherweise unterschiedliche Optimierungen oder Code-Generierung ermöglicht, die die Analyse weiter verwirren könnte, falls die Annahme durch einen Patch verletzt wird.

### Abhängigkeiten

Die Obfusk8-Bibliothek ist modular. Die Kernfunktionalität basiert auf:

- `Obfusk8/Instrumentation/materialization/state/Obfusk8Core.hpp`: (Diese Datei) Der zentrale Header, der die Haupt-Verschleierungsmakros und -Primitiven orchestriert und bereitstellt.
- `Obfusk8/Instrumentation/materialization/transform/AES8.hpp`: Bietet AES-basierte Compilerzeit-Zeichenkettenverschlüsselung und optionale PE-Abschnittsmanipulationsfunktionen.
- `Obfusk8/Instrumentation/materialization/transform/Resolve8.hpp`: Implementiert die PEB-basierte verdeckte Windows-API-Auflösung.
* `Obfusk8/Instrumentation/materialization/transform/k8_indsys.hpp`: Orchestriert die **Indirekte Syscall-Engine**. Sie verwaltet den Lebenszyklus von Übergangs-Stubs und stellt die Schnittstelle zur Ausführung von Systemaufrufen durch laterale Speicher-Gadgets bereit.
* `Obfusk8/Instrumentation/materialization/transform/getpeb8.hpp`: Ermöglicht den initialen Bootstrap und die **PEB-Erkennung**. Es enthält die benutzerdefinierte Hashing-Logik, native Strukturdefinitionen und den "Sortierhut"-Algorithmus zur SSN-Ableitung. Es dient als grundlegendes Fundament für alle Aufgaben der Modul-Enumeration.
Optionale Hilfs-API-Klassen werden in separaten Headern bereitgestellt, die sich normalerweise in Unterverzeichnissen befinden:
- `k8_ProcessManipulationAPIs/k8_ProcessManipulationAPIs.hpp`: Für verdeckte Prozessmanipulations-APIs.
- `k8_CryptographyAPIs/k8_CryptographyAPIs.hpp`: Für verdeckte Kryptografie-APIs.
- `k8_NetworkingAPIs/k8_NetworkingAPIs.hpp`: Für verdeckte Netzwerk-APIs.
- `k8_RegistryAPIs/k8_RegistryAPIs.hpp`: Für verdeckte Registrierungs-APIs.

### Visualisierung

  *   **ida graph**:
    
      ![image](https://assets.kitploit.com/production/public/readmes/8984/3e59704c1c37835ddc2e47faf69914ba1fb63943fcd37a983f5690bcc4b4e373.png)
     
  *   **einige Chunks aus ida pro**:
    
      ![image](https://assets.kitploit.com/production/public/readmes/8984/5c24307f490de40a07f88ca20821999c19912088d3047ca9446a84dfda2d0ec7.png)
      ![image](https://assets.kitploit.com/production/public/readmes/8984/edd0c5deae9d9d69006ca4bb1cd0cc0d2ba3e9794ac242460028fe438388c338.png)
      ![image](https://assets.kitploit.com/production/public/readmes/8984/341057315e4d3ea12c920df05ce3e6bcd13ecbc86386ffc3265e80b34f3bdcee.png)
    
  *   **Ergebnisse der "Detect it Easy"-Signaturen**:
    
      ![image](https://assets.kitploit.com/production/public/readmes/8984/007b2a1139fc33a9ff82675e10c8fe99f6be7b1d012ce773a5b7464db6b299ab.png)

  *   **Crowdsourced YARA-Regeln von virustotal**:

      ![yararules](https://assets.kitploit.com/production/public/readmes/8984/b168f882e1f945399908ab0cf4638a151e6991f98ec03460d305c1eca0b482cd.png)


  *   **Speicherkarte (von die)**:

      ![map](https://assets.kitploit.com/production/public/readmes/8984/75d11fce1656cc1944251d0e46f14c88ed9b8684acf5d1230c53f4d7385aaaf8.png)
  
  *   **Abschnitte (sections)**:

      ![sections](https://assets.kitploit.com/production/public/readmes/8984/bdb9bef4c155c4af8a73656ab5bdba533cf3283b7b729d9fa42fbb125e208978.png)

  *   **gebundene Dateien (bounded files)**:

      ![bfiles](https://assets.kitploit.com/production/public/readmes/8984/fe8cf0d963706cdd0fc532144e0e9b118daad7f3ca6d53705b4691b5f8c0aba2.png)

### Engine-Analyse und Erkennungsprofil

Obfusk8 wurde entwickelt, um die Umgehung statischer signaturbasierter Erkennungs-Engines zu priorisieren. Tests mit branchenüblichen Anbietern zeigen, dass die Kern-Verschleierungslogik von wichtigen Sicherheitsprodukten unerkannt bleibt, darunter:

*   **Microsoft Defender**: Unerkannt
*   **Kaspersky**: Unerkannt
*   **ESET-NOD32**: Unerkannt
*   **BitDefender**: Unerkannt

Während statische Signaturen umgangen werden, können bestimmte Next-Gen-AVs und EDRs (wie CrowdStrike oder Symantec) heuristische Flags erzeugen, die als "suspicious" oder "high Confidence Malicious" gekennzeichnet sind. Diese Erkennungen werden typischerweise durch die hohe architektonische Komplexität und das Vorhandensein benutzerdefinierter PE-Abschnitte ausgelöst und nicht durch identifizierbaren bösartigen Code.

### Strukturelle und forensische Merkmale

*   **Entropie-Management**: Die aktuelle Implementierung erzeugt eine globale Entropie von etwa 6,2. Dies ist bewusst so ausbalanciert, dass sie hoch genug ist, um Logik zu verschleiern, aber niedrig genug, um die üblichen "gepackte Datei"-Warnungen zu vermeiden, die durch Entropiewerte über 7,0 ausgelöst werden.
*   **Abschnittsanpassung**: Die Standardkonfiguration umfasst 23 PE-Abschnitte, von denen einige Tarnnamen (z.B. `.themida`, `.vmp0`, `.enigma2`) verwenden, um bekannte kommerzielle Schutzprogramme nachzuahmen.
    *   **Heuristische Optimierung**: Um den Verdachtspunktwert weiter zu senken, können Benutzer diese Abschnitte in generische Zeichenketten umbenennen (z.B. `.data_01`, `.rdata_aux`). Die Standardisierung von Abschnittsnamen senkt oft die heuristische "Einzigartigkeits"-Bewertung, sodass die Binärdatei wie eine herkömmlich kompilierte Anwendung aussieht.
*   **Import-Verschleierung**: Die Bibliothek eliminiert erfolgreich den Import Address Table (IAT)-Fußabdruck für kritische Windows-APIs. Durch die Verwendung des Process Environment Block (PEB) zur Auflösung und der Indirekten Syscall-Engine behält die Binärdatei einen sauberen Aufrufstapel bei, wodurch verhindert wird, dass Verhaltensmonitore Systemaufrufe zurück zu geschützten Codebereichen verfolgen.
     - **Kurze Erklärung**:
        *   **SSN-Ableitung**: Um User-Mode-Hooks zu umgehen, die oft auf dem Anweisungsstrom von ntdll.dll platziert werden, verwendet die Engine einen relativen Sortieralgorithmus. Durch das Parsen des Exportverzeichnisses und das Sortieren aller Zw-präfixierten Funktionen nach ihren Speicheradressen leitet die Engine System Service Numbers (SSNs) basierend auf ihrem relativen Index ab. Dadurch kann das Framework den korrekten Syscall-Index identifizieren, ohne jemals die gehookten Bytes des Funktionsprologs zu lesen.
Dynamische Syscall-Stubs: Anstatt statische Syscall-Anweisungen innerhalb der User-Land-Binärdatei zu verwenden, allokiert die Bibliothek dynamisch ausführbaren Speicher, um vorübergehende Übergangs-Stubs zu hosten. Die Engine füllt diese Stubs mit einer benutzerdefinierten Shellcode-Sequenz (`mov r10, rcx; mov eax, ssnnumber; syscall; ret`), um Systemaufrufe indirekt auszuführen.
        *   **Ketten-Bootstrap**: Der Auflösungsprozess ist selbststartend; die Engine verwendet einen anfänglich aufgelösten Aufruf, um die Umgebung für nachfolgende indirekte Syscalls einzurichten. Dadurch wird sichergestellt, dass der gesamte Lebenszyklus des Prozesses – von der Modulenumeration bis zur Funktionsausführung – für Verhaltensmonitore undurchsichtig bleibt und ein sauberer Aufrufstapel erhalten bleibt.
*   **Anti-Forensik**: Die Verwendung von Mixed Boolean-Arithmetic (MBA) und mehrschichtiger Virtual Instruction Set Architecture (V-ISA) stellt sicher, dass selbst wenn ein Speicherauszug (dump) erstellt wird, die zugrunde liegende Logik durch automatisierte Deobfuskierungs-Tools nur schwer zu rekonstruieren ist.

### Nutzung

1.  Binden Sie `Obfusk8/Instrumentation/materialization/state/Obfusk8Core.hpp` in Ihre Hauptprojektdatei (z.B. `main.cpp`) ein.
    ```cpp
    #include "Obfusk8/Instrumentation/materialization/state/Obfusk8Core.hpp" // Passen Sie den Pfad nach Bedarf an
    ```
2.  Umhüllen Sie den Rumpf Ihrer `main`-Funktion mit dem `_main`-Makro:
    ```cpp
    _main({
        // Hier Ihr ursprünglicher Hauptcode der Anwendung
        // Beispiel:
        // OBFUSCATE_STRING("Hallo, verschleierte Welt!").c_str();
        
        // Verwendung einer API-Wrapper-Klasse
        k8_NetworkingAPIs::NetworkingAPI* netAPI = new k8_NetworkingAPIs::NetworkingAPI;
        if (netAPI->IsInitialized() && netAPI->pInternetOpenA) {
            HINTERNET hInternet = netAPI->pInternetOpenA(OBFUSCATE_STRING("MyAgent").c_str(), INTERNET_OPEN_TYPE_DIRECT, NULL, NULL, 0);
            if (hInternet) {
                // ... hInternet verwenden ...
                netAPI->pInternetCloseHandle(hInternet);
            }
        }

        delete netAPI;
    })
    ```
3.  Verwenden Sie `OBFUSCATE_STRING("Ihr String")` für alle wichtigen Zeichenkettenliterale. Greifen Sie bei Bedarf über die Methode `.c_str()` auf die entschlüsselte Zeichenkette zu, oder verwenden Sie andere Methoden wie `.print_to_console()`, sofern von `Obfusk8/Instrumentation/materialization/transform/AES8.hpp` bereitgestellt.
4.  Verwenden Sie `STEALTH_API_OBFSTR("dll_name.dll", "FunctionNameA")` für direkte verdeckte API-Aufrufe, oder bevorzugen Sie die API-Wrapper-Klassen (z.B. `K8_ProcessManipulationAPIs::ProcessAPI`, `k8_NetworkingAPIs::NetworkingAPI`) für Bequemlichkeit und integrierte Tarnung.
5.  Streuen Sie `OBF_BOGUS_FLOW_*`, `OBF_CALL_ANY_LOCAL_JUNK`, `NOP()` und andere Primitive in leistungsunempfindliche kritische Abschnitte Ihres Codes ein, um zusätzliche Verschleierungsschichten hinzuzufügen.

* Siehe die Datei main.cpp.

### Bauen (Building)

*   **Compiler-Anforderung**: Diese Bibliothek ist für C++17 ausgelegt. Der Microsoft C++-Compiler (`cl.exe`) ist primär vorgesehen, insbesondere für PE-Abschnitts-Features und SEH-Nutzung.
*   **`cl.exe` (MSVC-Compiler) unter Windows erhalten**:
    1.  **Installieren Sie Visual Studio**: Der einfachste Weg, `cl.exe` zu erhalten, ist die Installation von Visual Studio. Sie können die Visual Studio Community Edition kostenlos von der [Visual Studio-Website](https://visualstudio.microsoft.com/downloads/) herunterladen.
    2.  **Workload auswählen**: Stellen Sie während der Installation sicher, dass Sie die Workload "Desktopentwicklung mit C++" auswählen. Dadurch werden der C++-Compiler, das Windows SDK und andere erforderliche Tools installiert.
    3.  **Developer Command Prompt verwenden**: Suchen Sie nach der Installation in Ihrem Startmenü nach "Developer Command Prompt for VS" (z.B. "x64 Native Tools Command Prompt for VS 2022") und führen Sie ihn aus. Diese Eingabeaufforderung stellt automatisch die Umgebungsvariablen (PATH, INCLUDE, LIB) ein, die für die Verwendung von `cl.exe` benötigt werden.
*   **Include-Pfade**:
    *   Stellen Sie sicher, dass das Verzeichnis, das `Obfusk8/Instrumentation/materialization/state/Obfusk8Core.hpp` enthält, im Include-Pfad Ihres Compilers liegt.
    *   Wenn sich `Obfusk8/Instrumentation/materialization/transform/AES8.hpp`, `Obfusk8/Instrumentation/materialization/transform/Resolve8.hpp` und die API-Wrapper-Verzeichnisse (z.B. `k8_NetworkingAPIs/`) nicht im selben Verzeichnis wie `Obfusk8/Instrumentation/materialization/state/Obfusk8Core.hpp` befinden, stellen Sie sicher, dass ihre Pfade ebenfalls korrekt konfiguriert sind. `Obfusk8/Instrumentation/materialization/state/Obfusk8Core.hpp` verwendet für einige seiner internen Includes der API-Wrapper relative Pfade wie `../Obfusk8Core.hpp`, daher ist die Verzeichnisstruktur wichtig. Wenn sich `Obfusk8/Instrumentation/materialization/state/Obfusk8Core.hpp` im Stammverzeichnis Ihres Include-Verzeichnisses für diese Bibliothek befindet, sollten die API-Wrapper in Unterverzeichnissen wie `k8_NetworkingAPIs/` relativ zu dem Ort sein, an dem `Obfusk8/Instrumentation/materialization/state/Obfusk8Core.hpp` sie erwartet, oder passen Sie die Include-Pfade innerhalb von `Obfusk8/Instrumentation/materialization/state/Obfusk8Core.hpp` selbst an.
*   **Kompilierungsbeispiel (mit Developer Command Prompt)**:
    Angenommen, Ihre `main.cpp` und die Obfusk8-Header sind korrekt strukturiert, können Sie mit einem Befehl ähnlich dem folgenden kompilieren:
    ```bash
    cl /std:c++17 /EHsc main.cpp
    ```
    *   nach dem Öffnen von `x64 Native Tools Command Prompt for VS 2022`:
      
        ![x64 Native Tools Command Prompt for VS 2022](https://assets.kitploit.com/production/public/readmes/8984/86c7ebae9ed88a06bb6de06a0766ebeebd213ac98a9f353af8db4dd462acd849.jpg)

        
    *   `/std:c++17`: Gibt den C++17-Standard an.
    *   `/EHsc`: Gibt das C++-Ausnahmebehandlungsmodell an.
    *   `main.cpp`: Ihre Hauptquellcodedatei.
    *   `/I"Pfad/zu/ihren/obfusk8_includes"`: (Optional, falls Header nicht in Standardpfaden sind) Fügen Sie das Verzeichnis hinzu, in dem sich `Obfusk8/Instrumentation/materialization/state/Obfusk8Core.hpp` und seine Abhängigkeiten befinden. Wenn sie sich in Unterverzeichnissen befinden, stellen Sie sicher, dass die relativen Pfade innerhalb von `Obfusk8Core.hpp` mit Ihrem Layout übereinstimmen.
    *   **Hinweis zu Bibliotheken**: Während die verdeckte API-Auflösung darauf abzielt, eine statische Verknüpfung für die verschleierten Funktionen zu vermeiden, erfordern die Windows SDK-Header selbst möglicherweise bestimmte `.lib`-Dateien, die dem Linker zur Verfügung stehen müssen, um nicht verschleierte SDK-Nutzung oder interne Typen aufzulösen (z.B. `Ws2_32.lib`, `Wininet.lib`, `Advapi32.lib` usw.). Bei einem einfachen Projekt wie `cl /std:c++17 /EHsc main.cpp` löst der Linker diese oft automatisch auf, wenn es sich um Standard-Windows-Bibliotheken handelt.

*   **CMAKE**: Sie können Obfusk8 auch mit CMake bauen.
   1. Klonen und in das Repo wechseln: `git clone https://github.com/x86byte/Obfusk8.git` und dann in das Verzeichnis wechseln: `cd Obfusk8`
   2. Konfigurieren und Dateien generieren: `cmake CMakeLists.txt`
   3. Automatische Auswahl der Build-Tools und Kompilieren: `cmake --build .`
   *   nach dem Öffnen von `x64 Native Tools Command Prompt for VS 2022`:
     
        ![x64 Native Tools Command Prompt for VS 2022](https://assets.kitploit.com/production/public/readmes/8984/0f644508b0677934acc81220dfe0131598c22302f78aefaea101cc38e413cb2b.png)

*   **CMAKE && Microsoft Visual Studio**:
    *   nach dem Öffnen von `microsoft visual studio` klicken Sie auf `Ctrl + B`, um das Projekt zu kompilieren:
      
       ![Microsoft Visual Studio](https://assets.kitploit.com/production/public/readmes/8984/23789327b22943c754f4a06e036cb2c7521c5b764d4c78f1363ed0edf974cb1e.png)
        
*   **Überlegungen zur Binärgröße & zukünftige Erweiterungen**:
    *   **Auswirkungen auf die Größe**: Beachten Sie, dass die umfangreiche Verwendung von Header-Only-Verschleierung, insbesondere mit Techniken wie Inline-Müllcode, MBA-Erweiterungen und abgeflachtem Kontrollfluss, zu einer erheblichen Vergrößerung der endgültigen Binärdatei führen kann. Ein kleines Programm könnte von Kilobyte auf potenziell 2 MB oder mehr anwachsen, abhängig von der Intensität der angewendeten Verschleierung.
    *   **Anpassung & Packen (Zukünftige Richtung)**:
        *   Derzeit konzentriert sich Obfusk8 auf die Verschleierung im Code. Benutzer müssen möglicherweise die Verwendung der verschiedenen Makros feinabstimmen (z.B. die Dichte von `OBF_CALL_ANY_LOCAL_JUNK` oder die Komplexität der `_main`-Schleifen reduzieren), wenn die Binärgröße eine kritische Einschränkung darstellt.
        *   Für eine erhebliche Größenreduzierung nach der Verschleierung wäre die Integration oder Verwendung eines externen PE-Packers (wie UPX, MPRESS oder benutzerdefinierte Lösungen) ein separater Schritt.
        *   Die zukünftige Entwicklung von Obfusk8 könnte Optionen für eine granularere Kontrolle über die Verschleierungsintensität oder sogar die Integration von leichtgewichtigen Pack-/Komprimierungs-Stubs direkt in die Bibliothek untersuchen, obwohl dies die Komplexität erheblich erhöhen würde.

### Post-Build-PE-Verschleierung
Obfusk8 enthält ein Post-Build-Skript, um die kompilierte Binärdatei weiter zu härten, indem forensische Artefakte entfernt werden.

*   **Skript-Speicherort**: `Obfusk8/SCRIPTS/obfuscate_pe.ps1`
*   **Was es tut**:
    1.  **Entfernt den Rich Header** — entfernt den MSVC-Build-Umgebungs-Fingerabdruck, der Compiler-Version und Toolchain-Details preisgibt.
    2.  **Fälscht den TimeDateStamp** — ersetzt den PE-Header-Zeitstempel durch einen festen Wert, um die Build-Zeit zu verschleiern.
    3.  **Löscht das Debug-Verzeichnis** — löscht Debug-Verzeichniseinträge, die PDB-Pfade oder Build-Metadaten preisgeben könnten.
*   **Verwendung**:
    Führen Sie es als Post-Build-Schritt nach der Kompilierung aus:
    ```powershell
    PowerShell -NoProfile -ExecutionPolicy Bypass -File Obfusk8/SCRIPTS/obfuscate_pe.ps1 -Path "Pfad\zu\Obfusk8.exe"
    ```
    Das Skript ändert die Binärdatei direkt. Es wird keine Sicherungskopie erstellt.

### Demo
   [[Obfusk8: C++17-Based Obfuscation Library - IDA pro Graph View] ~Video Demo](https://youtu.be/B9g4KSg3tHQ)

### Beitrag & FeedbackDieses Projekt, Obfusk8, ist eine laufende Erkundung fortgeschrittener C++-Verschleierungstechniken. Die aktuelle Version legt eine solide Grundlage mit einer Vielzahl ineinandergreifender Strategien.

*   **Ihr Feedback ist von unschätzbarem Wert**: Als Entwickler von Obfusk8 bin ich sehr an Ihrer Perspektive, Ihren Erkenntnissen und Ihrem Feedback interessiert. Ob es sich um Vorschläge für neue Funktionen, Verbesserungen bestehender Techniken, Berichte über erfolgreiche (oder erfolglose) Reverse-Engineering-Versuche gegen durch Obfusk8 geschützten Code oder allgemeine Gedanken zur Benutzerfreundlichkeit und Effektivität der Bibliothek handelt.
*   **Beitrag**: alle Beiträge sind willkommen und sehr geschätzt. Dieses Projekt lebt von Community-Input und realen Tests, um seine Grenzen zu erweitern und ein noch gewaltigeres Werkzeug zum Schutz von Code zu werden. Bitte zögern Sie nicht, Ihre Gedanken mitzuteilen, Probleme zu melden oder zu seiner Weiterentwicklung beizutragen!.
      *    **[Wie kann man zu Obfusk8 beitragen?](https://opensource.guide/how-to-contribute/)**

### Besonderer Dank
*   [sadMosquito](https://github.com/sadMosquito) — für das Melden von Problemen und das Testen des Projekts

**Haftungsausschluss**
Verschleierung ist eine Verteidigungsschicht, keine narrensichere Lösung. Entschlossene Angreifer mit ausreichender Fähigkeit und Zeit können verschleierten Code oft zurückentwickeln. Obfusk8 zielt darauf ab, die Hürde für solche Bemühungen deutlich zu erhöhen. Verwenden Sie es in Verbindung mit anderen Sicherheitsmaßnahmen.

**Kontakt aufnehmen**
Wenn Sie Feedback teilen, Verschleierungstechniken diskutieren, Reverse-Engineering-Versuche melden oder einfach eine technische Diskussion führen möchten, zögern Sie nicht, mich direkt zu kontaktieren. Ich bin immer offen für konstruktive Gespräche und Zusammenarbeit (ich würde mich freuen, bei verschleierungsbezogenen Projekten oder anderen Dingen mitzuarbeiten).

- x : https://x.com/x86byte  
- telegram: https://t.me/x86byte  
- discord: @x86byte
Tool herunterladen
goto
true
false
  • 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.
  • _main