Résumé exécutif

L'unpacking de malware est l'étape préliminaire indispensable à toute analyse statique approfondie car plus de soixante-dix pour cent des malwares avancés utilisent des packers ou des crypters pour protéger leur code contre l'analyse et la détection antivirus. Le packer compresse ou chiffre le payload malveillant et inclut un stub de décompression qui restaure le code original en mémoire à l'exécution, rendant l'analyse statique du binaire packé inutile puisque le code visible est uniquement le stub et non le malware lui-même. Ce guide technique expert présente les techniques d'unpacking manuel avec x64dbg par identification du point d'entrée original et dump mémoire au moment où le code est restauré en clair, la reconstruction de l'Import Address Table avec Scylla pour rendre le binaire dumpé fonctionnel et analysable, la déobfuscation du control flow aplati par les obfuscateurs commerciaux comme Themida et VMProtect, et les approches automatisées avec CAPE et Unipacker qui gèrent les packers connus sans intervention manuelle pour le triage à grande échelle des échantillons.

Le packing est la technique de protection la plus répandue dans l'écosystème malware : elle empêche l'analyse statique directe du code malveillant et réduit drastiquement le taux de détection par les moteurs antivirus basés sur les signatures. Les packers commerciaux (UPX, Themida, VMProtect, Enigma Protector) et les crypters custom développés par les acteurs de la menace ajoutent une couche de protection que l'analyste doit retirer avant de pouvoir étudier le comportement réel du malware. La maîtrise des techniques d'unpacking est un prérequis fondamental pour l'analyse dynamique avancée qui observe le code dépacké en exécution. La déobfuscation des malwares polymorphes complète ces techniques pour les protections multiniveaux. L'utilisation de Ghidra pour le reverse engineering est la destination finale du processus d'unpacking qui produit un binaire analysable. Les techniques d'anti-rétro-ingénierie des APT combinent packing et obfuscation pour créer des protections multicouches. Les tutoriels d'OALabs et les publications de hasherezade documentent les techniques d'unpacking des familles de malwares les plus récentes.

  • 70% des malwares avancés utilisent un packer ou un crypter pour protéger leur code
  • Le point d'entrée original (OEP) est le moment clé où le code est restauré en mémoire
  • Le dump mémoire à l'OEP capture le code déchiffré et les données restaurées
  • La reconstruction IAT avec Scylla reconstitue les imports pour un binaire fonctionnel
  • L'automatisation avec CAPE gère 200+ packers connus pour le triage à grande échelle

Identification du packer et analyse d'entropie

L'identification du packer utilise Detect It Easy (DIE) qui reconnaît plus de 400 packers par signatures et heuristiques. L'analyse d'entropie des sections PE confirme le diagnostic : une entropie supérieure à 7.0 sur 8.0 indique une section compressée ou chiffrée (le code natif x86/x64 a typiquement une entropie entre 5.5 et 6.5). La taille brute (raw size) significativement inférieure à la taille virtuelle (virtual size) d'une section indique que le contenu sera décompressé en mémoire. Les packers custom ne sont pas reconnus par DIE mais partagent les mêmes caractéristiques entropiques et structurelles que les packers connus, permettant leur identification par analyse heuristique.

Les protections multiniveaux combinent plusieurs packers en série : un crypter externe (souvent généré par un service MaaS de crypting) protège le loader intermédiaire qui déchiffre et charge le packer interne protégeant le payload final. L'unpacking requiert alors un processus itératif où chaque couche est retirée séquentiellement pour atteindre le malware original. La documentation des couches rencontrées et de l'ordre de dépackage est essentielle pour la reproductibilité de l'analyse et le développement de signatures de détection ciblant chaque couche indépendamment.

Unpacking manuel avec x64dbg

L'unpacking manuel avec x64dbg repose sur l'identification du point d'entrée original (OEP) où le contrôle est transféré du stub de décompression vers le code malveillant restauré. Les techniques pour localiser l'OEP incluent : breakpoints sur VirtualAlloc et VirtualProtect (le stub alloue de la mémoire pour le code décompressé), hardware breakpoint on execution sur la section .text restaurée, single-stepping à travers le stub de décompression pour les packers simples (UPX), et breakpoints conditionnels sur les instructions de transfert de contrôle (JMP/CALL vers des adresses dans les sections décompressées).

Le dump mémoire au point d'entrée original capture l'image du processus avec le code déchiffré en clair. Les outils de dump (x64dbg plugin Scylla, OllyDumpEx, PE-bear) sauvegardent l'image mémoire du processus en corrigeant les alignements de sections PE. Le binaire dumpé contient le code malveillant en clair mais nécessite la reconstruction de l'Import Address Table pour être analysable dans Ghidra ou IDA car les pointeurs d'imports résolus en mémoire ne correspondent plus aux entrées de l'IAT du fichier PE sur disque.

