Daniel Verton - Portfolio

Objectif et cadre

Le reverse engineering mobile consiste à partir d'une application compilée, par exemple un fichier Android .apk ou iOS .ipa, pour comprendre son fonctionnement général. L'objectif peut être d'apprendre, d'auditer sa propre application, de vérifier des pratiques de sécurité ou de documenter un comportement.

Ce tutoriel ne vise pas à contourner une authentification, accéder à des données privées, abuser d'une API non documentée ou suivre des utilisateurs sans autorisation. Il s'applique à des applications que vous possédez, à des environnements de test, à des labs volontairement vulnérables ou à des audits explicitement autorisés.

Définir le périmètre légal

Avant toute analyse, documentez le périmètre :

Application :
Version :
Plateforme : Android / iOS
Objectif : apprentissage / audit interne / bug bounty / pentest
Autorisation : oui / non
Dates de test :
Actions autorisées :
Actions interdites :
Contact sécurité :

Une application publiquement téléchargeable n'autorise pas automatiquement l'extraction de secrets, l'automatisation d'appels privés, le contournement de protections ou l'accès à des données qui ne vous appartiennent pas. Le bon réflexe est de travailler sur ses propres applications, des applications open source, des labs OWASP Mobile, un environnement de préproduction ou un programme de bug bounty avec règles explicites.

Analyse statique et analyse dynamique

L'analyse statique inspecte l'application sans l'exécuter. Elle couvre le manifeste Android, les permissions, les fichiers de configuration, les ressources, les chaînes de caractères, le code décompilé, les certificats et les bibliothèques embarquées.

L'analyse dynamique observe l'application pendant son exécution. On regarde les logs, les fichiers locaux créés, les préférences sauvegardées, la base de données locale, les scénarios utilisateur et, dans un cadre autorisé, les échanges réseau.

Les deux approches se complètent : la statique donne une carte, la dynamique montre le comportement réel.

Préparer son environnement

Séparez votre environnement d'analyse de votre téléphone personnel. Idéalement, utilisez :

un ordinateur Linux, macOS ou Windows ;
un téléphone Android de test ou un émulateur ;
un compte de test dédié ;
aucune donnée personnelle sensible sur l'appareil ;
des données fictives pour les scénarios.

Outils utiles

Côté Android, les outils courants sont :

adb pour communiquer avec l'appareil ;
jadx pour décompiler un APK en Java/Kotlin approximatif ;
apktool pour décoder ressources et manifeste ;
Android Studio pour l'émulateur, les logs et l'inspection ;
MobSF pour une première passe automatisée ;
mitmproxy, Burp Suite, Proxyman ou Charles Proxy pour l'observation réseau autorisée ;
Frida pour l'instrumentation dynamique dans un cadre de test strict.

Côté iOS, l'analyse est souvent plus contrainte. On rencontre Xcode, Console.app, MobSF, Frida, des outils Mach-O et parfois class-dump ou alternatives modernes. Pour débuter, Android est généralement plus accessible.

Récupérer et documenter l'APK

Depuis un appareil de test Android, on peut localiser une application :

adb shell pm list packages | grep nom.de.lapp
adb shell pm path com.exemple.application

Puis récupérer le fichier :

adb pull /data/app/chemin/base.apk ./application.apk

Selon les versions Android, l'app peut être découpée en plusieurs APK : base.apk, split de langue, split d'architecture ou split de densité. Documentez ensuite la version :

aapt dump badging application.apk
sha256sum application.apk

Le hash évite toute ambiguïté dans un rapport.

Première passe avec apktool

apktool décode les ressources et le manifeste :

apktool d application.apk -o application_decoded

On obtient notamment :

application_decoded/
├── AndroidManifest.xml
├── apktool.yml
├── res/
├── smali/
└── assets/

Le manifeste indique le package, les activités, services, receivers, providers, deep links, permissions et configurations réseau. La question utile n'est pas seulement "quelles permissions sont demandées ?", mais "sont-elles cohérentes avec la fonctionnalité annoncée ?".

Composants exportés et permissions

Un composant exporté peut être appelé par d'autres applications :

<activity
    android:name=".SomeActivity"
    android:exported="true" />

Ce n'est pas automatiquement une faille, mais cela mérite vérification. Regardez aussi les permissions sensibles comme localisation, caméra, contacts, stockage, micro ou notifications. Une permission doit toujours avoir une justification produit claire.

Décompiler avec JADX

JADX donne une représentation Java/Kotlin approximative :

jadx-gui application.apk
jadx -d jadx_output application.apk

Le résultat peut être incomplet, obfusqué ou différent du code source original. Il reste très utile pour comprendre l'architecture, les modèles, les bibliothèques et les zones sensibles.

Recherches utiles :

http, https, api, baseUrl, retrofit, okhttp, graphql,
firebase, sentry, amplitude, mixpanel,
token, auth, jwt, bearer, secret, client_id

Ces recherches servent à cartographier les risques dans un audit défensif, pas à réutiliser des secrets.

Ressources et configuration

Inspectez assets/, res/raw/ et res/xml/. On y trouve parfois des URLs d'environnement, flags, fichiers JSON, configurations Firebase, certificats publics ou règles de sécurité réseau.

Une configuration réseau Android peut ressembler à ceci :

<application
    android:networkSecurityConfig="@xml/network_security_config">
</application>

