Septembre 16, 2018 3 min to read

Une présentation de ce qui peut être fait pour un exemple simple de reverse.

Résolution d'un challenge de type Reverse.

Testé sous Windows 10 en septembre 2018

# IDA

IDA est un debbuger qui possède une version gratuite téléchargeable ici

Le challenge porte sur l’exécutable suivant :

Au démarrage d’IDA, on est invité à sélectionner un nouveau fichier à désassembler. Il faut alors choisir le bon format qui est PE pour Portable Executable. C’est le format standard des exécutables sous Windows.

Analyse

Découverte de l’exécutable

Dans un premier temps avant de commencer à désassembler une application, il faut prendre le temps de la manipuler un peu afin de comprendre ses fonctionnalités. Dans le cas d’un virus, il va être important de comprendre le comportement normal attendu. Car bien souvent, celui-ci essayera de faire en sorte de ne pas pouvoir être désassembler, en surveillant si un debbuger est présent, si le système est hébergé sur une machine virtuelle etc… Pour ceux que ça intéresse voici un article sur les techniques que peuvent utiliser les malwares pour se cacher : https://www.supinfo.com/articles/single/332-contourner-analyse-dynamique-antivirus

Ici le fonctionnement est très simple. Il faut rentrer un mot de passe qui doit être celui attendu. En cas d’erreur un message d’erreur apparaît : Wrong Password. Le but est simplement de trouver le bon mot de passe.

Recherche de chaînes de caractères

La première idée qui vient pour l’analyse est de regarder si la chaîne de caractère Wrong est stockée dans l’exécutable, si c’est le cas, on doit pouvoir la trouver en cherchant dans IDA. De plus, les variables référencées par des adresses mémoires connues sont affichées dans IDA. Une recherche de Wrong avec Alt+T conduit à deux résultats. La constante de texte stockée dans la portion data de l’exécutable et le moment où cette constante est chargée par le programme.

On voit dans cette image l’appel à la fonction Dialog.ShowMessage fait avec la chaîne de caractères qui nous intéresse. Le message affiché est conditionné par l’instruction jnz à l’adresse 454136.

On voit que le saut est fait suite à l’appel de System.StrCmp. Une recherche sur internet conduit à cette page qui précise les valeurs de retour et compare deux tableaux de char :

Analyse de la fonction System.StrCmp

On s’intéresse alors à l’intérieur de cette fonction pour voir les chaînes de caractères qui sont comparées. En double cliquant sur la fonction, on se rend à l’emplacement mémoire qui l’implémente. On observe la chose suivante :

La fonction est assez courte, elle est dans une boucle que l’on ne voit pas en entier sur l’image mais dont le principe est de comparer à chaque itération deux DWORD. Un DWORD correspond à 4 octets (d’où les +4 de modification des pointeurs esi et edi).

On met alors des breakpoints sur IDA et on lance le programme en debug. On saisit un mot de passe, l’arrêt se fait après.

L’arrêt au premier point à l’adresse 404655 permet d’observer l’état des registres ecx et ebx.

On observe dans ebx les 4 premiers octets de la chaîne de caractères saisie et dans ecx la valeur suivante : 0x74726F66 soit trof en ASCII. C’est le début du mot de passe.

Le second point d’arrêt nous donne ecx : 0x216E6172 soit !nar.

Les points d’arrêts sont de nouveaux atteint jusqu’à terminer la chaîne de caractères saisie comme mot de passe.

Le mot de passe est donc stockée en mémoire comme trof puis !nar soit trof!nar. Mais comme le désassembleur montre le code avec la convention LE, il faut en réalité lire fortran!

Remarques

• L’exemple ci-dessus est assez simple, en effet les chaînes de caractères sont stockées en clair (sauf le password), ce qui permet de vite se concentrer sur les fonctions importantes du code.

• Les fonctions sont appelées clairement dans le code, il n’y a pas d’appels cachés.