Comment dépaquer un malware : le guide de l'analyste

Les exécutables packés sont l'un des premiers murs que rencontre un analyste lors du triage d'un binaire suspect. Les chaînes sont du charabia, la table d'imports est presque vide, et le désassemblage est un fouillis de code automodifiant. Ce guide explique, dans une perspective défensive et orientée labo, comment reconnaître un échantillon packé et récupérer le code d'origine pour pouvoir réellement l'analyser.

Ce qu'est le packing et pourquoi les malwares l'utilisent

Un packer enveloppe un programme dans un petit stub de loader. Au repos, le vrai code se trouve compressé ou chiffré dans le fichier. Quand le binaire s'exécute, le stub dépaque cette charge utile en mémoire et y saute. Le programme d'origine ne change jamais — il est simplement caché jusqu'au runtime.

Les logiciels légitimes utilisent les packers pour réduire la taille ou décourager le cracking occasionnel. Les auteurs de malware s'appuient sur les mêmes techniques de packing pour des raisons plus sombres :

• Évasion de signature. Le code compressé ou chiffré déjoue les règles antivirus naïves basées sur les motifs d'octets.
• Analyse ralentie. Les outils statiques ne voient que le stub, pas le comportement.
• Polymorphisme à bas coût. Re-packer la même charge utile produit un hash flambant neuf à chaque build.

Comprendre le stub est la clé : il doit, à un moment donné, révéler le vrai code en mémoire. Cet instant est votre ouverture.

Reconnaître un binaire packé

Avant de dépaquer quoi que ce soit, confirmez que l'échantillon est réellement packé et identifiez ce qui l'a packé. Detect It Easy (DiE) est le premier arrêt standard. Cherchez trois indices :

Une entropie élevée

Les données compressées et chiffrées approchent le maximum d'aléatoire. Une lecture d'entropie proche de 8.0 sur une section — en particulier celle qui contient l'essentiel du fichier — suggère fortement du packing. Le code compilé normal se situe bien en dessous.

Une table d'imports suspectement petite

Une vraie application appelle des dizaines, voire des centaines d'API Windows. Un binaire packé n'en importe souvent qu'une poignée — fréquemment juste LoadLibrary et GetProcAddress, que le stub utilise pour reconstruire les vrais imports après dépaquetage. Une table d'imports quasi vide est un signal d'alarme. De nombreux packers vont plus loin avec l'obfuscation de la table d'imports, cachant les appels d'API derrière de l'indirection.

Des sections bizarres

• Des noms de section comme UPX0, .aspack, ou du charabia aléatoire au lieu de .text/.data.
• Une section marquée à la fois inscriptible et exécutable (RWX) — la destination du dépaquetage.
• Une taille brute nulle sur le disque mais une grande taille virtuelle, signifiant qu'elle est remplie au runtime.

PE-bear ou n'importe quel visualiseur PE feront remonter cela en quelques secondes.

Dépaquetage automatisé : tentez d'abord la voie facile

Certains packers ont des formats connus et réversibles. L'exemple le plus net est UPX, qui livre son propre dépaqueteur :

Quand ça marche, vous avez terminé en une seule commande. Pour en savoir plus, lisez reconnaître et défaire le packing UPX avant de sortir des outils plus lourds.

Le hic : les auteurs de malware trafiquent régulièrement les en-têtes UPX pour que upx -d refuse de s'exécuter, même si l'algorithme sous-jacent est inchangé. Et dès que vous affrontez un protecteur commercial ou un stub de déchiffrement au runtime personnalisé, les dépaqueteurs automatisés cessent d'aider. C'est là que vous le faites à la main.

L'approche manuelle générale

Le dépaquetage manuel est conceptuellement simple même quand les détails sont délicats. Vous laissez le stub faire le gros du travail de déchiffrement, puis vous capturez le résultat avant que le programme ne démarre. Faites toujours cela au sein d'une VM isolée avec un snapshot propre — vous êtes sur le point d'exécuter un malware vivant.

1. Exécuter jusqu'au point d'entrée d'origine (OEP)

