Analyse de Pokemon GO ! (Part 1 : Analyse de l’APK)

A part si vous habitez dans une grotte, où que vous sortez d’une longue sieste de un mois, vous devez connaitre “POKEMON GO”, le jeu incroyablement populaire de Niantic Labs. Cette vague a deferlé, “out of nowhere”, sur la planète gaming des initiés et non initiés. Mélant Réalité augmentée, et le monde déjà riche des “Pokemon”, franchise à succès de Nintendo, ce jeu a, en quelques jours dépassé Twitter pour le nombre d’utilisateurs actifs, et dépassé Facebook en terme de temps journalier passé sur l’application.
Ce succès fulgurant a laissé place a beaucoup de rumeur, sur l’insecurité de l’application, l’usage d’informations personnelles, ou pire, l’envoi vers les serveurs du méchant “Nintendo” des images de votre webcam, de votre quotidien, de vos trajets. Cet article est un petit exercice pour comprendre le fonctionnement de l’application, et en même temps une introduction aux outils utilisé pour le “reverse engineering” de l’application android.

Analyse du APK

La première étape de notre analyse consiste à vérifier ce qui se cache à l’interieur de cette application. Pour celà, et comme l’application est encore indisponible au Maroc sur le Play Store Google, je me suis procuré le fichier APK disponible sur ce lien.
J’ai pris sciemment le risque d’utiliser cet APK très populaire, tout en sachant que tout fichier APK disponible sur une source autre que le Play Store est un risque potentiel en terme de cyber sécurité. Je voulais vérifier le fichier le plus populaire, le plus téléchargé depuis notre pays.
Le fichier APK est une archive simple. Vous pouvez l’ouvrir avec Winzip ou Winrar et constater l’arborescence suivante à l’interieur du APK :
[icon name=”folder-open-o” class=”” unprefixed_class=””] META-INF : Il s’agit d’un dossier contenant les données META de l’application
[icon name=”folder-open-o” class=”” unprefixed_class=””] RES : Il s’agit du dossier contenant les ressources du projet.
[icon name=”folder-open-o” class=”” unprefixed_class=””] ASSETS : Il s’agit du dossier contenant les ASSETS de l’application.
[icon name=”folder-open-o” class=”” unprefixed_class=””] LIB : Il s’agit du dossier contenant les librairies natives du projet.
[icon name=”file-text-o” class=”” unprefixed_class=””] RESOURCES.ARSC : C’est la version compilée du fichier R.JAVA qui permet aux applications android de manipuler les ressources.
[icon name=”file-text-o” class=”” unprefixed_class=””] MANIFEST : Le fichier manifest de l’application qui comprend plusieurs informations comme : le nom de l’application, l’icone, la version, les permissions..
[icon name=”file-text-o” class=”” unprefixed_class=””] CLASSES.DEX : C’est la version compilée du code Java de l’application, et c’est sur ce fichier qu’on va s’atteler sur le prochain chapitre pour comprendre le fonctionnement.

Décompiler le DEX

DEX est le format “Dalvik Executable”. Il s’agit donc de l’executable qui démarre dans la machine virtuelle de Android.
Il existe plusieurs techniques pour décompiler un DEX, nous allons utiliser la plus simple à travers DEX2JAR, un outil qui va nous permettre de convertir l’executable en un JAR, autrement, en une archive comprenant les classes en bytecode Java. Ensuite nous allons utiliser un decompiler pour avoir le code JAVA depuis le .CLASS. Cet outil s’appelle JADX.
Télécharger DEX2JAR : https://sourceforge.net/projects/dex2jar/
Télécharger JADX : https://github.com/skylot/jadx
capture_code
Très important : Ce process ne nous permet pas d’avoir le code source tel qu’il a été écrit par le développeur ! Il s’agit plus ou moins d’une interprétation du moteur de décompilation de l’execution, et une décision sur le meilleur code qui execute la fonction en question. ce process donc cause beaucoup de pertes depuis le code original, notemment sur le nom des méthodes, des variables et le commentaire des développeurs …etc. Ceci ne nous posera pas de problème, on a pas besoin de savoir avec exactitude ce que fait l’application, et mes limitations en Java commencent à me poser de sérieux problèmes. Je vais essayer de comprendre les interactions de l’application à travers les librairies utilisées, comme je cherche à répondre à la question : Que fait l’application sur internet et sur le téléphone ?

