XCPE Botnet: Inside Videostrong’s Android Firmware Backdoor

Most threat models assume the attacker sits outside the supply chain: an unpatched parser exposed to the network, a credential stolen through phishing, a trojanized app someone side-loaded. None of that holds when the company that writes the board support package and signs the system image also runs the command-and-control server.

That is the situation Google Threat Intelligence Group (GTIG) described in its XCPE disclosure. Working with Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient, and TrendAI, GTIG dismantled the infrastructure behind a botnet of more than 1.3 million Android devices in over 170 countries. The takedown ran in late October 2026 and was announced on November 2. XCPE needed no social engineering and no software vulnerability. It was built into the firmware of television set-top boxes, projectors, telehealth terminals, karaoke machines, and digital signage units before they left the factory.

Google names Videostrong as the operator behind XCPE

Earlier investigations into pre-installed Android malware usually ended in a grey market of third-party firmware customizers, downstream resellers, and unnamed middlemen along the Shenzhen electronics supply chain. This time Google named the hardware manufacturer itself. GTIG assessed with high confidence that Videostrong Technology Co., Ltd., a Shenzhen-based original equipment manufacturer (OEM) and original design manufacturer (ODM), developed, deployed, and operated the XCPE backdoor and its botnet for financial gain.

Google’s findings rule out a rogue insider and a debug build left behind by accident. They describe a multi-year revenue model. Videostrong manufactured millions of low-cost connected devices, embedded a privileged implant in their read-only partitions, got past pre-release certification checks, and rented the resulting residential bandwidth and compute capacity to criminal affiliates.

How big is the XCPE botnet?

Google’s baseline figure is more than 1.3 million enrolled devices. TrendAI’s telemetry between June 3 and October 1, 2026 counted 1,472,554 distinct infected devices across 206 hardware models. Over those four months the botnet cycled through more than 3.8 million unique residential and mobile IP addresses and routed more than 2.3 billion control messages between compromised living rooms and operator servers. On an average day about 180,000 household IP addresses were available for rent as residential proxy exit nodes, and availability peaked near 370,000.

Synthient’s independent tracking shows roughly 500,000 infected devices online at any given time. They concentrate in Malaysia, Mexico, and Brazil, with tens of thousands of active nodes in the United States, Germany, and the United Kingdom on consumer broadband networks such as Comcast, Charter, AT&T, Virgin Media, and Vodafone.

Cutting the command-and-control servers does not clean the hardware, and the reason lies in how Android partitions are laid out, how system privileges are assigned at boot, and how Videostrong reworked its implant over two years to stay ahead of platform defenses.

How the XCPE backdoor survives reboots and factory resets

On a standard Android install, apps a user downloads live in /data/app/ and run in isolated Linux sandboxes with unique, unprivileged user IDs. Even if a user grants an app invasive permissions, the operating system stops it from silently installing other packages, changing global security flags, or surviving a factory reset. A manufacturer that controls the build environment removes every one of those limits.

The /oem/ partition and android.uid.system

The core of XCPE is a backdoor package named x.cpe, which appears in some firmware builds as com.oemservice (observed builds report version strings such as 6.8.3). Videostrong did not ship it as a normal user-space app. The company placed the stub inside the firmware’s /oem/ partition and preloaded it into the system area. Android uses /oem/ for manufacturer customizations and regional configuration that sit apart from the core AOSP /system/ image, and it stays read-only at runtime.

The manufacturer or its upstream board partner compiles and signs the firmware image, so the package receives the shared user ID android.uid.system. Synthient’s analysis of a retail MECOOL KM9PRO Max set-top box found the com.oemservice binary signed with a certificate attributed to Skyworth Digital Technology. Running as android.uid.system (UID 1000) puts the implant on the same privilege tier as the Android system server. It needs no kernel exploit and no chain of local privilege escalation bugs, because the operating system already treats it as a core administrative component.

Why a factory reset cannot remove XCPE

On first boot, a dedicated BootReceiver installs x.cpe from the read-only /oem/ partition into /data/app/, where it runs with full system authority. This layout leaves an ordinary owner with no practical fix. A technically capable user can enable Android Debug Bridge (ADB) over port 5555, find the package, and uninstall it from /data/app/, but the removal lasts only until the next reboot. The BootReceiver runs its startup routine again, reads the clean copy in /oem/, and reinstalls the backdoor. A full factory data reset wipes /data/ and /cache/ and leaves /oem/ untouched, so the device’s baseline factory state includes the active implant.

