REA et Android : auditer une APK avec JADX et Apktool

19 octobre 2026

Pour une APK, REA demande deux choses : JADX en mode headless et un JDK complet, sous Linux, macOS ou Windows x64. En échange, l'agent reçoit les déclarations du manifeste, les classes, les méthodes décompilées et les références entre elles. De quoi répondre à la question qu'une équipe sécurité se pose avant d'autoriser une application mobile dans le parc : quelles données touche-t-elle, et vers quels serveurs ?

Ce que REA lit dans une APK

Le README de REA sépare trois cibles Android¹. Le code d'abord : via JADX headless, REA renvoie le manifeste, les classes, les méthodes décompilées et leurs références. Les ressources ensuite : avec un lanceur Apktool fourni par l'utilisateur, il décode le manifeste, les tables de chaînes, les locales et les informations de version. Les signatures enfin : un outil statique lit les signataires v1 à v3.1, les empreintes de certificats et la rotation de clé. Un appareil ou un émulateur peut aussi être piloté via adb, ce qui relève de l'analyse dynamique et d'un autre niveau de précaution.

La documentation Android du projet épingle la version exacte du pont : jadx-headless-mcp 0.7.1, dont il faut vérifier l'empreinte SHA-256 publiée avant usage, avec un JDK 17 ou plus récent, compilateur compris². Ce détail compte en entreprise : le composant qui ouvre l'APK est un jar téléchargé, et son intégrité se contrôle.

L'audit avant mise en catalogue

L'usage défensif type tient en trois listes. Les permissions demandées par l'application, lues dans le manifeste. Les bibliothèques embarquées, notamment les SDK d'analytics, de publicité ou de suivi, repérables par leurs paquets et leurs classes. Les domaines et les points de terminaison présents dans le code et les ressources. Ces trois listes nourrissent les vérifications préalables avant de déployer l'application sur les terminaux gérés, ou un contrôle de ce qu'elle transmet au regard du RGPD (voir vérifier ce qu'une application envoie).

Chaque trouvaille arrive avec sa localisation dans l'archive, ce qui permet à un analyste de la vérifier. C'est la même démarche que pour un binaire de bureau, décrite dans auditer un binaire fournisseur sans son code source.

Une image Docker pour ne rien installer sur l'hôte

Le 18 octobre 2026, un développeur a publié psyb0t/docker-reverse-engineer-anything, une image communautaire non officielle qui embarque OpenJDK 21, le jar jadx-headless-mcp 0.7.1 vérifié contre l'empreinte épinglée par REA, Apktool 3.0.3 et adb 34.0.5³. Son README donne deux modes. En serveur MCP, le conteneur tourne en lecture seule, sans capacités Linux (--cap-drop ALL), avec no-new-privileges, et publie son endpoint sur 127.0.0.1:8080 derrière un jeton. En ligne de commande, l'exemple ajoute --network none et coupe le réseau. Le projet est jeune (créé le 18 octobre) et confidentiel ; il illustre une posture plus qu'il ne constitue une recommandation. Ghidra n'y est pas inclus.

Cette posture compte parce que REA n'isole rien lui-même : sa politique de sécurité précise que l'outil n'est pas un sandbox et que l'ouverture d'une cible délègue l'analyse au moteur local, avec les droits de l'utilisateur⁴. Notre article REA n'est pas un sandbox détaille le confinement.

Les limites

La décompilation reste statique. Le code chiffré, chargé dynamiquement depuis le réseau ou exécuté dans une bibliothèque native passe sous le radar de JADX, et l'obfuscation dégrade la lisibilité des noms. Une liste de domaines tirée du code dit ce que l'application peut contacter, pas ce qu'elle contacte : pour le savoir, il faut l'exécuter dans un émulateur isolé et observer le trafic. Lisez enfin les inconnues de la sortie avec la même attention que les trouvailles (lire une sortie REA).

Côté droit, le DISCLAIMER de REA rappelle que posséder un fichier ne donne pas toutes les permissions : l'autorisation d'inspecter un artefact n'autorise pas nécessairement son exécution ou l'interception de ses échanges⁵. Auditez les applications que vous êtes autorisé à examiner, et voyez notre hub clean-room ou reverse engineering pour le cadre européen.

Pour l'architecture de l'outil et son installation, voir REA expliqué en trois schémas.

Questions fréquentes

Faut-il installer JADX soi-même ?

Oui, REA utilise une installation fournie par l'utilisateur, à la version et à l'empreinte indiquées dans sa documentation. Une image Docker peut l'embarquer pour éviter l'installation sur le poste.

REA voit-il le code chargé dynamiquement ?

En analyse statique, non. Il faut une exécution en émulateur isolé pour observer ce qui arrive du réseau.

Peut-on auditer n'importe quelle APK ?

Celles que vous êtes autorisé à examiner. Les applications que votre organisation déploie sur ses terminaux sont le cas le plus courant, mais les déployer ne vaut pas autorisation de les décompiler : l'audit passe d'abord par l'observation de leur fonctionnement, et la décompilation par le cadre légal (interopérabilité, correction d'erreurs) ou l'accord de l'éditeur. Point d'attention à faire valider par votre juriste.

Contrôler avant de déployer

Avec AI Cyber, nous montons ces audits d'applications en environnement confiné et livrons des constats vérifiés, avec leur preuve dans l'archive.

Sources

morluto/rea, README (tableau « What you can analyze »), github.com/morluto/rea, consulté le 19 octobre 2026.
morluto/rea, Android analysis (docs/android-analysis.md), github.com, consulté le 19 octobre 2026.
psyb0t, docker-reverse-engineer-anything, release v0.1.1, github.com, 18 octobre 2026.
morluto/rea, SECURITY.md, github.com, consulté le 19 octobre 2026.
morluto/rea, DISCLAIMER.md, github.com, consulté le 19 octobre 2026.