Voyons aujourd’hui comment dépaqueter et analyser ce FareIT
Depacking
Le packer est suffisant pour un newbies comme moi, il m’a, comme il se doit, bien paummé. Une fois de plus je n’ai pas trouvé un saut propre du style JMP EAX et au final je ne sais pas ou il saute. L’animal est en plusieurs ‘stages’ et évidemment des pans entiers de code sont réservés et réécrits au vol. Et comme si cela ne suffisait pas, du code semble pris depuis les ressources (Icones, Curseur etc..)
Bref me rendant à l’évidence sur mes limites, je l’ai breaké en cours d’exécution pour le dumper. J’ai pris la tangeante aux techniques que je vous ai décrit précédemment (Voir post depacking). Principalement parce que cet animal ne s’attache pas a un process, je pouvais toujours l’y attendre ! J’ai essayé un ‘trace’ dans OllyDbg et cela à été “winwin”.
Quand on ouvre l’exécutable dans IDA on se rend compte rapidement que le code couvre une toute petite partie (grace à la barre, le code c’est le bleu et le rouge).
Fort de ce postulat et ne voyants pas de code réservant de la Heap, j’ai donc noté les offsets me disant, tôt ou tard, il sautera dans ce code dépacké. Le code est incompréhensible pour ida de l’offset 0x401000 à 0x41C000 (la grosse plage grise avant la flêche). Je sort mon Ollydbg et lui demande de pauser la trace quand EIP se trouve dans cette plage (CTRL+T)
Ensuite on fait “Trace -> Run Hit Trace” et hoo miracle, le code se break et il semblerai que le segment de data soit bien remplis.
Pourquoi suis-je à 0x40154A qui ne ressemble pas franchement à un début de fonction. En fait le ‘Trace’ de OllyDbg met un breakpoint avant tout saut ou embranchement. De fait il faut remonter un peut pour trouver le début de la procédure (un classique push ebp, mov ebp,esp) qui est à 0x401522. Il suffit ensuite de noter les EIP posés sur la pile afin de plus tard remonter tel un saumon les jumps afin de remonter à ce qui semble être le début du programme dépacké (Original Entry Point)
Dans le dépacker, je suppute qu’il y a un antidumper (un détournement d’IAT ou autre j’en sais rien). Car quand on tente de dumper l’exécutable avec LordPE, cela ne marche pas. Au mieux il manque des pans de code au pire on a droit à ce genre de messages.
Heureusement, dans OllyDbg, sur la vue dump, bouton droit de la souris, “Backup” -> “Save Data to file” fonctionne (Pourquoi ?? ca dépasse mes maigres compétences, si un lecteur sait HELP ME). Il suffit ensuite de Rebuilder l’exe avec LordPE, mais attention de lui dire de ne pas Wiper la table de relocation (car le packer a fourré aussi du code dedans). C’est dans les options de LordPE. On s’occupera de l’OEP après vous allez comprendre pourquoi.
Anti-Désassemblage primaire:
Quand on va voir les procédures dont on a noté l’adresse dans la stack précédement on se rend compte que ces salaud utilisent une technique fort bien connu pour offusquer le code. Voici un exemple;
Ca déconne à partir de 0x041E31
En effet IDA aime suivre les sauts, ils se servent donc de cette spécificité pour décaler le code avec un saut bidon et le rendre ilisible et inintéligible par le désassembler. Dans la vraie vie, ce saut n’est jamais possible JB saute si le Carry Flag est à 1, mais l’instruction CLC (Clear Carry Flag) le met à 0 systématiquement. Ce qui se passe en vrai c’est le Push adresse et ret. Voila à quoi ressemble le vrai code :
Mais pour décoder cela dans IDA il faut passer tout en data (touche D) allez sur le bon offset et re-analyser (touche C). En plus de cela, dans certains car il faut aussi supprimer la fonction car elle est fusionnée avec une autre. Bref c’est chiant. Mais heureuseument, cette petite joyeuseté arrive toujours de la même façons, il est facile de la retrouver. En Hexa ce bout de code est :
68 ZZ YY XX WW : Push DWORD WWXXYYZZ
F8 : CLC
72 01 : JMP +1
C3 : RET
FF : Garbage
Et il y a de nombreux ‘anti-desassembleur’ dans ce droppeur. Etonnament il y en a pile poil 32.
$ grep -boa $'\x68'....$'\xf8\x72\x01\xC3\xFF' backup_00400000.bin.bin | wc -l 32
Allors on y va gaiment, corrigeons ce code. On va transformer tout cela en gros champ de NOP. J’ai aussi un tools a chal pour cela ! ;) une bête subsitution avec regex.
$binpatch.py backup_00400000.bin.bin "\x68(....)\xF8\x72\x01\xC3\xFF" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
Et si on ouvre maintenant l’exe, Ida est très, très heureux.
FIN DU DEPACKING.
La procédure DELAY
Encore que pour avoir un exe qui soit ‘TipTop’ et éventuellement exécutable, il faut refaire le dump avec un hardware breakpoint juste au début du programme dépacké. Dans la fameuse loop random en 0x41072C que l’on à trouvé parce que l’on a suivis les valeurs sur la stack. Le premier ‘retour’ de fonction trouvé sur la stack est 0x410756.
Et la on se dit.. hooo J’avais demandé à Ollydbg de breaker si EIP était entre 0x401000 à 0x41C000, il aurait dû s’arrêter avant. Il aurait dû, s’il avait correctement analysé le code. L’obfuscation l’a attrapé lui aussi je pense (Ou alors c’est un coup des vents solaires).
Heureusement il n’a pas été bien loin après. Revenons à notre stack et le retour vers 0x410756, ce retour arrive en plein dans la procédure ‘delay’. Cette procédure est un ‘Timer’ dont l’unique but est de patienter de facons aléatoire avant de lancer le ‘malware’.
Mais tout cela IDA l’avait déja deviné, c’est lui qui a nommé la procédure ‘Start’ automatiquement avec un EP foireux dans l’exe ;) c’est beau !
A+