Turning off Google Play Protect

Once it holds UID 1000, x.cpe blinds the device’s built-in security telemetry. Play Protect scans installed apps, preloaded software on certified devices included, for known malicious behavior. Because x.cpe has system privileges, it does not need to evade Play Protect’s heuristics during stage-two payload delivery. It switches the scanner off.

GTIG documented an internal utility function, AppUtils.disablePackageVerify, that writes the integer -1 to the global setting package_verifier_user_consent. That single flag revokes user consent for package verification across the operating system, which mutes Play Protect and lets the backdoor install arbitrary third-party APKs and native binaries without warning prompts or cloud verification checks.

How XCPE passed Android TV certification

To ship a device with Android TV certification and Google Mobile Services, an OEM has to submit its firmware builds to Compatibility Test Suite (CTS) and security validation checks. According to Google’s post-mortem, Videostrong obfuscated x.cpe specifically to exploit blind spots in those static and dynamic tests. The factory image did not contain active monetization binaries. It shipped a dormant, obfuscated stub that passed automated inspection and fetched its malicious logic only after a consumer bought the box, plugged it into a home network, and finished the first boot.

XCPE command-and-control: HTTP bootstrap and MQTT brokers

With x.cpe running and Play Protect disabled, the implant starts a two-stage command-and-control sequence built to handle over a million concurrent endpoints without drowning in connection overhead.

the HTTP bootstrap

At startup the implant sends HTTP POST requests to a hardcoded setup server. In Synthient’s teardown of the MECOOL KM9PRO Max and in parallel analyses by Plume and GTIG, those beacons went to subdomains of anyevonline[.]com, specifically extstb[.]anyevonline[.]com, with the exact subdomain varying by device model and Android version. The POST body carries hardware identifiers, MAC addresses, device model strings, and the current firmware version (for example 58|6.8.3 plus a millisecond timestamp).

The bootstrap server answers with an AES-encrypted JSON payload of operational parameters: geolocation lookups, STUN server settings for NAT traversal, and credentials for the second stage. A query to the /router/config/mqtt endpoint returns a JSON object with a Message Queuing Telemetry Transport (MQTT) broker hostname, TCP port, an authentication token or password, and the topic strings the device must subscribe to.

MQTT brokers and regional pools

Using MQTT for day-to-day orchestration is a sensible engineering choice. The protocol was designed for industrial telemetry over unreliable, low-bandwidth links, and it uses a lightweight publish-and-subscribe model over persistent TCP connections. Instead of 1.3 million set-top boxes polling a web server every few minutes, each box holds an idle socket to a central broker and waits for messages on its assigned topic.

Across the samples GTIG and Synthient examined, MQTT traffic ran mainly through mqtt.szbboys[.]com (resolving to 219.134.163.210 and 219.134.163.211) and mqtt.anyevonline[.]com, over non-standard TCP ports 3885, 3886, and 3887. To manage load and regional monetization, the operators split the fleet into six timezone-separated pools hosted under ott.szbboys[.]com. One server pool configuration captured by Google assigned Middle East devices to "region": "Iraq" and routed them to "defaultPool": "Pool5".

What operators could do through MQTT topics

Through these persistent topics, Videostrong’s operators had interactive and automated control over every box on the network, and each topic mapped to a distinct handler routine inside x.cpe.

For application management and shell access, operators could push URLs to remote APKs, which the implant fetched with OkHttp into a temporary directory and installed silently using system package manager permissions. They could also push arbitrary shell scripts and commands that ran as system, and request reverse shells that gave interactive terminal access inside the owner’s home LAN.

For surveillance, the backdoor included handlers to capture live screenshots of whatever the user was watching or typing, inject synthetic keystrokes to navigate interfaces or click prompts, and exfiltrate local data. That data included linked Google and streaming account details, installed package inventories, system logs, and local network reconnaissance covering nearby Wi-Fi SSIDs and Bluetooth configurations.

How Videostrong rebuilt XCPE in 2024 and again in 2026

XCPE looks like an actively managed commercial product, and the way Videostrong refactored it after industry enforcement supports that reading. Before late 2024, early x.cpe builds used a flat, monolithic design in which the firmware implant embedded or launched the revenue-generating modules directly. After increased scrutiny of pre-installed Android TV threats and earlier enforcement against the original BadBox ecosystem, Videostrong moved the malware to a compartmentalized three-stage architecture in late 2024.

