Spirit Of Hack

Bon, quelques infos car là je suis bloqué.

Tout d'abord, on a un fichier 7zip. On dézippe, ok.
Bien sur, un grep @sstic.org n'affiche rien :-)

Le fichier est un memory dump, donc on attaque à grand coup de strings; rapidement on lit:
<6>Initializing cgroup subsys cpu
<5>Linux version 2.6.29-00255-g7ca5167 (digit@digit.mtv.corp.google.com) (gcc ve
rsion 4.4.0 (GCC) ) #9 Tue Dec 1 16:12:35 PST 2009
<4>CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177
<4>CPU: VIVT data cache, VIVT instruction cache
<4>Machine: Goldfish

avec ce numéro de kernel, on trouve qu'il s'agit d'une machine android 2.1.

L'émulateur s'installe depuis
http://developer.android.com/sdk/download.html?v=android-sdk_r05-linux_86.tgz

L'analyse des strings montre aussi:
com.anssi.textviewer
com.anssi.textviewer.textviewer
SecretApplicationcom.anssi.secretcom.anssi.secret.SecretJNI17301651

Hypothèse:
On a deux applis installées par l'ANSSI, une appelée textviewer, une appelée secret qui a un JNI (un genre de librairie partagée)

Je balance un coup de photorec sur le dump. J'ai une centaine de fichiers, mais pas grand chose de flagrant, sauf:
<package name="com.anssi.secret" codePath="/data/app/com.anssi.secret.apk" syste
m="false" ts="1270823989000" version="1" userId="10025">
<sigs count="1">
<cert index="5" key="308201ab30820114a00302010202044bbf3318300d06092a864886f70d0
101050500301a311830160603550403130f4368616c6c656e6765205353544943301e170d3130303
430393134303035365a170d3131303430393134303035365
a301a311830160603550403130f4368616c6c656e676520535354494330819f300d06092a864886f
70d010101050003818d0030818902818100920f2bc6b763a7e95466d92af9e6fc542608154f0910c
0c04cb8c023e6959c2b6fa359e056f560f1f9d9fa95accc2
f76ca481a28161bc777e50acabc52b4dccc37e001e99014bc249ebe91926cd1cd830f300de4713ee
11c9e513b1f96a50415610f52b760fa4d01185c7276a8c14a0026e5ff6d7edb2f0d3b6767485d868
4470203010001300d06092a864886f70d010105050003818
1000448bee215de4f3c3c9f1f9a63a4b9b54b230198047515af57e38e64ccf34089cfc01c8ab621b
b4e65ffabe0dd4241c9571162eba83fb3917d0f0cfe814e838b735140a94311257fe739106dd3012
2ea2af0d23789062a5732af9b660180c3808e790cf2d5440
fcc3783f0bc9fc556d027e7abb73ee159d278ebee5af4a8d1f1" />
</sigs>
<perms>
<item name="android.permission.ACCESS_LOCATION_EXTRA_COMMANDS" />
<item name="android.permission.ACCESS_FINE_LOCATION" />
<item name="android.permission.ACCESS_MOCK_LOCATION" />
</perms>
</package>

Le coup des permissions se lit:
http://developer.android.com/reference/android/Manifest.permission.html

donc l'appli secret.anssi doit pouvoir accéder à la géolocalisation du tel android. Je vérifie, l'emulateur permet de simuler cela au cas où.

Je regarde les apk installés, j'ai svox ??
http://www.svox.com/ une appli de text2speech. Curieux? C'est un faux positif, ou bien une partie de la solution? Le téléphone android qui lirait à haute voix l'adresse mail?

J'arrête de parser le dump avec les strings, j'avance un peu:

