Analyse technique
Shizuku est un outil open source légitime, très prisé des utilisateurs avancés d'Android. Il permet à une application d'obtenir les privilèges d'un technicien sans rooter le téléphone. Le malware RedHook, apparu en 2025, a montré que ces capacités intéressent aussi les attaquants : sa variante analysée en juillet 2026 réutilisait le code de Shizuku pour s'octroyer ces privilèges sans exploiter la moindre faille.
Nos experts ont voulu mesurer précisément ce que cet outil met entre les mains d'une application. Ils ont développé une application de test, exécuté 41 commandes avec et sans Shizuku sur Android 16, puis reproduit quatre scénarios d'abus. Voici ce qu'ils ont observé, et comment repérer Shizuku sur un appareil.
Shizuku, le badge du technicien prêté aux applications
Sur Android, chaque application vit dans un bac à sable. Elle ne voit que ses propres données et doit obtenir chaque permission sensible via une fenêtre de confirmation. Le shell ADB, utilisé par les développeurs lorsqu'ils pilotent le téléphone depuis un ordinateur, dispose de droits bien plus larges. Il peut lire l'intégralité du journal logcat, toutes applications et composants système confondus (le journal du noyau, lui, reste refusé), lister toutes les applications, modifier des réglages protégés ou piloter l'installeur.
Pendant longtemps, une application qui voulait ces droits devait exiger le root, ce qui suppose en général un bootloader déverrouillé : l'intégrité de l'appareil n'est plus garantie et les applications qui s'appuient sur Play Integrity, bancaires notamment, peuvent refuser de fonctionner. Shizuku propose une troisième voie. Il n'élève pas l'application, il lui prête l'identité du shell.
Comment ça fonctionne
- L'utilisateur démarre un serveur Shizuku via ADB, par câble ou par débogage sans fil. Ce serveur tourne sous l'identité shell (uid 2000), dans un processus distinct de l'application Shizuku elle-même.
- Une application cliente demande l'autorisation d'utiliser ce serveur. L'utilisateur l'accepte une seule fois.
- L'application transmet ensuite ses commandes au serveur, qui les exécute avec ses propres droits.
Pour un expert, le point clé se trouve dans le contrat d'interface utilisé par notre application de test. Le serveur charge et exécute du code fourni par l'application cliente, et ce code accepte une chaîne arbitraire :
// IUserService.aidl
interface IUserService {
String run(String command); // n'importe quelle commande
}Il n'existe aucune liste blanche d'opérations. Ce qui est délégué, c'est une identité et non une capacité précise. Une application autorisée peut faire tout ce que le shell peut faire.
Les usages légitimes sont nombreux : gestionnaires de paquets alternatifs, suppression d'applications préinstallées, sauvegardes, automatisation, pare-feu. C'est précisément ce qui en fait un sujet de sécurité. Un mécanisme conçu pour contourner légitimement le bac à sable reste, par construction, un mécanisme de contournement du bac à sable.
Shizuku fonctionne aussi en mode root (uid 0), avec des droits encore plus étendus. Nos mesures portent uniquement sur le mode ADB, le plus accessible puisqu'il ne demande aucun root. Les résultats qui suivent sont donc un minimum.
Ce que nos experts ont mesuré
Sur 41 commandes, 27 renvoient strictement plus d'informations quand elles passent par Shizuku. Le protocole est simple : la même commande est exécutée deux fois, une fois par l'application elle-même et une fois via Shizuku. Seule l'identité du processus change.
| Résultat | Commandes | Ce que ça signifie |
|---|---|---|
| Refusée sans Shizuku, acceptée avec | 13 | Capacité gagnée |
| Code de retour 0 sans Shizuku, mais refus dans la sortie | 6 | Capacité gagnée, invisible si l'on ne lit que le code |
| Réussie des deux côtés, mais vue tronquée sans Shizuku | 8 | Capacité gagnée, invisible si l'on ne lit que le code |
| Réussie des deux côtés, sans différence | 9 | Aucun gain |
| Échec des deux côtés | 5 | Limite du mode shell |
Une grande partie de ces écarts s'explique par une seule barrière. Les outils settings, cmd, pm ou appops commencent par identifier l'utilisateur courant, ce qui exige la permission INTERACT_ACROSS_USERS. Seuls le shell, le système et root la possèdent. Shizuku ne débloque donc pas treize capacités indépendantes : il franchit une barrière derrière laquelle tout l'outillage shell devient disponible.
Les écarts de visibilité sont tout aussi parlants :
| Ce que l'application voit | Sans Shizuku | Avec Shizuku |
|---|---|---|
| Applications installées | 98 (seuls les paquets que le filtrage de visibilité d'Android laisse voir à l'application) | 261 |
| Processus en cours | 3 lignes (l'en-tête, le processus de l'application et la commande ps elle-même), soit 2 processus, tous deux appartenant à l'application | 382 |
| Lignes du journal système | 284, toutes émises par l'application elle-même (le journal est filtré par uid) | 1 978 |
| Propriétés système | 539 | 563 |
Sans Shizuku, l'application ne voit littéralement que ses propres processus. Avec, elle obtient le même inventaire qu'un adb shell : la liste complète des paquets de l'utilisateur et tous les processus visibles du shell, init, processus root et threads noyau compris.
Démonstration 1 : lire les logs des autres applications, codes OTP compris
Un autre processus écrit deux secrets dans le journal système, comme le ferait une application trop bavarde : un faux code de validation bancaire et un jeton d'authentification. L'application de test lance ensuite logcat -d -s OTPDEMO:I.
[Via Shizuku]
I OTPDEMO : Your MyBank verification code is 471953 - do not share it
I OTPDEMO : Bearer eyJhbGciOiJIUzI1NiJ9.demo.token
[Sans Shizuku]
(aucune sortie)La permission READ_LOGS est réservée aux composants signés par la plateforme. Sur l'appareil, son niveau de protection est signature|privileged|development, hors de portée d'une application du Play Store. Le shell, lui, appartient au groupe log (1007) qui lève ce filtre. Tout secret écrit dans le journal système reste lisible, tant qu'il est encore dans le tampon circulaire de logd, par n'importe quelle application que l'utilisateur a autorisée dans Shizuku. Une application non autorisée ne voit que ses propres lignes.
Démonstration 2 : installer une application sans aucun écran
La charge utile est un APK inoffensif de 8,5 Ko, sans aucun code. Nos experts l'ont éprouvée en deux mesures distinctes. La première isole la barrière de permission : sans Shizuku, la commande pm install-create est refusée dès l'ouverture de session (INTERACT_ACROSS_USERS_FULL). L'application peut, elle, ouvrir une session par l'API PackageInstaller, mais le commit reste en attente d'une action de l'utilisateur et aucun paquet n'est installé.
pm install-create
[Via Shizuku]
Success: created install session [1908906140]
[Sans Shizuku]
java.lang.SecurityException: Permission Denial: doCreateSession ...
this requires android.permission.INTERACT_ACROSS_USERS_FULLLa seconde mesure démontre l'installation de bout en bout : via Shizuku, pm install -r renvoie Success (l'APK doit être lisible par le système : placé dans /data/local/tmp ou transmis par l'entrée standard avec pm install -S, car un fichier sous Android/data est refusé par SELinux) et l'application apparaît ensuite dans la liste des paquets installés.
Aucune fenêtre ne s'est affichée. Nos experts l'ont vérifié de trois manières : l'application de test est restée au premier plan pendant toute l'exécution, aucune activité de l'installeur (au sens Android : aucune fenêtre) n'a été démarrée, même si le journal système enregistre l'installation elle-même et le réveil du processus de l'installeur pour diffuser l'événement PACKAGE_ADDED, et les captures d'écran ne montrent jamais d'écran d'installation. C'est le comportement typique d'un dropper, qui télécharge puis installe d'autres malwares.
Démonstration 3 : s'accorder une permission sans popup
Pour cette démonstration uniquement, l'application de test a été modifiée pour déclarer deux permissions sensibles, l'accès aux contacts et aux SMS, sans les demander. Elle exécute ensuite pm grant sur les contacts uniquement. Les SMS servent de témoin. L'application interroge Android avant et après :
AVANT READ_CONTACTS granted=false
AVANT READ_SMS granted=false
APRÈS READ_CONTACTS granted=true ← accordée, sans aucune interaction
APRÈS READ_SMS granted=false ← témoin inchangéLa fenêtre de permission est le mécanisme de consentement d'Android depuis la version 6. Ici, l'application la contourne entièrement. La permission étant réellement accordée, tous les appels suivants paraissent légitimes aux yeux du système. Rien n'empêche de faire de même pour la localisation, le micro ou la caméra.
Démonstration 4 : dresser le profil complet de l'appareil
Via Shizuku, l'application récupère l'android_id du shell (celui que renvoie adb shell settings get secure android_id, commun à toutes les applications qui passent par Shizuku ou adb, et différent de l'android_id propre à l'application, qu'elle lit déjà sans aucune permission), le numéro de série, la liste des 261 applications avec leur emplacement, les comptes enregistrés et les statistiques d'usage des dernières 24 heures.
Le plus intrusif reste la table des connexions réseau (/proc/net/tcp et /proc/net/tcp6), qui associe chaque connexion à l'identifiant de l'application qui la détient. Croisée avec cmd package list packages -U, elle révèle quelle application parle à quel serveur. Le tout sans la moindre permission réseau.
Au-delà des démonstrations
En mode ADB, Shizuku n'ouvre pas les données privées des autres applications : le dossier /data/data reste refusé au shell. Une application ne peut donc pas lire directement la base de données d'une application bancaire, dès lors que celle-ci n'est pas marquée debuggable. Seul un paquet debuggable s'ouvre au shell, via run-as. En revanche, Shizuku permet de lire l'IMEI, de capturer l'écran et de simuler des gestes : RedHook s'en sert pour capturer l'écran sans fenêtre de consentement.
Pourquoi c'est un angle mort
Shizuku n'est pas une vulnérabilité. C'est une fonctionnalité utilisée conformément à sa conception, et il n'y a donc rien à corriger, ni côté Shizuku ni côté Android. Ce qui change, c'est le modèle de consentement.
| Modèle Android classique | Avec Shizuku autorisé | |
|---|---|---|
| Consentement | Une permission, une fenêtre | Une seule autorisation pour tout |
| Ce que voit l'utilisateur | La donnée visée (contacts, position…) | Une demande Shizuku, sans liste des capacités cédées |
| Révocation | Permission par permission, dans les réglages | Tout ou rien, dans l'application Shizuku |
| Identité qui agit | L'application elle-même | Le shell (uid 2000) |
L'utilisateur qui installe Shizuku le fait pour un usage légitime. Rien ne lui indique qu'autoriser une application revient à lui céder ses logs, l'inventaire de ses applications et le droit de s'accorder des permissions.
Autre point notable : détecter Shizuku ne demande aucun privilège. Notre application de test sait si un serveur tourne avant même d'avoir obtenu la moindre autorisation. Une application malveillante peut donc rester dormante sur les appareils sans Shizuku et n'agir que là où elle réussira.
RedHook va plus loin
Le scénario testé suppose que l'utilisateur a lui-même installé et démarré Shizuku. RedHook s'en passe. Une fois les droits d'accessibilité obtenus par ingénierie sociale, il active seul les options pour les développeurs et le débogage sans fil. Il s'appaire ensuite au service ADB du téléphone lui-même, puis déploie son propre serveur basé sur Shizuku. Après un redémarrage, il réactive le débogage et retrouve ses privilèges en quelques secondes.
Les capacités mesurées dans nos démonstrations recoupent celles qu'il exploite : installation silencieuse d'applications, modification de réglages protégés et octroi de permissions sans fenêtre de confirmation.
Comment repérer Shizuku
Quatre signaux doivent alerter sur un appareil.
- Options pour les développeurs activées. Elles sont le prérequis du mode ADB.
- Débogage USB ou sans fil actif. Le débogage sans fil permet de relancer Shizuku sans câble, et RedHook l'active lui-même.
- Application Shizuku installée. Elle révèle un usage de l'outil, légitime ou non.
- Application inconnue disposant de l'accès à l'accessibilité. C'est la porte d'entrée de RedHook, qui embarque son propre serveur basé sur Shizuku et n'apparaît donc pas sous ce nom dans la liste des applications.
Pour les équipes techniques, via ADB
Les équipes techniques peuvent vérifier ces points depuis un poste connecté, avec les commandes utilisées par nos experts sur leur banc :
# Débogage USB et sans fil (1 = activé)
adb shell settings get global adb_enabled
adb shell settings get global adb_wifi_enabled
# Serveur Shizuku actif
adb shell ps -A -o USER,PID,NAME | grep -i shizukuSi un serveur est actif, la dernière commande renvoie un processus shizuku_server exécuté sous l'identité shell.
Pour les éditeurs d'applications sensibles
Une application peut détecter Shizuku depuis son bac à sable, sans autorisation particulière. Notre application de test combine trois angles complémentaires : les traces d'installation, la réponse du serveur et les traces système.
| Question | Comment la poser depuis l'application | Ce que la réponse prouve | Ce qu'elle rate |
|---|---|---|---|
| Un serveur Shizuku répond-il en ce moment ? | Tenter un ping sur le binder que Shizuku dépose dans le bundle reçu par l'application : vrai ou faux. L'uid livré avec ce binder donne ses droits : 2000 = shell ADB, 0 = root | L'état réel du serveur et ses droits, sans aucune autorisation Shizuku | Rien : c'est le signal de référence |
| L'application Shizuku est-elle installée ? | getPermissionInfo() sur la permission moe.shizuku.manager.permission.API_V23, ou getPackageInfo() sur le paquet moe.shizuku.privileged.api | La présence de Shizuku, même serveur arrêté | Sui (ni paquet ni permission) et les forks renommés ; ne dit pas si le serveur tourne |
| Le débogage ADB est-il activé ? | Settings.Global.ADB_ENABLED | Le prérequis du mode ADB est en place | Indice seulement : ni nécessaire ni suffisant seul |
Le ping ne demande aucune bibliothèque : une application qui déclare la permission moe.shizuku.manager.permission.API_V23 et expose un provider <package>.shizuku reçoit de Shizuku un bundle contenant son binder, et un pingBinder() sur ce binder répond vrai ou faux.
Comment Pradeo répond
Vérifier chaque téléphone à la main ne tient pas à l'échelle d'une flotte. La solution Mobile Threat Defense de Pradeo surveille en continu, sur l'ensemble des terminaux, les conditions qui rendent Shizuku exploitable :
- Configurations à risque. Elle signale toute activation anormale des options pour les développeurs et du débogage sans fil, prérequis du mode ADB de Shizuku.
- Permissions critiques. Toute application qui demande l'accès à l'accessibilité est signalée comme potentiellement malveillante.
- Applications hors stores officiels. Elle détecte les apps installées depuis une autre source, mode de distribution de RedHook.
- Phishing mobile. Le blocage des liens frauduleux reçus par SMS ou messagerie instantanée, canaux de diffusion de RedHook, coupe la chaîne d'infection en amont.
Côté éditeurs d'applications, notre solution Runtime Application Self Protection détecte lorsqu'une application s'exécute sur un téléphone en mode développeur, prérequis du mode ADB de Shizuku. L'application sait ainsi qu'elle tourne dans un environnement à risque et peut réagir avant qu'un tiers n'abuse de ces privilèges.
