To update 10th-gen Honda Civics, Honda ships updates on specially-formatted USB drives. They're essentially Android 4.2.2rc1-era recovery packages with some Honda-added version checks (which can be spoofed). The packages are signed with the publicly-known AOSP test key, so with physical access to the front USB port you can sign and flash your own package for arbitrary code execution on the headunit. This doesn't require root/su. I've run it end-to-end on my own 2021 Civic and separately confirmed an official EU update file carries the AOSP test-key signature. Tooling and writeup in the post.
Seeing more and more projects eschew code docs with the idea that "well architected code can be queried by LLMs" and stick to more functional runbook style docs. It really is unlikely that at any given point all of the docs of a project are up to date with the code.
I'm generally aligned with this, but it is predicated on the whole "well architected" code part.
Hyundai head units at one point used an RSA key you got by googling “RSA key” (no joke: https://programmingwithstyle.com/posts/howihackedmycar/ ), an honestly even more amazing mistake since it required effort rather than just a default.
I’ve heard product managers proudly proclaim their firmware was signed using the corporate internal signing service (good).
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).
Wonder how good the rest of the security is. The head unit is likely hooked up to a CAN gateway, can it call into telematics. Maybe find some novel way to abuse carplay/aa to call home.
If I'm reading the room, the sentiment is Honda is incompetent and their cars are security holes on wheels. But if the opposite happened, they would be technofascists locking us out of our own cars, a 30 post sub-thread "this is why I drive a 1999 Ford Ranger" would ensue, and someone would be investigating it as a possible GPL violation. Do I have this right?
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?
Most (if not all) cars on the road are terrible in terms of the security of the infotainment system and other onboard electronics. What makes this even worse is the sensors they have onboard these days; the microphones, cameras, GNSS receivers, wifi and BT radios make them into mobile surveillance platforms.
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.
In one thread people fighting the ever decreasing amount of hw ownership of most devices in our lives and when we have one that is more open, the crowds come to attack that too.
The theat model with tech has always been that if an attacker has physical access to the device and time then it's game over.
I wish other car makers were as reasonable as Honda here.
No "evil valet" with half a brain cell would waste time hacking the head unit if they have physical access to the car. They would simply hide a spying device somewhere in the car.
Not to mention that people with Civics are never targets of three letter agencies.
It is rather cool that you can hack your own car that easily. Framing it like "the evil valet" gives incentive and excuse to the manufacturer to lock down everything. While a real 3 letter agency evil valet will not car anyway. There is an endless list of things that it can do anyway, like put microphone in 100 places, change the electronic, get the key from the manufacturer, add man in the middle devices,...
It's difficult for car manufacturer theese days. You do proper security with secure boot etc. and the reverse engineering homebrew community complains about no way to install own software. You use the public known test key that everyone can do homebrew stuff when he wants, the reverse engineering homebrew community calls it a security risk.
In my opinion this auther don't know what he wants.
I think Porsche (and related brands) also have this or a somewhat similar vulnerability. Owners use it to add Android Auto to a car that formerly only supported Apple Carplay.
That's VW AG "MIB" - a lot of these units had fixed per-infotainment-model root passwords and a shell service exposed over SSH or Telnet, so one could dump the flash memory directly from the board and crack the password hashes, then use some exposed network interface (on some, WiFi, on others, a USB Ethernet device would work) to get a shell.
Eventually a better vulnerability was discovered where the signature validator didn't work properly:
The vulnerability used there is explained here: https://github.com/jilleb/mib2-toolbox/issues/122 . It's a "classic" mistake in signature validation (iirc the Windows software licensing service had a similar vuln at some point) but is a lot less trivial than this one; basically, the signature validator would stop validating once validation succeeded, so it was possible to take a valid update manifest and just tack more instructions onto the end of it and it would happily run them (the validation would return True, and then the command-runner would happily iterate through everything it got).
There's also a vulnerability on the lower tier models that revolves around a logic error and a signed update which would copy unsigned files into a directory due to some issue with the path validation that I can't completely recall at this point, as used in https://github.com/olli991/mib-std2-pq-zr-toolbox .
Anyway, these were a lot more exciting from a vuln research standpoint than this one (the MIB head units are also _fascinating_; they are not standard Tegra Android devices but a morass of rare and exotic DSP hardware driven by QNX and a giant enterprise IBM Java applicatoin).
32 comments
[ 3.4 ms ] story [ 63.6 ms ] threadI'm generally aligned with this, but it is predicated on the whole "well architected" code part.
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).
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?
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...
The theat model with tech has always been that if an attacker has physical access to the device and time then it's game over.
No "evil valet" with half a brain cell would waste time hacking the head unit if they have physical access to the car. They would simply hide a spying device somewhere in the car.
Not to mention that people with Civics are never targets of three letter agencies.
It is rather cool that you can hack your own car that easily. Framing it like "the evil valet" gives incentive and excuse to the manufacturer to lock down everything. While a real 3 letter agency evil valet will not car anyway. There is an endless list of things that it can do anyway, like put microphone in 100 places, change the electronic, get the key from the manufacturer, add man in the middle devices,...
Your car …
In my opinion this auther don't know what he wants.
Eventually a better vulnerability was discovered where the signature validator didn't work properly:
The vulnerability used there is explained here: https://github.com/jilleb/mib2-toolbox/issues/122 . It's a "classic" mistake in signature validation (iirc the Windows software licensing service had a similar vuln at some point) but is a lot less trivial than this one; basically, the signature validator would stop validating once validation succeeded, so it was possible to take a valid update manifest and just tack more instructions onto the end of it and it would happily run them (the validation would return True, and then the command-runner would happily iterate through everything it got).
There's also a vulnerability on the lower tier models that revolves around a logic error and a signed update which would copy unsigned files into a directory due to some issue with the path validation that I can't completely recall at this point, as used in https://github.com/olli991/mib-std2-pq-zr-toolbox .
Anyway, these were a lot more exciting from a vuln research standpoint than this one (the MIB head units are also _fascinating_; they are not standard Tegra Android devices but a morass of rare and exotic DSP hardware driven by QNX and a giant enterprise IBM Java applicatoin).