Liste des librairies identifiées :

On remarque sur le code décompilée, que le nom des librairies n’est pas masqué ou crypté, on peut les voir clairement sur le code :
JACKSON (Parser JSON)
OTTO ( event bus, plus d’explications ici http://square.github.io/otto/)
DAGGER (optimisation de dependances, plus d’infos ici : http://square.github.io/dagger/)
GSON (un autre Parser JSON !)
APACHE COMMONS IO (pour les I/O)
FIREBASE-ADS (AdMob)
UPSIGHT (Analytics)
RXJAVA / RXANDROID (librairies de reactive programming)
CRITTERISM (log et monitoring de crash de l’appli)
UNITY (librairie et frameword de jeux video)
LUNAR MOBILE CONSOLE (log et monitoring des usages unity)
VOXELBUSTER CPNP (pour partager depuis unity)
GOOGLE VR SDK (fameuse librairie pour la réalité virtuelle de google !)
Celà fait beaucoup de librairies ! Pour une application qui a mis 10 ans à être conçue, il est anormal d’utiliser deux librairies de parsing JSON par exemple sur le même code. Il s’agit donc de l’ensemble des librairies et des dépendances des librairies utilisées. Une lecture du code permet de conclure que les seules librairies utilisées directement par le code de Pokemon GO sont :
GSON
CRITTERISM
UPSIGHT
FIREBASE-ADS
GOOGLE VR SDK
UNITY
En effet, UPSIGHT est la librairie qui necessite le reste des librairies dépendantes. A elle seule UPSIGHT rassemble 3000 methodes propres, et les méthodes des dépendances : 4000 RxAndroid, 200 Dagger, 1000 Commons I/O, 10000 JACKSON, 50 OTTO, 12000 Play Service ! Et tout ca pour les analytics ! Big DATA quand tu nous tiens. Ca nous donner une idée sur le business modèle de Pokemon GO, il est à présent certains que les données d’usage de l’application sont précieuses.
Maintenant que la liste de dépendance est claire, on voit que la première dépendance est UNITY.
Ceci explique pourquoi le logo de niantic et autre écran “loading” sont affichés au démarrage de l’application. Le Moteur UNITY a besoin de temps et de ressources pour démarrer en background. L’ensemble de l’application est donc à l’intérieur de Unity, il n’y pas d’element natif android de l’interface du jeu.
En terme de sécurité donc, Pokemon GO souffrirait des mêmes vulnérabilités que le moteur de jeu UNITY. Il y a lieu donc de se renseigner sur les limitations, les bugs et les travers de sécurité de ce moteur.
Une autre dépendance m’interesse, il s’agit du VR Google. Ceci laisserait présager que l’application serait dans le futur peut etre compatible avec les lunettes de réalité virtuelle VR Google. Malheureusement, sur le code, je vois que la librairie est utilisée seulement pour faire communiquer Unity avec la framework Android. Il n’y a aucun appel des méthodes ou des classes servant à adapter l’application à l’affichage du VR Cardboard Google. Donc à date, pas de code VR fonctionnel encore sur l’application. On devra encore utiliser nos téléphones !
Un troisième constat est que Google VR qui est la bibliothèque qui requiert le niveau d’android le plus élevé, requiert API Level 16 pour Android Jellybeans 4.1. Or sur le playstore, l’application a un requierement minimum de Android KitKat 4.4 Api LEVEL 19 ! Je ne sais pas pourquoi c’est le cas. D’après les chiffres de Google (https://developer.android.com/about/dashboards/index.html), 20% des utilisateurs donc ne peuvent utiliser l’application. Peut être une feature à venir qui requiert ce niveau minimum de Android.

Conclusion

A travers cette première analyse, nous connaissons maintenant la structure de l’application et ses dépendances. Le prochain article traitera d’une analyse du code, et notamment des communications réseaux, nous allons lister l’ensemble des serveurs avec qui l’application communique et nous allons ensuite faire une petite installation MITM (Man in the middle) pour pouvoir voir les interactions en clair de l’application avec les serveurs en question et confirmer si oui ou non, les informations communiquées sont relatives à votre vie privée ! A bientot !


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *