Le fichier à analyser peut être téléchargé ici : Virus.zip.

Ce programme étant dangereux, je décide de l'étudier de manière statique à l'aide du désassembleur IDA Freeware 4.3. Ce qui est, de plus, une bonne occasion pour découvrir cet outil dont l'interface m'a toujours rebuté. Avant de commencer l'analyse, je préfère m'assurer que le PE Header n'a pa été altéré, pour éviter tout problème de chargement sous IDA. J'inspecte donc la structure du fichier à l'aide de Lord PE.

Rien à signaler pour le PE Header, les valeurs semblent correctes. La table d'import ne contient qu'une seule fonction, ce qui fait penser que les autres seront importées dynamiquement. On remarque que les 2 champs ROffset et RSize de la première section sont nuls. De plus, l'EntryPoint se trouve dans la 3^ème section (00003010) et les 4 sections autorisent l'accès en écriture (E0000040 signifie que la section autorise l'accès en lecture, écriture et exécution). C'est souvent le cas lorsqu'un programme est compressé/crypté.

On charge le programme dans IDA en laissant les options par défaut dans un premier temps, et première chose frappante, le code semble crypté après les 15 premières instructions.

Les premières instructions sont typiques des loaders et permettent d'avoir un code indépendant de l'adressage. C'est à dire pouvant être exécuté à n'importe quel endroit (code relogeable). Au cours de l'exécution du programme, ebp contiendra un delta qui sera ajouté aux constantes pour pointer vers la bonne adresse. Ici, le delta est de 2000h (403016 - 6 - 401010).

Par exemple, en 0040302C, l'adresse 00401042 est placée dans edi. 00401042 correspond à l'adresse d'une variable lorsque le loader a été assemblé. Pour retrouver la bonne adresse dans ce nouvel adressage, le delta est ajouté ce qui donne 00403042 (le début du code crypté).

Pour bénéficier pleinement de la puissance de IDA, il serait préférable d'avoir les adresses directement calculées avec le delta. Je suis d'abord parti sur un script IDC qui calculait les adresses avant de les patcher mais ce n'était pas très propre et un peu trop long à coder. Finalement, après une petite discussion avec Deicide et une profonde réflexion, j'ai trouvé une méthode beaucoup plus simple et efficace.

On ferme IDA sans sauvegarder l'IDB et on recharge le programme mais cette fois en cochant Manual Load. Pour supprimer le delta, il suffit que la section du loader soit chargée à son adresse d'origine (00401000). Pour se faire, on va simplement retrancher le delta (2000) à l'ImageBase (400000). On entre donc dans le champ de IDA, la nouvelle ImageBase (003FE000) et on clique sur OK pour le reste.

Maintenant que le delta (ebp) vaut 0, on va pouvoir renommer les constantes en label. Voici la même partie de code maintenant plus compréhensible :

Juste après le cacul du delta, le programme sauvegarde la valeur contenue dans [esp-10h]. En regardant plusieurs programmes sous OllyDbg, j'ai remarqué que cette valeur est l'ImageBase de ntdll.dll sous Windows 2000 (mais pas sous XP). S'ensuit une simple boucle (DecryptLayer01) qui décrypte les 49 octets de Layer01_Start (en 00401042) à Layer01_End (en 00401073).

On ne peut pas continuer puisque le reste du code est crypté. On va donc le décrypter à l'aide d'un script IDC que voici :

Et voici le code fraichement décrypté et analysé (touche C) :

Ce code est exécuté juste après la boucle de décryptage et se trouve être une nouvelle boucle qui va décrypter un autre bout de code.

Le loader contient 15 couches de cryptage toutes différentes. Je ne vais pas les copier ici mais vous trouverez dans le dossier IDC les 15 scripts pour décrypter les 15 layers séparément.

Après 5 couches de décryptage successives, la 6^ème boucle va décrypter plusieurs fonctions utilitaires : une émulation de GetProcAddress, 3 fonctions pour résoudre les imports, et la fonction de décompression. Puis avant de sauter sur la prochaine boucle de décryptage, le loader récupère l'adresse de IsDebuggerPresent grâce à la fonction GetProcAddress émulée en 00401393, avant de l'appeler. Si un debugger est détecté, le programme quitte. Je ne copie pas le code qui ne présente aucun intérêt particulier.

Après quelques décryptages supplémentaires, on arrive sur cette partie de code qui va vérifier la date du système. L'adresse de la fonction GetSystemTime est récupérée dynamiquement (toujours avec l'émulation de GetProcAddress) puis appélée. Cette fonction va remplir une structure SYSTEMTIME déclarée plus haut.

