Reverse Engineering dans le développement mobile : ce que c’est, outils et méthodes d’analyse

Qu’est-ce que le Reverse Engineering ?

Le Reverse Engineering (ingénierie inverse) est la discipline d’analyse logicielle visant à récupérer les caractéristiques, la logique et la structure d’une application à partir de sa représentation binaire. Pour les applications mobiles, les objets d’analyse sont les fichiers APK (Android) et IPA (iOS), qui contiennent du code compilé, des ressources, des manifestes et des certificats. Le résultat du reverse engineering est l’extraction d’algorithmes, de protocoles, de clés de chiffrement, de schémas API et de logique métier.

Les objectifs du reverse engineering se divisent en légitimes et illégitimes. Légitimes : analyse de logiciels malveillants pour créer des outils de sécurité, audit de ses propres applications pour les vulnérabilités, garantie de compatibilité avec des protocoles fermés, analyse de brevets et formation. Illégitimes : vol de propriété intellectuelle, contournement de restrictions de licence, création de copies pirates et modification d’applications pour voler des données utilisateur. Selon Google Play Protect (2025), 78 % des modifications malveillantes des applications bancaires sont créées à partir de l’APK d’origine traité par reverse engineering.

La méthodologie du reverse engineering comprend deux directions principales : l’analyse statique (sans exécuter l’application) et l’analyse dynamique (pendant l’exécution). Chaque approche fournit un niveau d’information différent. L’analyse statique donne une image complète du code, mais sans données d’exécution. L’analyse dynamique révèle le comportement réel, le flux de données et les appels réseau, mais uniquement dans un scénario d’exécution spécifique. Le reverse engineering professionnel combine toujours les deux approches.

Outils d’analyse statique

L’analyse statique est la première étape du reverse engineering. L’APK ou l’IPA d’origine est décompressé, et chaque composant est analysé séparément. Les principales cibles : le bytecode DEX, les ressources, le manifeste, les bibliothèques natives (.so, .dylib) et les métadonnées.

jadx — décompilateur DEX vers Java

jadx est l’outil principal pour l’analyse statique des applications Android. Il convertit le bytecode DEX en code Java lisible avec une perte minimale. jadx prend en charge : la décompilation multidex, la reconnaissance des lambdas et des classes Kotlin intégrées, et l’exportation vers un projet Gradle. Pour le code obfusqué (ProGuard), jadx affiche le code avec des noms a, b, c, mais la structure des classes et la séquence des appels sont conservées. Selon des tests indépendants, jadx décompile correctement 85 – 92 % du code même avec obfuscation.

apktool — décompression des ressources

apktool décode l’APK en code smali (assembleur DEX) et restaure les ressources sous une forme lisible : AndroidManifest.xml est converti d’AXML en XML lisible, les layouts deviennent du balisage XML, strings.xml devient du texte brut. apktool permet de modifier les ressources et de reconstruire l’APK. Après décompression via apktool et remplacement des ressources, l’application peut être installée avec un contenu modifié.

Ghidra — analyse des bibliothèques natives

Ghidra (NSA) est un framework de reverse engineering essentiel pour analyser les bibliothèques .so sur Android et .dylib sur iOS. Ghidra désassemble le code ARM64, reconstruit le pseudo-code C et construit des graphes d’appels. Pour le reverse engineering mobile, Ghidra est utilisée pour analyser les implémentations natives de la cryptographie et des mécanismes DRM. Ghidra prend en charge les scripts en Python et Java pour automatiser l’analyse.

# Décompression et décompilation d’APK
$ jadx -d output_dir app.apk

# Décompression des ressources via apktool
$ apktool d app.apk -o app_unpacked

# Analyse de bibliothèque native via Ghidra
$ ghidra app.apk/lib/arm64-v8a/libnative.so

# Recherche de constantes de chaîne dans DEX
$ strings classes.dex | grep -i api_key

Outils d’analyse dynamique

L’analyse dynamique est effectuée sur une application en cours d’exécution. L’analyseur se connecte au processus et intercepte les appels de fonctions, les arguments et les valeurs de retour en temps réel.

Frida — outil d’instrumentation universel

