Les meilleurs outils pour tester le contournement du shielding des applications mobiles
Comparez Apktool, JADX, Ghidra, Frida, Objection et LLDB pour des tests manuels, avec l’évaluation automatisée du shielding et du RASP mobiles Android et iOS d’Ostorlab.
Résumé exécutif (TL;DR)
Tester si le shielding d’une application mobile peut être contourné demande des outils différents selon les étapes. Apktool décode, modifie et reconstruit des paquets Android pour les tests de repackaging ; JADX et Ghidra aident à localiser la logique de protection ; Frida, Objection et LLDB mettent à l’épreuve les contrôles de shielding et de RASP à l’exécution ; et Ostorlab automatise l’évaluation sur Android et iOS.
Le shielding peut détecter une attaque et pourtant ne pas protéger l’application. Dans l’évaluation de cinq applications bancaires par Ostorlab, une application a détecté qu’elle s’exécutait sur un appareil rooté, mais a quand même continué jusqu’à son écran de connexion. La protection était bien là. C’est la réaction qui posait problème.
Les tests doivent donc aller au-delà de la simple confirmation que la détection du root, l’anti-débogage ou l’épinglage de certificat existent. Les équipes doivent observer comment l’application réagit lorsque ces protections sont mises à l’épreuve, et si cette réaction peut être contournée.
Ce guide explique ce que chaque outil permet de vérifier, l’expertise qu’il exige et où s’arrêtent ses capacités. Il s’adresse aux testeurs de sécurité mobile et aux équipes AppSec qui doivent choisir entre un workflow manuel et une évaluation automatisée.
À propos de ce guide : ce guide est publié par Ostorlab, qui figure dans la comparaison. Il s’appuie sur la documentation officielle, des dépôts open source, les recommandations de l’OWASP et des recherches techniques publiées.
Qu’est-ce que le shielding des applications mobiles et le test du RASP ?
Le shielding des applications mobiles est un ensemble de protections ajoutées à une application Android ou iOS pour rendre l’analyse, la modification et l’interférence à l’exécution plus difficiles. Il peut inclure l’obfuscation du code, l’anti-falsification, les contrôles d’intégrité, l’anti-débogage, l’anti-instrumentation, la détection du root ou du jailbreak et l’épinglage de certificat.
Le Runtime Application Self-Protection (RASP) désigne plus précisément les protections qui surveillent l’application pendant son exécution. Lorsque le RASP détecte une condition suspecte, il peut afficher un avertissement, restreindre une action ou fermer l’application. Le RASP n’est donc qu’une composante de la couche de shielding plus large des applications mobiles.
Le test de contournement du shielding et du RASP vérifie si ces contrôles détectent les conditions d’attaque visées et si leur réaction peut être neutralisée ou évitée. Une protection n’est pas prouvée efficace du simple fait qu’elle est présente ou qu’elle produit une alerte. Le test doit aussi établir si l’application autorise encore le comportement que la protection devait empêcher.
Les outils de test du shielding des applications mobiles en un coup d’œil
Les outils ci-dessous sont gratuits et open source, mais aucun ne couvre à lui seul l’évaluation complète. Chacun prend en charge une partie précise du processus, de la modification de l’application et de la localisation de la logique de protection jusqu’à la mise à l’épreuve des contrôles à l’exécution et à la vérification du résultat.
| Outil | Quand l’utiliser | Périmètre mobile | Travail requis | Contrainte principale |
|---|---|---|---|---|
| Apktool | Préparer des APK modifiés pour les tests de repackaging, de signature et d’anti-falsification. | APK Android | Inspecter le manifeste, les ressources ou le Smali ; effectuer une modification contrôlée ; reconstruire et re-signer l’APK. | Android uniquement ; les échecs de reconstruction ou de signature doivent être distingués de la réaction de shielding de l’application. |
| JADX | Trouver les contrôles de protection et remonter à leurs appelants dans le code DEX Android. | Bytecode DEX Android | Lire le code décompilé et identifier les décisions à tester à l’exécution. | La décompilation peut être incomplète ; le code natif nécessite un autre outil d’analyse. |
| Ghidra | Suivre la logique de protection native et identifier les emplacements de hook ou de patch. | Bibliothèques natives Android ; binaires iOS | Interpréter le désassemblage et vérifier les fonctions décompilées. | Le code packé ou chiffré peut nécessiter une extraction à l’exécution avant l’analyse. |
| Frida | Écrire des hooks personnalisés pour observer ou modifier à l’exécution les contrôles de shielding et de RASP. | Android et iOS | Obtenir l’accès au processus, identifier les fonctions et adapter les scripts. | L’anti-instrumentation peut bloquer Frida avant l’exécution d’un script. |
| Objection | Essayer des routines de contournement existantes pour les contrôles courants de root, de jailbreak et d’épinglage de certificat. | Android et iOS | Obtenir l’accès Frida, sélectionner les routines et vérifier la réaction. | Dépend de Frida ; les protections personnalisées peuvent nécessiter des hooks sur mesure. |
| LLDB | Mettre en pause l’exécution native pour suivre un contrôle ou inspecter un état qui évolue. | Code natif Android et iOS | Obtenir l’accès au débogueur et interpréter l’exécution, la mémoire et les registres. | Les permissions du système et les restrictions de signature peuvent empêcher l’attachement indépendamment du shielding. |
Comment les outils open source s’intègrent dans un test de contournement du shielding
Le test open source du shielding combine plusieurs outils plutôt que de s’appuyer sur un seul scanner. Apktool permet d’inspecter, de modifier et de reconstruire des paquets Android. JADX et Ghidra aident les testeurs à localiser et à comprendre la logique de protection. Frida, Objection et LLDB sont utilisés à l’exécution pour mettre ces protections à l’épreuve et observer le résultat.
Le processus n’est pas toujours linéaire. Un test à l’exécution peut révéler un élément qui renvoie le testeur au code pour une analyse plus poussée.
Apktool : reconstruire des applications Android pour les tests de falsification
Apktool décode les paquets d’applications Android en une structure de type projet contenant le manifeste, les ressources et le code Smali. Il peut ensuite reconstruire le paquet une fois les modifications effectuées.
Rôle dans l’évaluation
Apktool est utile lorsqu’une évaluation de shielding nécessite de modifier et de repackager un APK. Un testeur peut effectuer une modification contrôlée du manifeste, des ressources ou du code Smali, reconstruire le paquet, puis vérifier si les protections d’intégrité, de signature ou d’anti-falsification détectent l’application modifiée.
Ce rôle diffère de celui de JADX. JADX présente le code DEX sous forme de code lisible proche de Java pour l’analyse, alors qu’Apktool préserve une structure de paquet qui peut être modifiée et reconstruite. L’OWASP documente Apktool comme un moyen de décoder le manifeste binaire, d’extraire les ressources, de désassembler les fichiers DEX en Smali et de repackager le résultat. (Voir le guide Apktool de l’OWASP)
Ce dont le testeur a besoin
Le testeur doit décider quoi modifier, éditer le fichier de manifeste, de ressource ou Smali concerné, reconstruire l’APK et le signer avant l’installation. Le résultat doit consigner l’endroit où un éventuel échec s’est produit : pendant le décodage, la reconstruction, la signature, l’installation ou après le lancement de l’application.
Limites
Apktool est limité aux paquets Android et ne teste pas à lui seul les protections à l’exécution. Il produit un APK non signé ; la signature est donc une étape distincte. Une application reconstruite qui ne s’installe pas ou ne se lance pas ne prouve pas automatiquement que le shielding a détecté la modification ; la cause peut aussi être un build invalide, un problème de signature ou une incompatibilité de paquet. Apktool indique également que certains APK créés avec des outils de build OEM modifiés ne peuvent pas être décodés ni reconstruits. FAQ Apktool
Lorsque l’objectif est de suivre la logique de protection Android de plus haut niveau avant de décider quoi modifier, JADX offre une vue plus lisible.
JADX : analyser la logique de protection Android
JADX transforme le bytecode DEX Android en code lisible proche de Java. Les testeurs peuvent rechercher dans un APK, passer d’une méthode à l’autre et suivre les références sans exécuter l’application.
Rôle dans l’évaluation
JADX aide à localiser les contrôles de root, la logique d’anti-débogage, les contrôles d’intégrité et le code qui décide de la réaction de l’application.
La réaction peut être gérée ailleurs que dans le contrôle d’origine. Une méthode peut détecter le root, tandis qu’une autre décide d’afficher un avertissement, de fermer l’application ou de restreindre une fonctionnalité. Suivre ces références aide le testeur à identifier le point de décision à examiner à l’exécution avec Frida ou un débogueur.
Ce dont le testeur a besoin
Utiliser JADX demande de connaître le développement Android et la rétro-ingénierie, surtout lorsque les noms de classes et le flux de contrôle ont été obfusqués.
La sortie décompilée est une interprétation du bytecode, et non le code source d’origine de l’application. JADX peut renommer ou intégrer en ligne des classes et des méthodes ; les identifiants affichés dans l’interface peuvent donc ne pas correspondre à ceux rencontrés à l’exécution. Une sortie douteuse doit être vérifiée par rapport au code Smali sous-jacent ou au graphe de flux de contrôle. Conseils de dépannage de JADX
Limites
JADX est un outil d’analyse Android, pas une solution complète de contournement. Son débogueur Smali nécessite une application débogable ou un appareil ou émulateur rooté. La logique de protection contenue dans des bibliothèques natives, chiffrée jusqu’au lancement ou générée à l’exécution nécessite elle aussi d’autres outils.
Lorsque la logique pertinente passe du bytecode Android à une bibliothèque native, Ghidra peut poursuivre l’investigation.
Ghidra : analyser le code de protection natif
Ghidra analyse le code natif compilé, notamment les bibliothèques Android .so ainsi que les exécutables et frameworks iOS.
Rôle dans l’évaluation
Le désassembleur, le décompilateur, la recherche de chaînes et les graphes de fonctions de Ghidra aident les testeurs à reconstituer le fonctionnement du code de protection natif. Sur Android, il peut poursuivre l’analyse lorsque JADX atteint un appel vers une bibliothèque native sans pouvoir montrer ce qui s’y passe.
Même lorsque les noms de fonctions ont été supprimés, les chaînes, les constantes et les références entre fonctions peuvent révéler un contrôle de protection probable, sa branche de décision et la réaction de l’application qui en résulte. Le guide Ghidra de l’OWASP explique comment ces vues fonctionnent ensemble lors de la revue d’un binaire.
Ce dont le testeur a besoin
Ghidra demande de meilleures compétences de rétro-ingénierie native que JADX. Le testeur peut avoir à corriger des signatures de fonctions, comparer la sortie décompilée avec l’assembleur et comprendre comment les valeurs circulent entre les registres et la mémoire.
L’objectif habituel est d’identifier un contrôle ou un point de décision probable pour les tests à l’exécution. Le trouver dans Ghidra ne prouve pas qu’il peut être contourné.
Limites
Le code packé ou chiffré peut rester caché jusqu’à l’exécution de l’application. Le débogueur de Ghidra peut relier un processus en cours d’exécution au binaire importé et inspecter la mémoire à l’exécution, mais le testeur doit d’abord obtenir l’accès au débogage et localiser le code pertinent.
Tout contournement présumé doit encore être reproduit pendant que l’application s’exécute. Frida est couramment utilisé pour cette partie de l’évaluation.
Frida : instrumentation personnalisée à l’exécution
Frida injecte du JavaScript dans des processus Android et iOS. Il permet aux testeurs d’intercepter les appels de fonctions, d’inspecter leurs entrées et sorties et de modifier le comportement de l’application pendant son exécution.
Rôle dans l’évaluation
Frida sert à mettre à l’épreuve les contrôles de protection et le code qui y réagit. Il permet de tester si le comportement d’une protection peut être modifié même lorsque la détection initiale fonctionne.
Dans l’exemple OWASP Android UnCrackable L1, l’application détecte le root et affiche un avertissement avant de se fermer. Un hook Frida modifie la fonction chargée de fermer l’application. Le contrôle du root s’exécute toujours, mais l’application n’applique plus la réaction prévue.
Ce dont le testeur a besoin
Le testeur doit identifier les fonctions pertinentes, écrire ou adapter des hooks JavaScript et vérifier que le comportement visé a réellement changé. Les protections personnalisées peuvent nécessiter une rétro-ingénierie supplémentaire pour comprendre comment leurs contrôles et leurs réactions s’articulent.
L’environnement de test compte aussi. Les tests Android utilisent couramment un appareil rooté, bien que Frida Gadget puisse être intégré dans une application repackagée. Sur iOS, un appareil jailbreaké offre un accès plus large, tandis que les tests sur un appareil non jailbreaké se limitent aux applications débogables.
Limites
Le shielding ou le RASP peut détecter ou bloquer Frida avant le début du test prévu. Dans l’évaluation de cinq applications bancaires par Ostorlab, une application s’est terminée pendant l’injection, avant que le script Frida produise son premier message de log. Dans ce cas, établir une session d’instrumentation fonctionnelle devient une partie distincte de l’investigation.
Pour les techniques de contournement courantes, Objection offre un point de départ plus rapide en regroupant des routines Frida existantes dans des commandes prêtes à l’emploi.
Objection : des fonctions de contournement prêtes à l’emploi
Objection s’exécute au-dessus de Frida et regroupe des techniques courantes de test mobile dans une console interactive.
Rôle dans l’évaluation
Objection inclut des commandes pour tenter de contourner les contrôles connus de root et de jailbreak, désactiver les implémentations courantes d’épinglage de certificat, inspecter les classes chargées et surveiller les appels de méthodes. Les testeurs peuvent ainsi essayer des techniques éprouvées avant d’écrire un script Frida personnalisé.
Les contrôles qui s’exécutent au démarrage peuvent devoir être atteints avant le lancement complet de l’application. Objection prend en charge l’instrumentation précoce, qui permet de charger des commandes ou des scripts Frida personnalisés à la reprise de l’application.
Ce dont le testeur a besoin
Le testeur doit confirmer ce que chaque commande a modifié et si la protection évaluée a réellement été atteinte. Une commande qui se termine avec succès montre seulement que la routine s’est exécutée. Elle n’établit pas que la protection a été contournée.
Objection peut aussi patcher une application Android avec Frida Gadget. Comme cela reconstruit et re-signe l’APK, le testeur doit déterminer si un éventuel échec provient de la tentative de contournement ou d’un contrôle d’intégrité ou de signature.
Limites
Objection fonctionne mieux lorsque ses routines existantes correspondent à la protection utilisée par l’application. Il devient moins utile face à une logique de protection personnalisée ou lorsque l’application bloque la session Frida sous-jacente.
Dans ces cas, le testeur a généralement besoin d’une analyse de code et d’un script Frida sur mesure. Si l’investigation exige de suivre l’exécution native instruction par instruction, LLDB offre une vue de plus bas niveau.
LLDB : examiner les contrôles de protection avec un débogueur
LLDB permet aux testeurs de mettre en pause le code natif, de le parcourir instruction par instruction et d’inspecter les registres, la mémoire et les valeurs de retour. C’est le débogueur par défaut dans Xcode, également utilisé pour le débogage natif Android.
Rôle dans l’évaluation
Un testeur peut placer un point d’arrêt sur un contrôle de protection suspecté, observer la valeur qu’il renvoie et suivre la réaction de l’application. LLDB peut aussi modifier l’état du processus lors d’un test contrôlé.
Ses watchpoints sont utiles lorsque le testeur sait où est stocké le résultat d’une protection mais ne sait pas encore quelle fonction le met à jour.
Ce dont le testeur a besoin
Les builds de production contiennent souvent peu de symboles utiles. Les testeurs peuvent devoir reporter des adresses et d’autres résultats depuis Ghidra, puis tenir compte de la façon dont le binaire est mappé en mémoire. Cela demande de comprendre l’assembleur, les conventions d’appel, les registres et le flux d’exécution natif. Les recommandations de l’OWASP sur le débogage iOS traitent de ces contraintes dans les builds de production.
L’accès à l’appareil détermine aussi ce que LLDB peut atteindre. Sur un appareil Android non rooté, Android Studio ne peut s’attacher qu’à des processus débogables. LLDB traite la couche native plutôt que le code Java ou Kotlin. Sur iOS, une application de production peut exiger un appareil adapté et un build re-signé ou autrement débogable.
Limites
L’échec de l’attachement de LLDB ne signifie pas automatiquement que le shielding a arrêté le débogueur. Les permissions du système d’exploitation, les exigences de signature ou les entitlements de l’application peuvent empêcher l’attachement avant que la protection soit atteinte.
Le testeur doit distinguer ces échecs de configuration des cas où l’application elle-même détecte ou bloque clairement le débogage. Comme pour les autres outils d’exécution, connecter le débogueur avec succès n’est que le début ; la preuve finale doit montrer comment la protection visée s’est comportée pendant le test.
Ostorlab : automatiser le test du shielding des applications mobiles
Le Mobile Shielding Scan d’Ostorlab réunit la découverte des protections, les tentatives de contournement et la vérification dans une seule évaluation pour Android et iOS. Il gère l’environnement de test et utilise des agents IA pour étudier comment l’application réagit lorsque ses protections sont mises à l’épreuve.
Ce qu’Ostorlab automatise
Le workflow d’évaluation comporte quatre étapes :
- Identifier les protections. Le scan examine l’application à la recherche de détection du root et du jailbreak, de contrôles d’intégrité, d’anti-débogage, d’anti-instrumentation, d’épinglage de certificat et d’obfuscation du code ou des chaînes.
- Atteindre les parcours protégés. Il exécute l’application sur de vrais appareils et navigue dans ses écrans pour atteindre les points où les protections s’activent. C’est important lorsqu’un contrôle ne s’exécute qu’après la connexion ou à l’ouverture d’une fonctionnalité sensible.
- Tenter des contournements et suivre la réaction. Selon la protection, les tentatives peuvent faire appel à l’instrumentation à l’exécution, au repackaging, à la re-signature, à la dissimulation des indicateurs de root ou à la modification de la logique de protection. Les agents inspectent l’interface et les logs, puis utilisent les avertissements, les plantages, les requêtes bloquées et les autres réactions pour orienter la suite de l’investigation.
- Consigner ce qui s’est passé. Les résultats distinguent les protections qui ont tenu pendant les attaques tentées de celles qui étaient absentes, inactives ou contournées. Les contournements réussis sont accompagnés de preuves et des étapes pour les reproduire.
Ce que vous fournissez : un APK, un AAB ou un IPA, ou une application sélectionnée via Google Play, l’App Store ou TestFlight. Après avoir choisi le profil Mobile Shielding Scan, vous sélectionnez les Cybermodels d’Ostorlab ou apportez votre propre clé de fournisseur d’IA pris en charge. Les Cybermodels proposent différents niveaux d’effort d’investigation. Vous pouvez aussi fournir des identifiants de test et des instructions de navigation pour que le scan atteigne les écrans authentifiés et les parcours pertinents. Guide de configuration du scan
À quoi ressemblent les résultats
Le tableau de bord des résultats fournit une vue d’ensemble du durcissement, des notes par catégorie et des informations de couverture, ainsi que chaque contrôle vérifié. Pour une équipe AppSec qui étudie un contournement, le détail utile est la preuve qui explique comment une protection donnée s’est comportée.
Un exemple provient de l’évaluation de cinq applications bancaires publiée par Ostorlab. Pour étudier l’épinglage de certificat, le scan a sollicité deux fois le vérificateur de certificat propre à l’application. Les deux exécutions ont utilisé le même certificat, la même instance du vérificateur et les mêmes pins configurés ; les hooks de contournement étaient désactivés pour une exécution et activés pour l’autre.
| Observation | Hooks désactivés | Hooks activés |
|---|---|---|
| Les deux comparaisons de pin | Ont renvoyé false |
Ont renvoyé true |
| Décision du vérificateur de certificat | A rejeté le certificat et levé une exception | A accepté le certificat sans exception |
Ce changement contrôlé démontre un contournement du vérificateur de certificat sollicité dans ce test. La preuve vient de l’appel direct de la logique de vérification : la même entrée, qui était rejetée, a été acceptée lorsque les hooks étaient actifs.
L’équipe dispose ainsi d’une défaillance précise à investiguer et d’une condition concrète à revérifier après un correctif : le vérificateur rejette-t-il encore ce certificat lorsque le même contournement est tenté ?
Limites
Ostorlab est une plateforme commerciale ; elle nécessite donc un accès payant et s’adresse principalement aux équipes sécurité et d’ingénierie qui réalisent des évaluations reproductibles. En contrepartie, elle gère l’environnement de test, les tentatives de contournement et la collecte de preuves que l’équipe doit assembler et maintenir dans un workflow manuel.
Choisir la bonne approche pour tester le contournement du shielding d’une application
La bonne approche dépend de ce que l’équipe doit faire : trouver une protection, la mettre à l’épreuve pendant que l’application s’exécute, ou automatiser l’évaluation dans son ensemble.
- Pour la modification de paquets et l’analyse de code : utilisez Apktool pour décoder, modifier et reconstruire des APK Android, JADX pour examiner le code DEX Android et Ghidra pour étudier les binaires natifs Android ou iOS. Ces outils prennent en charge les tests de repackaging et aident à localiser les contrôles de protection, mais ils ne démontrent pas à eux seuls un contournement à l’exécution.
- Pour les tests à l’exécution : Objection fournit des routines prêtes à l’emploi pour les protections courantes, tandis que Frida donne plus de contrôle aux testeurs grâce à des hooks personnalisés. LLDB est utile lorsque l’investigation exige de mettre en pause l’exécution native et de suivre une décision de protection instruction par instruction. Les résultats de JADX ou de Ghidra orientent souvent les points sur lesquels ces tests à l’exécution doivent se concentrer.
- Pour les tests automatisés : Ostorlab réunit la découverte des protections, les tentatives de contournement et la collecte de preuves dans un seul workflow automatisé. Les outils manuels peuvent toujours être utilisés en complément lorsqu’un spécialiste doit étudier plus en profondeur un résultat particulier. Pour évaluer une application Android ou iOS protégée, découvrez Mobile Shielding Scan.
Foire aux questions
Quels outils permettent de tester si la détection du root, la détection du jailbreak et l’épinglage de certificat résistent aux tentatives de contournement ?
Objection inclut des routines pour les contrôles courants de root, de jailbreak et d’épinglage de certificat. Frida permet de créer des hooks sur mesure lorsque ces routines ne correspondent pas à l’implémentation de l’application. Ostorlab Mobile Shielding Scan automatise les tests sur ces domaines de protection sur Android et iOS. Dans chaque cas, le résultat doit identifier le build, l’état de l’appareil, le parcours atteint et le comportement observé.
Les outils open source peuvent-ils réaliser une évaluation complète du shielding mobile ?
Ils peuvent prendre en charge l’ensemble du workflow manuel lorsque l’équipe dispose des accès et de l’expertise de rétro-ingénierie nécessaires. Un testeur peut utiliser Apktool pour modifier et reconstruire un paquet Android, JADX ou Ghidra pour comprendre une protection, puis Frida, Objection ou LLDB pour la mettre à l’épreuve et vérifier le résultat. Aucun outil open source de cette comparaison n’effectue automatiquement toutes les étapes ; l’équipe doit donc relier les outils et documenter les preuves.
Détecter une fonction de shielding prouve-t-il qu’elle résiste aux tentatives de contournement ?
Non. Trouver du code de détection du root, d’anti-débogage ou d’épinglage de certificat montre qu’une protection est présente. Son efficacité s’établit en mettant le contrôle à l’épreuve, en observant la réaction de l’application et en vérifiant si le comportement restreint reste accessible.
Quelle preuve montre qu’un contournement du shielding a fonctionné ?
La preuve la plus solide relie un changement contrôlé à la décision protégée. Par exemple, le même vérificateur et la même entrée peuvent être sollicités avec un contournement désactivé puis activé, et les deux résultats comparés. Un hook chargé ou une session d’instrumentation en cours ne prouve pas à lui seul que la protection visée a été contournée.