Obfusk8 : Bibliothèque d'obfuscation basée sur C++17

Obfusk8 est une bibliothèque légère, uniquement en-tête, conçue pour le C++17, destinée à renforcer considérablement l'obfuscation de vos applications, rendant la rétro-ingénierie nettement plus ardue. Elle y parvient grâce à un ensemble varié de techniques à la compilation et à l'exécution visant à protéger la logique et les données de votre code.

---

Table des matières

1. Stratégies d'obfuscation principales
2. Dépendances
3. Visualisation
4. Profil d'analyse et de détection du moteur
5. Caractéristiques structurelles et médico-légales
6. Utilisation
7. Compilation
8. Démonstration
9. Contribution & Retours

---

Stratégies d'obfuscation principales

1. Encapsulation de la fonction main (macro _main)

Le point d'entrée de votre application (main) est transformé en un moteur d'obfuscation complexe et multicouche :

• Exécution de Machine Virtuelle (MV) (Conceptuelle) : Avant que votre code main_body ne soit exécuté, une mini-MV (CPU simulé) exécute une séquence d'instructions « chiffrées ». Cela dissimule le véritable point d'entrée et les opérations initiales. L'état de la MV (registres, compteur de programme, clé de dispatch) est initialisé avec des valeurs aléatoires à l'exécution.
• Aplatissement de flux de contrôle indirect (ICFF) : Les boucles critiques dans la macro _main (à la fois dans le prologue et l'épilogue) sont transformées en machines à états complexes. Le flux de contrôle n'est pas direct mais déterminé par des variables d'état fortement « chiffrées ». Les clés de codage/décodage de ces variables d'état sont dynamiques, dérivées de l'état de la MV, des compteurs de boucle, de l'aléatoire à la compilation (comme __COUNTER__, __LINE__, __TIME__) et d'une graine opaque globale. Cela rend l'analyse statique du flux de contrôle exceptionnellement difficile.
  • Deux moteurs ICFF distincts (obf_icff_ns_dcff et obf_icff_ns_epd) sont utilisés avec des logiques de transition d'état et de génération de clés différentes, compliquant encore l'analyse.
• Flux de contrôle factices (OBF_BOGUS_FLOW_* macros) : De nombreux motifs de saut trompeurs et structures conditionnelles alambiquées sont injectés tout au long de _main. Ceux-ci utilisent des instructions goto combinées à des prédicats opaques (conditions qui s'évaluent toujours à vrai ou faux mais qui sont coûteuses en calcul ou difficiles à déterminer statiquement). Cela crée un labyrinthe de fausses pistes pour les désassembleurs et décompilateurs.
  • Inclut OBF_BOGUS_FLOW_LABYRINTH, OBF_BOGUS_FLOW_GRID, OBF_BOGUS_FLOW_SCRAMBLE, OBF_BOGUS_FLOW_WEAVER, OBF_BOGUS_FLOW_CASCADE et OBF_BOGUS_FLOW_CYCLONE pour générer des flux factices variés et complexes.
• Anti-analyse & Anti-débogage (macro Runtime, SEH) :
  • Exceptions forcées & SEH : La gestion structurée des exceptions (SEH) est utilisée pour créer des chemins impliquant des exceptions forcées. Les blocs __except peuvent modifier l'état du programme, rendant difficile le suivi si le débogueur ignore les exceptions.
  • Vérifications de débogueur (Conceptuelle) : La macro Runtime contient des conditions qui, si elles sont remplies (en raison d'états MV spécifiques ou de temporisation), pourraient déclencher __debugbreak() ou lever des exceptions, conçues pour perturber les sessions de débogage.

2. Moteur ISA virtuel (obf_vm_engine)

Un composant central de la macro _main pour l'obfuscation :

• Simulation de mini-CPU personnalisée : Simule un CPU avec des registres volatils (r0, r1, r2), un compteur de programme (pc) et une dispatch_key. Il exécute des « instructions » personnalisées (gestionnaires).
• Instructions obfusquées : Les gestionnaires d'instructions MV effectuent des opérations fortement déguisées à l'aide d'arithmétique mixte booléenne (MBA) et de manipulations binaires. Les gestionnaires incluent des opérations arithmétiques, logiques binaires, de masquage de clé, des séquences factices, des mises à jour conditionnelles, une simulation mémoire et un masquage du PC.
• Dispatch dynamique : La sélection du prochain gestionnaire d'instructions MV est randomisée via plusieurs mécanismes de dispatch :
  • Dispatch basé sur registre (reg_dispatch_idx).
  • Dispatch basé sur table mémoire (table de pointeurs de fonction mélangée get_mem_dispatch_table).
  • Dispatch mixte (mixed_dispatch_idx). La dispatch_key est constamment mutée, rendant la séquence des gestionnaires exécutés hautement imprévisible.
• Mutation de la table des gestionnaires : La table des gestionnaires d'instructions MV (vm_handler_table) est elle-même mutée à l'exécution dans le prologue et l'épilogue de _main, obscurcissant davantage le comportement de la MV.

3. Chiffrement de chaînes à la compilation (OBFUSCATE_STRING de AES8.hpp)

• Chaînes cachées : Chiffre tous les littéraux de chaîne à la compilation à l'aide d'un chiffrement AES modifié.
• Clés dynamiques : Les clés de chiffrement sont uniques par instance de chaîne, dérivées du contenu de la chaîne, de l'emplacement du fichier (__FILE__, __LINE__) et de l'heure de compilation (__DATE__, __TIME__).
• Déchiffrement à la volée : Les chaînes sont déchiffrées sur la pile uniquement lorsqu'elles sont accédées à l'exécution, minimisant ainsi leur durée de vie en clair en mémoire.
• (Optionnel) Sections PE factices : Peut stocker des chaînes chiffrées dans des sections PE personnalisées conçues pour imiter les signatures de packers courants, pouvant induire en erreur les analystes (fonctionnalité spécifique à MSVC issue de AES8.hpp).

4. Appels d'API Windows discrets (STEALTH_API_OBFSTR / STEALTH_API_OBF de Resolve8.hpp)

• Obscurcissement de l'IAT : Évite de laisser des entrées directes et facilement identifiables pour les API Windows dans la table d'adresses d'importation (IAT).
• Résolution basée sur le PEB : Trouve dynamiquement les adresses de base des DLL chargées et les adresses des fonctions API en analysant directement les structures de données du bloc d'environnement de processus (PEB) à l'exécution. Cela contourne les appels standards GetModuleHandle et GetProcAddress pour la résolution initiale si ceux-ci ne sont pas encore résolus par ce mécanisme.
• Noms hachés : Utilise un hachage à la compilation (algorithme personnalisé CT_HASH) des noms de DLL et d'API pour les recherches. Cela empêche l'apparition des noms en clair de DLL et d'API dans les données relatives aux importations ou dans les tables de chaînes du binaire lors de l'utilisation de ces macros.