À vérifier : HTTP clair autorisé ou non, domaines spécifiques, différences debug/release, certificats de confiance et éventuel certificate pinning.

Stockage local

Dans un environnement autorisé, on inspecte souvent :

/data/data/com.exemple.application/
├── shared_prefs/
├── databases/
├── files/
├── cache/
└── no_backup/

Cherchez si l'application stocke des tokens, données personnelles, historiques, préférences sensibles, fichiers temporaires ou données de session. Les bonnes pratiques attendues sont le stockage minimal, le chiffrement des données sensibles, l'expiration des sessions, l'absence de secrets statiques et l'absence de données sensibles dans les logs.

Logs et trafic réseau

Les logs Android se lisent avec :

adb logcat
adb logcat | grep com.exemple.application

Une app de production ne devrait jamais écrire tokens, mots de passe, emails, coordonnées, paiements ou données métier confidentielles.

L'observation réseau doit rester dans un cadre autorisé : compte de test, données fictives, environnement de test et endpoints explicitement couverts. On peut documenter domaines contactés, formats JSON, codes de réponse, erreurs, usage de TLS et cohérence des contrôles serveur. Sans autorisation explicite, évitez tout contournement de TLS, pinning, rejouage de requêtes ou automatisation.

Obfuscation

Avec R8 ou ProGuard, le code peut ressembler à :

public final class a {
    public final String b;
    public final int c;
}

Pour s'y retrouver, partez des chaînes de caractères, suivez les appels réseau, identifiez les modèles de données, repérez les annotations Retrofit ou de sérialisation et reconstruisez progressivement le graphe d'appel.

MobSF pour une première passe

MobSF automatise un rapport initial :

docker run -it --rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Puis ouvrez :

http://localhost:8000

MobSF peut repérer permissions, trackers, URLs, fichiers sensibles, certificats, bibliothèques, manifeste et configurations faibles. Un rapport automatique n'est jamais une vérité absolue : il sert de point de départ.

Méthodologie d'audit

Une analyse propre suit une méthode reproductible :

Identifier l'application : nom, package, version, hash, source, date.
Inspecter le manifeste : permissions, composants exportés, deep links, providers, services, configuration réseau.
Cartographier les dépendances : analytics, crash reporting, réseau, paiement, authentification, publicité, chiffrement.
Repérer les zones sensibles : auth, session, stockage local, logs, WebView, deep links, fichiers temporaires.
Tester dynamiquement avec un compte de test.
Rédiger un rapport clair : résumé, impact, conditions, preuves, risque et recommandation.

Mini-analyse fictive

Pour une app fictive DemoBike, le manifeste peut demander :

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

C'est cohérent pour afficher des stations proches. Dans network_security_config.xml, un bon signe serait :

<base-config cleartextTrafficPermitted="false" />

Dans le code décompilé, on peut repérer Retrofit :

Retrofit retrofit = new Retrofit.Builder()
    .baseUrl("https://api.example.com/")
    .build();

Dans un rapport public, on évite de divulguer des détails sensibles si l'URL réelle est privée. On documente le type de communication et le risque.

Points de vigilance fréquents

Les problèmes courants sont :

secrets embarqués dans l'APK ;
contrôles de sécurité uniquement côté client ;
logs trop bavards ;
WebView mal configurée ;
deep links trop permissifs ;
stockage local de tokens ou données personnelles en clair ;
configuration réseau trop permissive ;
sessions sans expiration claire.

Tout ce qui est dans un APK peut être extrait tôt ou tard. Les secrets critiques doivent rester côté serveur.

Ce qu'il faut éviter

Évitez d'utiliser des endpoints privés découverts par reverse, contourner des protections, accéder à des données qui ne vous appartiennent pas, publier des secrets, automatiser des appels sans autorisation, tester en production sans accord ou provoquer une charge excessive.

Une règle simple : si vous ne pourriez pas expliquer calmement votre action dans un rapport d'audit envoyé à l'éditeur de l'application, ne la faites pas.

Progresser sans risque

Pour apprendre, utilisez des cibles prévues pour ça : applications volontairement vulnérables, labs OWASP Mobile, apps open source, projets personnels, CTF mobiles ou bug bounties avec scope clair.

Compétences à développer : Android internals, Kotlin/Java, HTTP/TLS, OAuth/OIDC, stockage sécurisé, cryptographie appliquée, architecture backend et rédaction de rapports.

Checklist rapide

[ ] APK obtenu légalement
[ ] Version et hash documentés
[ ] Manifeste analysé
[ ] Permissions vérifiées
[ ] Composants exportés identifiés
[ ] Deep links inspectés
[ ] Network security config vérifiée
[ ] Code décompilé inspecté
[ ] Dépendances principales listées
[ ] Stockage local analysé
[ ] Logs vérifiés
[ ] Trafic réseau observé uniquement dans le cadre autorisé
[ ] Données sensibles recherchées
[ ] Rapport rédigé
[ ] Vulnérabilités signalées proprement

Conclusion

Le reverse engineering mobile est à la croisée du développement, de la sécurité, de l'architecture et de l'investigation technique. Bien utilisé, il améliore la sécurité des applications et aide à devenir un meilleur développeur.

Mal utilisé, il peut devenir intrusif ou illégal. La différence tient souvent à une seule chose : le cadre d'autorisation.

Reverse engineering mobile : méthode, outils et bonnes pratiques