Perhaps the most annoying kinds of faults are those that involve expensive equipment that just sit around in a cupboard, only for them to just stop working at all. Such was the case with the £2,000 Amprobe cable trace kit that [Tom] bought for work-related purposes. After sitting around unused for a few years, the signal generating part of the kit refused to power up at all, with Fluke’s service department wanting at least £600 to even attempt a repair after already having had [Tom] cough up £70 to even get this quote.
Subsequently he instead sent it to [Buy it Fix it] on YouTube for an attempted repair, which at the very least would be a less costly option. These systems use a signal generator connected to the cable, with a separate detector wirelessly tracking this signal. By itself that doesn’t sound too complex, but as it turns out it wasn’t quite so straightforward to diagnose.
After eliminating a basic power or display issue, the SoC’s boot sequence was traced, including reading from the 128 MB NAND Flash. At first glance the unit appeared to be trying to boot and work as normal, which was confirmed after finding a serial port and seeing the log output on it. This showed that the NAND Flash’s boot image failed validation due to apparent corruption.
After desoldering the TSOP 48 Flash package and stuffing it into a reader, at first glance the data on it looked fine. After a tragic detour with Google’s Gemini chatbot that led to a lot of wasted time, the solution that the human intelligence came up with was to crack open the tracer unit in the set and ogle at its firmware, in particular the bootloader.
Comparing the two Flash dump files, there were a few flipped bits in the bootloader section, likely due to cells in the Flash having lost their charge. Writing the generator’s Flash with a corrected image led to it booting up happily again into the Linux 2.6-based firmware, seemingly no worse for wear. Of course, one has to consider here that the NAND Flash IC clearly has a few leaky cells in it, so replacing it with a fresh one could be a good idea for a long-term fix.
While monitoring Android threats in June 2026, we discovered a new piece of Android malware. What struck us as unusual was that it installed like an ordinary user app yet made no attempt to disguise itself as legitimate software: it had no user interface at all. This led us to suspect the app might be reaching users’ devices without their knowledge. Further investigation confirmed that hypothesis and allowed us to reconstruct the entire infection chain.
Key findings:
We identified new Android malware: a multi-stage downloader whose ultimate purpose is ad fraud and creation of a proxy botnet.
The malware spread through the built-in updaters of Android-based automotive head unit firmware. This is the first documented case of malware found on a car head unit with an infection chain specific to that type of device.
We attribute this activity, with high confidence, to the MoYu Group, an actor linked to the BADBOX botnet.
Kaspersky solutions detect the threats described below under the following detection names:
HEUR:Trojan-Dropper.AndroidOS.Agent.vu
HEUR:Trojan-Downloader.AndroidOS.Agent.ov
HEUR:Trojan-Proxy.AndroidOS.Zhima.*
HEUR:Trojan.AndroidOS.Vo1d.*
Head unit firmware overview
A head unit is a system that combines multimedia functions with partial control over certain vehicle functions. Head units may come as part of a car’s factory equipment or as an aftermarket upgrade. The main attack vectors for these systems are compromise via physical access and vulnerabilities in the head unit’s OS or components, both of which we’ve covered previously.
In some cases, head units run on Android, primarily because it’s convenient for manufacturers: Android’s source code already accounts for use cases within automotive head units. Android also allows manufacturers to add their own system applications during the build process, which they can use for a range of purposes: customizing the UI, adding system components tailored to the vendor’s needs, and more.
Most apps developed for Android devices can also run on an Android-based head unit, and that is true for malware as well. That said, it’s hard to imagine certain categories of smartphone-targeted malware being used to attack a head unit. Banking Trojans are a good example: since mobile banking is used almost exclusively on smartphones, infecting a head unit with a banking Trojan would be a waste of the attacker’s resources.
It’s worth noting that head units often include SIM card slots and can connect to the internet, enabling features like navigation and software updates. Since a head unit typically holds nothing of value to an attacker, one of the more likely attack scenarios using “classic” Android malware is infecting the device to recruit it into a botnet – similar to attacks on IoT devices.
During our research, we found exactly that kind of malware. The design of firmware for DoFun head units enabled attackers to distribute malware. We notified the vendor about the distribution scheme, and they subsequently reported fixing the security issues.
Below is the entire infection chain:
Head unit infection scheme
Let’s look at exactly how these head units became infected.
The TWCore app
TWCore is a legitimate system application responsible for collecting analytics data and updating the head unit software. Let’s take a closer look at how the update function works.
The process is fairly simple. An MQTT message broker hosted on the subdomain cardoor[.]cn sends a message containing information about the APK files that need to be downloaded and installed on the head unit. Notably, the object describing this message includes an installNotExists field, a Boolean flag that can be set to true or false. This flag allows TWCore to install apps that weren’t originally present on the device.
TWCore only checks whether an app is already installed on the device when installNotExists = false
The APK file is downloaded to <TWCore external cache dir>/push/apk/ for installation.
The path TWCore uses to download APK files
Our telemetry revealed previously unknown malware at these file paths. On top of that, our data indicates that in every observed case, the malware was installed by an app with the package name com.tw.core, which matches the TWCore package name.
Next, we’ll break down the malware installed by TWCore: the JarService dropper.
Stage 1: the JarService dropper
As mentioned earlier, JarService is a small dropper app with no UI of any kind. It decrypts data stored as encrypted blocks within the Trojan’s code. Each block is XOR-encrypted with a single-byte key that shifts linearly from block to block. The decrypted data contains serialized information about the payload version and entry point, along with the malware’s own code for further loading.
Decrypting and deserializing information about the stage 2 payload
In the version of JarService we analyzed, the entry point for the next-stage payload was the wa method of the com.c.j.qbh class.
Stage 2: the loader
This stage’s payload is a malicious loader. Its code contains encrypted strings that are later used as class names to execute the stage 3 payload using the reflection mechanism. The loader sends implant information to one of the attackers’ servers via a POST request. Example of a request to the C2 server:
The Trojan uses the link in the dexUrl field of the data object to download serialized data for loading the next stage. This data begins with a single-byte integer, a key used to decrypt the strings in the loader’s code. Immediately following this number is a four-byte floating-point value used to XOR-decrypt the stage 3 payload, which itself is located after these keys.
Decrypting the stage 3 payload
In the decrypted payload, the entry point is the init method of the com.ast.sdk.BillingMain class, shown in the screenshot below.
Entry point of the stage 3 payload
While analyzing this stage, we noticed that the download link for the next-stage payload includes a version number. We decided to try other version numbers to retrieve different payload versions, and ultimately obtained seven distinct variants, which we list under “Indicators of Compromise” at the end of this report. The earliest version, numbered 3.57, uses a different decoding algorithm than the one described above. This may indicate that an earlier version of the infection chain used a different loader between JarService and the stage 3 payload.
Stage 3: clicker / reverse proxy loader
In this stage, the malware sends a POST request to /cpc/api/task every 90 minutes by default, containing information about the infected device (display resolution, device model, the SSID of the connected Wi-Fi network, MAC address, and so on) along with the Trojan’s configuration version. If the configuration is outdated, the C2 server returns an updated configuration containing new C2 addresses and new paths for sending HTTP requests. An example of a response is shown below. Note that at the time of our research, the most up-to-date configuration version was 3.82.
If the configuration version doesn’t need updating, the C2 server instead returns integer command identifiers, which the attackers refer to as productId. The Trojan maps each identifier to command information, which it stores as a serialized JSON object using the SharedPreferences API. Each identifier also has its own version, expressed as a UNIX timestamp. If the C2 response includes an unknown productId or one whose version is outdated, the malware sends a GET request to the attackers’ server at /cpc/api/xml to retrieve the command contents for all such identifiers. The C2 server responds with command information for each unknown identifier. An example of a response is shown below.
The command information includes a tagName field, which is the command name. The code maps each name to the corresponding class responsible for executing it.
List of executable commands
At the time of our research, the attackers had implemented nine commands. The table below lists command names, brief descriptions, and arguments. The functionality of these commands suggests that the malware can be used to display ads, commit ad fraud (serving as a clicker), and download additional malicious code.
Command name
Description
Arguments
return
Return a value from SharedPreferences.
key: the key whose value should be returned
copy
Set the contents of the clipboard.
text: the key whose value from SharedPreferences is returned as the clipboard contents url: a link for downloading gzip-compressed data (optional); this data is then concatenated with the value of the text key, with (5 spaces) used as a separator
http
Make a POST/GET HTTP request to a specified resource and, if instructed, save the response in SharedPreferences under a specified key.
url: the resource address method: the HTTP method name (optional) startLabel: a marker for the start of the data to save from the resource (optional) endLabel: a marker for the end of the data to save from the resource (optional) valueLabel: the key under which to save the value (optional) header: a dictionary of headers for the HTTP request (optional) content: the content of the POST request (optional)
web
Open a link in the WebView and execute arbitrary JavaScript code within it.
url: the link to open in the WebView js: base64-encoded JavaScript code to execute in the WebView; used when the url parameter is empty or absent corejs: JavaScript code to execute when the resource loads in the WebView (optional) param: a string dictionary of parameters for launching the WebView client: if this key is present, WebViewClient is used to handle redirects manually time: task timeout
loadlib
Not fully implemented at the time of publishing this report.
–
loadlib2
Download and execute arbitrary code.
url: the address to download the payload from name: the name of the module being downloaded md5: the MD5 hash of the payload clear: a comma-separated list of payload names to delete (optional) params: an array of parameters to launch the payload with className: the class name of the payload entry point method: the name of the virtual method at the payload entry point cmethod: the name of the static method used to instantiate the entry-point class (optional) thread: a flag; the payload runs in a separate thread if this flag is not set reload: a flag that, when set, restarts already loaded modules
loadlib3
Not fully implemented at the time of publishing this report.
–
deeplink
Open a resource in the browser.
url: a link to the resource
traceroute
Check resource availability via an ICMP ping.
host: comma-separated list of resources to check
However, attackers use only a relatively small subset of these commands in real-world attacks. As shown in the example C2 response above, at the time of publishing this report the attackers were using the loadlib2 and http commands. The payload downloaded via the loadlib2 command is a reverse proxy module named “zhima”, which researchers from the Nokia Deepfield Emergency Response Team independently discovered in TV set-top boxes around the same time as we did and also described in their report. This confirms that the attackers’ ultimate goal is building a proxy botnet.
While investigating this stage of the attack chain, we noticed that the zhima download link also included a version number. As with the previous stage, we tried other possible version numbers and found eight variants of the zhima module, the earliest of which was version 57. The complete list of identified zhima modules is provided under “Indicators of Compromise” below.
Attribution
While analyzing the complete infection chain, we noticed that the stage 2 loader created a thread with the meaningful name mosdk-host-loader. We decided to investigate what mosdk referred to in that name. This led us to a malicious app installed on various TV set-top boxes with the package name com.abc.nexus (3AD4BF5A86D26FFBF09CAE42AF330A98). It consists of several components (including a dropper similar to JarService), each used by the attackers to covertly monetize the device’s computing power. Each malicious component in the app corresponds to its own service, and the service containing the launch code for the JarService-like dropper is named AdmoyuService. In light of this and the name of the malicious thread found in the payload code, we concluded that moyu in the service name referred to MoYu Group, one of the actors linked to the BADBOX malware platform, which had been described by researchers at HUMAN. This assessment is further supported by extensive overlap between the malware’s network infrastructure and that of MoYu Group, which was independently identified by researchers from the Nokia Deepfield Emergency Response Team around the same time as our own research. Based on these similar naming patterns and prominent infrastructure overlap between the activity of MoYu Group and the attacks described in this report, we attribute it to the same actor with high confidence.
While investigating the malware downloaded by TWCore, we noticed that the domain admin.uipoxy[.]com resolved to the IP address 128.14.210[.]58, one of the C2 servers for the zhima reverse proxy module. It appears that the URL hxxp://admin.uipoxy[.]com/proxy/u/login hosts the zhima admin panel. Interestingly, this panel allows anyone to register as long as they have a valid invite code.
The malware operator registration page
During registration, users are prompted to review the terms of use and privacy policy. Both documents are hosted on links under the pxyedge[.]com domain, which belongs to PXYEDGE, a vendor specializing in the sale of residential proxies.
We found several similarities in the authentication APIs across all of these sites:
The sign-in page was hosted on an admin.* subdomain.
The sign-in page was located at /proxy/u/login.
The signup page was located at /proxy/register?channelKey=<invitation code>.
Based on this, we believe these services are connected to MoYu Group.
Conclusion
Despite efforts by cybersecurity professionals and law enforcement to shut down the BADBOX botnet, individual actors linked to it continue their malicious activity, infecting devices worldwide. Delivery methods for this kind of malware vary widely, from downloads via pre-installed backdoors to infected builds of IPTV apps. The case examined here demonstrates an even more sophisticated delivery method: distribution through the legitimate update functionality of a system application. Attackers are also actively expanding into new platforms. This malware is the first known malicious app targeting head units, which means these platforms now require protection against malware as well.
If you are a regular reader, then the odds are you have taken apart an electronic gadget, either for a fix, or simply because your curiosity got the better of you. Once inside, it’s all but impossible to help yourself from doing at least a little reverse engineering. That’s what happened when [PRBS23] took a look inside a MasterBuilt Gravity 800 Grill for a simple wire fix. But one thing led to the next, and now open source firmware for the grill is freely available!
The thermistor along with the physical inputs are connected to a 16 pin chip, interfacing with the MCU over a 9600 baud UART connection. [PRBS23] cannot determine an ADC chip meeting these specifications, so the most likely answer is a cheap MCU programmed to act as a simple analog fronted.
The neatly labeled programming header is used to quite easily dump the firmware with the espflash utility. Analyzing this dump reveals a rather strange ADC correction function used by the original firmware. The necessity and overall utility of this function remains unclear, does corrects a maximum of around 40 degrees Fahrenheit.
Most of the other features ended up being at least somewhat easier. The CS1621 segmented display driver is reasonably well documented with datasheets making its implementation far easier. Likewise, the other odds and ends were implemented in a far more normal manner compared to the thermistors.
Over a thousand bitcoins are believed to have been stolen so far in a hack that started to be discussed on social media in the afternoon of July 30th. Coinkite, one of the most reputable hardware wallet manufacturers, was revealed to have a critical bug in the way it generated secure private keys for its Bitcoin hardware wallets. Industry experts believe AI was used in the breach.
Coldcard MK3 devices with firmware version 4.0.1 (March 2021) through 4.1.9 are the worst affected. 12- or 24-word seeds generated by the device that did not include user-generated dice rolls or a BIP 39 extra passphrase are vulnerable.
The vulnerability was a specific line of code in the firmware, a low-level software codebase that controls the hardware. This firmware appears to be upgradable. The Coinkite advisory was updated this morning, advising users to upgrade device firmware for all three chips, MK3, MK4 and MK5 devices, including the Coldcard Q:
Coinkite also explained in their advisory that updating the firmware does not mean that the private and public keys generated by the vulnerable firmware before it are now secure; those keys remain vulnerable as they were effectively created with a weak password. After the firmware is updated, a new wallet needs to be created, and the funds need to be sent onchain to the new addresses to secure the funds. Coinkite wrote:
“Updating the firmware does not change or repair an existing seed. If your seed was generated before the fixed firmware version for your model, follow the migration guidance below unless the independent dice-entropy exception applies to you.”
Some Multisignature Wallets May Be At Risk
Peter Todd, Core contributor and cybersecurity engineer, today addressed specific edge cases for multi-signature wallets that use a threshold of Coldcards to secure funds. “Example case: you have a 2-of-3, with 2 Cold Cards, and a 3rd uncompromised device. If you move your funds, the moment your script is revealed for the first time – previously hidden behind the address hash – the attacker now knows enough to use the compromised 2 cold card keys to steal your funds.”
The transaction that reveals the multisig script might be unconfirmed, giving hackers enough time to create a competing transaction with a higher fee. Fortunately, such cases have a solution: the MARA mining pool can help in this case with their private mempool mining service, Slipstream; “because they promise to keep your transaction – and thus pubkeys – secret until they’re already in a block. Dramatically reducing the ability of the attacker to steal the funds,” said Todd. He added that “If you’ve already reused addresses, this isn’t relevant, and you should just try to move your funds ASAP. But if you haven’t, MARA may be able to help.”
Beyond The Immediate Crisis
NVK, one of the co-founders of Coldcard, published a long post on X with an initial analysis beyond the basic security steps needed to secure funds. In it, he wrote that the company is “committed to working with affected users who want to pursue a police report, insurance claim, or their own investigation”, including “a written incident summary specific to your loss and any transaction data we can share”.
Beyond the immediate crisis, NVK pointed to a broader tech shift as the hacking capabilities of AI begin to change previous cybersecurity dynamics and expectations. In the blog post he wrote:
“To every other developer: we believe this is a sober reality of the new AI paradigm. AI-assisted code review can now find latent bugs at a speed that is outpacing even the industry’s most seasoned experts. If your firmware is open-source or has ever been public, assume it’s already being read by attackers and defenders alike.”
The hack and over 70 million dollars in estimated stolen funds in the past 24 hours are an effective bounty paid to hackers who are now likely auditing every wallet codebase available for vulnerabilities. While the Bitcoin and broader crypto industry has generally operated under the assumption that hackers will test their code, the development of AI models optimized for cybersecurity accelerates these processes.
Industry experts gathered in a long X Spaces public call last night, discussing the topic for many hours. Beyond the immediate recommendations and answering questions to Bitcoin users throughout the long Spaces, analysis of what is likely to follow in the coming weeks was also discussed. Other wallet providers are likely to get probed, and especially open source projects which generate private key material will be tested.
The X Spaces was not recorded, likely to preserve the privacy of everyone in the call; however, initial sentiment suggests companies will need to be auditing their code with the latest frontier models, as a matter of survival. The latest cybersecurity-oriented AI models by Anthropic, OpenAI, Moonshot’s Kimi K3 and others are already available to the public. Many companies in the Bitcoin industry already use these to test the integrity of the code, but some might not be, and the race to find vulnerabilities in wallet-facing code will certainly continue, especially in the following weeks.
Ultimately, today we grieve lost coins, and a state of introspection and careful review occurs. Beyond this now historic hack will be an open source self-custody industry and infrastructure that is likely to be orders of magnitude more secure, with very hard lessons learned. After all, every hacker with an AI agent is likely testing defenses now.
Multi-vendor, Multi-key Wallets and Covenants
Future high sovereignty wallets, be it at the retail or corporate level, are likely to not depend on any single vendor. Multisignature wallets, when well done, can distribute vulnerability risks across different code bases, teams and hardware.
User-generated entropy was also a major theme in the X Spaces discussed earlier, with dice roll-generated entropy brought up regularly as a solution. Coldcards, as well as other hardware wallets like Foundation Devices, guide users on how to add their own entropy properly; many dice need to be rolled, ideally north of a hundred individual rolls. Once done, however, dice rolls represent a non-software source of randomness for wallets that also separates users from the edge-case risks in software- or hardware-generated entropy.
Covenants a popular soft fork among a certain niche in the Bitcoin industry have also started to be brought up as further step to strengthen the self-custody industry. This upgrade to the Bitcoin consensus which might be hard fought if achieved at all, could give users important smart contract capabilities, such a wallet that can only send to a white list of addresses, something not possible in Bitcoin script today.
Login
