Ce que je peux affirmer, et ce que je ne peux pas

Cet article est le pendant du récit technique : là je racontais comment j'ai reconstruit le micrologiciel de mon projecteur, ici je montre pourquoi je l'ai fait, chiffres à l'appui.

Un mot de méthode avant tout le reste, parce qu'il commande la lecture de tout ce qui suit. Je distingue trois choses, et je les tiendrai séparées d'un bout à l'autre :

• Ce que des publications sérieuses ont établi, que je cite et que je n'ai pas reproduit.
• Ce que j'ai mesuré moi-même, sur ma machine, avec des outils que je nomme et des relevés que je publie.
• Ce que je ne sais pas, et que je ne comblerai pas par des suppositions.

C'est fastidieux à écrire. C'est aussi la seule façon de rendre un article de ce genre utilisable par quelqu'un d'autre que son auteur.

Ce que les publications ont établi avant moi

Janvier 2023 — un particulier, un Pi-hole, et le premier signalement

Toute cette affaire commence par un achat ordinaire. Daniel Milisic, consultant canadien, commande un boîtier Android T95 sur Amazon pour y faire tourner un Pi-hole — un filtre publicitaire à l'échelle du réseau domestique.

C'est le Pi-hole lui-même qui vend la mèche : à peine branché, le boîtier interroge des domaines associés à des campagnes malveillantes. Milisic remonte la piste, identifie les composants fautifs, et publie en janvier 2023 un dépôt public avec un script de neutralisation, faute d'avoir trouvé une ROM propre.

Je m'arrête sur ce point parce qu'il m'a frappé : à trois ans de distance, c'est exactement la méthode que j'ai employée. Journaliser les noms depuis le réseau, parce que la machine ne peut pas se surveiller elle-même. Nous y reviendrons en conclusion, ce n'est pas un hasard.

Mars 2025 — une entreprise de sécurité nomme le réseau

L'équipe Satori de HUMAN Security publie le 5 mars 2025 l'analyse d'un réseau qu'elle baptise BADBOX 2.0 : plus d'un million d'appareils Android bon marché — téléviseurs connectés, boîtiers, tablettes — livrés avec une porte dérobée installée avant la vente. Le rapport décrit plusieurs modèles de fraude greffés dessus, dont la revente d'accès à des connexions résidentielles.

C'est le cadre général. Il ne parle pas de mon projecteur, il décrit le phénomène auquel il appartient.

Décembre 2024 à juillet 2025 — les autorités s'en mêlent

Entre-temps, l'affaire change d'échelle et cesse d'être une histoire de passionnés.

• Décembre 2024 — l'office fédéral allemand de la sécurité informatique (BSI) détourne un serveur de commande du réseau et coupe la communication de 30 000 appareils sur le territoire allemand.
• Décembre 2024 — l'entreprise Bitsight détourne à son tour un domaine et compte plus de 160 000 adresses IP uniques en 24 heures. Son relevé apporte un élément que je n'ai vu nulle part ailleurs : l'infection ne touche plus seulement des appareils sans marque, mais aussi des produits de fabricants connus.
• Mars 2025 — une opération conjointe entre HUMAN, Google, Trend Micro et la Shadowserver Foundation neutralise plus de 500 000 appareils.
• 5 juin 2025 — le FBI publie un avis public (référence I-060525-PSA) sur les objets connectés domestiques servant à des activités criminelles. Il mentionne explicitement les projecteurs.
• Juillet 2025 — Google engage une action en justice contre les opérateurs du réseau.

On peut donc écarter l'hypothèse du fantasme : un office fédéral, une agence fédérale américaine et plusieurs entreprises de sécurité travaillent sur le même objet depuis deux ans.

Février 2026 — un professionnel observe sa propre ligne

Johny Metellus, responsable informatique, publie le 15 février 2026 le récit d'un projecteur acheté sur Amazon et devenu, selon son analyse, un relais pour du trafic criminel pendant deux mois. Son relevé est précis : une requête toutes les 65 secondes vers un domaine imitant celui de Facebook, et l'envoi d'une empreinte complète de l'appareil — adresse MAC, identifiant, version du micrologiciel — 2,17 secondes après l'allumage.

