# Is your TV box, or your car's head unit, safe? XCPE and the backdoor that outlives the takedown > In its November 2026 report, Google says XCPE enrolled more than 1.3 million set-top boxes. The takedown left implants on sold devices. Source: https://sheng.page/en/posts/xcpe-preloaded-backdoor-tv-boxes-and-car-head-units/ · Published: 2026-11-04 · Author: Sheng The XCPE takedown cut the operator off from the boxes, but left the backdoor on devices people had already bought. [TrendAI](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices) says removing the servers stopped the operator reaching the devices, while the backdoor remained in boxes already sold. [Google](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) says XCPE enrolled more than 1.3 million set-top boxes, with Videostrong selling access to criminal affiliates and loading their modules for residential proxies and advertising fraud. A residential proxy uses a household device's address to relay traffic, making a connection appear to come from elsewhere, as the [FBI explains](https://www.fbi.gov/investigate/cyber/alerts/2026/evading-residential-proxy-networks-protecting-your-devices-from-becoming-a-tool-for-criminals). For car head units, the evidence is limited to an infotainment category in BADBOX 2.0 reporting and the DoFun case, where malware spread through an updater. Neither establishes that those head units joined XCPE. Sources for this post were checked to 08:31 Taipei time on 4 November 2026. ## What the dates tell us None of the dates in these reports tells an owner when their box became infected. Sample records and architectural changes describe the malware itself; researchers also record when they obtained a device or observed traffic, and when they published their findings. [Synthient's indicator README](https://github.com/synthient/public-research/blob/main/2026/11/Videostrong/README.md) gives one `x.cpe` version 3.6.5 sample a first-seen date of 14 December 2020. [Plume's reconstructed version history](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) places versions 3.4.0 to 3.8.5 at about 2021; the difference is unexplained. [Google's](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) “since at least late 2024” instead dates the evolution towards a modular three-stage architecture. [Synthient](https://synthient.com/blog/the-internals-of-a-badbox-operation) bought its MECOOL KM9PRO Max in late 2025. The observation windows also vary: [Plume's](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) broker snapshot is from 8 September 2026, while [TrendAI's](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices) telemetry spans 3 June to 1 October 2026; neither dates the start of the operation. The unit's [specification](https://github.com/synthient/public-research/blob/main/2026/11/Videostrong/README.md) gives 11 April 2025 as the build date for firmware `C1.0.8_20250325`, with a security patch dated 5 February 2025. These dates describe the software on the purchased unit and cannot tell us when it was analysed. [Plume](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) began with suspicious MQTT traffic in home-router telemetry, then examined more than 150 factory firmware images and 100 additional samples, so these numbers count research materials rather than affected devices. Both [Synthient](https://synthient.com/blog/the-internals-of-a-badbox-operation) and [TrendAI](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices) published on 2 November 2026. [Google's page](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) has shown 2 November 2026 and 3 November 2026, and the difference is unexplained. No publication date is given on [Plume's PDF](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf), so the `10-2026` in the filename cannot establish when it was published. On the infrastructure action, Google and TrendAI say only "last week", and do not give a day. ## A backdoor in the firmware Uninstalling XCPE may only remove it until the next reboot, because the backdoor shipped with the firmware. [Google](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) describes a system-partition implant using `android.uid.system`, reinstalling from `/oem/` on reboot; [TrendAI](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices) describes a system app signed with the manufacturer's key. Google calls it `x.cpe`, running as `com.oemservice` in some builds, while [Plume](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) uses `X.CPE`. These names alone do not establish that all the samples are the same package under different names. [Google](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) records `BootReceiver` restoring the package after removal from `/data/app/`. The Nexus 1.7.88 sample analysed by [Plume](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) could install other applications without further confirmation; it could also update or remove them without asking. Services could therefore run on the box without its owner having agreed to them. [Google](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) describes how the malware first fetches its configuration over HTTP, then keeps an MQTT connection open; identified samples used a single broker hostname. It can silently install applications or disable Play Protect, as well as execute a shell and capture the screen. Researchers saw screenshots being taken and keystrokes injected; they also observed theft of account and device information, and reverse shells. Most interactions concerned module installation and removal, along with changes to module settings. [Google](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) also observed advertising-fraud modules and saw Spirit load further modules, as well as Moyu being initialised. A single device had up to three residential-proxy SDKs. That does not mean every box ran every module: [TrendAI](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices) reports scheduled deployment to about 1.33 million devices, while one [Plume](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) configuration had only `linkfog` enabled. [TrendAI](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices) observed devices joining commercial bandwidth-sharing programs without a consent screen and generating fraudulent advertising impressions. It also found a script disabling Play Protect on many devices. The researchers could see how access was being monetised, but did not observe a specific buyer for the fleet's proxy capacity. Modules could connect independently of the main control channel: [Plume](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) describes Linkfog's channel as independent of MQTT, appearing at home as another outbound connection resembling a video stream. That description tells us nothing about how many devices remained accessible after the takedown. Plume dates the move of monetisation out of the main package to November 2024; [Google](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) places the introduction of `com.abc.nexus` in late 2024. The reports suggest the change may have been intended to avoid an audit or respond to BadBox enforcement, without establishing either motive. ## What the counts measure The three headline counts cannot be added together: they cover different populations and periods, and none measures how many devices are online now. [Google's](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) more than 1.3 million is a count of enrolled set-top boxes, and the post gives no reporting window. [TrendAI's](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices) 1,472,554 counts infected devices observed from 3 June to 1 October 2026, across 206 models and more than 170 countries. These figures are lower bounds and cover both TV boxes and projectors. The partners jointly used "more than 1.3 million", since their visibility and snapshots differed. The 3,849,226 in the table counts IP addresses, and it cannot be read as a device count. [Google's](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) at least 10 million is an assessment of additional compromised devices: affiliates distribute modules through channels beyond XCPE, and removing their infrastructure “will sever” access. That assessment does not make them XCPE boxes, nor does it establish that they have been cleaned. [Plume's](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) 424,108 counts cluster sessions, while 26,477 counts live connections on another broker on 8 September 2026; its estimate of over 1.3 million unique devices is separate. [Synthient's](https://synthient.com/blog/the-internals-of-a-badbox-operation) roughly half a million online or communicating daily is also an estimate, without a reproducible method. ## A gap in the tests Google acknowledges that its certification tests missed the malware, but has not explained which test failed. Its [report](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) says Videostrong used obfuscation to exploit “a gap in our tests” and load malicious code after first boot. Google says it changed the review process; it does not say that the image submitted for testing differed from the production image. [Google's measures](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) prohibit Videostrong and future subsidiaries or affiliates from building and selling certified Android devices or supplying software to certified vendors. The firmware-integrity improvements Google says it is implementing do not provide a repair image for devices already sold. Certification alone cannot tell you whether a particular box is infected. [Google requires](https://www.android.com/certified/) certified devices to ship without pre-installed malware, while its [support page](https://support.google.com/android/answer/7165974?hl=en) distinguishes certification from Play Protect scanning. A certified device may still be infected later, while a device without certification is not necessarily infected. [Plume](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) describes a mixed AOSP and Google-certified fleet, without a complete certification list for affected models. There is therefore no basis for treating all 1.3 million boxes as certified. Certification still matters when buying or maintaining a device. [Google's support guidance](https://support.google.com/android/answer/7165974?hl=en) warns that uncertified devices may be insecure or miss system and app updates, and that their Google apps are unlicensed. Its [certification page](https://www.android.com/certified/) adds that basic security features have not been ensured and Google apps may not work as intended. These are reasons to consider certification when choosing or maintaining a device, though they do not prove that a particular unit is infected. ## Attribution and company roles Google's attribution of the backdoor to Videostrong is made with high confidence, and the XCPE reports provide no judicial finding against the company. [Google assesses](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) that the company deliberately developed the backdoor for profit and was responsible for deploying and operating it, ruling out a rogue insider or development oversight as an explanation. [Synthient](https://synthient.com/blog/the-internals-of-a-badbox-operation) also assesses Videostrong as the operator with high confidence, citing signing email addresses, overlapping infrastructure and a document found in a public directory. Google does not identify the court behind its legal action, or supply a case number or complaint. The companies named in these reports had different roles, and a name on the hardware or a software signature does not establish who operated the backdoor. The backdoor on [Synthient's](https://synthient.com/blog/the-internals-of-a-badbox-operation) MECOOL sample was signed by Skyworth Digital Technology; the unit's [manufacturer field](https://github.com/synthient/public-research/blob/main/2026/11/Videostrong/README.md) says SkyworthDigital. [Plume](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) identifies Videostrong as a firmware and management-platform supplier, with Nexus using its platform certificate and loading third-party libraries. Skyworth's role remains unresolved; the details above do not make every company involved an operator. A matching model name is only a starting point, as [Synthient's README](https://github.com/synthient/public-research/blob/main/2026/11/Videostrong/README.md) explicitly cautions: infection must be checked against indicators on the individual device. [Videostrong's homepage](https://www.videostrong.com/) and [first company-news page](https://www.videostrong.com/news-Videostrong-Company-News) showed no statement on the case as of 4 November 2026. The [README's](https://github.com/synthient/public-research/blob/main/2026/11/Videostrong/README.md) observed strings include `KM9PRO`, `KM9PRO_MAX`, `KM6`, `STV-3000_Plus` and `PRO-M2`. Those model strings were observed in the operation; their presence on another box does not establish infection. The published indicators include file hashes and certificate fingerprints as well as network and SDK identifiers. ## The link to BADBOX XCPE has links to BADBOX through particular modules, but the reports do not establish that the two share an operator. [Google](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) connects Moyu and Bird to the earlier BadBox enterprise; [TrendAI](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices) also cites Kaspersky's link between `com.abc.nexus` and IPMoyu. The figures from earlier BADBOX operations describe separate investigations. [HUMAN](https://www.humansecurity.com/learn/blog/trojans-all-the-way-down-badbox-and-peachpit/) reported over 74,000 devices showing BADBOX infection signs. [BSI's](https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2024/241212_Badbox_Sinkholing.html) diversion of communications for up to 30,000 devices in Germany on 12 December 2024 did not establish removal. For BADBOX 2.0, [HUMAN](https://www.humansecurity.com/satori-threat-intelligence-disruption-badbox-2-0/) estimated more than 1 million devices as of January 2025; [Google's 17 July 2025 post](https://blog.google/innovation-and-ai/technology/safety-security/google-taking-legal-action-against-the-badbox-20-botnet/) reported over 10 million uncertified AOSP devices. These counts cannot be added to XCPE's, and the description of an entirely uncertified fleet does not fit XCPE's mix of devices. The BADBOX 2.0 civil case, Southern District of New York 1:25-cv-04503, names Does 1-25 as defendants. The [18 September 2025 default judgment](https://docs.justia.com/cases/federal/district-courts/new-york/nysdce/1:2025cv04503/643466/41) finds them liable under the CFAA and RICO and grants a permanent injunction, but does not name Videostrong. ## What is known about head units For head units, the reports name a category of devices and describe the DoFun updater case in detail. [HUMAN](https://www.humansecurity.com/company/satori-threat-intelligence/badbox-2-0/) and the [FBI's 5 June 2025 alert](https://www.fbi.gov/investigate/cyber/alerts/2025/home-internet-connected-devices-facilitate-criminal-activity) list aftermarket vehicle infotainment systems under BADBOX 2.0, without naming any head-unit brands or models. They give no count of affected head units. The FBI describes infection before purchase or through required applications downloaded during setup. In the DoFun case, malware spread through built-in updaters, which [Securelist](https://securelist.com/android-head-unit-malware/121106/) found in June 2026 and described in research published on 21 August 2026. The updaters were part of Android head-unit firmware, and the malware was used for advertising fraud and a proxy botnet. Kaspersky attributes it with high confidence to the BADBOX-linked MoYu Group, and the vendor reported fixing the issues. The articles do not classify affected DoFun units as aftermarket or factory equipment, and they give no infection count. The [companion blog's](https://www.kaspersky.com/blog/car-botnet-malware-for-head-units-with-android/56296/) more than 30 million vehicle owners is a figure DoFun's website gives for its reach. The claimed customer base gives no measure of how many head units were infected. [Securelist's account](https://securelist.com/android-head-unit-malware/121106/) describes installation through an updater after the units were in use, without calling the malware pre-installed. Evidence about a television box's factory firmware cannot establish how a head unit was infected or which units were affected. [Plume](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) links to that research and says the same Nexus package appeared in the head-unit campaign. A shared package does not establish membership of the XCPE botnet. [Google's XCPE victim list](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) chiefly describes Android TV boxes, and also mentions telehealth devices and karaoke machines, as well as digital signage; it does not include head units. These reports provide no evidence of affected factory Android Automotive systems or Google built-in cars. [Android's documentation](https://source.android.com/docs/automotive/start/what_automotive) describes Android Automotive as open source and Google Automotive Services as optional licensed services; the [developer overview](https://developer.android.com/training/cars/platforms/automotive-os) says Google built-in cars run Android Automotive OS. Those platform relationships do not determine any head unit's infection or certification status. ## What an owner can do If a device matches the indicators, or there are concrete reasons to suspect it, disconnect it and stop using it. Look for a fix from a trusted source that applies to that device and has evidence behind it; if you cannot confirm it works, replace the device. [TrendAI](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices) says cleanup requires action by the vendor or protection from the platform, with replacement as another option; [Synthient](https://synthient.com/blog/the-internals-of-a-badbox-operation) advises unplugging suspicious devices. Google and TrendAI provide no verifiable clean firmware for sold units. A matching model name still needs an [indicator check](https://github.com/synthient/public-research/blob/main/2026/11/Videostrong/README.md). Disconnecting stops the device's network activity while leaving the firmware in place. [Plume](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) recommends a factory reset but also describes `dw1` as preserving device identity across one, without verifying that a reset removes X.CPE. The reports establish neither that 1.3 million devices remain controlled nor that they are clean. [Plume's](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf) reason for recommending a reset is that modules may have installed further backdoors. [Synthient](https://synthient.com/blog/the-internals-of-a-badbox-operation) suggests changing Wi-Fi passwords and updating router and device firmware to reduce reinfection risk. Neither report shows that these steps were tested and removed the implant from an affected unit. To check certification, open the Play Store, tap the profile icon and go to Settings, then About, following [Google's support page](https://support.google.com/android/answer/7165974?hl=en). If it shows “Device is not certified”, consult the [certified-device list](https://storage.googleapis.com/play_public/supported_devices.html). [Google](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) recommends buying from reputable manufacturers and keeping Play Protect on, with particular caution around apps that pay for shared bandwidth. [TrendAI](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices) also treats unmanaged devices in remote workers' homes as organisational exposure, and warns online services against relying on IP reputation alone. Retailers can require their suppliers to address these risks. [Google](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) recommends independent security audits from ODMs and delisting manufacturers implicated in this abuse. [TrendAI](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices) calls for certified firmware from white-label suppliers and managed endpoints for corporate access from homes. ## What remains unknown The [XCPE report](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/) does not identify affected batches or factory dates, and provides neither a complete model-to-certification list nor legal papers. [Synthient's evidence](https://synthient.com/blog/the-internals-of-a-badbox-operation) does not settle Skyworth's role, and the [Videostrong pages checked here](https://www.videostrong.com/) offer no response. The reports checked here still provide no evidence of verified repairs or successful cleanup counts for existing units. The outcome for the additional 10 million devices also needs supporting evidence. ## Notes - The takedown cut infrastructure access while leaving implants on sold boxes; the reports provide no verified clean firmware. - More than 1.3 million, 1,472,554 and at least 10 million measure different populations; 3,849,226 counts IP addresses. - Google's high-confidence attribution is a research assessment; the BADBOX 2.0 default judgment does not name Videostrong. - BADBOX links reach named modules, without establishing a shared operator or an identical certification profile. - Head-unit evidence covers the BADBOX 2.0 category and DoFun case; the Nexus link does not establish XCPE membership or factory Android Automotive victims. - A matching model name does not prove infection, and disconnecting does not prove removal. ## Further reading - [Google Threat Intelligence, XCPE](https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet/): primary investigation, with an unresolved 2 November 2026 / 3 November 2026 date discrepancy. - [TrendAI, 2 November 2026](https://www.trendaisecurity.com/en-us/resources-insights/trendai-security-blog/trendaitm-research-helps-disrupt-android-tv-botnet-of-more-than-13-million-pre-infected-devices): partner telemetry and takedown account. - [Synthient, 2 November 2026](https://synthient.com/blog/the-internals-of-a-badbox-operation): device analysis and attribution. - [Synthient indicator README](https://github.com/synthient/public-research/blob/main/2026/11/Videostrong/README.md): sample and certificate data with cautions about model names, 2 November 2026. - [Plume white paper](https://cdn.plume.com/3d/92/f7c576bd4afabd79df4e7b39ca7f/xcpe-botnet-whitepaper-10-2026.pdf): undated technical analysis on a public CDN with an NDA notice. - [Videostrong homepage](https://www.videostrong.com/) and [company news, page 1](https://www.videostrong.com/news-Videostrong-Company-News): company pages with no statement on the case as of 4 November 2026. - [HUMAN, The BADBOX 2.0 Operation](https://www.humansecurity.com/company/satori-threat-intelligence/badbox-2-0/): undated device-category overview. - [HUMAN, BADBOX 2.0 disruption](https://www.humansecurity.com/satori-threat-intelligence-disruption-badbox-2-0/): investigation dated 5 March 2025, updated 6 June 2025. - [HUMAN, BADBOX and PEACHPIT](https://www.humansecurity.com/learn/blog/trojans-all-the-way-down-badbox-and-peachpit/): original investigation, with a disputed header date. - [FBI PSA, 5 June 2025](https://www.fbi.gov/investigate/cyber/alerts/2025/home-internet-connected-devices-facilitate-criminal-activity): official device-category and infection-route alert. - [IC3 copy](https://www.ic3.gov/PSA/2025/PSA250605): official copy of I-060525-PSA. - [BSI, 12 December 2024](https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2024/241212_Badbox_Sinkholing.html): German communications-diversion notice. - [Google, 17 July 2025](https://blog.google/innovation-and-ai/technology/safety-security/google-taking-legal-action-against-the-badbox-20-botnet/): plaintiff's account of BADBOX 2.0 legal action. - [CourtListener docket](https://www.courtlistener.com/docket/70683171/google-llc-v-does-1-25/): court docket index, unavailable with a 403 response when consulted, leaving later developments unconfirmed. - [Default judgment, document 41](https://docs.justia.com/cases/federal/district-courts/new-york/nysdce/1:2025cv04503/643466/41): 18 September 2025 findings against Does 1-25. - [Securelist, 21 August 2026](https://securelist.com/android-head-unit-malware/121106/): DoFun updater-chain research; this post does not validate individual indicators. - [Kaspersky blog, 21 August 2026](https://www.kaspersky.com/blog/car-botnet-malware-for-head-units-with-android/56296/): companion account of the DoFun case. - [What is Android Automotive?](https://source.android.com/docs/automotive/start/what_automotive): platform and optional GAS licensing documentation. - [Android Automotive OS overview](https://developer.android.com/training/cars/platforms/automotive-os): Google built-in platform documentation. - [Play Protect certified devices](https://www.android.com/certified/): undated certification requirements and [partner list](https://www.android.com/certified/partners/). - [Check certification status](https://support.google.com/android/answer/7165974?hl=en): official instructions distinguishing certification from Play Protect. - [FBI PSA, 12 March 2026](https://www.fbi.gov/investigate/cyber/alerts/2026/evading-residential-proxy-networks-protecting-your-devices-from-becoming-a-tool-for-criminals): residential-proxy explanation, I-031226-PSA. > Ideas and technical judgement by Sheng; drafted with Claude · Topic chosen by Sheng; fact check by Grok (grok-4.7), outline by Claude Fable, text by Grok (grok-4.7), de-AI pass and second review by Codex (gpt-6-astra); sources checked to 08:31 Taipei on 4 November 2026.