In March 2026, a bunch of controls were added to the Australian Government Information Security Manual[0] basically instructing people to not connect government devices to the infotainment systems of any vehicles, or to view or discuss anything sensitive in the presence of one.
> Security Control: 2099; Revision: 0; Updated: Mar-26; Marking: NC, OS, P, S, TS Mobile devices are not connected to the infotainment systems of connected vehicles.
> Security Control: 2100; Revision: 0; Updated: Mar-26; Marking: NC, OS, P, S, TS Sensitive or classified data is not viewed on mobile devices within or near connected vehicles.
> Security Control: 2101; Revision: 0; Updated: Mar-26; Marking: NC, OS, P, S, TS Sensitive or classified phone calls and conversations are not conducted within or near connected vehicles.
[0] https://www.cyber.gov.au/business-government/asds-cyber-secu...
Of course, the question explicitly being asked (related to internal mandate) was if the firmware was signed — not if the firmware update process actually checked the signature (it certainly did not).
I'm generally aligned with this, but it is predicated on the whole "well architected" code part.
It's also a good assumption most people airing such complaints have never eaten in a restaurant fancy enough to have valet parking, let alone evil valets.
That said, are evil valets known to tote around USB drives, or would they more likely use your navigation system to drive back to your empty house and clean it out while you're eating?
They should have provided some mechanism for the real owner to approve updates if the updates aren't all trusted by default.
It works on more brands of cars too than just one gen of honda civics, and probably quicker to install.
The test can show intended use, show interesting corner cases, and I know it is up to date because it is constantly running and passing.
I think that is a huge underrated benefit of adding a lot more testing.
If I think a developer is going to ask a question of how something works, or about a corner case, isn't that deserving of a test, so they can just see proof of the answer to their question immediately rather than trying to re-derive it?
Edit: Looks like a Tegra 3 in this one, but my bet is meager RAM.
In fact, put away all this physical access nonsense and just buy it from the data broker.
Just by running them you can measure if they are in or out of sync with the code (well, if they were written correctly).
That said, if you pitched me something like a Jupyter notebook style doc where tests validating the claims of the documentation were inline, I'd totally buy into that.
Like, sure, if you're just going to use it to spy on the user, you could also rent a rental car and leave a recording device under the floormat, or hidden behind the head unit, or whatever.
But if you have an Apple Carplay exploit, where someone tethering their phone to the car can be compromised, renting a car and flashing a malicious OS to exploit the phones of people who come after you could maybe be a real attack. It's kinda hard to get people to otherwise connect to a malicious infotainment system with carplay, so if you have an exploit that requires that, this could be part of it...
Except actually, no, if you have a carplay exploit, just rent the car, and rewire the USB port to go through a flipper zero or whatever and don't bother reflashing the car's software, that's just as easy.
... So yeah, I guess I agree with you, even in the rental car scenario, where this seems like it would be worst, your attacker might as well just hide something in the car instead of flashing the software.
Another thing to consider is Honda may have signed these packages with a wink and a nudge, because it may be required, regulatory or Android or otherwise, but they're also not interested in building closed devices. Instead of thanking them we're complaining.
Three years ago, I published my initial work to understand and reverse engineer my car, specifically the headunit of my 2021 Honda Civic.1
The initial response was incredibly encouraging. I’m writing to give a project update.
The biggest progress has been made while mapping out the update process.
Honda supports updating the headunit via USB. There are a number of Honda-specific checks, but ultimately the USB drive contains a signed AOSP update file that gets staged and applied via Android recovery. The good news? They left the publicly-known AOSP test key in res/keys*, and, even though they modified the recovery binary, the verify_file signature logic matches stock AOSP.
So as long as you can properly format a USB drive and sign it with the publicly-known AOSP test key, you can install whatever you want to the headunit, without conventional root access (no need for su with setuid). This means that, as long as the headunit has power and an attacker has physical access to the front-most USB port, they have arbitrary code execution on the headunit via the update path.
This is an evil maid attack. Since it requires physical access to the cabin of the car rather than the hotel room, I call it an evil valet attack. Imagine a journalist drives to a hotel and leaves their car with the valet. The valet, who works for a three-letter agency, installs an update via USB. When the car is returned, the journalist doesn’t know the headunit has been modified. Since I want a cool vulnerability name, I’m calling this “EvilValet”.
This blog article is not intended as a technical writeup. If you want the gory details, see the technical docs.2
I’ve also published a new tool, ota-builder3, that allows people to easily prepare update files that will be accepted by the headunit. While in its early days, it should be trivial to now build an update file that, for example, installs an su binary with setuid set (i.e., to root the device).
*I have strong reason to believe that all updates are signed with the publicly-known AOSP test key, but I don’t have access to every possible official update file, nor access to every headunit variant and its filesystem. My headunit has the AOSP test key in res/keys, though I’ve also installed HondaHack, so it’s possible that it injected the key into the keystore. However, I’ve also confirmed that MRC_EU_SW_v12_4.zip, a publicly-available EU software update file, is test key signed. This file was downloaded from a public forum4 and was never modified by me. So it seems highly likely that all updates are signed with the AOSP test key. Contributors are welcome to help support or refute this hypothesis.
Beyond the update process, the most useful work has been on apk-rebuilder5. It has one very important job: take in a Honda Civic update file from the Internet, and produce a clean tree of output files that automates everything a reverse engineer would otherwise have to do manually, including:
This also serves an important role because we can’t publish actual Honda source code. We publish a function that takes in an update file (that we don’t host) and spits out Honda .smali code, image assets, etc. The resulting output follows a clear directory structure that can be referenced in documentation without actually uploading the sensitive files themselves.
There are a few outstanding things that would be nice to have.
The update process is fragile and relies heavily on version numbers. This doesn’t limit the ability to run unsigned code, because the version numbers can be “spoofed” (see the technical docs). But in order to build an update file in the first place you need to know what versions your headunit expects. Further, any changes to the headunit software that don’t match my build could lead to unexpected behavior and recovery loops.
If you drive a 10th gen Honda Civic and are tech-savvy, I encourage you to contribute to the “Known Versions, Display Audio Software” section of the repo.6
If you’re feeling particularly brave, read through the ota-builder code and try and flash an update. But do so at your own risk; if your headunit differs from mine you could get stuck in a recovery loop and softbrick your device.
I have an experimental/work-in-progress toolchain on my local machine. It takes candidate .c code and compiles it for ARMv7, using the same compiler version and build flags as the original vendor binaries. This proved indispensable in my work to understand the update process. It makes heavy use of Docker. The current iteration is messy and largely specific to my workflow, but I’d like to publish a clean implementation.
I explored this a bit while vibe-coding apk-renderer7. Custom themes are likely difficult to ship because they live in Mitsubishi’s fork of the AOSP framework, and the headunit apps are minified to expect hardcoded resource IDs. Any attempt to ship a custom theme would likely involve surgically editing the vendor framework (and writing a tool to do so automatically). None of this is trivial and probably isn’t worth the effort, but I welcome contributors.
I started working on a tool to parse .smali files and generate/map out all AIDL interfaces on the headunit. This works but I haven’t reviewed it fully for accuracy. This opens up the door for custom apps such as virtual speedometers. Contributors welcome.
I’ve placed less emphasis on reference documentation and more on tooling. The idea is that if I can ship reliable, deterministic tools that map the headunit code to more digestible forms, then people can use LLMs to query those more digestible forms to answer whatever their specific questions are. This avoids having to maintain reference docs that can stray from the actual headunit code, because the headunit code is the source of truth.
For example, a user guide that explains how to connect to the headunit via ADB is still deemed useful. But a document explaining how some Java code works, when the Java code itself is available to an LLM, seems like a maintenance burden.
At this point, I’ve done most of the investigative work I intend to do on the headunit. This is one of those projects that I could toil endlessly on, but I’ll likely transition to other projects. That said, the repo is by no means abandoned. PRs are always welcome.
Special thanks to Tunas8 for the memories, and to Hackaday9 for covering my original work.
See everyone sometime down the road 🌱
Eric
McDonald, E. (2023). “Honda Reverse Engineering”. Juniperspring. Retrieved June 13, 2026. ↩︎
McDonald, E. (n.d.). “Display Audio Update Files”. GitHub. Retrieved June 13, 2026. ↩︎
McDonald, E. (n.d.). “ota-builder”. GitHub. Retrieved June 13, 2026. ↩︎
felixlennart (September 22, 2022). “Install American firmware on European head unit”. 2016+ Honda Civic Forum (CivicX.com). Retrieved June 13, 2026. ↩︎
McDonald, E. (n.d.). “apk-rebuilder”. GitHub. Retrieved June 13, 2026. ↩︎
McDonald, E. (n.d.). “Known Versions, Display Audio Software”. GitHub. Retrieved June 13, 2026. ↩︎
McDonald, E. (n.d.). “apk-renderer”. GitHub. Retrieved June 13, 2026. ↩︎
Tunas. (n.d.). “Tunas1337”. GitHub. Retrieved June 13, 2026. ↩︎
Posch, M. (June 27, 2023). “Honda Headunit Reverse Engineering, And The Dismal State Of Infotainment Systems”. Hackaday. Retrieved June 13, 2026. ↩︎