The three-stage split and its anti-analysis features

The redesign appears aimed at resilience and evasion. If a security vendor flagged a noisy ad-fraud SDK or a residential proxy binary, that detection would no longer point back at the underlying x.cpe firmware package. In the post-2024 design, x.cpe (stage one) lost its direct monetization logic and handled only C2 communication and system-level tasking. Execution of affiliate payloads moved to a new stage-two loader written by Videostrong, com.abc.nexus.

com.abc.nexus acts as the local execution engine and bundler, and it includes native anti-analysis utilities meant to detect and block automated sandboxes and dynamic analysis environments. When the MQTT broker pushed a tasking bundle, x.cpe parsed the policy instructions and handed the parameters to com.abc.nexus. Google’s technical report shows the JSON structure of these exchanges. An incoming configuration payload held an "infos" array that specified the module channel (such as "libChannel": "SZKJ"), the module identifier ("libCode": "linkfog"), the target CPU architecture ("arm64-v8a"), expected MD5 checksums, resource priority weights, and download URLs.

The operators hosted many of their native ELF binaries and stage-three payloads on operator-controlled GitHub repositories through GitHub Releases, for example https://github.com/Aviciiii/ott/releases/download/cpe_ext_lib/lw_android_agent_special_ndk_64. That let the download traffic blend into ordinary developer CDN requests.

A second JSON object, "policys", controlled which embedded or downloaded services com.abc.nexus should start or kill at any moment, using boolean flags for the module codes linkfog, bwm, adtime, admoyu, titan, and lb102. The requested services ran under internal class names including TitanService, BwmService, AdtimeService, lb102Service, and LinkfogService (also seen as AgentService). After com.abc.nexus ingested the bundle and started them, x.cpe published an acknowledgment to the MQTT topic ext/lib/config/reply with "code": 0, "msg": "success", and "data": "received data success and applying". The device then kept reporting bandwidth consumption and system resource alarms to its assigned server pool, so the criminal workloads would not stutter the owner’s video streaming and give the game away.

The 2026 dropper model

By August 2026, Videostrong’s engineers were phasing out even this design. Telemetry across the botnet showed operators issuing synchronized MQTT commands to mass-uninstall com.abc.nexus while pushing smaller, single-purpose droppers. These newer droppers masqueraded as core operating system utilities, most notably com.android.system.ntp, which imitates the Android Network Time Protocol service.

com.abc.nexus talked to x.cpe over inter-process communication (IPC) and toggled half a dozen modules dynamically. The late-2026 droppers carry hardcoded configuration for a single affiliate payload and never listen for IPC messages. x.cpe controls them entirely through root-level shell scripts pushed over MQTT. To manage where and how the droppers sit on disk, the malware used custom Android system properties:

• persist.networkstack.uninstall triggers an immediate self-uninstall and forensic cleanup when the dropper reads it.
• persist.networkstack.skip_system_install keeps the package in /data/app/ instead of migrating it to system directories.
• persist.networkstack.install_time records when the package was installed.

How XCPE made money: residential proxies and ad fraud

Why build partition persistence and multi-stage MQTT loaders into a forty-dollar streaming box? Because a clean residential IP address is one of the most liquid commodities in the cybercrime economy.

Banks, ticketing platforms, e-commerce fraud engines, and enterprise defenders lean on IP reputation and autonomous system number (ASN) lookups to block automated attacks. Traffic from commercial cloud providers or known VPN ranges is routinely challenged or dropped. Traffic from a residential fiber or cable line in suburban Chicago, Munich, or São Paulo passes straight through geo-restrictions and risk-scoring thresholds. By turning 1.3 million consumer devices into unwitting proxy exit nodes, Videostrong built a wholesale bandwidth brokerage.

The company did not depend on a single revenue stream. It sold access to the XCPE fleet to multiple external affiliates at the same time, and researchers regularly saw a single set-top box running three separate residential proxy SDKs alongside background ad-fraud engines. The stage-three modules fall into several families.

Linkfog and DianxinCloud: PCDN and AI gateway proxying