Frida est l’outil leader pour l’analyse dynamique des applications mobiles. Frida injecte un moteur JavaScript dans le processus de l’application (Android ART ou application iOS) et permet d’intercepter les appels aux fonctions Java/Objective-C et C/C++. Avec Frida, les ingénieurs inverse peuvent : journaliser tous les appels à la méthode AES.decrypt() avec paramètres, substituer arbitrairement les valeurs de retour, désactiver le SSL-pinning via Universal Android SSL Unpin, et tracer les appels natifs via Stalker. Frida fonctionne sans modifier l’APK/IPA, ce qui la rend indispensable pour les tests d’intrusion.

Objection — surcouche de Frida

Objection fournit des commandes prêtes à l’emploi pour les tâches courantes de reverse engineering sans écrire de scripts JavaScript : disable-pinning (désactivation du SSL-pinning), dump-keychain (iOS), explore (parcours de la hiérarchie des classes), memory search (recherche de chaînes en mémoire). Objection permet d’effectuer une analyse dynamique complète sans une seule ligne de code. Pour les applications iOS, Objection trouve et journalise automatiquement les appels à NSURLSession, CFNetwork et NSKeyedArchiver.

Xposed Framework

Xposed est un framework pour Android qui fonctionne en remplaçant le fichier app_process dans Zygote. Contrairement à Frida, Xposed ne nécessite pas d’accès root après l’installation. Les modules Xposed peuvent intercepter les appels de méthodes dans n’importe quelle application. Pour le reverse engineering, Xposed est pratique pour l’analyse à long terme : le module est installé et fonctionne en continu, journalisant le comportement de l’application dans différents scénarios. Xposed prend en charge Android jusqu’à la version 8.1 ; pour Android 9+, EdXposed basé sur SandHook est utilisé.

// Frida : interception de la méthode decrypt() dans une application
let aesClass = Java.use("javax.crypto.Cipher");

aesClass.doFinal.overload(
    "[B", "int", "int"
).implementation = function(
    input, offset, len
) {
    console("[AES] decrypt called, len=" + len);
    return this.doFinal(input, offset, len);
};

Processus d’ingénierie inverse d’une application Android

Le flux de travail standard du reverse engineering comprend des étapes séquentielles, chacune fournissant un certain niveau d’information.

Étape 1 : Collecte de renseignements

L’analyste examine l’APK au niveau des métadonnées : targetSdk, uses-permission (quelles autorisations sont demandées), intent-filter et composants exportés. Les autorisations peuvent révéler quelles API sont utilisées (android.permission.CAMERA → caméra, android.permission.RECORD_AUDIO → audio). Les activités exportées identifient les points d’entrée sans authentification. Cette étape est réalisée via aapt ou ApkAnalyzer et prend 1 à 2 minutes.

Étape 2 : Décompilation DEX

L’APK est décompressé et classes.dex (ou multidex) est passé à jadx. La sortie est du code Java/Kotlin organisé en paquets. L’analyste recherche les classes clés : CryptoUtils, ApiClient, AuthManager, DatabaseHelper, et vérifie quels algorithmes sont utilisés. Si le code contient des chaînes comme AES/CBC/PKCS5Padding, l’application utilise le chiffrement et la clé doit être trouvée. À cette étape, sont identifiés : les clés codées en dur, les URL d’API, les tokens OAuth et les secrets. Sans obfuscation, tout le code de l’application se lit comme un projet Java ordinaire.

Étape 3 : Analyse du trafic

Après avoir configuré Frida ou Objection pour désactiver le SSL-pinning, l’analyste lance l’application et intercepte le trafic réseau via Burp Suite ou mitmproxy. Les données de trafic révèlent le schéma API : quels points de terminaison, quels paramètres et dans quel format. Si possible, l’analyste modifie les requêtes et vérifie la réponse du serveur aux données incorrectes ou malveillantes. L’absence de validation côté serveur est une vulnérabilité directe découverte à cette étape.

Étape 4 : Enregistrement dans data.json

Les résultats de l’analyse sont enregistrés dans un format structuré. Pour chaque point vulnérable trouvé, sont indiqués : la classe et la méthode, la description de la vulnérabilité, le vecteur d’exploitation et la recommandation de correction. Cet ensemble de données est transmis à l’équipe de développement ou utilisé pour rédiger un rapport de test d’intrusion. Dans les environnements automatisés (MobSF), le rapport est généré automatiquement sur la base des résultats de l’analyse statique et dynamique.

Spécificités du reverse engineering des applications iOS