Un détail m'a arrêté : son appareil est vendu sous la marque AODIN. Or le mien, de marque Magcubic, interroge des serveurs du domaine aodintech.com. Je le note comme une observation, sans en tirer de conclusion : ces appareils partagent visiblement une base commune, revendue sous plusieurs marques.

Mai 2026 — un CERT national démonte un projecteur

Le 25 mai 2026, le centre de réponse aux incidents d'Azerbaïdjan publie l'analyse d'un projecteur à 35 dollars. Il y identifie deux composants, com.hotack.silentsdk et com.hotack.writesn, et un domaine, usmyip.kkoip.com, dont le nom même annonce la fonction : enregistrer l'adresse IP de l'utilisateur.

Le CERT précise que des composants similaires ont été trouvés sur des projecteurs vendus sous les marques Hotack, Huyukang et Nonete. Là encore : une base commune, plusieurs étiquettes.

Ce que ces sources ont en commun — et ce qui les sépare

Elles convergent sur le mécanisme : des composants installés en usine, invisibles à l'utilisateur, qui contactent des serveurs distants sans consentement et servent d'infrastructure à des activités marchandes ou criminelles.

Mais — et c'est ce que la plupart des articles de reprise omettent — elles portent sur des appareils différents des miens, avec des composants différents et des domaines différents. Le CERT azerbaïdjanais analyse un HY300 Pro+ ; Johny Metellus un AODIN X1BQ ; ni l'un ni l'autre un HY350 Max.

C'est précisément pour ça que j'ai regardé le mien.

La réponse du constructeur

Le 22 avril 2026, Magcubic publie un communiqué au sujet de certains fichiers APK présents sur ses produits. Je le résume fidèlement, en m'en tenant à ce qu'il dit :

• il annonce « the following APK files » — et aucune liste ne suit, ni dans la version anglaise ni dans la française ;
• il affirme que ces fichiers sont nécessaires à des services locaux et ne contiennent pas de logiciel malveillant ;
• il cantonne la question aux appareils de la série HY300 équipés de la puce H713 ;
• il indique que les modèles équipés de la puce H726 ne contiennent pas cet APK ;
• il recommande d'utiliser l'appareil hors ligne et d'installer les applications depuis une clé USB.

Le HY350 Max est un H726. Le communiqué ne le mentionne pas, et je n'en tire aucune intention : un constructeur qui assemble un matériel autour d'une base logicielle fournie par un tiers ne connaît pas nécessairement le contenu de cette base. Je constate simplement que mon modèle n'est traité nulle part, et que j'ai donc dû regarder moi-même.

Et les autres ?

J'ai cherché les réponses publiques des autres marques citées dans ces affaires — droit de réponse, communiqué, message sur les réseaux sociaux. Je n'en ai trouvé aucune.

La seule prise de parole d'un acteur industriel que j'aie pu identifier vient de Google, et elle consiste à prendre ses distances : les appareils concernés ne sont pas certifiés Play Protect, dit en substance l'entreprise, et les appareils qui le sont passent des tests que ceux-là n'ont pas passés. C'est exact, et ça ne renseigne pas beaucoup l'acheteur qui a déjà l'appareil chez lui.

Il faut donc être juste : Magcubic fait partie du très petit nombre de constructeurs à avoir publié quelque chose. On peut trouver ce communiqué incomplet — il annonce une liste qu'il ne donne pas — et regretter qu'il ne traite pas mon modèle. Il n'en reste pas moins que la plupart des marques concernées n'ont, à ma connaissance, jamais rien dit du tout.

Ma méthode

Les outils

Tout ce qui suit a été obtenu avec des outils libres ou fournis par Android, sur ma propre machine.