LinkfogService inside com.abc.nexus unpacks a compiled Go binary named lw_android_agent from the app’s assets/ folder into local storage and launches it with vendor-specific parameters. Beijing Linkfog Technology, associated with Dianxinyun (DianxinCloud), operates it. The binary opens Fast Reverse Proxy (FRP) tunnels back to edge aggregation servers and uploads bandwidth accounting metrics to Linkfog API endpoints. TrendAI noted that alongside peer-to-peer content delivery network (PCDN) traffic, DianxinCloud components powered “DianxinAI,” a load-balanced AI API access platform that routes automated queries across hijacked residential connections.

Jaguar: a native proxy relay

When AdtimeService activates, it extracts libjaguar.so from its assets/ directory. GTIG’s analysis found an unobfuscated 32-bit native ELF binary written in C that uses the Java Native Interface (JNI) to bootstrap its routines. To protect its command infrastructure from static extraction, the binary derives a ChaCha20 decryption key at runtime, using ARM NEON SIMD vector instructions to decode heavily obfuscated configuration blocks. After it registers with its C2, a native command loop (x_ctrl_do_ctrl_msg) parses incoming JSON directives and relays arbitrary third-party TCP and UDP traffic through the victim’s router.

AppSalt, GaGaNode, NetNut, and Traffmonetizer proxy SDKs

The AppSalt SDK (Honeygain) comes preconfigured with a list of proxy gateway domains, updatable through C2, and opens persistent UDP and QUIC tunnels to relay client traffic. Researchers also saw the GaGaNode module (linked to IPCola) acting as an intermediary broker on infected boxes. It initialized secondary residential proxy SDKs, including PopaNet (linked to NetNut) and EarnFM Fleet, while other builds deployed Traffmonetizer.

Bandwidth-sharing SDKs often claim in their marketing that they rely on consenting users who opt in to share idle capacity. Google’s researchers stressed that in the XCPE ecosystem these modules were force-installed silently, with no consent prompt.

CBOXTV, HiddenView, and DevourService: ad fraud

Affiliates also used the devices’ graphics and CPU cycles for automated advertising fraud. Modules such as CBOXTV and HiddenView ran as standalone background apps with transparent window overlays and hidden Android WebView instances. Invisible to the person watching television, these hidden browsers loaded targeted web pages, played muted video ads unattended, and injected simulated touch, scroll, click, and typing events to fake human engagement.

Moyu, Spirit, and Bird: secondary backdoors

A manufacturer-installed rootkit was apparently not enough. Videostrong also let affiliates deploy independent backdoor families, including Moyu, Spirit, and Bird, which gave external threat groups redundant persistence channels on the same hardware.

How operational security failures exposed Videostrong

Pinning malware on a specific company with high confidence is hard when the target is embedded firmware. An ODM can claim its build server was compromised or that a third-party vendor supplied a tainted SDK without its knowledge. In the XCPE investigation, mistakes by the infrastructure operators tied the command-and-control network directly to Videostrong’s corporate headquarters and engineering leadership.

In late 2025, Synthient researchers working with the Motion Picture Association (MPA) bought several suspect streaming boxes for physical teardown, including a MECOOL KM9PRO Max. They enabled developer mode, dumped the running processes and firmware partitions over ADB on port 5555, and traced the com.oemservice bootstrap traffic to anyevonline[.]com. Pivoting across that domain’s infrastructure, they found a sibling subdomain, file.anyevonline[.]com, serving an unauthenticated, publicly accessible HTTP directory listing on port 8000.

The open directory sat on the live malware staging server. It held the raw backdoor binaries pushed to infected devices and a folder named pdf. Inside that folder was an official corporate device declaration signed by Owen Cao, Research and Development Director of Videostrong Technology Co., Ltd.

The overlaps went beyond a misplaced PDF. Passive DNS showed that Videostrong’s corporate domain, videostrong[.]cn, resolved to the same IP address as mqtt.anyevonline[.]com, which hosted the main web-based administration panel operators used to view active victims, manage task queues, and push silent APK installs across the botnet. Cryptographic inspection of the malware samples also showed that many of the certificates used to sign the backdoor packages contained the corporate email addresses of several Videostrong employees.

