Is your TV box, or your car's head unit, safe? XCPE and the backdoor that outlives the takedown

The XCPE takedown cut the operator off from the boxes, but left the backdoor on devices people had already bought.

TrendAI says removing the servers stopped the operator reaching the devices, while the backdoor remained in boxes already sold. Google 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.

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 gives one x.cpe version 3.6.5 sample a first-seen date of 14 December 2020. Plume’s reconstructed version history places versions 3.4.0 to 3.8.5 at about 2021; the difference is unexplained. Google’s “since at least late 2024” instead dates the evolution towards a modular three-stage architecture.

Synthient bought its MECOOL KM9PRO Max in late 2025. The observation windows also vary: Plume’s broker snapshot is from 8 September 2026, while TrendAI’s telemetry spans 3 June to 1 October 2026; neither dates the start of the operation.

The unit’s specification 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 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 and TrendAI published on 2 November 2026. Google’s page has shown 2 November 2026 and 3 November 2026, and the difference is unexplained. No publication date is given on Plume’s 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 describes a system-partition implant using android.uid.system, reinstalling from /oem/ on reboot; TrendAI describes a system app signed with the manufacturer’s key. Google calls it x.cpe, running as com.oemservice in some builds, while Plume uses X.CPE. These names alone do not establish that all the samples are the same package under different names.

Google records BootReceiver restoring the package after removal from /data/app/. The Nexus 1.7.88 sample analysed by Plume 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 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 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 reports scheduled deployment to about 1.33 million devices, while one Plume configuration had only linkfog enabled.

TrendAI 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 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 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 more than 1.3 million is a count of enrolled set-top boxes, and the post gives no reporting window. TrendAI’s 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 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 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 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 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 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 certified devices to ship without pre-installed malware, while its support page distinguishes certification from Play Protect scanning. A certified device may still be infected later, while a device without certification is not necessarily infected. Plume 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 warns that uncertified devices may be insecure or miss system and app updates, and that their Google apps are unlicensed. Its certification page 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 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 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 MECOOL sample was signed by Skyworth Digital Technology; the unit’s manufacturer field says SkyworthDigital. Plume 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 explicitly cautions: infection must be checked against indicators on the individual device. Videostrong’s homepage and first company-news page showed no statement on the case as of 4 November 2026.

The README’s 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 connects Moyu and Bird to the earlier BadBox enterprise; TrendAI also cites Kaspersky’s link between com.abc.nexus and IPMoyu.

The figures from earlier BADBOX operations describe separate investigations. HUMAN reported over 74,000 devices showing BADBOX infection signs. BSI’s diversion of communications for up to 30,000 devices in Germany on 12 December 2024 did not establish removal. For BADBOX 2.0, HUMAN estimated more than 1 million devices as of January 2025; Google’s 17 July 2025 post 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 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 and the FBI’s 5 June 2025 alert 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 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 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 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 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 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 describes Android Automotive as open source and Google Automotive Services as optional licensed services; the developer overview 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 says cleanup requires action by the vendor or protection from the platform, with replacement as another option; Synthient advises unplugging suspicious devices. Google and TrendAI provide no verifiable clean firmware for sold units. A matching model name still needs an indicator check.

Disconnecting stops the device’s network activity while leaving the firmware in place. Plume 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 reason for recommending a reset is that modules may have installed further backdoors. Synthient 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. If it shows “Device is not certified”, consult the certified-device list. Google recommends buying from reputable manufacturers and keeping Play Protect on, with particular caution around apps that pay for shared bandwidth. TrendAI 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 recommends independent security audits from ODMs and delisting manufacturers implicated in this abuse. TrendAI calls for certified firmware from white-label suppliers and managed endpoints for corporate access from homes.

What remains unknown

The XCPE report does not identify affected batches or factory dates, and provides neither a complete model-to-certification list nor legal papers. Synthient’s evidence does not settle Skyworth’s role, and the Videostrong pages checked here 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.