Je n'ai pas fait ce challenge pendant la nuit du Hack, c'est @PaulWebSec qui l'a validé lors du wargame. je n'avais jamais regardé un apk de près, je vais donc profiter de ce write up pour présenter tous les outils que j'ai pu utiliser pour valider ce challenge.
Enoncé du challenge:
Chuck Norris
Ce qui nous intéresse ici, c'est le code source de l'application. le fichier classes.dex semble tout indiqué.
Une recherche google plus tard et on apprend qu'il existe un outil nommé dex2jar permettant de transformer un .dex en .jar. Il est de plus livré de base avec Kali / Accessible dans le AUR repository dans Archlinux / téléchargeable en tar.gz.
On a maintenant un beau .jar prêt à être décompilé. Pour cela jd-gui est l'outil tout indiqué. On le télécharge depuis leur site web ou dans l'AUR. Ensuite, un simple
permet d'obtenir une GUI présentant le code source de l'application. Ce code source est cependant lacunaire. Il permet simplement d'avoir une idée de ce qui se passe mais ne permet pas de patcher un apk.
Pour patcher un apk, il faut utiliser un autre outil: apktool.
Petit piège, il faut utiliser apktool2 pour que tout marche bien, sinon gare aux heures de sommeil perdues en vain devant des pages d'exception java. Donc téléchargez apktool depuis le site de son auteur et pas depuis autre part. apktool doit être situé dans le path, ainsi que apktool.jar et aapt. Tant qu'on y est mettez aussi les dossiers platform-tools et tools du sdk android dans le path.
On peut alors désassembler l'apk pour obtenir un code entre le Java et le Bytecode: le smali. Compréhensible et modifiable.
Sous windows, on peut aussi utiliser Virtuous 10 qui permet en quelques clics d'obtenir le smali. Je n'ai pas réussi à le faire fonctionner. J'obtiens les mêmes erreurs qu'avec apktool 1.
Une autre façon de voir ce qui se passe dans cet apk est ... de le lancer.
Pour cela on peut soit lancer l'apk sur un vrai smartphone, soit le lancer grâce à l'émulateur fourni par le sdk android.
Pour utiliser l'émulateur, trois étapes nécessaires:
Ma première tentative a été de désassembler l'apk avec apktool, de changer le numéro de téléphone en un que je connais puis de réassembler l'apk. Je pense que ça fonctionne, mais mon téléphone est trop vieux, l'apk ne le supporte pas.
On répond aux trois questions et droidbox enregistre (entre autre) l'appel sms et l'affiche sous forme de json.
Le contenu du sms est le flag à valider: NDH2k14_2F6F1126D3DD17DA3A42CBE0C2B0447C
Enoncé du challenge:
Chuck Norris
We found a strange application on Chuck Norris' smartphone. Notice would be something like NDH2K14_XXXXXXXX
(where XXXXXXXX stands for the mysterious hash inside the application).
On télécharge l'apk et c'est parti ! Première étape: Un apk, qu'est ce que c'est ?
[tic@Arch ndh]$ file ChuckNorris.apk ChuckNorris.apk: Microsoft OOXML
[tic@Arch ndh]$ unzip ChuckNorris.apk; ls ChuckNorrisAndroidManifest.xml classes.dex META-INF res resources.arscCe qui nous intéresse ici, c'est le code source de l'application. le fichier classes.dex semble tout indiqué.
[tic@Arch ndh]$ file classes.dex classes.dex: Dalvik dex file version 035
Une recherche google plus tard et on apprend qu'il existe un outil nommé dex2jar permettant de transformer un .dex en .jar. Il est de plus livré de base avec Kali / Accessible dans le AUR repository dans Archlinux / téléchargeable en tar.gz.
[tic@Arch ndh]$ dex2jar classes.dex dex2jar classes.dex -> classes-dex2jar.jarOn a maintenant un beau .jar prêt à être décompilé. Pour cela jd-gui est l'outil tout indiqué. On le télécharge depuis leur site web ou dans l'AUR. Ensuite, un simple
[tic@Arch ndh]$ jd-gui classes.dex2jar.jarpermet d'obtenir une GUI présentant le code source de l'application. Ce code source est cependant lacunaire. Il permet simplement d'avoir une idée de ce qui se passe mais ne permet pas de patcher un apk.
Pour patcher un apk, il faut utiliser un autre outil: apktool.
Petit piège, il faut utiliser apktool2 pour que tout marche bien, sinon gare aux heures de sommeil perdues en vain devant des pages d'exception java. Donc téléchargez apktool depuis le site de son auteur et pas depuis autre part. apktool doit être situé dans le path, ainsi que apktool.jar et aapt. Tant qu'on y est mettez aussi les dossiers platform-tools et tools du sdk android dans le path.
On peut alors désassembler l'apk pour obtenir un code entre le Java et le Bytecode: le smali. Compréhensible et modifiable.
[tic@Arch ndh]$ apktool d $(pwd)/ChuckNorris.apk# désassemble l'apk[tic@Arch ndh]$ apktool b $(pwd)/ChuckNorris.apk # réassemble l'apk
Sous windows, on peut aussi utiliser Virtuous 10 qui permet en quelques clics d'obtenir le smali. Je n'ai pas réussi à le faire fonctionner. J'obtiens les mêmes erreurs qu'avec apktool 1.
Une autre façon de voir ce qui se passe dans cet apk est ... de le lancer.
Pour cela on peut soit lancer l'apk sur un vrai smartphone, soit le lancer grâce à l'émulateur fourni par le sdk android.
Pour utiliser l'émulateur, trois étapes nécessaires:
[tic@Arch ndh]$ android [tic@Arch ndh]$ android avd
[tic@Arch ndh]$ emulator -avd <nom_vm>
[tic@Arch ndh]$ adb install -r ChuckNorris.apk
Ma première tentative a été de désassembler l'apk avec apktool, de changer le numéro de téléphone en un que je connais puis de réassembler l'apk. Je pense que ça fonctionne, mais mon téléphone est trop vieux, l'apk ne le supporte pas.
On répond aux trois questions et droidbox enregistre (entre autre) l'appel sms et l'affiche sous forme de json.
Le contenu du sms est le flag à valider: NDH2k14_2F6F1126D3DD17DA3A42CBE0C2B0447C
.png)