Ouverture du firmware   outil maison pour le conteneur Allwinner, lpunpack, debugfs
Analyse des paquets     jadx (decompilation), lecture des manifestes
Etat du systeme         adb, dumpsys, pm list packages -U, /proc/net/tcp
Capture reseau          tcpdump sur l'appareil (variante rootee)
Journal des noms        MyPublicWiFi, point d'acces logiciel avec journal d'URL
Verification des noms   resolution DNS depuis un poste tiers

Le point d'accès qui a rendu tout ceci possible

Je m'arrête un instant sur MyPublicWiFi, parce que sans lui la moitié de cet article n'existerait pas, et parce que le service qu'il rend n'est pas celui auquel on pense.

Le principe est simple : le logiciel transforme un PC sous Windows en point d'accès Wi-Fi, et journalise les noms de domaine demandés par les appareils qui s'y connectent. On y branche le projecteur comme sur une box, et on lit ce qu'il réclame.

Mais la fonction décisive est ailleurs. Dans ses modes d'accès au réseau, il propose « Pas de partage Internet » : le projecteur reçoit une adresse, un serveur de noms, un réseau parfaitement fonctionnel — et aucune route vers l'extérieur.

C'est ce mode qui a permis le premier relevé, et il fallait qu'il existe. Le firmware d'origine embarque un installateur silencieux en état de marche ; lui ouvrir une route pour l'observer aurait été lui permettre d'aboutir. Là, il parle dans le vide et on l'écoute parler. On mesure une intention sans jamais courir le risque d'une transmission.

Pour le second relevé, le mode « routeur (NAT) » a fait l'inverse : il achemine le trafic selon la table de routage de Windows, donc à travers un VPN une fois celui-ci connecté. L'infrastructure sollicitée a vu une adresse de centre de données, pas mon domicile.

Et c'est là que se joue la validité de la comparaison : le même instrument a servi aux deux conditions. Un « avant » relevé au Pi-hole et un « après » relevé autrement ne se compareraient pas honnêtement. Ici, seul le paramètre étudié change.

Ce logiciel mérite un article à lui seul, et il l'aura.

Quatre relevés, quatre conditions

Un relevé réseau ne veut rien dire si l'on ne précise pas les conditions. J'en ai fait quatre, tous le même jour, sur la même machine, appareil allumé et laissé au repos :

Les relevés 1 et 3 se comparent entre eux, les relevés 2 et 4 entre eux. Comparer un « avant » avec route à un « après » sans route ne prouverait rien, et c'est une erreur que je me suis efforcé de ne pas commettre.

Ce que chaque instrument voit, et ne voit pas

Un journal de noms enregistre les domaines qu'un appareil cherche à résoudre. Il est extérieur à la machine, donc insensible à ce qui s'y exécute — c'est sa force. Mais il ne voit ni le contenu ni même si une connexion a suivi, et il est aveugle à une adresse IP jointe sans passer par le DNS.

Une capture de paquets voit tout ce qui entre et sort, dans les deux sens, adresses comprises. Mais le contenu des sessions chiffrées lui échappe — et il faut le root pour la faire.

D'où l'emploi des deux.

L'analyse des applications

Sept noms circulent : deux existaient vraiment sur ma machine

Une liste de sept paquets circule pour cette famille d'appareils. J'ai vérifié chacun, non pas en cherchant des chaînes de caractères — méthode trompeuse — mais en cherchant les répertoires d'applications dans les partitions d'origine.

Deux sur sept. Les cinq autres n'apparaissent que comme noms dans des listes de configuration héritées de la plateforme : des listes d'exemption au tueur de mémoire, des filtres d'affichage du lanceur, des tables de chaînes. Une entrée qui nomme un paquet absent ne fait rien.

Je le souligne parce que la tentation était grande d'annoncer sept retraits. Ç'aurait été faux, et un lecteur qui vérifie s'en apercevrait.

Un mot sur silentsdk, absent de la liste ci-dessus : selon les analyses publiées, il n'est pas préinstallé par construction — il est téléchargé à l'exécution par l'installateur. Son absence sur une machine neuve ne prouve donc pas grand-chose, et c'est justement ce qui rend l'installateur central.

Le point le plus grave : l'identité système