Those findings undercut the OEM/ODM white-labeling that normally shields hardware makers from scrutiny. On its public website (videostrong[.]com), the Shenzhen firm presents itself as an industry leader in AI companion robotics, smart speakers, and Google-certified Android TV boxes and sticks. Almost nobody buys a box with “Videostrong” printed on the shell. The company builds hardware and compiles firmware for retail storefronts and consumer brands, most notably MECOOL and YOKATV (yokatv[.]com). A shopper ordering a budget streaming box sees the brand a video reviewer promoted and has no view of the ODM that assembled the board, compiled the /oem/ partition, and kept root access after delivery.

Google’s XCPE takedown and what it left untouched

Google and its partners ran a two-part disruption in late October 2026 and announced it publicly on November 2, 2026.

First, Google took legal action to seize and sinkhole the core command-and-control domains and servers Videostrong operated. That cut the HTTP bootstrap endpoints (anyevonline[.]com) and the MQTT brokers (szbboys[.]com) that x.cpe relies on for tasking. Second, Google went after the upstream command-and-control domains of more than a dozen affiliate malware families, the stage-three proxy and ad-fraud modules loaded onto the boxes. Those affiliates also distribute their SDKs and trojans through other channels, including trojanized mobile apps and parallel botnets such as BadBox 2.0, Vo1d, and Kimwolf. GTIG estimates that taking down the affiliate domains cut attackers’ access to at least 10 million additional compromised devices worldwide, on top of the 1.3 million XCPE units.

Google also permanently ended its commercial relationship with Videostrong. The ban covers any future subsidiaries or corporate affiliates the company creates, and it bars them from building or selling certified Android devices or supplying software components to any other Google-certified manufacturer. Google says it has also overhauled its firmware integrity review for certified Android TV devices to catch obfuscated staging that activates after first boot.

For the households and businesses with an affected device under a television or on a clinic wall, a network takedown leaves the firmware exactly as it was. Sinking the MQTT brokers stops Videostrong and its affiliates from pushing new commands through the disrupted domains, and that relieves home networks of the proxy traffic that was saturating their upload bandwidth. But the x.cpe / com.oemservice binary is still in the read-only /oem/ partition of all 1.3 million devices. Play Protect stays disabled (package_verifier_user_consent = -1). Stage-three droppers and secondary backdoors such as Moyu, Spirit, and com.android.system.ntp stay on disk, and any that talk to surviving or fallback IP addresses can keep working. Nobody can reasonably expect the manufacturer to ship a clean over-the-air (OTA) update that removes a backdoor it built on purpose.

How to detect and remove XCPE infected devices

Detect XCPE on the network

Audit DNS logs, firewall states, and netflow telemetry for outbound connections to *.anyevonline[.]com and *.szbboys[.]com, HTTP requests to port 8000, and persistent TCP connections over the non-standard MQTT ports 3885, 3886, and 3887, particularly toward 219.134.163.210, 219.134.163.211, and 23.94.49.57. Move any Android-based IoT hardware (a streaming box, a signage player, a kiosk) that makes unexpected requests to GitHub Releases, or opens rapid bursts of UDP/QUIC and FRP tunnel connections, onto an untrusted VLAN immediately.

Verify the host over ADB

Where you have physical or local network access, connect over ADB and inspect the package inventory with pm list packages -f, along with the running processes, for x.cpe, com.oemservice, com.abc.nexus, and masqueraders such as com.android.system.ntp. Then run settings get global package_verifier_user_consent and check for a value of -1.

Dispose of the hardware

Deleting the package from /data/app/ triggers reinstallation from /oem/ at the next reboot, and clean, cryptographically verifiable factory images do not exist for these white-labeled boards. Synthient and independent security analysts therefore recommend the blunt fix: unplug the affected devices and dispose of them permanently.

Because x.cpe harvested account tokens, keystrokes, and local Wi-Fi configurations, anyone who ran a compromised box should also rotate the passwords on any Google, streaming, or router accounts used on that network.

What XCPE shows about trust in OEM firmware

XCPE follows BadBox 2.0 in March 2025 and the earlier Vo1d and Keenadu operations, and I read it as the clearest sign yet that low-cost embedded hardware runs on different economics than flagship smartphones. When hardware margins are razor thin, an ODM has a strong incentive to cover manufacturing costs by turning the customer’s residential IP address into a recurring revenue stream.

Today’s certification checks a device once, in a lab, before it ships. Until firmware attestation can verify that the /oem/ and /system/ partitions stay free of covert tasking engines for the whole life of the device, a certification logo on a retail box says little about what the factory compiled into the image.