Introduction au RCE sur Android

Mettez à disposition vos propres cours de cracking ou des cours que vous trouvez intéressant.

Introduction au RCE sur Android

Messagepar etherlord » 23 Mars 2012, 16:41

Introduction au Reverse engineering sur Android

etherlord - ForumCrack - v1.0
http://www.forumcrack.com



Avec l'explosion du smartphone, et l'apparition de plates-formes de plus en plus
usitées (Symbian, Android, ....), on observe également une explosion des codes
malicieux qui visent spécifiquement certains systèmes embarqués.

Il faut dire que si les outils que l'on trouve sur ces plates-formes sont moins
développés que ce qu'on trouve pour nos PCs, un smartphone offre de base des fonctions
qui ouvrent la voie à des malversations...

Exemple d'un cas connu : un PC est infecté par un virus qui injecte un keylogger
sur le PC pour récupérer les identifiants bancaires d'un usager. Un accès bancaire
est généralement conditionné sur plusieurs éléments pour arriver à une authentification
complète, pour pas mal de banques cela consiste à se logger sur un portail à partir
d'éléments connus de l'utilisateur (son no de contrat par exemple), et ensuite d'envoyer
un code unique par SMS à l'usager (le code n'étant pas réutilisable, c'est censé
protéger l'usager => multiples token donc assimilé à une authentification forte)).