S'il ne fallait retenir qu'une seule chose de tout cet article, ce serait celle-ci.

com.htc.storeos       sharedUser = android.uid.system  (uid 1000)
                      pkgFlags   = [ SYSTEM HAS_CODE … ]
com.htc.htcotaupdate  sharedUser = android.uid.system  (uid 1000)

Il faut mesurer ce que ça signifie. Android repose sur un principe simple : chaque application reçoit son propre identifiant d'utilisateur, et ne peut toucher ni aux fichiers ni aux processus des autres. C'est le bac à sable, et c'est ce qui rend un téléphone à peu près sûr malgré les centaines d'applications qu'on y installe.

L'UID 1000 est l'identité du système Android lui-même. Une application qui la porte n'est plus dans un bac à sable : elle est à côté du gestionnaire de paquets, du serveur de fenêtres, du gestionnaire de comptes. Elle peut installer et désinstaller silencieusement, lire les réglages protégés, survivre à une réinitialisation d'usine.

Ce niveau ne s'obtient pas en cochant une case. Il faut que l'application soit signée avec la clé de plateforme du micrologiciel — la clé maîtresse de l'appareil. Quelqu'un, quelque part dans la chaîne, a délibérément accordé cette clé à un installateur silencieux.

Et cette identité partagée a une conséquence pratique redoutable pour qui veut enquêter : toute comptabilité par application devient inutilisable. Le compteur réseau d'Android range ces composants avec des dizaines de services légitimes du système. Impossible de leur attribuer un octet. Seuls les noms de domaine tranchent — ce qui explique la suite de cet article.

Un binaire su setuid livré d'usine

Deuxième trouvaille, du même ordre. Le micrologiciel d'origine contient :

-rwsr-sr-x  1 root shell  5788  /system/xbin/hotacksu
            ^
            le bit setuid : le programme s'execute en tant que root
            quel que soit l'utilisateur qui le lance

C'est le binaire su d'Android, renommé. Et il n'est pas là par accident : son chemin figure dans la table des permissions du système de fichiers, compilée à l'intérieur de libcutils.so, libadbd_fs.so et mkfs.erofs. Autrement dit, l'arbre de compilation d'Android a été modifié pour lui accorder ce privilège à la construction de l'image.

Une nuance honnête, et elle est importante : sur le firmware d'origine, ce binaire ne fonctionne pas. Je l'ai essayé — SELinux refuse la transition et il échoue. Il est là, armé, mais neutralisé par la politique de sécurité. Reste que sa seule présence, avec cette déclaration dans la table des permissions, en dit long sur la façon dont cette image a été construite.

L'interface du constructeur

La décompilation de com.htc.magcubicos, l'accueil et le panneau de réglages de l'appareil, donne :

• un appel HTTP en clair vers store-api.aodintech.com, dans la méthode de démarrage ;
• le traceur com.baidu.mobstat, démarré au lancement de l'application — 357 fichiers, 4 Mo de code ;
• les permissions INTERNET, INSTALL_PACKAGES, GET_ACCOUNTS_PRIVILEGED et PACKAGE_USAGE_STATS ;
• sur l'écran « Informations système », cinq points de lancement vers l'OTA constructeur et trois composants de la famille hotack, dont quatre accessibles par une combinaison de touches non documentée.

Une application de réglages qui embarque un traceur publicitaire et la permission d'installer des paquets, ce n'est pas une anomalie de configuration. C'est un choix de conception.

Les mesures réseau

Relevé 1 — sans route : l'intention à l'état pur

Premier relevé, 26 minutes, appareil au repos, volontairement privé d'accès à Internet. Le firmware d'origine embarquant un installateur silencieux en état de marche, lui ouvrir une route pour les besoins de la mesure aurait été lui permettre d'aboutir.

Résultat : 904 requêtes DNS, soit environ 35 par minute, sur un appareil que personne ne touche.

Le point d'installation silencieuse est sollicité toutes les 5 à 10 secondes, sans interruption. L'isolement rend d'ailleurs la mesure plus propre, et non moins : rien ne déclenche ces requêtes, aucune réponse ne revient, et la cadence ne faiblit pas pour autant.

