Identification des binaires empaquetés

• manque de chaînes : Il est courant de constater que les binaires empaquetés n'ont presque aucune chaîne.
• Beaucoup de chaînes inutilisées : De plus, lorsqu'un malware utilise un type de packer commercial, il est courant de trouver beaucoup de chaînes sans références croisées. Même si ces chaînes existent, cela ne signifie pas que le binaire n'est pas empaqueté.
• Vous pouvez également utiliser certains outils pour essayer de trouver quel packer a été utilisé pour empaqueter un binaire :
• PEiD
• Exeinfo PE
• Language 2000

Recommandations de base

• Commencez à analyser le binaire empaqueté par le bas dans IDA et remontez. Les dépackers sortent une fois que le code dépacké sort, donc il est peu probable que le dépacker passe l'exécution au code dépacké au début.
• Recherchez des JMP ou des CALL vers des registres ou des zones de mémoire. Recherchez également des fonctions poussant des arguments et une direction d'adresse puis appelant retn, car le retour de la fonction dans ce cas peut appeler l'adresse juste poussée sur la pile avant de l'appeler.
• Mettez un point d'arrêt sur VirtualAlloc car cela alloue de l'espace en mémoire où le programme peut écrire du code dépacké. "Exécuter jusqu'au code utilisateur" ou utilisez F8 pour obtenir la valeur à l'intérieur de EAX après l'exécution de la fonction et "suivez cette adresse dans le dump". Vous ne savez jamais si c'est la région où le code dépacké va être sauvegardé.
• VirtualAlloc avec la valeur "40" comme argument signifie Lecture+Écriture+Exécution (certaines instructions nécessitant une exécution vont être copiées ici).
• Lors du dépackaging du code, il est normal de trouver plusieurs appels à des opérations arithmétiques et des fonctions comme memcopy ou VirtualAlloc. Si vous vous trouvez dans une fonction qui apparemment ne réalise que des opérations arithmétiques et peut-être quelques memcopy, la recommandation est d'essayer de trouver la fin de la fonction (peut-être un JMP ou un appel à un registre) ou au moins l'appel à la dernière fonction et d'exécuter jusqu'à là car le code n'est pas intéressant.
• Lors du dépackaging du code, notez chaque fois que vous changez de région mémoire car un changement de région mémoire peut indiquer le début du code dépacké. Vous pouvez facilement dumper une région mémoire en utilisant Process Hacker (processus --> propriétés --> mémoire).
• Lors de la tentative de dépackaging du code, une bonne façon de savoir si vous travaillez déjà avec le code dépacké (pour que vous puissiez simplement le dumper) est de vérifier les chaînes du binaire. Si à un moment donné vous effectuez un saut (peut-être en changeant la région mémoire) et que vous remarquez que beaucoup plus de chaînes ont été ajoutées, alors vous pouvez savoir que vous travaillez avec le code dépacké.
  Cependant, si le packer contient déjà beaucoup de chaînes, vous pouvez voir combien de chaînes contiennent le mot "http" et voir si ce nombre augmente.
• Lorsque vous dumpez un exécutable d'une région de mémoire, vous pouvez corriger certains en-têtes en utilisant PE-bear.