Obfusk8: Libreria di Offuscamento Basata su C++17

Obfusk8 è una libreria C++17 leggera, header-only, progettata per migliorare significativamente l'offuscamento delle tue applicazioni, rendendo il reverse engineering un'impresa sostanzialmente più difficile. Raggiunge questo obiettivo attraverso un insieme eterogeneo di tecniche compile-time e runtime volte a proteggere la logica e i dati del tuo codice.

---

Indice dei Contenuti

1. Strategie di Offuscamento Principali
2. Dipendenze
3. Visualizzazione
4. Profilo di Analisi e Rilevamento del Motore
5. Caratteristiche Strutturali e Forensi
6. Utilizzo
7. Compilazione
8. Demo
9. Contributi e Feedback

---

Strategie di Offuscamento Principali

1. Wrapping della Funzione main (Macro _main)

Il punto di ingresso della tua applicazione (main) viene trasformato in un motore di offuscamento complesso e multilivello:

• Esecuzione tramite Macchina Virtuale (VM) (Concettuale): Prima che il codice effettivo di main_body venga eseguito, una mini-VM (CPU simulata) esegue una sequenza di istruzioni "crittografate". Questo nasconde il vero punto di ingresso e le operazioni iniziali. Lo stato della VM (registri, program counter, dispatch key) viene inizializzato con valori randomizzati a runtime.
• Indirect Control Flow Flattening (ICFF): I loop critici all'interno della macro _main (sia nel prologo che nell'epilogo) vengono trasformati in intricate macchine a stati. Il flusso di controllo non è diretto ma determinato da variabili di stato pesantemente "crittografate". Le chiavi di codifica/decodifica per queste variabili di stato sono dinamiche, derivate dallo stato della VM, dai contatori di loop, dalla casualità compile-time (come __COUNTER__, __LINE__, __TIME__) e da un seed opaco globale. Questo rende l'analisi statica del flusso di controllo eccezionalmente difficile.
  • Vengono utilizzati due distinti motori ICFF (obf_icff_ns_dcff e obf_icff_ns_epd) con diverse logiche di transizione di stato e generazione delle chiavi, complicando ulteriormente l'analisi.
• Bogus Control Flow (macro OBF_BOGUS_FLOW_*): Numerosi pattern di salto fuorvianti e strutture condizionali contorte vengono iniettati in tutto _main. Questi usano istruzioni goto combinate con predicati opachi (condizioni che valutano sempre vero o falso ma sono computazionalmente costose o difficili da determinare staticamente). Questo crea un labirinto di percorsi falsi per disassembler e decompilatori.
  • Include OBF_BOGUS_FLOW_LABYRINTH, OBF_BOGUS_FLOW_GRID, OBF_BOGUS_FLOW_SCRAMBLE, OBF_BOGUS_FLOW_WEAVER, OBF_BOGUS_FLOW_CASCADE e OBF_BOGUS_FLOW_CYCLONE per generare flussi fittizi diversi e complessi.
• Trucchi Anti-Analisi e Anti-Debug (macro Runtime, SEH):
  • Eccezioni Forzate e SEH: Structured Exception Handling (SEH) viene utilizzato per creare percorsi che coinvolgono eccezioni forzate. I blocchi __except possono alterare lo stato del programma, rendendo difficile seguirlo se il debugger salta le eccezioni.
  • Controlli Anti-Debug (Concettuale): La macro Runtime contiene condizioni che, se verificate (a causa di specifici stati della VM o tempistiche), potrebbero attivare __debugbreak() o lanciare eccezioni, progettate per interrompere le sessioni di debug.

2. Motore ISA Virtuale (obf_vm_engine)

Un componente fondamentale dell'offuscamento della macro _main:

• Simulazione di Mini-CPU Personalizzata: Simula una CPU con registri volatili (r0, r1, r2), un program counter (pc) e una dispatch_key. Esegue "istruzioni" personalizzate (handler).
• Istruzioni Offuscate: Gli handler delle istruzioni VM eseguono operazioni pesantemente mascherate usando Mixed Boolean-Arithmetic (MBA) e manipolazioni bitwise. Gli handler includono aritmetica, logica bitwise, key mangling, sequenze spazzatura, aggiornamenti condizionali, simulazione di memoria e PC mangling.
• Dispatch Dinamica: La selezione del prossimo handler di istruzioni VM viene randomizzata attraverso molteplici meccanismi di dispatch:
  • Dispatch basata su registri (reg_dispatch_idx).
  • Dispatch basata su tabella in memoria (tabella di puntatori a funzione rimescolata get_mem_dispatch_table).
  • Dispatch mista (mixed_dispatch_idx). La dispatch_key viene costantemente mutata, rendendo la sequenza degli handler eseguiti altamente imprevedibile.
• Mutazione della Tabella degli Handler: La tabella degli handler di istruzioni VM (vm_handler_table) viene essa stessa mutata a runtime nel prologo ed epilogo di _main, oscurando ulteriormente il comportamento della VM.

3. Crittografia delle Stringhe Compile-Time (OBFUSCATE_STRING da AES8.hpp)

• Stringhe Nascoste: Crittografa tutti i literal di stringa in compile-time usando una cifratura AES modificata.
• Chiavi Dinamiche: Le chiavi di crittografia sono uniche per ogni istanza di stringa, derivate dal contenuto della stringa, dalla posizione del file (__FILE__, __LINE__) e dal tempo di build (__DATE__, __TIME__).
• Decrittografia Just-In-Time: Le stringhe vengono decrittografate nello stack solo quando vengono accedute a runtime, minimizzando la loro durata in chiaro in memoria.
• (Opzionale) Sezioni PE Decoy: Può memorizzare stringhe crittografate in sezioni PE personalizzate progettate per imitare firme comuni di packer, potenzialmente fuorviando gli analisti (funzionalità specifica MSVC da AES8.hpp).

4. Chiamata Stealth alle API di Windows (STEALTH_API_OBFSTR / STEALTH_API_OBF da Resolve8.hpp)

• Oscuramento della IAT: Evita di lasciare voci dirette e facilmente identificabili per le API Windows nella Import Address Table (IAT).
• Risoluzione Basata su PEB: Trova dinamicamente gli indirizzi base delle DLL caricate e gli indirizzi delle funzioni API analizzando direttamente a runtime le strutture dati del Process Environment Block (PEB). Questo bypassa le funzioni standard GetModuleHandle e GetProcAddress per la risoluzione iniziale, se essi stessi non sono già stati risolti da questo meccanismo.
• Nomi Hashati: Usa l'hashing compile-time (algoritmo personalizzato CT_HASH) dei nomi di DLL e API per le ricerche. Questo impedisce che i nomi in chiaro di DLL e API appaiano nei dati relativi all'import o nelle tabelle di stringhe del binario quando si usano queste macro.

5. Motore Indirect Syscall (K8_SYSCALL)

Obfusk8 ora integra un meccanismo Indirect Syscall all'avanguardia per bypassare gli User-Mode Hook (EDR/AV) e i controlli di analisi statica.

• Risoluzione "The Sorting Hat": Invece di leggere la sezione .text di ntdll.dll (che è spesso hookata o monitorata), il motore analizza l'Export Directory. Filtra le funzioni che iniziano con Zw, le ordina per indirizzo di memoria e deduce il System Call Number (SSN) in base al loro indice. Questo consente la risoluzione dell'SSN senza mai toccare codice eseguibile.
• Esecuzione Laterale tramite Gadget: Il motore non contiene l'istruzione syscall (0F 05) nel proprio binario. Invece, individua a runtime un gadget valido syscall; ret all'interno della memoria di ntdll.dll. Clean Call Stack: Viene allocato un thunk personalizzato che salta al gadget di ntdll. Per il kernel del sistema operativo e i sensori di sicurezza, la chiamata di sistema sembra provenire legittimamente da ntdll.dll, mantenendo un call stack pulito.
• Utilizzo: Semplicemente usa K8_SYSCALL("ZwOpenProcess", ...) al posto di NtOpenProcess.