Dans le cas du PC infecté, une fois que le keylogger a permis la récupération des
identifiants (fixes) de l'usager pour accéder au portail, le virus envoie un programme
au smartphone (en général, le PC utilisé pour ses transactions bancaires est également
celui qui sert à synchroniser le smartphone) qui, s'installe généralement tout seul
(voir les alertes sécurité actuelles qui concernent le "rootage" d'un Android), ou qui
fait appel au social engineering.

Ce programme peut alors sans problèmes se lancer avec la priorité la plus élevée sur le
smartphone (cela signifie que cette portion de code sera la première à réagir à un
événement tel que la réception d'un SMS), récupérer le code unique envoyé par la banque,
et, c'est là la beauté de la chose, froidement signifier à toutes les autres
applications que comme il a pris en charge le SMS, il n'y as plus rien à faire. Le SMS
ne sera donc même pas affiché, l'usager n'as aucun moyen de savoir qu'il a reçu un SMS
de la banque. A partir de là.....

On est heureusement dans une période où les virus qui circulent sont encore relativement
simples (dû au manque d'outils de développement et d'analyse présent sur ces systèmes),
mais les gens qui développent ces virus engrangent chaque jour un peu plus d'expérience,
et on observe des évolutions dans la protection de ces virus. Par exemple, certains ont
trouvés un moyen aisé de détecter si l'application tourne réellement sur un smartphone
ou sur un émulateur. (Donc quand on évalue le programme dans un émulateur, on ne voit
pas la partie du code malicieux s'exécuter).

Par chance pour nous autres, on commence quand même à avoir quelques outils qui ont pour
certains des fonctionnalités très intéressantes vis-à-vis de ce qui nous intéressent
tous, le reverse-engineering de ces applications dédiées aux smartphones.


Les outils de base:

- Un émulateur

* hxxp://developer.android.com/sdk/index.html (émulateur contenu dans le SDK)
* hxxp://www.addictivetips.com/windows-ti ... -emulator/
(pour ceux qui ne veulent pas prendre le SDK)


- Un compilateur/décompilateur Smali

* hxxp://code.google.com/p/android-apktool/


- Un des convertisseurs DEx/Java (Utile pour ceux qui ne sont pas familiers du Smali)

* hxxp://code.google.com/p/dex2jar/


- Un décompilateur de classes Java

* hxxp://java.decompiler.free.fr/?q=jdgui



Concernant l'émulateur, il est conseillé de rapidement le modifier pour ne pas être
directement identifié par les cibles comme tels. La détection de l'émulateur se fait
assez facilement de la part du programme, à savoir qu'il suffit de récupérer les
informations propres au smartphone (IMEI, IMSI, MIN, ESMetc..). Un émulateur à un IMEI à
0 par exemple, il faut donc retrouver dans la cible la partie où il stocke ces
identifiants, et introduire une valeur non nulle de manière à passer pour un appareil
légal.


Concernant les convertisseurs Dex/Java/C, il sont très utiles lorsqu'on débute et qu'on
ne maîtrise pas le smali aussi bien que le Java ou le C. Par contre, il faut en
permanence garder en mémoire que ces convertisseurs ne sont pas aboutis à 100%. On
retrouve assez souvent des erreurs d'interprétations. Qui font que le code que vous
voyez semble correct (il est fonctionnel), mais ne correspond pas à ce qui est
réellement exécuté par le smartphone.

Cela peut vous faire manquer des branchement importants par exemple, ou même vous cacher
des fonctions du programme. Donc ne pas hésiter à utiliser ces outils mais toujours
garder en mémoire qu'en cas de doute, ou de code qui ne correspond pas au comportement
observé, de partir sur la version smali.



En pratique:

Première étape, installer l'émulateur et les programmes. Je vous laisse vous référer à
la documentation, rien de spécial à dire à ce niveau. Pour notre exemple, j'ai
téléchargé un fichier apk que l'on trouve sur internet sans passer par le 'store'


Installation d'un paquet dans l'émulateur (attention, l'émulateur doit tourner pour
pouvoir installer une application):


C:\smali\Android-Emulator>adb install diskusage_3.2.1.apk
1498 KB/s (153503 bytes in 0.100s)
pkg: /data/local/tmp/diskusage_3.2.1.apk
Success


Notre application apparaît alors dans l'émulateur.

A partir de ce point, il y a deux possibilités d'approcher le code, soit utiliser le
convertisseur Dex2jar pour transformer l'exécutable (dex : Dalvik excutable) en code
java, soit décompiler le dex en smali.


1.Décompilation smali


Pour obtenir le code source, on utilise apktool avec l'option d (comme decode), en
incluant le nom du paquet ainsi que le dossier de destination dans lequel il va stocker
le contenu du paquet:


c:\smali\apktool>apktool d diskusage_3.2.1.apk diskusage

I: Baksmaling...
I: Loading resource table...
I: Loaded.
I: Loading resource table from file: C:\Users\********\apktool\framework\1.apk
I: Loaded.
I: Decoding file-resources...
I: Decoding values*/* XMLs...
I: Done.
I: Copying assets and libs...


On retrouve dans notre dossier le contenu complet du paquet. Ce qui nous intéresse plus
particulièrement, c'est le dossier smali:


Répertoire de c:\smali\apktool\diskusage

23.03.2012 08:08 <REP> .
23.03.2012 08:08 <REP> ..
23.03.2012 08:08 1'875 AndroidManifest.xml
23.03.2012 08:08 98 apktool.yml
23.03.2012 08:08 <REP> assets
23.03.2012 08:08 <REP> res
23.03.2012 08:08 <REP> smali
2 fichier(s) 1'973 octets



La fichier AndroidManifest est un fichier de type XML, qui contient entre autres la
version minimale de l'OS nécessaire pour faire tourner l'application, ainsi que certains
privilèges nécessaires à l'application (ci-dessous un extrait du manifest):


Code: Tout sélectionner
<?xml version="1.0" encoding="utf-8"?>

// Ci dessous la version d'OS nécessaire

<manifest android:versionCode="3021" android:versionName="3.2.1" android:installLocation="auto" package="
                           com.google.android.diskusage"
  xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-sdk android:minSdkVersion="1" android:targetSdkVersion="11" />

// permissions spécifiques à l'applciation


    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.GET_PACKAGE_SIZE" />

etc....


</manifest>


Les dossiers assets et res contiennent les ressources nécessaire au programme.

Le dossier smali contient le code proprement dit.

Extrait de code smali:

Code: Tout sélectionner
   :goto_0
    array-length v4, v3

    if-ge v2, v4, :cond_2

    aget-object v4, v3, v2

    const-string v5, "referrer_index"

    invoke-virtual {v4, v5}, Ljava/lang/String;->equals(Ljava/lang/Object;)Z

    move-result v4

    if-eqz v4, :cond_1

    move v1, v8

    :cond_0
    :goto_1
    add-int/lit8 v2, v2, 0x1


(Opcodes smali : hxxp://pallergabor.uw.hu/androidblog/da ... codes.html)


2.Conversion en Java:


L'utilitaire Dex2jar propose plusieurs fonctionnalités, la principale qui nous
intéresse étant la possibilité de convertir l'exécutable en format Java. Pour utiliser
dex2java, il faut repartir du paquet apk, qui n'est qu'une enveloppe zip du fichier
exécutable et des ressources liées à l'exécutable.

Si on reprend notre paquet du debut, on peut l'extraire en tant qu'archive de type .zip:

Répertoire de C:\smali\Android-Emulator\diskusage_3.2.1

23.03.2012 08:19 <REP> .
23.03.2012 08:19 <REP> ..
19.03.2012 06:32 3'540 AndroidManifest.xml
23.03.2012 08:19 <REP> assets
19.03.2012 06:32 187'484 classes.dex
23.03.2012 08:19 <REP> META-INF
23.03.2012 08:19 <REP> res
19.03.2012 06:32 32'828 resources.arsc
3 fichier(s) 223'852 octets


On retrouve nos dossiers ressources (asset et res), le dossier smali étant logiquement
remplacé par l'exécutable DEX, le dossier META-INF contenant le certificat du fichier
apk, et la signature SHA-1 des resources.


Il reste maintenant à convertir notre exécutable:


c:\smali\dex2jar-0.0.9.8>d2j-dex2jar classes.dex
dex2jar classes.dex -> classes-dex2jar.jar

c:\smali\dex2jar-0.0.9.8>d2j-asm-verify classes-dex2jar.jar
verify classes-dex2jar.jar


A partir de là, le plus simple, c'est d'utiliser le programme JD-GUI pour accéder au
code source.


Extrait de code :


Code: Tout sélectionner
import java.util.ArrayList;
import java.util.Arrays;

public class AppUsage extends DiskUsage
{
  private AppFilter pendingFilter;

  private FileSystemSpecial getAppsElement(FileSystemState paramFileSystemState)
  {
    FileSystemEntry localFileSystemEntry = paramFileSystemState.masterRoot.children[0].children[0];
    if ((localFileSystemEntry instanceof FileSystemPackage))
      localFileSystemEntry = localFileSystemEntry.parent;
    return (FileSystemSpecial)localFileSystemEntry;
  }



Comme vous pouvez le constater, on se retrouve avec un code parfaitement lisible.



3.Repackaging du code:


Afin de ne pas trop alourdir ce document, on va simplement voir comment reconstruire le
paquet apk à partir d'un code modifié, en l'occurrence une simple traduction d'une chaîne
de caractère qui est affichée par le programme:


On transforme dans un fichier smali la chaîne :


Code: Tout sélectionner
    const-string v1, "clear history finished"

    iget v2, p1, Landroid/os/Message;->arg1:I


En:

Code: Tout sélectionner
    const-string v1, "Effacement de l'historique terminé"

    iget v2, p1, Landroid/os/Message;->arg1:I




On reconstruit le fichier apk avec apktool:


c:\smali\apktool>apktool b diskusage du.apk

I: Checking whether sources has changed...
I: Smaling...
I: Checking whether resources has changed...
I: Building resources...
I: Building apk file...



On signe le paquet:

c:\smali\dex2jar-0.0.9.8>d2j-apk-sign du.apk
sign du.apk -> du-signed.apk


(note : dex2jar permet également la reconstruction du paquet, mais à partir des classes
Java, un peu plus long donc....)


On supprime notre ancienne version du programme de l'émulateur:


c:\smali\Android-Emulator>adb shell

# cd /data/app
cd /data/app
# ls
ls
SoftKeyboard.apk
ApiDemos.apk
com.shazam.android.apk
com.softakgames.tappuzzle.apk
com.google.android.diskusage.apk
# rm com.google.android.diskusage.apk
rm com.google.android.diskusage.apk
# exit
exit



Et on installe notre nouveau paquet:

c:\smali\Android-Emulator>adb install du-signed.apk
1184 KB/s (133403 bytes in 0.110s)
pkg: /data/local/tmp/du-signed.apk
Success



!!Attention!! : Suivant le programme, il peut être nécessaire de faire un wipe
complet de l'émulateur pour pouvoir réinstaller le paquet, Android étant assez
sensible lorsqu'on réinstalle un paquet avec un nom identique à un paquet déjà
installé si la signature n'est pas identique (traces dans /DATA qui ne sont pas
forcément supprimées lorsqu'on retire le paquet avec la méthode ci-dessus)


Les erreurs apk-tool courantes:


* Failure [INSTALL_FAILED_OLDER_SDK]

Cela signifie que l'application vise à utiliser une version supérieure de l'OS par
rapport à celle qui est installée.

Solution => upgrader l'émulateur


* Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]

Cela signifie que le paquet que l'on tente d'installer n'est pas signé

Solution => signer le paquet avec dex2java (d2j-apk-sign)


* [INSTALL_FAILED_UPDATE_INCOMPATIBLE]

Cela signifie que l'émulateur contient des traces d'un programme du même
nom mais dont la signature ne correspond pas

Solution => Wipe de l'émulateur



etherlord
http://www.forumcrack.com
etherlord
Triumvirat
Triumvirat
 
Messages: 2471
Inscription: 22 Mars 2004, 16:12

Re: Introduction au RCE sur Android

Messagepar Todd » 23 Mars 2012, 22:12

Salut,

merci pour cet excellent dossier sur Android ! 8)
On peut dire qu'il est complet et qu'il rassemble l'essentiel des éléments pour nous permettre de regarder ça de plus près ! :D

Todd
Avatar de l’utilisateur
Todd
Modérateur
Modérateur
 
Messages: 1795
Inscription: 19 Avril 2009, 12:11

Re: Introduction au RCE sur Android

Messagepar baboon » 23 Mars 2012, 22:55

Ah cool merci ! :)
Ca donne de bonnes bases pour se lancer dans l'aventure !

Je me permet d'ajouter le framework androgard à ton post : hxxp://code.google.com/p/androguard
Il est assez orienté analyse de malware et création de tool plus que analyse manuelle mais il est assez prometteur.
Et puis c'est dev par un français (cocorico ;) )
Newbie mais ayant soif d'apprendre et étant motivé
Avatar de l’utilisateur
baboon
Modérateur
Modérateur
 
Messages: 3274
Inscription: 08 Juillet 2005, 17:49

Re: Introduction au RCE sur Android

Messagepar Kaslyb » 16 Avril 2012, 09:33

J'avais fait un essai avec le tuto de virtuallabs qui traine aussi sur ce forum, j'étais resté bloqué sur l'installation du paquet (A noter que je faisais ca sur mon tel directement et non sur l'émulateur).

Tu m'as donné une piste à regarder, celle des datas qui trainent. J'essayerai la solution de l'émulateur avant de faire un wipe de mes données =) (L'appli visée pour les tests était météo france pour virer les pub, rien de difficile)

J'ai aussi rencontré un jeu qui avait un fichier.so. La méthode décompilation java fonctionne pas dans ce cas et on doit passer par un debugger standard. Est ce que vous avez des outils plus faciles que gdb ?
Kaslyb
Membre Anti-Shareware
Membre Anti-Shareware
 
Messages: 87
Inscription: 16 Juillet 2007, 09:39
Localisation: export LANG=C

Re: Introduction au RCE sur Android

Messagepar Deamon » 16 Avril 2012, 16:48

Intéressant, merci etherlord. :)
Deamon

Les connaissances qu'on a cherchées restent, celles qu'on n'a pas cherchées se perdent. [Baden-Powell]
En un mot : cherche sur Google avant de demander !
Avatar de l’utilisateur
Deamon
Triumvirat
Triumvirat
 
Messages: 4374
Inscription: 25 Janvier 2004, 12:46
Localisation: Devant mon PC

Re: Introduction au RCE sur Android

Messagepar etherlord » 17 Avril 2012, 07:25

Est ce que vous avez des outils plus faciles que gdb ?


j'hésite à répondre IDA..... (plus facile ? :roll: )

etherlord
etherlord
Triumvirat
Triumvirat
 
Messages: 2471
Inscription: 22 Mars 2004, 16:12

Re: Introduction au RCE sur Android

Messagepar Kaslyb » 17 Avril 2012, 13:37

IDA pour une analyse statique m'irait déjà bien. J'ai pas testé, la version leak 6.1 sait decompiler du arm ?
(J'ai bien compris que pour une analyse dynamique c'est mort ;))
Kaslyb
Membre Anti-Shareware
Membre Anti-Shareware
 
Messages: 87
Inscription: 16 Juillet 2007, 09:39
Localisation: export LANG=C

Re: Introduction au RCE sur Android

Messagepar Todd » 17 Avril 2012, 16:51

Kaslyb a écrit:la version leak 6.1 sait decompiler du arm ?
IDA... rien ne l'arrête ! 8)
Code: Tout sélectionner
    Famille Intel 80x86
    ARM, y compris jeu d'instructions Thumb
    Motorola 68xxx/h8
    Zilog Z80
    MOS Technology 6502
    Intel i860
    DEC Alpha
    Analog Devices ADSP218x
    Angstrem KR1878
    Atmel AVR series
    DEC series PDP11
    Fujitsu F2MC16L/F2MC16LX
    Fujitsu FR 32-bit Family
    Hitachi SH3/SH3B/SH4/SH4B
    Hitachi H8: h8300/h8300a/h8s300/h8500
    Série Intel 196 : 80196/80196NP
    Série Intel 51 : 8051/80251b/80251s/80930b/80930s
    Série Intel i960
    Série Intel Itanium (ia64)
    Machine virtuelle Java
    MIPS: mipsb/mipsl/mipsr/mipsrl/r5900b/r5900l
    Microchip PIC: PIC12Cxx/PIC16Cxx/PIC18Cxx
    MSIL
    Famille Mitsubishi 7700 : m7700/m7750
    Mitsubishi m32/m32rx
    Mitsubishi m740
    Mitsubishi m7900
    Famille DSP 5600x : dsp561xx/dsp5663xx/dsp566xx/dsp56k
    Motorola ColdFire
    Motorola HCS12
    NEC 78K0/78K0S
    PA-RISC
    PowerPC
    SGS-Thomson ST20/ST20c4/ST7
    Famille SPARC
    Samsung SAM8
    Siemens C166 series
    TMS320Cxxx series
Source Wikipédia. :wink:

Todd
Avatar de l’utilisateur
Todd
Modérateur
Modérateur
 
Messages: 1795
Inscription: 19 Avril 2009, 12:11

Re: Introduction au RCE sur Android

Messagepar baboon » 18 Avril 2012, 09:09

Oui mais non
la version leakée de IDA comporte hexrays x86 mais pas ARM, elle sait donc désassembler l'arm mais pas le décompiler.
Newbie mais ayant soif d'apprendre et étant motivé
Avatar de l’utilisateur
baboon
Modérateur
Modérateur
 
Messages: 3274
Inscription: 08 Juillet 2005, 17:49

Re: Introduction au RCE sur Android

Messagepar Todd » 12 Juillet 2012, 14:12

Je viens enfin de trouver une occasion et quelques minutes pour essayer cet excellent tutoriel 8), sur un programme douteux qui demandait le droit de consulter l'état du téléphone* :o, alors que cela ne semblait avoir aucun lien avec la fonction première de cet outil ! :twisted: De plus, certains freewares ont tendances à abuser de la publicité :evil: et une petite "optimisation" peut être nécessaire. :mrgreen:

Bref, j'ai suivi à la lettre les instructions et il n'y a absolument rien à redire :roll: ... sauf que moi j'ai toujours quelque chose à dire ! :lol: Disons qu'il y a simplement deux petites précisions à ajouter :wink: :

1) Pour les étourdis comme moi, qui foncent tête baissée sur les téléchargements :P ... pour en conclure que apktool ne fonctionne pas ! :aie:
Je préciserai juste qu'il faut parfois prendre le temps de lire pour gagner du temps ! :oops:
android-apktool a écrit:Exemple pour Windows:
    Download apktool-install-windows-* file
    Download apktool-* file
    Unpack both to your Windows directory
En gros, il ne faut pas se contenter de télécharger le fichier pour sa version d'OS :wink:

2) L'autre "difficulté" est que depuis que le MarketPlace a muté en PlayStore (vous me direz : "Aucun rapport !?") et bien les fichiers APK officiels et non open-source sont extrêmement difficiles à trouver ! :? Certes, les sites de partages illégaux proposent un peu de tout, mais en terme d'authenticité et d'intégrité, on a vu mieux, car on a plus de chance de choper des cochonneries qu'autre chose. :evil: Tout ça pour dire que les fichiers APK se téléchargent et s'installent en toute transparence et qu'on n'a plus la main dessus. :( Bien entendu, il y a des solutions :D, dont voici les deux principales :
    a) Avoir les droits en tant que 'root' sur son mobile, ce qui donne accès aux entrailles du système et permet de récupérer ce dont on a besoin. :wink: Notez que les fichiers APK sont stockés dans "/data/app/", voire "/data/app-private/" et qu'ils sont vides avec des droits standards. :cry:
    Le problème est qu'être 'root' est "dangereux" et ça peut aussi être délicat à mettre en place :| ... mais voici deux possibilités :
      -Soit trouver une application compatible avec votre mobile pour démarrer Android en tant que 'root'. :) Pour ma part j'en ai essayé plusieurs sans succès... seul 'Unlock Root' a été en mesure de réussir ! 8) Il est conseillé de quitter le mode 'root' après avoir fini. :wink:
      -Soit se connecter à son mobile en USB via le mode console, en apprenant à se servir de adb.exe, très puissant, mais à manipuler également avec précaution. :roll: Voici un dossier très complet ici. :wink: D'ailleurs cet article vous permettra de comprendre comment lancer certaines commandes présentées par etherlord. :roll:
    b) Sinon vous avez la méthode pour les Androïdophobes/linuxophobes :mrgreen:, qui consiste à installer simplement une application comme AppMonster et extraire les fichiers APK. :)

Cette fois-ci le dossier est complet ! :aie:
Ce sujet était original et passionnant, merci encore de l'avoir présenté ! :wink:

Todd

*Ma cible utilisait l'état du téléphone et précisément la fonction 'getDeviceId()' pour contrôler la licence. :wink:
Avatar de l’utilisateur
Todd
Modérateur
Modérateur
 
Messages: 1795
Inscription: 19 Avril 2009, 12:11


Retourner vers Tutoriels

Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 2 invités

cron