Commencez avec la télécommande en main et le boîtier encore branché. Vous ne nettoyez encore rien. Vous construisez un registre, une vérification à la fois, pour que le verdict à la fin repose sur des preuves tirées de votre propre boîtier et non sur un nom de marque ou une étiquette de prix. Notre reportage sur le démantèlement couvre qui a construit XCPE et comment Google et ses partenaires ont coupé ses serveurs de contrôle fin octobre. Ce tutoriel couvre le boîtier sous votre télévision.
Ce que vous allez construire ou apprendre
Vous terminerez avec un verdict écrit pour un boîtier précis. Le verdict est une de trois lectures. Confirmé signifie qu’un nom de paquet que Google a publié comme partie de XCPE est présent sur votre boîtier. Suspect signifie que des signes plus faibles concordent, comme un nom de modèle sur la liste publiée plus un réglage de protection trouvé éteint. Aucune preuve trouvée signifie que chaque vérification est revenue propre, ce qui abaisse le soupçon et ne prouve jamais qu’un boîtier est sûr.
Les faits sur lesquels la vérification repose viennent du Google Threat Intelligence Group. La porte dérobée principale fonctionne comme x.cpe, ou comme com.oemservice dans certaines versions, au niveau de privilège android.uid.system, dans le micrologiciel. Un chargeur appelé com.abc.nexus exécutait les modules qui faisaient de l’argent pour les affiliés. Depuis août 2026, dit Google, de plus petits compte gouttes déguisés en applications système remplacent ce chargeur, avec des noms comme com.android.system.ntp et com.android.sso.auth.handler. Cinq noms de paquets. Ces noms sont le cœur de cette vérification.
Avant de commencer
Comprenez ce qu’un résultat propre peut dire et ne peut pas dire. Google dit que la conception a évolué sur des années et que les versions récentes ont éliminé le chargeur en faveur de compte gouttes construits pour des modules uniques. Un boîtier peut porter une variante que cette vérification ne nomme pas. L’absence des cinq noms de paquets est une preuve. Ce n’est pas un certificat.
Comprenez aussi la limite inverse. Synthient, l’entreprise qui a acheté un MECOOL KM9PRO Max et trouvé la porte dérobée dedans, a publié une liste de 182 noms de modèles vus dans la campagne et avertit dans son propre reportage qu’un nom de modèle correspondant seul ne confirme pas qu’un boîtier est infecté. Les noms de modèles sont partagés, réutilisés et imprimés vaguement sur du matériel bon marché. Traitez une correspondance de liste comme une raison de continuer de vérifier, jamais comme le verdict.
L’échelle derrière la vérification : Google a cartographié des boîtiers infectés dans plus de 200 pays. Image : Google
Deux notes de sécurité pour l’étape ADB. Le débogage réseau ouvre une porte dans le boîtier pour tout appareil sur votre réseau domestique, alors vous l’activerez pour une session et vous l’éteindrez de nouveau avant la fin de ce tutoriel. Acceptez une invite de débogage à la télévision seulement quand elle nomme votre propre ordinateur. Et sautez toute application de nettoyage ou d’antivirus offerte hors du Play Store. Cette vérification utilise seulement les outils que Google livre et les réglages déjà sur le boîtier.
Étape 1 : enregistrer l’identité exacte du boîtier
Action : avec la télécommande, ouvrez Settings et trouvez l’écran About. Sur la plupart des boîtiers Android TV, le chemin est Settings, puis Device Preferences, puis About. Sur les versions Google TV, le chemin est Settings, puis System, puis About. Notez trois valeurs exactement comme montrées : le nom du modèle, la version Android et le numéro de version. Les étiquettes de menu varient un peu selon la marque, alors suivez la forme du chemin si votre libellé diffère.
Action : retournez le boîtier et lisez l’étiquette imprimée. Notez la marque sur le devant, le code de modèle sur l’étiquette, le nom du fabricant s’il est imprimé et le numéro de série. Gardez le numéro de série dans vos notes privées et hors de toute publication publique. Notez aussi où et quand vous avez acheté le boîtier. Vous voudrez le nom du vendeur si le verdict va contre le boîtier.
Résultat attendu : vous tenez deux versions de l’identité du modèle, la version logicielle tirée de About et la version imprimée tirée de l’étiquette. Les deux comptent. Les listes publiées utilisent des chaînes de modèle sous plus d’une orthographe, alors un boîtier qui se signale comme KM9PRO Max dans About peut apparaître sur une liste comme KM9PRO_MAX. Gardez les deux orthographes dans vos notes et cherchez les deux à l’étape suivante.
Étape 2 : comparer le modèle aux listes publiées
Action : ouvrez le rapport Synthient, The Internals of a Badbox Operation, et trouvez sa liste de noms de modèles vus dans la campagne. Cherchez dans la page votre modèle sous chaque orthographe que vous avez enregistrée. La liste compte 182 noms. Les noms confirmés dans le reportage autour du démantèlement incluent KM9PRO_MAX, KM7PLUS et KD3, et beaucoup d’entrées sont des chaînes génériques comme 4K_Android_TV_Box, ce qui montre pourquoi cette étape peut seulement relever le soupçon et jamais le régler.
Action : notez la question du fabricant séparément de la question de la marque. Synthient lie la marque MECOOL à Videostrong, et Google dit que Videostrong a aussi construit des appareils que d’autres marques ont vendus comme les leurs. Un badge MECOOL relève les enjeux des étapes ultérieures. Un badge différent ne les abaisse pas, parce que le nom sur le devant pourrait ne pas être le nom de l’entreprise qui a construit le micrologiciel.
Action : comme contexte seulement, vérifiez si la marque apparaît sur la page des partenaires Google TV, liée dans Sources, et enregistrez la réponse. Google conseille aux acheteurs d’acheter des décodeurs seulement de fabricants réputés et pointe vers sa liste de partenaires Android TV. Gardez ce conseil à son juste poids. XCPE a été livré sur des appareils qui ont passé les vérifications de certification, selon Google, alors le statut de partenaire et la certification sont un contexte, pas un verdict.
Résultat attendu : une de deux lectures. Listé signifie que votre nom de modèle a été vu dans la campagne et que les vérifications de paquets ci dessous deviennent décisives. Non listé signifie que cette étape n’a rien trouvé, et les vérifications de paquets décident encore, parce que Google a trouvé le code dans beaucoup de modèles et de marques sur plusieurs années et qu’aucune liste publique n’est complète.
Étape 3 : chasser les cinq noms de paquets dans la liste des applications
Action : ouvrez Settings, puis Apps, puis la liste complète des applications. La plupart des versions l’étiquettent See all apps. Trouvez l’option pour montrer les applications système, habituellement dans un menu en haut de cette liste, et activez la. Sans cette option, la porte dérobée reste invisible, parce qu’elle fonctionne comme une application système et que la liste par défaut montre seulement les applications avec une présence de lanceur.
Action : faites défiler la liste complète lentement et cherchez ces cinq noms de paquets, exactement comme écrits :
x.cpe
com.oemservice
com.abc.nexus
com.android.system.ntp
com.android.sso.auth.handler
Action : lisez les noms d’affichage avec soin. Les deux derniers noms sur la liste sont des compte gouttes déguisés en applications système Android, selon Google, alors une étiquette fade qui sonne système ne prouve rien dans un sens ou dans l’autre. Jugez par nom de paquet, pas par le nom aimable à côté d’une icône. Un autre nom mérite une note. Google dit que la porte dérobée partageait sa configuration avec le logiciel du fabricant YokaTV Player. Une application YokaTV Player seule est une application de diffusion et ne prouve rien. Elle gagne une ligne dans vos notes seulement quand elle se trouve à côté d’une correspondance de paquet ci dessus.
Ce que les cinq noms sont : une porte dérobée dans le micrologiciel, un chargeur et des modules chargés pour les affiliés payants. Image : Google
Résultat attendu : une correspondance sur x.cpe ou com.oemservice est une correspondance sur les noms de la porte dérobée principale que Google a publiés. Une correspondance sur com.abc.nexus est une correspondance sur le chargeur. Une correspondance sur l’un ou l’autre nom de compte gouttes est un fort signal suspect que l’étape 5 peut confirmer par le chemin du paquet. Aucune correspondance signifie que la vérification à la télécommande n’a rien trouvé, et la vérification continue, parce que certaines versions cachent des paquets des listes d’applications du fournisseur.
Étape 4 : tester le réglage Play Protect que la porte dérobée éteint
Google décrit un acte concret de sabotage dans son rapport. La porte dérobée désactive la vérification des applications Google Play Protect en réglant la valeur globale package_verifier_user_consent à -1. Cette étape vérifie cet acte des deux bouts : l’interrupteur visible à la télévision, et la valeur brute elle même à l’étape 5.
Action : sur un boîtier qui exécute Android 11 ou plus, ouvrez l’application Play Store, ouvrez le menu, choisissez Play Protect et ouvrez ses Settings. Confirmez que Scan apps with Play Protect est activé, et que Improve harmful app detection est activé. Lancez ensuite un balayage depuis l’écran Play Protect et enregistrez le résultat. Sur un boîtier qui exécute Android 10 ou moins, ouvrez Settings, puis Apps, puis Security & restrictions, et confirmez que Verify apps est activé. Ce sont les chemins que Google publie dans sa propre page d’aide Play Protect pour Android TV.
Action : sur le même boîtier, ouvrez le Play Store, touchez l’icône de profil, ouvrez Settings, ouvrez About et lisez la ligne de certification Play Protect. Enregistrez si elle dit que l’appareil est certifié.
Résultat attendu : trois lectures comptent. Si Scan apps with Play Protect est éteint et que vous ne l’avez jamais éteint, cela correspond au sabotage que Google a décrit, et cela compte comme un signe suspect. Si la ligne de certification dit que l’appareil n’est pas certifié sur un boîtier vendu comme un boîtier Google TV certifié, c’est un deuxième signe d’avertissement au sujet du micrologiciel comme un tout. Si les deux réglages sont activés et que le balayage est propre, cette étape n’a rien trouvé. Un balayage propre ne remplace jamais une correspondance de paquet de l’étape 3. L’implant fonctionne au niveau système et a éteint la vérification au départ, selon Google, alors son propre balayage est le témoin le plus faible dans cette vérification.
Étape 5 : confirmer la liste des paquets par ADB
C’est la vérification la plus forte dans le tutoriel, parce qu’elle demande au système d’exploitation sa liste complète de paquets directement au lieu de faire confiance à une liste d’applications du fournisseur. Android Debug Bridge, habituellement raccourci en ADB, fait partie d’Android SDK Platform Tools de Google. Chaque commande ci dessous est une requête en lecture seule. Aucune ne change le boîtier.
Action : téléchargez SDK Platform Tools depuis la page des développeurs Android liée dans Sources et décompressez le sur votre ordinateur. Ouvrez un terminal dans le dossier platform-tools décompressé et confirmez que l’outil fonctionne :
adb version
Résultat attendu : l’outil affiche sa version. La version actuelle de Platform Tools est 37.0.1, de juillet 2026.
Action : activez le débogage sur le boîtier. Ouvrez Settings, puis Device Preferences, puis About, ou System, puis About sur les versions Google TV. Sélectionnez l’entrée Build, étiquetée Android TV OS build sur certaines versions, sept fois, jusqu’à ce que le boîtier dise que vous êtes maintenant un développeur. Retournez d’un écran, ouvrez Developer options et activez USB debugging et Network debugging. Certaines versions plus récentes nomment la voie sans fil Wireless debugging et montrent un code d’appariement et un port d’appariement à la place. Suivez ce que votre boîtier montre plutôt que de supposer une mise en page. Trouvez ensuite l’adresse du boîtier sous Settings, puis Network & Internet, puis votre réseau connecté, et notez l’adresse IP.
Action : connectez vous depuis l’ordinateur, en remplaçant l’adresse d’exemple par l’adresse de votre boîtier. Le port 5555 est le port fréquent de débogage réseau. Si votre boîtier a montré un port différent pendant l’appariement, utilisez le port qu’il a montré, et utilisez d’abord la commande adb pair vers laquelle il vous dirige.
adb connect 192.168.1.50:5555
adb devices
Résultat attendu : la télévision demande si elle doit permettre le débogage depuis cet ordinateur. Acceptez seulement si l’ordinateur est le vôtre. La deuxième commande liste votre boîtier avec le mot device à côté. Le mot unauthorized signifie que l’invite à la télévision n’a pas été acceptée.
Action : enregistrez l’identité du boîtier depuis le système lui même, et comparez la avec vos notes de l’étape 1 :
adb shell getprop ro.product.model
adb shell getprop ro.product.manufacturer
adb shell getprop ro.build.fingerprint
adb shell getprop ro.mecool.device
Résultat attendu : les trois premières commandes affichent le modèle, le fabricant et la version exacte du micrologiciel. La quatrième commande mérite une pause. Google signale que le code de la porte dérobée lit cette même propriété pour décider quel hôte de contrôle contacter, en utilisant un hôte fixe quand la propriété lit true. Une valeur de true signifie que le micrologiciel identifie le boîtier comme un appareil MECOOL quel que soit le badge sur le devant. C’est une lignée de fabricant, pas une preuve d’infection, et elle appartient dans vos notes à côté du résultat de l’étape 2.
Action : exécutez la chasse aux paquets. Sous macOS et Linux :
adb shell pm list packages | grep -E "x\.cpe|oemservice|abc\.nexus|system\.ntp|sso\.auth"
Sous Windows, dans l’invite de commandes, utilisez la même liste avec le filtre Windows :
adb shell pm list packages | findstr /I "oemservice nexus ntp auth cpe"
Le filtre Windows est plus large que le filtre macOS et Linux, alors jugez chaque ligne qu’il affiche par son nom de paquet complet par rapport aux cinq noms à l’étape 3 avant de la compter comme une correspondance.
Action : enregistrez la liste complète des paquets dans un fichier sur l’ordinateur avant de juger le résultat filtré, pour que votre registre survive à la session :
adb shell pm list packages -f > tv-packages.txt
Résultat attendu : le silence de la commande filtrée signifie qu’aucun des cinq noms de paquets n’est installé sous ces orthographes. Toute ligne affichée est une correspondance, et le fichier enregistré montre le chemin du fichier d’application à côté de chaque paquet, pour que vous puissiez voir si une correspondance vit dans un emplacement système. Pour une correspondance nommée, une requête de plus confirme où elle se trouve :
adb shell pm path com.oemservice
Exécutez la même commande avec x.cpe ou com.abc.nexus à la place du nom d’exemple quand un nom différent a correspondu. Un chemin affiché confirme que le paquet est vraiment installé. Aucun chemin signifie que ce paquet est absent.
Action : lisez la valeur du vérificateur que la porte dérobée sabote :
adb shell settings get global package_verifier_user_consent
Résultat attendu : une valeur de -1 signifie que le consentement à la vérification des applications a été refusé ou éteint, ce qui est exactement le changement que Google attribue à la porte dérobée. Une valeur de 1 signifie que le consentement est activé. Une réponse de null signifie que la valeur n’a jamais été écrite sur cette version, et l’état de l’interrupteur Play Protect de l’étape 4 est votre preuve pour cette vérification à la place.
Action : fermez la porte que vous avez ouverte. Sur le boîtier, ouvrez Developer options, éteignez Network debugging et USB debugging, et utilisez l’option de révocation des autorisations si votre version en offre une. Sur l’ordinateur, lancez adb disconnect puis adb kill-server.
Étape 6 : vérifier le routeur pour le trafic de contrôle
Cette étape est facultative, et c’est la seule étape où le silence est attendu même sur un boîtier coupable. Google a démantelé les domaines de contrôle fin octobre, alors une porte dérobée dormante peut ne passer aucun appel du tout. Traitez le trafic comme un témoin bonus, jamais comme le juge.
Action : connectez vous à votre page administrateur de routeur et trouvez ses journaux pour les requêtes DNS ou pour les connexions par appareil. Le libellé varie largement selon le fabricant, alors suivez la forme plutôt qu’un chemin fixe. Cherchez dans les journaux les deux familles de domaines que Google a publiées comme l’infrastructure de contrôle centrale pour XCPE :
szbboys.com
anyevonline.com
Google nomme mqtt.szbboys.com comme le seul hôte courtier qui portait le trafic de contrôle pour les échantillons qu’il a identifiés, sur les ports 3885 à 3887, et nomme les hôtes anyevonline.com comme la porte d’entrée d’enregistrement et de configuration. Si votre routeur montre des connexions sortantes depuis l’adresse du boîtier vers les ports 3885, 3886 ou 3887, enregistrez l’heure et la destination. La liste complète d’indicateurs dans le rapport Google est bien plus longue et couvre les modules affiliés. Cherchez y tout domaine que vos journaux font remonter avant de juger un résultat.
Résultat attendu : un résultat de journal sur l’une ou l’autre famille, lié à l’adresse du boîtier, est une forte preuve suspecte et appartient en haut de vos notes. Aucun résultat signifie seulement que le boîtier n’a passé aucun appel que vos journaux ont gardé pendant la fenêtre qu’ils couvrent. Le verdict repose sur les étapes 2 à 5.
Vérification
La vérification a fonctionné quand vous pouvez placer votre boîtier dans exactement une rangée de ce tableau avec vos propres notes. Lisez les rangées depuis le haut. La première rangée à laquelle votre preuve convient est votre verdict.
| Preuve tirée de vos notes | Verdict |
|---|---|
x.cpe ou com.oemservice trouvé à l’étape 3 ou à l’étape 5 | Correspondance confirmée sur la porte dérobée principale. Traitez le boîtier comme compromis. |
com.abc.nexus, com.android.system.ntp ou com.android.sso.auth.handler trouvé, et aucun nom principal | Fort suspect. Ce sont les noms de chargeur et de compte gouttes que Google a publiés. Traitez le boîtier comme compromis à moins que le fabricant les documente par écrit, ce qu’aucun fabricant n’a fait dans le reportage public. |
Modèle sur la liste Synthient, plus balayage Play Protect trouvé éteint, ou valeur du vérificateur qui lit -1 | Suspect. Deux signes faibles concordent. Traitez le boîtier comme compromis s’il traite des comptes qui comptent pour vous. |
| Modèle sur la liste Synthient seulement | Non prouvé. Un nom de modèle seul ne confirme pas l’infection, selon Synthient. Décidez par risque. Un boîtier qui joue seulement des fichiers locaux sur un poste de rechange est un risque différent du boîtier principal connecté à des comptes payants. |
| Aucune correspondance de paquet, vérificateur normal, modèle non listé | Aucune preuve trouvée. Le soupçon est bas et jamais zéro, parce que la conception a évolué et que les nouveaux compte gouttes varient. Gardez Play Protect activé et répétez cette vérification après toute mise à jour du micrologiciel. |
Agissez sur un verdict confirmé ou suspect dans cet ordre :
- Retirez le boîtier du réseau. Tirez le câble réseau ou éteignez le boîtier, et laissez le hors du réseau domestique pendant que vous parcourez le reste de cette liste.
- Depuis un appareil propre, changez les mots de passe pour chaque compte qui était connecté sur le boîtier, en commençant par le compte Google et tout compte de diffusion avec des détails de paiement joints. Google a observé des opérateurs qui recueillaient des informations de compte, capturaient l’écran et injectaient des frappes, alors traitez tout ce qui a été tapé sur le boîtier comme vu.
- Vérifiez ces comptes pour des connexions et des achats que vous ne reconnaissez pas, depuis le même appareil propre.
- Écrivez au vendeur et au fabricant avec votre registre de l’étape 1, votre preuve de paquet et une demande de micrologiciel propre ou de remboursement. Au 3 novembre, aucun rappel et aucun programme de micrologiciel propre n’apparaît dans les rapports publics de Google, Synthient ou TrendAI, alors une trace écrite est votre levier.
- Retirez le boîtier si aucun micrologiciel propre n’arrive. Synthient recommande que les appareils touchés soient jetés de façon permanente, parce qu’un boîtier avec une porte dérobée peut en porter davantage. Ne le vendez pas et ne le passez pas. Amenez le à un point de recyclage électronique local quand vous le remplacerez.
Dépannage
| Problème | Cause probable | Correctif |
|---|---|---|
| La liste des applications n’a aucune option pour montrer les applications système | La version du fournisseur cache l’interrupteur ou le place sous une étiquette différente | Sautez à l’étape 5. La liste de paquets ADB inclut les paquets système sans aucun interrupteur. |
| L’écran About ne montre aucune entrée Build à sélectionner | Le boîtier utilise une coquille de réglages du fournisseur avec une mise en page différente | Cherchez sous Device Preferences, puis About, ou System, puis About. S’il n’existe aucune entrée de version du tout, le fabricant n’expose aucune voie de débogage utilisateur, et les étapes 1 à 4 sont toute votre vérification. |
adb connect est refusé ou expire | Le débogage réseau est éteint, l’adresse est fausse ou l’ordinateur se trouve sur un réseau différent | Confirmez l’adresse sur le boîtier, mettez les deux appareils sur le même réseau domestique et acceptez l’invite à la télévision. Une connexion USB filaire fonctionne sur les boîtiers avec un port de service. |
adb devices liste le boîtier comme unauthorized | L’invite d’autorisation à la télévision a été manquée ou refusée | Déconnectez, connectez de nouveau et acceptez l’invite, en autorisant seulement votre propre ordinateur. |
| La commande de paquet filtrée n’affiche rien et vous attendiez une correspondance | La version utilise un nom de variante, ou la lecture précédente de la liste des applications était un nom d’affichage et non un nom de paquet | Cherchez dans votre liste complète enregistrée de l’étape 5 les courtes chaînes oem, nexus et cpe, et jugez tout résultat par son nom de paquet complet par rapport aux cinq noms à l’étape 3. |
| Le balayage Play Protect ne signale aucune application nuisible sur un boîtier avec une correspondance de paquet | La porte dérobée est un préchargement système et elle a désactivé la vérification au départ, selon Google | La correspondance de paquet surclasse le balayage. Suivez les actions de verdict ci dessus. |
La commande du vérificateur retourne null | Cette version n’a jamais écrit la valeur | Fiez vous à l’état de l’interrupteur que vous avez enregistré à l’étape 4 et notez le résultat null dans votre registre. |
| Les journaux du routeur ne montrent aucun domaine de contrôle | Les serveurs de contrôle ont été démantelés fin octobre, ou le routeur garde seulement une courte fenêtre de journal | Le silence est attendu même sur un boîtier coupable. Faites reposer le verdict sur les étapes 2 à 5. |
| Le boîtier n’a aucun Play Store du tout | Le boîtier exécute une version fondée sur l’Android Open Source Project sans applications Google | L’étape 4 et la lecture de certification ne s’appliquent pas. La vérification du modèle et la chasse aux paquets ADB sont votre vérification, et un boîtier sans Play Protect n’a aucun filet de sécurité à restaurer. |
Prochaines étapes
Faites de la vérification une habitude avec une courte queue. Répétez les étapes 3 à 5 après toute mise à jour du micrologiciel, puisqu’une mise à jour change la liste de paquets à laquelle vous faites confiance. Gardez le fichier de paquets enregistré de votre première vérification propre, si vous en avez eu une, et comparez les listes ultérieures à lui. Les nouveaux noms de paquets qui apparaissent après une mise à jour méritent le même examen que les cinq noms dans ce tutoriel.
Si vous achetez un remplacement, achetez le comme Google le conseille. Choisissez un fabricant réputé, confirmez la marque sur la liste des partenaires, vérifiez la ligne de certification Play Protect en boutique ou le jour où le boîtier arrive et exécutez cette vérification sur le nouveau boîtier avant de vous connecter à quoi que ce soit. Un boîtier bon marché est un ordinateur qui vit sur votre réseau domestique avec votre adresse sur son trafic. La vérification prend quarante minutes. Exécutez la avant que le boîtier gagne vos mots de passe.
Noms de paquets, valeur du vérificateur, hôtes de contrôle et comportement de persistance vérifiés par rapport au rapport du Google Threat Intelligence Group sur le démantèlement XCPE, à l’enquête Synthient et à la page d’aide Google Play Protect pour Android TV, novembre 2026. Les chemins de menu ont été vérifiés par rapport à ces documents et par rapport aux mises en page de réglages Android TV publiées. Cette vérification a été vérifiée par rapport aux documents. Elle n’a pas été exécutée sur un boîtier physique dans ce passage, alors utilisez le tableau de vérification sur votre propre matériel pour confirmer chaque lecture.
Sources
- Google Threat Intelligence Group, Shutting the Door on the XCPE Botnet, November 2, 2026. Primary source for the five package names, the system privilege level, the
/oem/partition persistence, the verifier value the backdoor sets, the control hosts and ports, and the statement that a system preload cannot be removed by the user. Both body images are from this report and are credited to Google. - Synthient, The Internals of a Badbox Operation, November 2026. Source for the MECOOL KM9PRO Max examination, the link between MECOOL and Videostrong, the list of 182 model names seen in the campaign, the warning that a model name alone does not confirm infection, and the recommendation that affected devices be disposed of permanently.
- Google Support, Protect your TV from harmful apps with Google Play Protect. Source for the Play Protect paths on Android TV, split between Android 11 and up and Android 10 and lower.
- Android Developers, SDK Platform Tools release notes. Source for the Platform Tools download and the 37.0.1 release line used in Step 5.
- BleepingComputer, Google disrupts million device XCPE Android malware botnet, bans TV box maker, November 2, 2026. Reporting on the Synthient investigation and the takedown, used to cross check the model list reporting and the partner positions on removal.
- Google TV, Our global partners. The partner list Google points buyers to, used as context in Step 2.
- Hero image: Dirty Static, generated in house style
FIN DE LA TRANSMISSION
Restez curieux. Remettez tout en question.
