DEV Community

Jason Miller
Jason Miller

Posted on Originally published at axeploit.com

The DoFun head unit botnet used zero exploits. The updater did the work.

Most coverage of Kaspersky's June 2026 DoFun disclosure buried the lede: nothing was hacked. The malware arrived through TWCore (com.tw.core), the legitimate system app that ships firmware updates on DoFun-based Android head units, installed silently as a routine push.

DoFun builds firmware and cloud services for aftermarket infotainment and claims 30+ million vehicle owners. Its updater takes instructions from an MQTT broker on a cardoor[.]cn subdomain and installs whatever APKs land in its push/apk/ cache folder. Attackers used that pipe to deliver JarService, an empty app with no icon. It decrypts a loader, the loader pulls a payload, and your dashboard becomes a click fraud bot plus a residential proxy exit (via a module called zhima). Kaspersky attributes the campaign to the MoYu Group, the BADBOX TV box ecosystem. Google sued 25 unnamed people over BADBOX in July 2025. About a year later, the same crew was installing on cars.

Why this was inevitable

A handful of firmware houses ship software inside units sold under dozens of brand names, and the marketplace seller often has no idea whose updater is inside. Worse, a setting called installNotExists controls whether TWCore can install apps that were never 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. If your seller can't produce an update, treat the unit as unpatchable and lean on network controls.

The ten-minute check

First, confirm you're on DoFun firmware. Settings > About, look for DoFun, TWCore, or cardoor.cn. Or over ADB (many units expose it, sometimes enabled out of the box):

adb shell pm list packages | grep -i "tw.core"
Enter fullscreen mode Exit fullscreen mode

If com.tw.core comes back, keep going. List third-party apps and their installers:

adb shell pm list packages -3 -i
Enter fullscreen mode Exit fullscreen mode

Flag anything you didn't install, especially a UI-less app with a generic name (JarService is the known one). Any package installed by com.tw.core that isn't a known firmware component is hostile until proven otherwise. Then check the drop zone:

adb shell ls -la /sdcard/Android/data/com.tw.core/cache/push/apk/
Enter fullscreen mode Exit fullscreen mode

Leftover APKs that never became legitimate updates are a red flag.

No ADB? Give the unit a DHCP reservation and log its traffic for a day. The strongest signal: HTTP POSTs to a /cpc/api/task path on a roughly 90-minute cadence. Also flag 144.217.243[.]201, admin.uipoxy[.]com, and sustained outbound relay traffic. A healthy head unit talks to a handful of map and streaming endpoints. One pushing gigabytes while parked is not fetching map tiles.

"It doesn't touch the car, so who cares"

True about steering and braking, and I'd push back on anyone claiming otherwise from this disclosure. But your unit became a proxy exit. Strangers' traffic leaves through your hotspot or driveway WiFi with your IP in the far end's logs. It also exfiltrated device model, screen resolution, WiFi SSID, and MAC. And the install primitive doesn't care what APK it delivers. Two of the payload's nine commands are stubbed out. They're still building.

Removal is the easy part, since the payload is a regular user app:

adb shell pm uninstall --user 0 <package.name>
Enter fullscreen mode Exit fullscreen mode

Then segment the unit: own SSID or VLAN, client isolation on, nothing inbound, nothing to your LAN.

Do this week:

  • Check for com.tw.core in your package list or cardoor[.]cn in DNS logs. If either hits, run the full check.
  • Alert on POSTs to /cpc/api/task. It catches reinfection and whatever family reuses this pipe next.
  • Revoke "install unknown apps" from everything except the store.
  • Next purchase, ask the seller whose firmware and updater the unit runs. If they can't answer, that's your answer.

Genuine question for the comments: has anyone pulled the updater config off one of these units and checked what installNotExists defaults to across brands? I haven't seen a good survey and it would settle how exposed the installed base really is.

Longer writeup with the full argument: https://axeploit.com/blog/your-dashboard-might-be-someone-s-proxy-exit-a-field-check-for-the-dofun-head-unit-botnet

Top comments (0)