Pentest d'Applications Mobile Android: Frida, MobSF et Lab Genymotion

Un APK est un fichier zip deguise, et c'est precisement ce qui rend le pentest mobile Android aussi amusant que chirurgical. Chez Basilisk OffSec, nous montons des labs ou nous ne testons que des binaires que nous possedons ou pour lesquels nous avons une autorisation ecrite, car retro-ingenierer une app tierce sans consentement reste un delit federal dans presque toutes les juridictions. Ce guide parcourt le workflow complet: perimetre et droit, un lab reproductible, analyse statique, interception du trafic, attaque du backend, hooks sur mesure, stockage local, defenses runtime et un rapport propre - dans l'ordre ou se deroule une vraie mission.

D'abord: perimetre, contrat, modele de menace#

Avant le moindre hook Frida, on definit perimetre, contrat et modele de menace, dans l'esprit de Threat Modeling STRIDE en Sprints : Exemple Complet sur un Microservice. Fixez par ecrit: quels package names sont dans le perimetre, si le backend peut etre teste, quelles classes de donnees sont interdites, et qui est le contact d'urgence sur un vrai finding. Sans ca, ce n'est pas de la recherche, c'est une collection de convocations judiciaires. Actez aussi que les findings ne circulent que par canaux chiffres.

La stack de base pour 2026#

La stack est simple: Genymotion Personal pour l'emulation x86_64 avec Google Apps en option, MobSF en Docker pour l'analyse statique et dynamique automatisee, Frida 16.x avec frida-tools sur l'hote, objection pour accelerer les workflows et jadx-gui pour lire le smali decompile. Genymotion bat l'AVD en vitesse d'IO et expose ADB sur le port 5555 par defaut. Lancez une image Android 13 rootee, deployez Magisk via setup-frida et poussez frida-server-arm64 dans /data/local/tmp en 755. En moins de quinze minutes vous avez un environnement reproductible, isole de votre reseau de prod, dans la philosophie de Analyse de Malware en Lab Isole: Setup Securise avec FlareVM et REMnux.

Analyse statique avec MobSF#

MobSF est votre premier pivot. Lancez-le avec docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest, glissez l'APK dans l'interface et il extrait AndroidManifest, permissions dangereuses, secrets en dur, controles Janus, WebView avec setJavaScriptEnabled active et meme les domaines exposes dans network_security_config. Le scan statique remonte regulierement des tokens AWS oublies, des cles Firebase aux regles publiques et des endpoints de staging que personne ne devait voir. Servez-vous de cette cartographie pour guider vos hypotheses dynamiques, sans prendre le score numerique de MobSF pour parole d'evangile. Comme tout SAST il fait du bruit, comme on l'aborde dans AppSec Shift-Left: SAST, SCA et Secrets Scanning sans Bloquer l Equipe.

Decompiler et lire le smali#

Ouvrez l'APK dans jadx-gui et lisez le Java decompile en gardant la couche smali sous la main pour les details que le decompilateur avale. Chassez les classiques: Log.d avec des tokens, endpoints en dur, WebView.addJavascriptInterface, activities et receivers exportes dans le manifest, et constantes string pour les cles crypto. Les composants exportes avec android:exported="true" sans permission sont un point d'entree direct pour une app malveillante sur le meme appareil. Marquez chaque composant de ce type comme candidat de test dynamique pour l'etape suivante.

Contourner le SSL pinning avec Frida#

Surface cartographiee, ouvrez Frida. Exemple classique: contourner le SSL pinning pour inspecter le trafic TLS dans Burp ou mitmproxy. Chargez le script avec frida -U -f com.societe.app -l ssl-bypass.js --no-pause; le hook reecrit checkServerTrusted dans TrustManagerImpl et neutralise okhttp3 CertificatePinner. Sans pinning, vous devenez proxy man-in-the-middle dans l'emulateur, capturez des JSON authentifies et testez l'API back comme un pentest web classique, avec Burp configure comme dans Pentest Web depuis Zero: Construire un Lab Sur avec DVWA, Juice Shop et Burp Suite. Rappel: ce bypass n'est legitime que sur une app que vous avez le droit d'auditer.

Attaquer l'API backend#

Trafic propre, attaquez l'API. Les vecteurs classiques reviennent: mass assignment, IDOR sur /v2/users/{id}, JWT avec algorithme none, GraphQL avec introspection ouverte. Appliquez la methodologie de Pentest APIs REST et GraphQL : Checklist Technique pour Bug Bounty Legal et, pour l'injection backend, validez les candidats avec des payloads parametres comme dans SQL Injection en Pratique: Exploiter, Detecter et Mitiger dans un Lab Controle. Rappelez-vous que l'app mobile n'est qu'un client: la vraie faille d'autorisation siege presque toujours cote serveur, la ou l'UI de l'app a ete traitee a tort comme une frontiere de securite.

WebView et addJavascriptInterface#

Autre cible sous-estimee: le WebView interne. Si l'app charge du HTML distant sans allowlist, vous pouvez enchainer un XSS dans un contexte privilegie via addJavascriptInterface qui expose des methodes Java au JS - sur d'anciens API levels jusqu'a l'execution de code distante via reflection. Verifiez si setAllowFileAccess, setAllowUniversalAccessFromFileURLs et loadUrl se combinent avec des donnees controlees par l'utilisateur. On detaille la mecanique de payload dans XSS Moderne: DOM, Stored et Reflected avec Exemples Reels en Environnement de Test. Un WebView qui resout des URLs intent:// sans filtre est aussi candidat au deep-link hijacking.

