Présentation d'Ostorlab Mobile Shielding Scan

Le shielding mobile se contourne facilement. Un attaquant déterminé passera de toute façon, donc le tester ne change rien.

Ce point de vue exige du shielding une promesse qu'il n'a jamais eu vocation à tenir.

Le shielding n'est pas censé rendre une application impossible à rétro-concevoir. Il est censé rendre nettement plus difficiles la falsification, l'instrumentation, l'interception du trafic et l'analyse du code.

La vraie question est de savoir quelle résistance il crée, en particulier à l'ère de la rétro-ingénierie et de l'instrumentation assistées par l'IA.

La détection du root peut être présente mais échouer face aux techniques de dissimulation modernes. Le certificate pinning peut protéger un chemin réseau tout en en laissant un autre exposé. Un contrôle d'intégrité peut détecter une modification mais laisser l'application continuer à s'exécuter.

Savoir qu'une protection existe est utile. Savoir ce qui se passe quand quelqu'un l'attaque est ce qui donne confiance aux équipes. C'est aussi savoir si la solution de shielding pour laquelle vous payez une somme rondelette en vaut la peine.

C'est ce que le nouveau Mobile Shielding Scan d'Ostorlab est conçu pour montrer.

Le scan attaque ce qu'il trouve

Mobile Shielding Scan évalue comment les applications Android et iOS se défendent contre la rétro-ingénierie et la falsification.

Il commence par analyser l'application pour identifier la détection du root et du jailbreak, les contrôles d'anti-falsification et d'intégrité, l'anti-débogage, l'anti-instrumentation, le certificate pinning et l'obfuscation du code ou des chaînes.

Il exécute ensuite l'application sur de vrais appareils et parcourt ses workflows pour atteindre les points où ces protections s'activent. Certains contrôles ne s'exécutent qu'après l'authentification, pendant un paiement ou à l'ouverture d'une fonctionnalité sensible. Trouver le code sous-jacent ne suffit pas si la protection ne se déclenche jamais lors d'un usage réel.

Une fois un contrôle atteint, le scan tente de le mettre en échec.

Il peut reconditionner et re-signer l'application, attacher une instrumentation à l'exécution avec des outils comme Frida, dissimuler les traces d'un appareil rooté, intercepter le trafic réseau, modifier le code de l'application ou de ses bibliothèques et manipuler les contrôles d'intégrité.

Des agents IA conduisent l'investigation. Ils observent l'interface, lisent les journaux et interprètent la réaction de l'application. Un plantage, une boîte de dialogue d'avertissement, une requête bloquée, une sortie silencieuse ou un workflow qui cesse discrètement de fonctionner peuvent tous révéler si une défense a réagi.

Les agents utilisent ces éléments pour choisir la technique suivante et réessayer. Le processus suit la même boucle de base qu'une évaluation de rétro-ingénierie manuelle : observer, attaquer, interpréter et s'adapter.

Le scan peut s'exécuter sur un build téléversé ou directement à partir d'une fiche de store.

Trois protections, modifiées directement sur l'appareil

L'exemple suivant est tiré d'un scan réel, dont les détails identifiants ont été supprimés.

Une application bancaire mettait en œuvre trois protections côté client dans sa bibliothèque native, libsecurity.so, et dans son code DEX :

• Un contrôle JNI_OnLoad analysait /proc/self/maps à la recherche d'artefacts de Frida et cherchait des binaires su et des clés de test. S'il trouvait quelque chose de suspect, il appelait _exit(1).
• Un contrôle d'intégrité natif calculait une somme de contrôle CRC32 sur les octets de la bibliothèque elle-même et la comparait à une valeur stockée à côté d'une chaîne marqueur.
• Une méthode Java, HookDetector.isHooked(), inspectait les cartes mémoire du processus, les noms de threads et les ports par défaut de Frida, 27042 et 27043.

Sur le papier, l'application disposait d'une anti-instrumentation, d'une détection du root et d'une protection d'intégrité. La faiblesse était que chaque contrôle reposait sur des fichiers et des décisions stockés entièrement sur l'appareil.

L'application utilisait extractNativeLibs=false, ce qui laissait la bibliothèque native non compressée dans l'APK installé et la chargeait directement à partir de là. Son code DEX s'exécutait à partir du fichier VDEX de l'appareil. Sur un appareil rooté, les deux pouvaient être modifiés sur place.

Le scan a modifié la branche de terminaison dans JNI_OnLoad pour qu'elle suive le chemin de retour normal au lieu d'appeler _exit(1). Comme la modification de la bibliothèque changeait sa somme de contrôle, le scan a recalculé la valeur CRC32 et écrit le nouveau résultat dans le champ stocké. Le contrôle d'intégrité a continué à s'exécuter, mais il considérait désormais la bibliothèque modifiée comme valide.

Il a ensuite modifié HookDetector.isHooked() dans le fichier VDEX pour qu'elle renvoie toujours false. Après la modification, le scan a réparé les sommes de contrôle Adler-32 et SHA-1 du DEX nécessaires au bon chargement du code.

Aucune de ces modifications n'a nécessité de reconstruire, de reconditionner ou de re-signer l'application.

Le contrôle de signature de l'application n'a pas empêché l'attaque, car Android avait mis en cache le certificat de signature d'origine lors de l'installation et n'a pas revalidé les fichiers modifiés sur le disque.

Une fois les trois modifications appliquées, et alors qu'un artefact de Frida restait visible dans /proc/self/maps, l'application a maintenu une session authentifiée pendant plus d'une minute, est passée d'un écran à l'autre et a franchi sans réagir des contrôles d'intégrité répétés en arrière-plan.

Les trois protections étaient présentes et actives dans le build d'origine. Mais comme chacune reposait sur du code côté client sans confirmation indépendante côté serveur, les trois pouvaient être modifiées sur l'appareil qu'elles étaient censées protéger.

Une checklist aurait indiqué que l'anti-instrumentation, la détection du root et la protection d'intégrité étaient présentes. Les tests actifs ont montré précisément comment chacune pouvait être neutralisée.

Un verdict étayé par des preuves

Chaque protection est marquée Secure lorsqu'elle réagit et tient, ou Hardening lorsqu'elle est absente, inactive ou contournée. La détection seule ne suffit pas si l'application continue de fonctionner normalement.

Les défenses en échec incluent des étapes de contournement reproductibles. Les défenses réussies sont confirmées sous attaque. Les résultats sont validés avant d'être rapportés et peuvent être contestés ou relancés avec de nouvelles consignes.

Chaque version peut changer le résultat

Un changement de build ou une mise à niveau de SDK peut affaiblir le shielding sans casser l'application ni déclencher le pipeline de livraison.

Répéter le scan montre ce qui tient dans l'application et le build livrés actuellement.

Sachez ce que votre shielding peut supporter

Mobile Shielding Scan montre quelles défenses ont tenu, lesquelles ont échoué, et comment le résultat a été prouvé.

Le shielding n'a pas besoin de rendre une application impossible à attaquer. Il doit créer de la résistance, et prouver qu'il le fait.

Testez ce que votre shielding mobile peut supporter.