Unpack un binaire packé avec UPX

[crown]

Unpack UPX

0x00 Introduction :

Salut les poneys alors aujourd’hui j'ai décidé de faire un petit tutoriel sur, " comment unpacker un binaire packé avec UPX " [1], bon il n'est pas nécessaire d'avoir des connaissances en langage ASM.

0x01 Pré-requis :

• OllyDbg [2] /WinDasm [3]
  
• LordPE [4] /PE Tools [5]
  
• Import Reconstructor [6]
  
• PEid [7] / StudPE [8]
  
• Crackme packé avec UPX [9] [Scan]
  

0x02 Try to unpack me !

C'est partit donc comme tout bon cracker un petit reflex doit vous venir à l'esprit qui est de passer le binaire dans PEid ou StudPE.



Comme on peut le voir ici PEid ne nous apprends rien nous essayons donc avec StudPE.



Avec StudPE on voit qu'il détecte le packer UPX il nous faut donc l'unpacker si on veut pouvoir travailler sur notre binaire. Maintenant que nous savons qu'il est packé nous le lançons dans ODBG puis on tombe nez-à-nez avec un PUSHAD qui est le debut de la routine du loader qui va être lancé pour pouvoir déchiffrer le programme.

Ici nous avons notre EP (Entry Point) c'est lui que nous allons changer pour que le programme puisse commencer sur le programme et non le loader.
Adresse de l'EP : 00466290, gardons cela en tête pour plus tard.

Il nous faut maintenant trouver un POPAD qui signifie la fin de la routine de déchiffrement. L'instruction POPAD a une valeur hexadécimal de 61 on fait donc un CTRL + B puis dans la case Hex + 00 on y met le nombre 61.

On tombe ensuite sur cette ligne, la ligne du POPAD :



Ici comme nous pouvons l'observer il y a, à l'adresse 00466413 un JMP [10] qui va jumper sur l'OEP (Original Entry Point) ce qui nous amèneras au début du programme unpacké. Donc on appui sur F9 on vois une fenêtre qui s'ouvre puis on clique sur la ligne du JMP et on appui sur Entrer. Normalement on arrive ici :



On note l'adresse à laquel on tombe qui est 00401280 puis on ouvre LordPE on cherche notre programme (débuggé) puis on clique droit dessus puis on fait un "dump full".



On se retrouve donc avec un programme du nom de dumped.exe mais si vous le lancez il ne marchera pas puisqu'il manque touts les DLL et les librairies il va donc falloir les reconstruire.

Il faudra aussi changer l'EP (Entry Point) pour que le programme aille directement à l'OEP (où le programme est unpack) et non sur le loader.

Donc on ouvre ImportRec puis on cherche notre programme en cour qui est unpacké (dans OllyDbg) :




On voit sur la dernière ligne que l'Image Base est 00040000 on note ça quelque part puis la il va nous falloir faire une petite soustraction pour trouver l'OEP qui n'est autre que EP - Image Base = OEP. On a donc 00401280 - 00400000 = 00001280, on écrit cette valeur dans OEP puis on clique sur IAT AutoSearch, ça devrait vous affichez un jolie message qui dit que l'adresse a bien était trouvée.

Il nous dit ensuite de cliquer sur Get Import.
On a maintenant nos DLL puis nos Import Tables recrée, nous pouvons donc fixer le dump en cliquant sur Fix Dump puis en choisissant le fichier dumped.exe.



Là encore une fois un beau message disant que l'opération c'est bien passée, ImportRec vient de crée un fichier Dumped_.exe qui est votre fichier final unpack.

Aperçu des strings sur le binaire packé :



Et voilà le fichier dumped_.exe crée par ImpRec avec les imports tables et les DLLs et bien sûr unpacké :



Voilà on arrive à la fin de ce tutoriel entièrement rédigé par moi-même, et ça m'a pris pas mal de temps donc j'espère qu'il vous plairas, surtout si vous avez des questions n'hésitez car pour des débutants ça peut tout de suite devenir assez technique.

[supersnail]

Pas mal ton tuto

Sinon pour les flemmards... upx -d :>

[Di0Sasm]

Je lui ai dit hier soir pour "upx -d" plus rapide.

Je déplace dans tuto reverse.

[Swissky]

Merci c'est cool
Mais quand je sais que c'est packé avec UPX j'utilise upx -d 1.exe en nommant mon fichier 1.exe .
Comme le disent DiosAsm et Supersnail c'est plus rapide mais ta rapide est plus manuelle

[supersnail]

Ça fait surtout un bon entraînement à l'unpacking

[Swissky]

Je n'ai pas encore testé mais est-ce que sa marche contre d'autre type de packer comme Aspack ou c'est seulement dédié à UPX ?

[supersnail]

Bah généralement les packers font des pushad/popad pour préserver les valeurs des registres sur la pile (étant donné que la plupart de ces registres seront modifiés par les opération de décompression/remplissage de l'IAT (si elle a été aussi packée).
Donc à la sortie du popad, on peut s'attendre à ce qu'on trouve un saut vers l'OEP .
Après t'as d'autres packers qui jouent avec les SEH ou d'autres trucs tricky pour essayer de paumer les débuggers, mais y'aura dans 99% des cas un popad suivi d'un saut vers l'OEP.

Après vient le cas des "crypters" RunPE, qui fonctionnent différement: ces crypters créent un processus en "suspended", avant de le défoncer pour remplacer son code par celui de l'exécutable chiffré par le crypter, et laisser le loader win32 faire le reste (remplissage d'IAT, etc). Bref, ça reste traçable (j'ai d'ailleurs codé un p'tit tool nommé Stalker qui permet justement de tracer les écritures dans un autre processus).

[crown]

C'est sur que comme vous dîtes upx -d est beaucoup plus rapide mais au moins vous saurez le faire à la main. Après pour ce qui est des autres packer j'ai eu l'occasion de tomber sur ARM protector et yoda's protector qui eux n'utilise pas cette méthode (PUSHAD/POPAD).

[supersnail]

Perso, je vois bien des pushad dans ARM unpacker (ils sont juste difficiles à trouver du fait des tricks anti-désassembleur/débugger), mais ils sont là

[Horgh]

Hum c'est assez sale la méthode de la recherche par opcode. Ca marche bien sur upx parce que le loader est court & qu'il n'y a aucun trick, mais dès que ça devient élaboré on se retrouve en général face à du déchiffrement dynamique de code au cours de l'exécution & donc impossible de trouver le popad dès le début. Sans compter que sur un vrai protector, il n'y aura pas qu'une seule occurrence pour 0x61 mais des dizaines voire des centaines. La recherche d'une suite de commande / de bytes est plus fiable dans ce cas là, même si cette méthode montre vite aussi ces limites.
Pour conclure : ESP Trick > *

[sakiir]

merci bon tutoriel !!

[0pc0deFR]

Un packer va simplement compresser le code. Un protector va compresser le code mais aussi le protéger via des systèmes de chiffrement, d'anti-debugging. Dans certains cas, le binaire est même émulé. Certains protector intègre aussi un système de licence.

MPRESS s'unpack de la même manière (PUSHAD/POPAD).

Yoda's Protector est open source donc le mieux (je pense) pour l'unpacker est de regarder les sources pour comprendre son fonctionnement et donc l'unpack assez simplement.

[WizOut]

Merci du tutoriel ! intéressant !

[Atlas]

Merci pour le tutoriel !
mais pourrais tu mettre à jour le lien du crack-me ?
Merci d'avance