DoFun Android head-unit botnet used the vendor's own updater, no exploits required

What happened

In June 2026, Kaspersky disclosed a botnet infecting aftermarket Android infotainment head units built on firmware from DoFun, a supplier of infotainment firmware and cloud services that claims its software reaches more than 30 million vehicle owners. A follow-up analysis on dev.to points to the detail much of the coverage skipped: nothing on these devices was exploited. The malware arrived through TWCore (com.tw.core), the legitimate system app that ships firmware updates on DoFun-based units, and was installed silently as though it were a routine update push.

How the updater became the attack

According to the dev.to writeup, TWCore takes its instructions from an MQTT broker on a subdomain of cardoor[.]cn and installs any APK that lands in its push/apk/ cache directory. That turns the update channel itself into the attack surface: whoever can feed the channel decides what runs on the device.

The chain begins with JarService, an app with no icon and no user-facing interface. It decrypts a loader, the loader fetches the real payload, and the infected unit becomes a click-fraud node and a residential proxy exit point through a module named zhima. The payload also collects device model, screen resolution, Wi-Fi SSID and MAC address. Two of the payload's nine commands are stubs, which the writeup reads as evidence that the operators are still building out the toolkit.

One boundary is worth stating plainly, per the writeup: the malware does not touch driving functions, and nothing in the disclosure suggests steering or braking is affected. The harm is network-side — other people's traffic leaves via the owner's hotspot or home Wi-Fi, with the owner's IP recorded on the far side.

Attribution and the BADBOX link

Kaspersky attributes the campaign to the MoYu Group, the actors behind the BADBOX ecosystem of compromised TV boxes. The dev.to piece notes that Google sued 25 unnamed people over BADBOX in July 2025, and that roughly a year later the same crew was installing software on cars.

Why the ecosystem invited it

A small number of firmware vendors ship software inside units sold under dozens of brand names, and marketplace sellers often have no idea whose updater is in the box. On top of that, a configuration flag called installNotExists governs whether TWCore can install apps that never shipped on the device, and there is no owner-facing switch for it. DoFun closed the abused path after disclosure, but aftermarket updates flow through sellers, and sellers churn. The writeup's advice: if a seller cannot produce an update, treat the unit as stuck on whatever code it already runs and rely on network controls for defense.

How owners can check

The writeup outlines a short audit. Under Settings > About, look for DoFun, TWCore or cardoor.cn to confirm the firmware vendor, or check over ADB with adb shell pm list packages | grep -i "tw.core". If com.tw.core is present, list third-party packages together with their installers via adb shell pm list packages -3 -i; anything installed by com.tw.core that is not a known firmware component should be treated as suspect, with JarService the identified name. Leftover APKs sitting in the updater's push/apk/ cache directory that never became legitimate updates are another warning sign.

Without ADB, network logs tell the story: HTTP POSTs to a /cpc/api/task path on a roughly 90-minute cadence, contact with admin.uipoxy[.]com or 144.217.243[.]201, or sustained outbound relay traffic from a device that normally talks to only a few mapping and streaming services. Because the payload runs as an ordinary user app, removal is straightforward with adb shell pm uninstall --user 0 <package.name>, after which the unit belongs on its own SSID or VLAN with client isolation enabled.

Why it matters

This is a software-distribution failure rather than a vulnerability story, and the distinction carries the lesson. An updater trusted to install arbitrary packages is effectively a remote-install primitive; when its command channel is abused, every device that trusts it is compromised with no exploits and no user interaction. The design takeaways are concrete: update agents should install only signed, expected artifacts, wide-reaching install rights like installNotExists should default narrowly or expose an owner-facing control, and devices whose updates depend on ephemeral marketplace sellers need a lifecycle answer for when that seller disappears. For buyers, asking whose firmware and updater a unit runs has become a purchase-criteria question. The BADBOX lineage also shows these operators treat device categories as interchangeable — infrastructure built for TV boxes moved to cars with ease.