Relevé 2 — avec route : le canal permanent

Deuxième relevé, deux minutes seulement, avec un accès réel acheminé par un VPN pour que l'infrastructure sollicitée ne découvre pas mon adresse résidentielle. Fait juste avant la réinstallation, de sorte que tout ce qui aurait pu être déposé était effacé dans la foulée.

Les connexions aboutissent :

3.12.169.56:443     mphotool     3 sessions simultanees, en permanence
119.28.17.161:443   store-api    presente dans 60 echantillons sur 60

Le point d'installation silencieuse maintient un canal chiffré ouvert pendant la totalité de l'observation, tenu par l'UID système, vers une adresse de Tencent Cloud. Ce n'est plus une tentative de résolution : c'est une session établie, sur un appareil que personne ne touche.

Le piège de lecture

Voici la chose la plus contre-intuitive que cette enquête m'ait apprise, et elle vaut pour quiconque lit un journal DNS.

Avec une route, store-api.aodintech.com n'est résolu qu'une seule fois. Le premier relevé en comptait 216 : c'étaient des reprises, parce que rien n'aboutissait jamais.

Une requête unique suivie d'un canal permanent représente donc davantage de contact qu'une rafale de résolutions sans lendemain — et non l'inverse. Qui compterait les lignes d'un journal DNS pour mesurer l'activité d'un appareil conclurait exactement à rebours de la réalité.

Ces points de terminaison sont vivants

Mon appareil ne pouvant pas résoudre ces noms pendant le premier relevé, la question restait ouverte : cette infrastructure existe-t-elle encore ? Résolution faite depuis un poste tiers disposant d'un accès normal :

store-api.aodintech.com  ->  119.28.17.161    Tencent Cloud
ota-api.aodintech.com    ->  124.156.99.68    Tencent Cloud
ota.triplesai.com        ->  111.230.36.129   Tencent Cloud
otaapi.triplesai.com     ->  111.230.36.129   Tencent Cloud
server.mphotool.com      ->  3.12.169.56      AWS
server2.mphotool.com     ->  3.12.169.56      AWS
hmma.baidu.com           ->  103.235.46.195   Baidu
api.bigbigcloud.cn       ->  NXDOMAIN         (canal officiel du constructeur, mort)

L'infrastructure sollicitée est en service. Détail savoureux : le seul domaine réellement mort de la liste est le canal de mise à jour officiel du constructeur — ce qui explique au passage pourquoi la mise à jour en ligne d'origine ne fonctionne plus pour personne.

Relevés 3 et 4 — après nettoyage

Mêmes conditions, mêmes durées, sur la ROM reconstruite. La variante rootée donne accès à tcpdump : la mesure porte cette fois sur les paquets eux-mêmes, à la source, dans les deux sens.

Sans route, 275 paquets en 10 minutes. 90 requêtes DNS, toutes vers Google, plus le contrôle de connectivité et le rapport de plantage de SmartTube. Aucune connexion unicast vers l'extérieur.

Avec route, 3 729 paquets en 10 minutes, et six destinations extérieures :

2001:4860:4840:400::       143 764 o recus / 29 733 emis   Google
142.251.156.4              109 918 o /  8 328 o            Google
2a00:1450:4007:817::2003     5 956 o /  1 324 o            Google
2001:4860:4844:400::             0 o /     24 o            Google
2a00:1450:4007:81a::200e        73 o /      0 o            Google
2a00:1450:400c:c06::bc          24 o /     28 o            Google

Six destinations, toutes chez Google. Aucune autre, d'aucune sorte. J'ai vérifié chaque adresse restante de la capture une par une : réseau local, adresses lien-local d'appareils voisins annonçant leurs services, ARP, trames de commutation.

Les quatre seuls noms demandés : www.googleapis.com, www.youtube.com, firebaseinstallations.googleapis.com et firebase-settings.crashlytics.com — ce dernier étant le rapport de plantage de SmartTube, que je documente et qui se désactive.