Le stub décompresse la charge utile puis effectue un tail jump vers le point d'entrée d'origine. Trouvez ce saut et vous avez trouvé la frontière entre le packer et le vrai programme. Tactiques courantes :

• Placez un breakpoint en accès mémoire sur la section qui contiendra le code dépaqueté, puis exécutez jusqu'à ce que le stub y écrive et y saute.
• Guettez le motif classique d'un long stub qui se termine par un unique saut lointain vers une autre section.
• Utilisez un plugin de débogueur qui automatise la détection de l'OEP pour les stubs connus.

Les packers qui déchiffrent par étapes, décrits sous packing multicouche, exigent de répéter cela jusqu'à exposer la dernière couche.

2. Dumper le processus depuis la mémoire

Une fois l'exécution arrivée à l'OEP, le code déchiffré est entièrement présent dans l'espace d'adressage du processus. Utilisez Scylla (ou la fonction de dump de votre débogueur) pour réécrire l'image en mémoire dans un fichier. Ce snapshot contient le vrai .text que vous ne pouviez pas voir sur le disque.

3. Réparer la table d'imports

Le dump seul ne s'exécutera ou ne se désassemblera généralement pas proprement, parce que l'import address table (IAT) a été reconstruite au runtime par le stub et pointe dans la mémoire vive. Scylla peut :

1. Prendre l'OEP comme point de départ.
2. Rechercher l'IAT dans le processus.
3. Reconstruire l'import directory et l'appliquer à votre dump.

Après cela, les appels d'API du binaire se résolvent à nouveau vers des fonctions nommées, ce qui rend le désassemblage lisible.

Attention : certains stubs utilisent du code automodifiant qui réécrit les instructions à la volée, donc la version que vous dumpez n'est correcte qu'à l'instant précis où vous l'avez capturée.

Packers courants que vous rencontrerez

• UPX — open source, extrêmement courant, souvent cassé par trafiquage mais conceptuellement simple.
• ASPack / FSG / MPRESS — compresseurs plus anciens aux stubs bien documentés.
• Themida / VMProtect — protecteurs commerciaux qui ajoutent de la virtualisation par-dessus le packing ; ils résistent au simple dump-and-fix et demandent bien plus d'efforts.
• Crypters personnalisés — loaders sur mesure vendus sur les marchés underground, généralement du type stub de déchiffrement au runtime.

Un terme que vous ne reconnaissez pas ? Le glossaire du reverse engineering définit le vocabulaire employé tout au long de ce flux de travail.

Vérifier le résultat

Vous n'avez pas fini quand le dump existe — vous avez fini quand il est correct. Vérifiez :

• L'entropie a chuté. Re-scannez le dump dans DiE. L'entropie de la section packée doit retomber aux niveaux d'un code normal.
• Les imports ont l'air réels. Une table peuplée d'API nommées (CreateFileW, WSASocket, RegSetValueEx, etc.) signale une reconstruction propre de l'IAT.
• Le code se désassemble. Les octets à l'OEP doivent former un prologue de fonction sensé, pas du bruit aléatoire.
• Les chaînes réapparaissent. Les URL, clés de registre et chaînes de commande qui étaient cachées apparaissent maintenant dans un scan de chaînes.

Si l'un de ces points échoue, vous avez probablement dumpé trop tôt, manqué une couche de packing ou mal localisé l'OEP. Restaurez le snapshot de la VM et réessayez.

Pour conclure

Le dépaquetage est une porte, pas le but. Une fois que vous avez un binaire propre aux imports corrigés, la vraie analyse — comportement, capacités, indicateurs — commence. Maîtrisez le rythme identifier, exécuter jusqu'à l'OEP, dumper, reconstruire, vérifier, et la plupart des échantillons packés deviennent traitables.

Prêt à aller plus loin ? Parcourez la bibliothèque complète des techniques de packing et de dépaquetage pour voir des décompositions détaillées de chaque famille de packer, et gardez le glossaire ouvert comme référence pendant que vous travaillez.