Reconstruction IAT et finalisation

Scylla est l'outil de référence pour la reconstruction de l'Import Address Table. Il scanne la mémoire du processus dumpé pour identifier les pointeurs vers les fonctions exportées des DLL système (kernel32.dll, ntdll.dll, user32.dll, advapi32.dll) et reconstruit l'IAT en associant chaque adresse à son nom de fonction. Les cas problématiques incluent les imports par ordinal (sans nom de fonction), les imports de DLL non standard (bibliothèques tierces) et les techniques d'import mangling utilisées par certains packers avancés qui résolvent les imports via des tables de hashing custom au lieu de l'IAT standard.

La validation du binaire reconstruit vérifie que le fichier PE dumpé et réparé est fonctionnel : chargement dans Ghidra avec identification correcte des fonctions et des strings, exécution en sandbox pour vérifier que le comportement est identique à l'échantillon original, et comparaison des appels API observés en dynamique avec les imports reconstruits dans l'IAT. Les divergences indiquent des imports manquants ou incorrects qui nécessitent une correction manuelle dans l'IAT reconstruite par Scylla pour obtenir un binaire parfaitement analysable.

Control flow flattening : technique d'obfuscation qui remplace la structure de contrôle naturelle du programme (if/else, boucles, switch) par un dispatcher central qui sélectionne le prochain bloc de code à exécuter via une variable d'état, rendant le graphe de contrôle illisible dans les désassembleurs et empêchant l'analyse statique efficace.

PackerDifficultéTechnique d'unpackingAutomatisable
UPXTrivialupx -d ou OEP + dumpOui (upx -d)
MPRESSFacileOEP + dump + IAT fixOui (CAPE)
ThemidaDifficileVM analysis + dumpPartiel
VMProtectExpertVM bytecode analysisNon
Custom APTVariableManual OEP + dumpNon

L'analyse d'un dropper APT ciblant le secteur aérospatial européen présentait trois couches de protection : un crypter commercial (Enigma Protector) protégeant un loader .NET obfusqué avec ConfuserEx qui déchiffrait un shellcode final en mémoire. Le dépackage itératif a nécessité 2 jours : d'abord le retrait d'Enigma Protector par dump mémoire avec x64dbg, puis la décompilation du loader .NET avec de4dot pour retirer ConfuserEx, et enfin l'extraction du shellcode par breakpoint sur VirtualAlloc. Le payload final était un implant custom communiquant via DNS-over-HTTPS avec un C2 hébergé sur une infrastructure cloud légitime.

Mon avis : l'investissement en compétences d'unpacking est le meilleur différenciateur pour un analyste malware. Les outils automatisés gèrent le quotidien mais échouent systématiquement sur les échantillons APT et les packers custom. La capacité à unpacker manuellement un binaire est ce qui distingue un analyste junior d'un analyste senior capable de traiter les menaces les plus sophistiquées.

Comment identifier le packer utilisé par un malware ?

Detect It Easy identifie les packers connus par signatures. Pour les packers custom, analysez l'entropie des sections PE (supérieure à 7.0 indique compression/chiffrement) et la disparité entre taille brute et taille virtuelle des sections.

Peut-on automatiser l'unpacking de tous les malwares ?

Non. Les outils automatisés gèrent les packers connus. Les packers avancés comme Themida, VMProtect et les packers custom APT nécessitent un unpacking manuel avec x64dbg et des techniques spécifiques à chaque packer.

Qu'est-ce que la reconstruction d'IAT et pourquoi est-elle nécessaire ?

L'Import Address Table liste les fonctions système importées. Après le dump mémoire, les adresses sont invalides. Scylla reconstruit l'IAT en résolvant les adresses vers les noms de fonctions DLL pour un binaire analysable.

Conclusion

L'unpacking de malware est le prérequis technique à toute analyse statique efficace. La combinaison d'identification de packer, dump mémoire à l'OEP, reconstruction IAT avec Scylla et déobfuscation du control flow produit un binaire analysable qui révèle le comportement réel du malware protégé. La maîtrise de ces techniques manuelles complète les outils automatisés pour traiter les menaces les plus sophistiquées.

Investissez dans les compétences d'unpacking manuel pour votre équipe d'analyse malware. Les outils automatisés gèrent le triage quotidien mais la capacité à dépacketer manuellement est ce qui fait la différence face aux APT et aux malwares protégés par des packers custom.