Les limites de tout ceci

Un relevé sans ses limites ne vaut pas grand-chose. Voici les miennes, et je préfère les écrire moi-même.

Je n'ai jamais vu ce qui s'échangeait

Tout ce qui compte passe en TLS. Même avec une capture intégrale, le contenu d'une session vers store-api.aodintech.com resterait chiffré. Lire ce qui s'y dit demanderait une interception avec certificat installé sur l'appareil — un autre chantier, que je n'ai pas mené.

Je sais donc qui parle à qui, quand, et combien d'octets. Jamais ce qui est dit.

Je n'ai pas observé de relais

Les publications que je cite décrivent des appareils enrôlés comme relais résidentiels. Je n'ai rien mesuré de tel.

Le seul élément qui y ressemblait : sur le relevé de deux minutes, l'application de recopie d'écran a reçu 179 581 octets et en a émis 178 345 — presque symétrique, sur un appareil au repos. Un service qui se contente d'écouter ne renvoie pas l'équivalent de ce qu'il reçoit. C'est le profil d'un relais. Deux minutes ne permettent pas de l'affirmer, et je ne l'affirme pas.

Un échantillonnage ne prouve pas une absence

Mes relevés établissent ce qu'ils ont attrapé. Ils n'établissent jamais que rien d'autre n'a eu lieu. Douze domaines de la liste d'indicateurs publique n'ont pas été observés du tout : ils appartiennent probablement aux étages ultérieurs de la chaîne, déclenchés une fois les instructions reçues. Leur absence n'infirme rien.

Et rien ici ne prouve quoi que ce soit contre moi

C'est la limite la plus honnête. Ces mesures montrent ce qui change entre deux micrologiciels ; elles supposent encore que mon outillage est loyal. Le seul niveau de preuve qui supprimerait cette confiance est la reproductibilité : publier les scripts et l'empreinte de la base pour que quiconque rebâtisse et compare. C'est la direction à prendre, et ce n'est pas encore fait.

Ce que je retiens

Ce que je sais à 100 %, parce que je l'ai mesuré sur ma machine et que les fichiers bruts existent : deux applications non documentées, portant l'identité système d'Android, étaient présentes sur un micrologiciel officiel de septembre 2026. L'une d'elles maintenait un canal chiffré permanent vers une infrastructure hébergée chez Tencent. Un binaire su setuid était livré avec l'image et déclaré dans la table des permissions du système de fichiers. L'interface de réglages embarquait un traceur publicitaire et un appel marchand en clair. Et après reconstruction, sur dix minutes de capture avec un accès réel, il ne reste rien d'autre que Google.

Ce que je crois, sans pouvoir le démontrer : que ces composants font partie de l'ensemble décrit par les publications citées, et que le profil de trafic de la recopie d'écran mériterait une observation plus longue.

Ce que je ne saurai jamais : qui a placé ces composants, à quel étage de la chaîne, et si l'entreprise qui vend l'appareil en avait connaissance. Une chaîne de fabrication compte plusieurs intervenants, et n'importe lequel peut lui-même avoir été compromis. Il y a des victimes — à commencer par ceux qui ont acheté l'appareil — mais désigner un coupable relèverait de la spéculation.

Reste une chose que ce travail m'a apprise et qui dépasse ce projecteur : l'identité système accordée à un installateur silencieux rend l'appareil inauditable par ses propres moyens. Aucun compteur, aucune statistique d'usage, aucune application de sécurité installée par-dessus ne peut distinguer ce composant du système lui-même. Il a fallu sortir de la machine — journaliser les noms depuis le réseau — pour voir quelque chose.

C'est peut-être le vrai enseignement de cette histoire. Un appareil à 60 € n'a pas les moyens de se surveiller lui-même. Il faut le regarder de l'extérieur.

Sources

Les analyses de composants — appels réseau, permissions, traceurs, points de lancement cachés — proviennent de la décompilation des applications de l'image d'origine et de mesures faites sur mon appareil. Elles ne sont reprises d'aucune source extérieure.