Travail: comment fonctionnent les programmes sous android.
Réponse:
On a un fichier .apk, qui est un zip, qui contient ceci:
AndroidManifest.xml  META-INF/  classes.dex  res/  resources.arsc
Le AndroidManifest.xml n'est pas du xml (bin non) c'est du wbxml. Apparement, je n'ai pas d'outil sous nux pour les lire (??). wbxml2xml me pète une erreur de libiconv? Je passe.
Le META-INF on s'en fout.
Le classes.dex est le bytecode compilé du programme. J'y reviens. Le res contient les ressources (audio video des progs) et le resources.arsc, c'est une version optimisée de res/
Le classes.dex c'est le bytecode de la machine virtuelle dalvik. C'est grosso modo une JVM.

Il n'existe à peu près aucun tool pour reverser du .dex. J'ai trouvé undx. Le classes.dex peut être optimisé au runtime en .odex. Là, il faut utiliser baksmali pour de-odexer le bytecode.

Hypothèse:
lors du chargement du programme apk, le fichier classes.dex doit bien passer dans le cache de la mémoire. Cherchons les classes.dex de la RAM et reversons les.
Les fichiers .dex ont une structure connue: http://retrodev.com/android/dexformat.html
Je lance l'outil scalpel sur challv2 avec comme critère de séléction:
dex     y       100000     dex\x0a\x30\x33\x35
L'émulateur dispose d'un outil dexdump.

Sur l'ensemble des fichiers, j'ai un fichier OK (vérifié à l'aide de dexdump), le textviewer.anssi qui fait 3092 octets.
Par contre, la decompile via undx ne me montre rien, ni avec baksmali

J'ai fait pas mal d'autres recherches de fichiers à l'aide de scalpel, mais absolument rien de probant n'en sort... J'ai cherché des fichiers sonores (rapport à svox) mais rien d'intéressant n'existe.

Bref, je passe un peu la main car là, je suis un peu au point mort. Si quelqu'un a une autre idée, je prends.

Le Bravo, oui, j'avais vu, mais sans plus d'infos, j'ai laissé de côté, je pensais plutôt que c'était à fournir à la fin.
Pour le bloc, non, c'est bien de l'ascii. Effectivement, c'est de l'ascii qui ressemble à de l'hexa, mais ça ne permet pas d'aller très loin.

Le début: 477689b3 ne correspond à rien de connu, comme programme. Aussi bien remis en binaire que laissé tel quel:
\x47 : G
\x76 : v
etc...
--> Néant.

Entre ce gros Bloc et le Bravo, on peut lire clinit et init qui sont deux mots clés de programmes java, mais qu'en faire?


Le bytecode de la JVM d'android, c'est le classes.dex qui peut être optimisé en .odex (optimized dex).

Pour dex, ce bytecode démarre par: dex.035 ; pour l'odex, c'est dey.035

Mais comme je dis, sur tous les dex et odex que je remonte de la mémoire via scalpel, je ne vois que le textviewer.anssi
Et la décompilation de ce programme fonctionne (au moins ça veut dire que j'ai bien récupéré le bon truc) mais ne m'apprend absolument rien :-/

C'est bien pour cette raison que je me demande:
- Si c'est pertinent de chercher dans le dump mémoire du bytecode Android
- Si oui, est ce que c'est du .dex ou du .odex qu'il faut chercher?

Ou alors:
- Peut-être que l'appli Android est une fausse route et qu'il faut chercher un programme linux-ARM plutôt que Dalvik?


Dans les autres pistes que je n'ai pas du tout exploré, c'est plutôt partir à l'envers et savoir quelle méthode a été employée pour générer le dump mémoire, peut-être que cela apprendrait des choses. Je pense qu'il a pris l'émulateur sous nux, puis qu'il a dumpé la RAM du process de l'émulateur auquel cas cela n'apprend rien, mais peut-être qu'il existe des manières de dumper la RAM d'un android qui permettrait d'apprendre des choses, typiquement, réinjecter la RAM dans un émulateur (j'y crois pas trop dû aux problèmes entre les fichiers sur disque et le cache fichier, mébon, ptet qu'il faut aller voir)

wali wala.