Le reverse engineering des applications iOS est plus difficile que celui d’Android en raison de l’architecture de sécurité plus stricte d’Apple et de l’absence d’accès direct au système de fichiers sur les appareils standards. Un jailbreak est nécessaire pour l’analyse iOS.

Analyse statique Mach-O

Une archive IPA contient un binaire Mach-O — le format universel de fichiers exécutables d’Apple. Pour la décompilation, on utilise Hopper Disassembler ou IDA Pro. Contrairement à Android DEX, qui se décompile en Java avec une perte minimale, Mach-O contient du code ARM64 natif qui est reconstruit en pseudo-code C avec une précision moindre. Hopper atteint 60 – 70 % de reconstruction ; le reste doit être analysé au niveau assembleur.

Analyse dynamique avec Frida pour iOS

Frida sur iOS nécessite un jailbreak et l’installation de frida-server. Après la connexion, Frida intercepte les méthodes Objective-C via le routage de messages API. Pour les applications iOS, un scénario typique comprend : l’interception de NSURLSession.dataTaskWithRequest pour journaliser les requêtes HTTP, l’interception de NSKeyedUnarchiver pour analyser les données sérialisées et le traçage des requêtes CoreData via frida-trace. Frida est devenue disponible pour iOS 15 – 17 avec la sortie du jailbreak Dopamine.

Modification d’IPA

Le reverse engineering peut impliquer la modification de l’IPA suivie du reconditionnement et de l’installation sur l’appareil. Les outils incluent : ipatool pour décompresser, MachOView pour visualiser les sections et optool pour l’injection de code. Après modification, l’IPA est signée via ldid ou fastlane sigh pour l’installation sur un appareil jailbreaké. Pour iOS 16+, la signature de code est vérifiée au niveau du Secure Enclave, et une IPA modifiée ne s’exécutera pas sur un appareil non jailbreaké.

// Frida : interception de requêtes HTTP dans une application iOS
if (ObjC.available) {
    let NSURLSession = ObjC.classes.NSURLSession;
    let dataTaskWithRequest = ObjC.protocol("NSURLSessionDelegate")
        .method("- URLSession:dataTask:didReceiveData:");
    Interceptor.attach(dataTaskWithRequest.implementation, {
        onEnter(args) {
            let data = ObjC.Object(args[3]);
            console("[HTTP Response]", data.toString());
        }
    });
}

Méthodes de protection contre le reverse engineering

La protection contre le reverse engineering suit le principe de la sécurité en couches : aucune méthode unique n’offre une protection à 100 %, mais une combinaison rend le reverse engineering économiquement non viable.

Obfuscation de code

Le niveau de base est ProGuard pour Android, qui remplace les noms de classes et de méthodes par des noms d’un seul caractère. Pour une protection renforcée, DexGuard ajoute l’induction de surcharge (plusieurs méthodes avec des signatures différentes et le même nom) et le chiffrement de chaînes AES-256. L’obfuscation augmente le temps d’analyse du code de 5 minutes à 5 – 20 heures selon le niveau. DexGuard obfusque en outre le flux de contrôle, rendant le code illisible pour jadx.

Chiffrement des constantes

Toutes les constantes de chaîne — URL, clés, tokens, requêtes SQL — sont chiffrées à la compilation et déchiffrées à l’exécution. Cela protège contre l’analyse statique des chaînes dans les fichiers DEX. Un attaquant exécutant strings sur app.apk ne verra aucun point de terminaison API. Même après décompilation, toutes les chaînes apparaissent comme des données binaires. Chaque chaîne peut utiliser une clé distincte, ce qui complique la désécurisation.

RASP et contrôles d’intégrité

Un agent RASP à l’intérieur de l’application détecte Frida et le débogage à l’exécution. Les contrôles d’intégrité via le hachage SHA-256 de l’APK empêchent l’exécution d’une version modifiée de l’application. Si le hachage APK ne correspond pas au hachage de référence (stocké dans la couche native), l’application se termine. Cela bloque les attaques basées sur la modification de l’APK, y compris le reconditionnement.

Protection côté serveur

La logique métier critique doit être exécutée sur le serveur, pas sur le client. Même si un attaquant décompile entièrement l’application, le code serveur reste inaccessible. La validation côté serveur de toutes les requêtes et paramètres empêche l’exploitation des vulnérabilités découvertes lors du reverse engineering. L’attestation serveur via Play Integrity API ou App Attest confirme que la requête provient d’une application authentique et non modifiée.