Build1 distinct publisher2 min readUpdated
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
Compiled by The EngineerSomething wrong?How this is made
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 [11]. 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 [13]. 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 [7] is 16 check-ins per device per day [1], around 480 a month [2], each carrying device model, screen resolution, connected Wi-Fi SSID and MAC address [7]. 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 [15], and blocking C2 and zhima traffic at the perimeter before the implant can collect its modules [16].
The reassurance in the report deserves reading slowly. Kaspersky has not observed interference with driving operations or critical vehicle controls [18]. It also says head units usually fall outside enterprise EDR, making direct visibility into APKs, processes and C2 traffic unlikely [14]. 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 [12], while the method used to get malicious install instructions into the legitimate channel is not public [17]. 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 [19]. The defect belongs to the update channel, and update channels ship on everything.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
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.
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.
Enabling the installNotExists parameter allows the installation of new apps that do not yet exist on the device.
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.
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.
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.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed single-source vendor research, no corroboration
The technical record is specific and falsifiable: named package (com.tw.core), a named parameter (installNotExists), a staged loader chain, a 90-minute default beacon to /cpc/api/task, named commands (loadlib2, http), a named proxy module (zhima), plus domains, IPs, cache paths, hashes and loaded class names. That specificity is what lifts the score above the middle. It is capped because the entire cluster is one dev.to relay of one vendor's research: no second publisher, no CVE or coordinated advisory to anchor it, the update-infrastructure breach method is explicitly not public, and the remediation claim is second-hand with no version or date.
Confirmed active in the wild, scale undisclosed
Real-world activity is confirmed rather than theoretical: the source states which commands attackers were actually using at the time of analysis (loadlib2 loading zhima, http for ad click fraud), and the vendor engaged and reported a fix - both indicate a campaign that reached shipped devices. The score stays low because none of the quantities that would establish scale are supplied: no infected-device count, no affected DoFun model or firmware list, no geography, no fleet exposure figures, and no patch-coverage numbers. Only the per-device beaconing cadence is derivable.
Broadly aligned; scale claims unsupported
The framing tracks the technical record closely and the source polices its own overreach - it says no root or privilege escalation was involved, that no interference with driving operations or critical vehicle controls was observed, that this is not an email vector, and that IdP/account authentication is not abused. 'No CVE required' and 'factory updater installed whatever the broker sent' are literal restatements of the MQTT-plus-installNotExists finding. The small positive residue comes from the implied breadth of 'shipped cars': turning vehicles into proxy nodes is presented without any population figure, and remediation is asserted rather than verified.
Vendor research plus self-reported vendor fix
Two visible incentive vectors, neither hidden. The originating researcher is a commercial security vendor whose published output carries its own detection name (HEUR:Trojan-Downloader.AndroidOS.Agent.ov) and links to adjacent research on MoYu/zhima and BADBOX, so the write-up doubles as product and threat-intel positioning. Separately, the 'issue has been resolved' statement originates with the implicated head-unit vendor and is repeated without verification, which is the classic direction of remediation optimism. Offsetting factors keep this mid-range: the IOC set and hashes are publishable and checkable, and the source volunteers limits that cut against sensationalism.
Mechanism solid, scale and remediation uncertain
Confidence is moderate. The attack mechanism, artifacts and defensive actions are described with enough precision to act on today, and the internal consistency of the account is high. But every element traces to one publisher relaying one vendor, the compromise vector into the update infrastructure is undisclosed, the affected population is unquantified, and the fix is unverified - so conclusions about mechanism deserve more trust than conclusions about breadth or closure.
build
TrueConf's update directory is the delivery route: two KEV bugs, one swapped installer1 distinct publisher
build
The runner holds your deploy keys, and nobody put it in the scanning program1 distinct publisher
leadership
VECT 2.0 shreds anything over 128 KB, which makes paying its ransom pointless1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 22, 2026