860 votes positifs, 404 commentaires : la communauté s’embrase
En juillet 2026, la capture d’écran d’un commentaire interne issu de l’IssueTracker de Google a fuité. Un mainteneur clé de l’équipe ADB chez Google y écrivait : « La connexion localhost s’avère également être une voie d’élévation de privilèges pour les applications via les sockets ADB. Pourquoi ne pas restreindre la liaison uniquement à l’interface sans fil wlan0 ? »
Cette discussion technique d’apparence anodine a recueilli 860 votes positifs et 404 commentaires sur Hacker News, déclenchant l’un des débats les plus passionnés au sein de la communauté des développeurs Android depuis près d’une décennie. Au cœur de la controverse se trouve une question incontournable : s’agit-il d’une véritable avancée en matière de sécurité, ou d’un prétexte opportun pour éliminer des outils jugés indisciplinés ?
Une « porte dérobée » dissimulée dans les options pour développeurs
L’ADB (Android Debug Bridge) est quasi inexistant pour l’utilisateur lambda d’Android — il réside dans les « Options pour développeurs » des paramètres, elles-mêmes dissimulées sous forme d’easter egg nécessitant de tapoter sept fois d’affilée sur le « Numéro de build » pour apparaître.
Pourtant, le pouvoir d’ADB est immense. Il agit comme un canal d’administration système : il peut installer ou désinstaller des applications, lire les journaux, consulter des fichiers et simuler des pressions sur les touches ou l’écran. Les développeurs s’en servent pour déboguer leurs applications, tandis que les utilisateurs avancés l’utilisent pour débloquer des fonctionnalités non exposées par le système.
À l’origine, ADB nécessitait un câble USB relié à un ordinateur. Android 11 a introduit le débogage sans fil (Wireless Debugging), permettant une connexion en Wi-Fi après un appairage par code QR. Ces deux méthodes imposaient toutefois d’avoir deux appareils : un smartphone et un ordinateur.
C’était sans compter sur l’ingéniosité des développeurs : et si l’on exécutait un client ADB directement sur le smartphone en se connectant à lui-même via 127.0.0.1 (localhost) ?
Cette pratique a pris le nom d’« ADB sur l’appareil » (On-Device ADB). Bien qu’elle n’ait jamais été prévue à l’origine par Google, elle a donné naissance à tout un écosystème d’outils open source.
Shizuku : un écosystème inattendu
L’application phare issue de cette pratique est Shizuku (nommé d’après le mot japonais 雫 signifiant goutte d’eau).
Le rôle de Shizuku se résume en une phrase : il exploite l’ADB sur l’appareil pour obtenir des privilèges système, puis permet à d’autres applications d’invoquer ces autorisations sans nécessiter d’accès root.
Cela semble encore abstrait ? Voici quelques exemples concrets :
- Canta : permet de désinstaller les applications indésirables (bloatware) préinstallées par les constructeurs (boutiques ou portefeuilles propriétaires) sans aucun accès root.
- App Manager : permet de vérifier en détail quelles autorisations chaque application utilise réellement et à quels fichiers elle accède.
- aShell : ouvre une fenêtre de terminal directement sur le téléphone pour exécuter nativement des commandes ADB.
- ShizuCallRecorder : active l’enregistrement des appels sur les téléphones vendus dans les régions où cette fonction est désactivée. Son auteur, Kitsumed, l’a créé spécifiquement pour l’aider à compenser sa déficience auditive au quotidien.
Lorsque Rikka, créateur de projets open source Android, a publié Shizuku en 2019, il n’imaginait probablement pas qu’il deviendrait une « infrastructure de base » aussi essentielle. Aujourd’hui, Shizuku compte plus d’un million d’installations rien que via le Google Play Store — un chiffre largement sous-estimé, une grande partie des utilisateurs l’installant directement depuis F-Droid ou GitHub.
Le scénario d’attaque : une accumulation de prérequis
La crainte du mainteneur ADB de Google est qu’une application malveillante puisse utiliser la connexion 127.0.0.1 de l’ADB sur l’appareil pour élever ses propres privilèges et contourner ainsi le bac à sable (sandbox) d’Android.
Dès lors, combien d’étapes une application malveillante doit-elle franchir pour réussir une telle attaque ?
En synthétisant l’analyse de Kitsumed et les échanges dans les commentaires sur HN, la chaîne d’attaque réelle se décompose comme suit :
- L’utilisateur doit se rendre dans « Paramètres → À propos du téléphone » et tapoter 7 fois sur « Numéro de build » pour activer les options pour développeurs.
- L’utilisateur doit entrer manuellement dans les options pour développeurs et activer le « Débogage USB » pour démarrer le démon ADB.
- L’utilisateur doit ensuite activer le « Débogage sans fil » (Android 11+) ou se connecter via USB à un PC pour activer le mode TCP/IP.
- Lorsqu’une application malveillante initie une connexion, une boîte de dialogue apparaît à l’écran et l’utilisateur doit cliquer explicitement sur « Autoriser ».
- En cas d’utilisation du mode d’appairage du débogage sans fil, l’utilisateur doit saisir manuellement un code d’appairage à 6 chiffres.
Le commentaire de l’utilisateur microtonal sur HN est devenu le plus plébiscité : « Ce vecteur d’attaque nécessite d’avoir à la fois les paramètres développeur et l’ADB distant activés. Pour 99,9 % des utilisateurs, ce n’est pas un vecteur d’attaque réaliste. Les 0,1 % restants savent parfaitement ce qu’ils font. »
Un autre utilisateur, crote, s’est montré encore plus direct : « Il est pratiquement impossible que cela touche des utilisateurs ordinaires ; seuls des développeurs distraits pourraient se faire piéger. Et cela suppose que la détection de malwares du Google Play soit totalement inefficace — attendez, l’argument pour restreindre l’installation d’applications tierces n’était-il pas justement que l’analyse du Play Store était formidable ? »
D’un point de vue ingénierie, la faille CVE-2026-0073 était certes une vulnérabilité réelle — elle permettait de contourner l’authentification du débogage sans fil. Cependant, cette vulnérabilité a déjà été corrigée. La proposition actuellement débattue vise à bloquer la fonctionnalité d’ADB sur l’appareil elle-même, bien après que la faille a été comblée.
Qui est le véritable antagoniste ?
Il est difficile de ne pas déceler ici la répétition d’un schéma bien connu.
Si l’on passe en revue les décisions de Google ces dernières années : Chrome a déployé Manifest V3, affaiblissant les bloqueurs de publicites au nom de la sécurité ; Android a durci les autorisations d’installation d’applications externes (sideloading), restreignant les installations hors du Play Store sous le même prétexte. À chaque fois, la « sécurité » est la carte maîtresse abattue, et à chaque fois, le résultat est identique : réduire la marge de contrôle de l’utilisateur sur son propre appareil.
L’utilisateur transcriptase sur HN a résumé le sentiment général : « Je n’arrive toujours pas à croire qu’une régie publicitaire soit parvenue à neutraliser efficacement les capacités de blocage de publicités et de contenus pour 80 % des utilisateurs mondiaux sous couvert de problèmes de sécurité inexistants. »
Le scénario de cette restriction ADB suit exactement le même script. Il existait une demande de fonctionnalité légitime sur IssueTracker : permettre aux développeurs de choisir sur quelles interfaces réseau le démon ADB écoute (il écoute actuellement sur toutes les interfaces). C’était une amélioration raisonnable. Cependant, dans les commentaires, le mainteneur ADB a détourné le sujet, passant de la « restriction de la sélection d’interface » au « bannissement complet des connexions en boucle locale (localhost) » — détruisant ainsi le fondement même sur lequel repose l’ADB sur l’appareil.
Dans tout cet écosystème, il n’y a pas de « méchant » caricature. Le véritable enjeu est une bataille sur les frontières du pouvoir entre le propriétaire de la plateforme (Google) et les véritables propriétaires des appareils (consommateurs et développeurs). Google cherche à préserver le caractère fermé et contrôlable de l’écosystème Android, tandis que les utilisateurs et développeurs réclament le contrôle effectif de leur propre matériel.
L’écosystème sacrifié
Si cette proposition venait à être adoptée, que perdrait-on exactement ?
- Toutes les fonctionnalités de Shizuku : du nettoyage des applications préinstallées au blocage du réveil des applications, tout serait paralysé.
- Des dizaines d’outils dépendant de Shizuku, tels que Canta, App Manager ou aShell.
- Des bibliothèques de bas niveau comme
libadb-android. - L’ensemble des flux de travail de développement utilisant ADB dans Termux.
Dans son article original, Kitsumed a appelé les développeurs à soumettre des avis constructifs sur IssueTracker plutôt qu’à publier des commentaires hostiles sans valeur. Cette posture retenue ressemble à un sourire amer : « Nous savons que cela ne pourra probablement pas être arrêté, mais au moins, ne passons pas pour des imbéciles. »
Au vu des récents mouvements sur IssueTracker, la tâche a déjà été réattribuée aux ingénieurs principaux de l’équipe ADB, preuve que l’initiative suit son cours.
La sécurité n’est jamais seulement une question technique
Le blocage de l’ADB sur l’appareil peut être vu, sous un certain angle, comme un durcissement logique de la sécurité — toute mesure réduisant la surface d’attaque possède une valeur. Mais sous un autre angle, c’est le signal d’une « défiance par défaut envers le propriétaire de l’appareil » : vous avez acheté ce téléphone, mais vous n’avez pas nécessairement le droit de décider quel code il peut exécuter.
Au cours du débat, l’utilisateur JoshTriplett sur HN a proposé un compromis : interdire par défaut les connexions en boucle locale, tout en proposant un interrupteur permanent dans les paramètres (qui persiste après un redémarrage) et dont l’état ne peut pas être lu par des applications tierces. Cela garantirait la sécurité des utilisateurs ordinaires tout en préservant une issue pour les utilisateurs avancés. Du point de vue de l’ingénierie, il ne s’agit pas d’une conception difficile à mettre en œuvre.
Mais si la proposition suscite tant de remous, c’est précisément parce qu’elle a écarté tout compromis.
En 2026, Android vit un équilibrage délicat : d’un côté, le Digital Markets Act (DMA) de l’UE l’oblige à s’ouvrir au sideloading et aux magasins d’applications tiers ; de l’autre, Google resserre en interne son contrôle sur les couches basses du système. La restriction de l’ADB sur l’appareil n’est peut-être qu’un domino de plus qui tombe dans cette lutte d’influence, sans même que la majorité des utilisateurs ne s’en aperçoive.
Fig. : Interface de configuration du débogage sans fil dans Shizuku. Source : shizuku.rikka.app
Fig. : Interface après le lancement réussi de Shizuku. Source : shizuku.rikka.app
Fig. : Boîte de dialogue de saisie du code d’appairage à 6 chiffres. Source : shizuku.rikka.app
Sources de référence
- Android May Soon Restrict On-Device ADB, Affecting Shizuku, libadb and Developers — Kitsumed Blog
- Hacker News Discussion (item?id=49045159)
- Shizuku User Manual — Rikka Apps
- Google IssueTracker — ADB Feature Request
- Android Developers — Documentation officielle ADB