Pour déclarer une structure dans IDA, on se place dans la fenêtre Structures (Alt+9) et on crée une nouvelle définition (Inser). Dans la boîte de dialogue, on clique sur Add standard structure puis on choisit dans la liste la structure qui nous intéresse (ici SYSTEMTIME). Il ne reste plus qu'à cliquer sur l'adresse représentant le début de la structure (004011AC) puis Alt+Q pour afficher la liste des structures disponibles et choisir SYSTEMTIME. Les membres sont renommés automatiquement dans tout le listing.

Voici un point important. Le programme continuera son exécution uniquement si la date système est le 16 février 2011.

Les adresses des fonctions LoadLibraryA, GetProcAddress et VirtualAlloc (cette dernière n'est pas utilisée) sont récupérées de la manière suivante :

La fonction appelée ensuite ressemble fortement à la fonction aP_depack_asm_fast de aPLib.

La première section .text est décompressée à sa place en 00401000.

Après avoir récupéré l'ImageBase de User32.dll, la fonction de résolution des imports est appelée. Celle-ci est très confuse du fait de nombreux JMP dans tous les sens. Elle a été découpée en plusieurs blocs qui ont ensuite été mélangés. Lorsque l'on a compris l'ordre d'exécution, elle ne pose pas de problèmes particuliers. A part une fonction que j'ai appelé CheckKernelUser car elle teste les ImageBases de Kernel32 et de User32. Cependant le résultat n'est pas utilisé. Le seul intérêt de cette fonction, à la fin, est qu'elle fait pointer le nom de la dll courante vers la suivante.

Ici, il n'y a qu'un seul import, Kernel32.EraseTape. On note également que le nom de l'api est décrypté (xor byte ptr [edi], 0C5h) avant d'en déterminer l'adresse (script IDC pour décrypter le nom de l'api).

L'Original EntryPoint est calculé simplement puis le loader patche l'adresse 0040138E pour donner push 00401004h et le retn saute sur l'OEP du programme démarrant ainsi l'exécution du virus. Juste avant de sauter, le loader restaure la valeur sauvegardé en début de programme.

Vous trouverez la base LoaderVirus.idb du listing complet, décrypté et commenté dans le dossier IDB.

D'après l'analyse, on a vu que le virus est simplement compressé avec aPLib. Le cryptage n'est là que pour le loader. La décompression sera donc simple.

On va d'abord copier la fonction de décompression depuis IDA en faisant menu File -> Produce -> Create ASM file.... On obtient un fichier asm contenant le listing complet de ida. Il ne reste plus qu'à copier la fonction aP_depack_asm_fast et la coller dans notre code (éventuellement corriger certaines lignes si l'assembleur n'est pas content, j'ai utilisé MASM).

Voici la structure de mon programme :

• Ouvrir le fichier Virus.exe
• Lire les données compressées
• Décompresser les données
• Copier l'intégralité du fichier virus.exe en mémoire
• Corriger le PEHeader
• Décrypter le nom de l'api importée
• Créer un nouveau fichier
• Ecrire le PEHeader corrigé
• Ecrire la section décompressée
• Ecrire le reste du fichier

Voici les corrections apportées au PEHeader :

Le code source du décompresseur est disponible dans le dossier Sources/Unpacker/