BuildNot yet confirmed elsewhere1 publisher2 min readPublished
No CVE required: DoFun head units installed whatever their MQTT update broker sent
Kaspersky says the factory updater on DoFun Android car head units installed whatever an MQTT broker told it to. No CVE was involved in turning shipped cars into proxy nodes.
The Engineer · Build desk
What happened
- Kaspersky Securelist research dated 21 August 2026 documents a supply chain attack on DoFun Android car head units, rated High, with no CVEs attached.
- TWCore, a legitimate system app shipped on those units, accepts APK installation commands from an MQTT broker under cardoor[.]cn.
- Attackers used that channel to have the updater download and install the JarService APK into its own external cache, with no user action involved.
- JarService runs without a user interface, unpacks an XOR-encoded block and chains through a second and third stage pulled from a C2 over HTTP.
- The loadlib2 command loads the zhima reverse proxy, making the car a relay for third-party traffic on its own cellular or network address.
Why it matters
- constraint With no CVE in the chain, there is no advisory to track and nothing for a scanner to match; the defect sits in a vendor design decision that normal vulnerability management cannot see, let alone...
- exposure Whoever pays the vehicle's data bill owns the address that turns up in a third party's logs as the source of relayed traffic and fraudulent ad clicks.
- decision Anyone buying connected hardware now has to make who may publish to the update broker, and what signs the payload, a purchasing question, because every effective control named here is the vendor's...
- capability loadlib2 fetches and runs arbitrary modules, so ad fraud and proxy relay describe what the operators chose to load, not the limit of what the installed foothold can do.
Nothing in the chain had to break. A broker topic that accepts an instruction to install a package, plus a parameter named `installNotExists` that permits packages the device has never held, is remote code execution offered as a product feature [3]. JarService needed no root and no privilege escalation; Kaspersky records it going on as an ordinary user application [9]. Hardening the Android build underneath would have changed nothing, because the privilege the attackers used was the one the vendor had already granted its own updater [2].
The forensic artefact makes the point better than an advisory could. Kaspersky's advice for finding an infected unit is to look for unknown APKs in the TWCore cache directory with `com.tw.core` recorded as the installer [10]. The install record correctly names the vendor's software as responsible, because it was. Any control that treats installer provenance as a trust signal reads this as a legitimate update, and in the narrow sense it is one.
The traffic is not subtle. A 90-minute default beacon interval [6] is 16 check-ins per device per day [17], around 480 a month [18], each carrying device model, screen resolution, connected Wi-Fi SSID and MAC address [6]. That is a metronome on any link somebody is watching, and every mitigation Kaspersky lists sits away from the device: signature verification and allowlists on update instructions and APKs at the vendor [12], and blocking C2 and zhima traffic at the perimeter before the implant can collect its modules [13].
The reassurance in the report deserves reading slowly. Kaspersky has not observed interference with driving operations or critical vehicle controls [15]. It also says head units usually fall outside enterprise EDR, making direct visibility into APKs, processes and C2 traffic unlikely [11]. Absence of observation on a platform nobody can observe is thin evidence, and here it is the only kind available.
DoFun has reported to Kaspersky that the issue is resolved [19], while the method used to get malicious install instructions into the legitimate channel is not public [14]. A buyer therefore cannot tell an authenticated broker with signed payloads from a rotated credential on the same open path, and those are not the same repair. Related Kaspersky reporting ties the zhima proxy to the MoYu Group and describes it running on a television as well as on car dashboards [16]. The defect belongs to the update channel, and update channels ship on everything.
What to watch
- Whether DoFun publishes what actually changed in the update channel, broker authentication or payload signing, rather than only that the issue is resolved.
- Whether other head unit or smart TV vendors are named as shipping the same style of MQTT install path with an installNotExists equivalent.
- Whether commands beyond loadlib2 and http appear in later samples, particularly any that touch vehicle buses rather than the network stack.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence62
- Adoption30
- Hype gap+5
- Incentives55
- Confidence58
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Kaspersky Securelist research titled "The invisible passenger in your car", publication date 2026-08-21, describes a supply chain attack distributing multi-stage Android malware via legitimate vehicle software update apps; severity is rated High and no CVEs are listed.
- [2]
The legitimate system app TWCore (com.tw.core) on DoFun Android car head units receives an APK installation command from an MQTT broker under cardoor[.]cn; the TWCore update function is enabled on target head units running DoFun software.
- [3]
Enabling the installNotExists parameter allows the installation of new apps that do not yet exist on the device.
- [4]
Attackers abused this update path to download and install the JarService APK into the external cache of TWCore without user action; the legitimate update feature handles the process automatically, so users do not need to click or manually install APKs.
- [5]
JarService has no user interface, decrypts an internal XOR-encoded block and runs a Stage 2 loader, which sends device and implant details to the C2 by HTTP POST and fetches an encrypted Stage 3 from the dexUrl in the response.
- [6]
Stage 3 reports the device model, screen resolution, connected Wi-Fi SSID and MAC address to the C2 every 90 minutes by default, retrieving configurations and commands.
- [7]
At the time of analysis the commands actually used by the attackers were loadlib2, which fetches and runs arbitrary modules, and http, which visits specific URLs to generate web traffic for ad click fraud.
- [8]
The loadlib2 command loads the zhima reverse proxy module, turning the infected device into a relay node for external traffic and abusing the cellular or network IP address of the vehicle as a relay point for third-party traffic.
- [9]
Root access or privilege escalation is not mentioned in the article; JarService was installed as a standard user application.
- [10]
Unknown APKs may be found under the TWCore cache directory, with com.tw.core recorded as the installer.
- [11]
Android car head units are usually outside the scope of enterprise EDR tools, making direct visibility into APKs, processes and C2 traffic unlikely.
- [12]
Recommended remediation includes strong signature verification and allowlists applied to update instructions and APKs so unknown packages are rejected.
- [13]
Blocking C2 and zhima communications at the network perimeter prevents retrieval of commands and additional modules.
- [14]
Attackers were positioned to inject malicious APK distribution instructions into DoFun's legitimate update channel, but the exact method used to breach the update infrastructure is not public.
- [15]
Kaspersky has not observed interference with driving operations or critical vehicle controls.
- [16]
Related Kaspersky material listed alongside the research includes "Hackers infect Android car head units with proxy botnet malware" and "Open sesame: inside MoYu's zhima proxy and the TV it runs on"; related entities named include the MoYu Group and BADBOX, and the detection name HEUR:Trojan-Downloader.AndroidOS.Agent.ov.
- [17]
A 90-minute default beacon interval is 16 C2 check-ins per infected device per day.
- [18]
Sixteen check-ins per day is about 480 per device per 30-day month.
- [19]
DoFun reported to Kaspersky that the issue has been resolved.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toJarService / zhima Malware Entering via Insecure Android Car Head Unit Update Paths
1 article · August 22, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.