Hooks sur mesure: la ou le pentester brille#

Trois scripts Frida en or: dump des cles AES passees a Cipher.init en capturant le premier argument de SecretKeySpec; instrumentation de SharedPreferences.Editor.putString pour detecter les tokens stockes en clair; et hook sur java.io.File pour journaliser tout ce qui est ecrit sous /data/data/com.societe.app pendant le login. Combinez avec adb shell run-as com.societe.app pour extraire les bases sqlite et les ouvrir dans sqlitebrowser. Lors d'un audit recent, nous avons trouve un refresh_token persiste hors keystore, defaut qui s'est transforme en account takeover en une apres-midi.

Stockage local et keystore#

Les donnees sensibles vont dans l'Android Keystore avec des cles adossees au materiel, jamais dans SharedPreferences en clair ni dans un SQLite non chiffre. Verifiez systematiquement databases/, shared_prefs/, le cache et les chemins de stockage externe pour tokens, PII et materiel crypto. Un finding courant est une couche crypto maison dont la cle est juste a cote des donnees - de fait du texte clair. Recommandez EncryptedSharedPreferences ou Jetpack Security, avec des cles liees a StrongBox ou au TEE et non extractibles sous root.

Passer en revue les defenses runtime#

Ne concluez pas sans passer en revue les defenses runtime. Verifiez la detection root via RootBeer, la detection Frida par scan des ports locaux (27042), la detection d'emulateur via Build.FINGERPRINT et l'integrite via Play Integrity API. Documentez precisement comment chaque controle a ete contourne et proposez une defense en profondeur, pas des solutions miracles - un unique controle root qu'un one-liner objection tue n'est pas une protection. Cote serveur, durcissez SSH sur le bastion API selon Durcissement SSH 2026 : Algorithmes, Certificats et Bastion Hosts.

Rapport et nettoyage#

Le rapport est le produit: par finding, CVSS, etapes de reproduction, la classe ou l'endpoint touche, et une remediation concrete. Nettoyez artefacts, captures et PDF avant d'envoyer le rapport, comme dans Hygiene des Metadonnees : Nettoyer EXIF, PDF et Office avant Publication, pour qu'aucun chemin interne ni nom de client ne fuite. A la fin, supprimez les donnees d'app extraites et revenez au snapshot. Un bon rapport priorise par risque reel, pas par le nombre de lignes du output de l'outil.

objection pour iterer vite#

La ou un script Frida sur mesure est trop couteux, objection accelere le cycle. Apres objection -g com.societe.app explore, les commandes android sslpinning disable, android keystore list, android hooking list classes et memory search --string "token" touchent les cibles les plus courantes en quelques minutes. android hooking watch class_method ... --dump-args --dump-return montre en direct les arguments et retours d'une methode sans ecrire une ligne de JavaScript. Objection est un wrapper autour de Frida, pas un remplacant : pour tout ce qui n'est pas trivial vous ecrivez toujours vos propres hooks, mais pour la recon et le bypass de pinning le one-liner est imbattable de vitesse. Rappelez-vous que chaque action objection tourne dans la memoire du processus de l'app et disparait au redemarrage.

Deep links et hijacking de redirect OAuth#

Verifiez les intent-filter du manifest : un handler de deep link avec android:autoVerify="false" ou un redirect de custom scheme (monapp://callback) peut etre intercepte par une app malveillante sur le meme appareil. Le hit classique est un flux OAuth qui renvoie l'authorization code vers un custom scheme non verifie : une seconde app enregistre le meme scheme et capture le code. La contre-mesure : des App Links verifies (HTTPS avec assetlinks.json) plus PKCE, pour qu'un code intercepte soit sans valeur sans le verifier. Testez chaque endpoint deep link exporte avec adb shell am start -a android.intent.action.VIEW -d "..." et observez quelle activity demarre sans authentification.

FAQ: Emulateur ou appareil physique?#

Pour l'essentiel du travail, un emulateur Genymotion roote suffit, plus rapide et plus jetable. Les appareils physiques sont necessaires quand l'app utilise une attestation liee au materiel, SafetyNet/Play Integrity avec verdict strict, NFC, peripheriques Bluetooth ou capteurs specifiques que l'emulateur ne reproduit pas proprement. Un melange pragmatique: emulateur pour l'iteration rapide, un telephone de test dedie pour les cas que l'emulateur bloque.

FAQ: Comment contourner Play Integrity sans root physique?#

Franchement: pas toujours, et c'est voulu. Play Integrity avec MEETS_STRONG_INTEGRITY est atteste par le materiel et vise a rejeter precisement les environnements modifies que vous utilisez. Dans un test autorise vous documentez que le controle tient, plutot que de le casser a tout prix - un controle d'integrite qui passe est un resultat positif. La ou l'app ne verifie que le verdict faible ou evalue le resultat cote client, c'est exactement la faille que vous rapportez.

Conclusion et takeaway pratique#

Faites tourner Genymotion, MobSF et Frida dans une VM dediee, avec un snapshot propre par mission, jamais reliee a votre identite personnelle. Parcourez le workflow dans un ordre fixe: perimetre, statique, decompilation, trafic, backend, hooks sur mesure, stockage, defenses runtime, rapport. La plupart des findings serieux ne vivent pas dans une crypto exotique mais dans une autorisation banale cote serveur et dans des tokens persistes en clair - c'est la que vous cherchez d'abord, et c'est la qu'est la valeur pour le client.