Honda Civics and the Evil Valet
juniperspring.org
Previously: Show HN: Honda Civic Infotainment Reverse-Engineering - https://news.ycombinator.com/item?id=36052753 - May 2023 (43 comments)
juniperspring.org
Android Open Source Project
for those outside the bubble!
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 people who are vulnerable to this type of attack have procedures and trusted equipment to conduct their business (or not). US police agencies have had rules like this for rental cars since OnStar came out.
Most of the dangerous telematics information for the average person is offered for sale anyway.
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).
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.
Manufacturers need to pick a lane - either fully open, and then people who need it can harden their own stuff (and at least be aware of the tradeoff), or fully closed and secure.
This in-between where cars are invasive privacy nightmares that spy on you at all driving hours, and are insecure nightmares that will give up that data to anyone remotely invested, is the worst case scenario, obviously.
How could you do a clean system reset after someone had access to all installed software/data including the cryptographic keys? The information is gone, maybe the recovery partition is changed. How could you securely recover?
I'm freelancer and helped to develop some head units. I have a surprize for you: This documentation mostly doesn't exsists. Most of the time there are some chip datasheets and requirement documents, depending on the customer(car manufacturer) they are good or bad and then are some partly outdated wiki pages written down for some important special things. You learn all other stuff out of the code or from your colleagues.
Wait two years and the most knowledge is gone, except of the things that are used for the next head unit.
The biggest advantage actual developers have is access to the NDA'd vendor docs and the official SDKs. And, the vendor docs are bad and the official SDKs are a mess. Internal documentation? You'd be lucky if it's two steps above "nonexistent". It's usually just one step.
BUT, there is no documentation because there is no time to do it. There are SOP-1(Start of Production). This date is carved in stone. When a feature is not done for SOP-1, than it is not delivered in SOP-2. SOP-2 happens normally 6 month later. After that, updates are only done when something bad happens. The complete team moves on to the next head unit.
So, I would expect your bugs will not get fixed in any way, at least when they are not important enough to mobilize a new small team or some people that worked on it to fix them. Normally shortly before SOP-2, all tickets are closed, known bugs too. That feels a little frustrating as customer, but more as developer.
Oh, and don't think that you can run away from that by buing another brand. Normally not your car manufacturer develops the head unit. It's other companies and they work all the same and they work for all car companies.
It's definitely better to not keep data locally if it's going to be seized, because of varying laws that can coerce unlocking, but in the U.S., it should be safe to refuse to give up passwords.
On the technical side, Google and Apple have changed the game with numerous improvements to physical security and GrapheneOS takes it even further building on their foundation reducing attack surface and adding good features. Particularly with Auto reboot[1] becoming widely adopted, your conclusion can be modified on phones.
[2]:
>This (https://osservatorionessuno.org/blog/2026/05/demystifying-ph...) is an article by an Italian non-profit that provides an introductive technical overview to forensic phone unlocking exploit kits used by governments and law enforcement, most notably Cellebrite.
>This post provides an overview on how disk encryption works on Android, common attack vectors used by forensic tools to brute force or extract a device, their countermeasures against popular security features like automatic reboot in iOS and how you can protect yourself against such tools, including several mentions about GrapheneOS.
[1] https://grapheneos.org/features#auto-reboot
[2] https://discuss.grapheneos.org/d/35728-demystifying-phone-un...
Just because a sufficiently advanced and determined attacker can own any device with physical access doesn’t mean we might as well make it easy for anyone.
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.
> I wish other car makers were as reasonable as Honda here.
I doubt they did this on purpose.
> No "evil valet" with half a brain cell would waste time hacking the head unit if they have physical access to the car.
Keep in mind that head units usually also contain historic data; stuff like left-over synced phone contacts in SQLite databases, historic location data collected either explicitly for telemetry or accidentally in log files etc.
Additionally, head units usually have access to a lot of internal buses in a car; depending on manufacturer there's sometimes some level of firewalling effort, for example through a Gateway module, but these firewalls are usually quite weak when they are present at all (see: the famous thing with Honda unlock and starter release working with no cryptographic material through the same CAN bus as the headlights). This means that the infotainment can usually control some part of the car, and is much more powerful than a tracking device.
Plus, implanting code (or just extracting the data that's already there) from a head unit leaves much less evidence than adding an additional tracker.
> Not to mention that people with Civics are never targets of three letter agencies.
???
People who drive Civics are boring, normal people with boring, normal lives. Not of any interest to the NSA.
But if you’re not - why would someone driving a civic not be a target of an intelligence agency? It’s one of the most common cars about there, so if you want to fade into the background it’s a perfect car. Also, lots of otherwise “normal” people - scientists, engineers, journalists, lawyers - likely drive Honda civics.
A spying device hidden in the car may be found. Something installed directly within the car’s firmware is somewhat less likely to be found.
As a Honda owner (but the kind the company probably doesn't really really love since i'm still driving a 2006) i actually think it's better for the long haul that their cars are hackable given physical possession.
They should have provided some mechanism for the real owner to approve updates if the updates aren't all trusted by default.
You could do a PIN/password, but if it is never used during operation, nobody will know it. Ask anyone who’s had a head unit that needed a PIN after losing power.
Agree that a PIN/Password would have usability problems with a car. Since no car manufacturer intentionally permits you to install software you want, there's no standard mechanism. But if this was standard I think an owner-set PIN would be very reasonable.
Some cars have special valet keys, which prevent aggressive driving and high speeds, and maybe that’s the solution? But of course it means remembering to bring the special key.
Maybe the answer is just to look at loaning your car the same as handing your unlocked laptop to someone.
Otherwise they would have had something like an unlockable bootloader where you need a special key to unlock it, or something difficult to access switch or something like that.
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,...
I think there is a line between security, and keeping a device useful in the long term. I think the threat of people installing listening malware on the car via an evil-maid type attack is low.
However, when these cars are 10+ years old, and are in the hands of those willing to tinker, I think the ability to open up the software and customize will be a great thing. Hopefully communities form around creating modifications they find useful, and prolongs the life of the devices.
Seems much better than the end-users ripping out the factory head unit to install the Aliexpress "Android Tablet" style units, which likely have much worse security and engineering than the Honda units they'd be replacing.
It works on more brands of cars too than just one gen of honda civics, and probably quicker to install.
In fact, put away all this physical access nonsense and just buy it from the data broker.
In my opinion this auther don't know what he wants.
I'm generally aligned with this, but it is predicated on the whole "well architected" code part.
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?
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.
Just by running them you can measure if they are in or out of sync with the code (well, if they were written correctly).
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?
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.
Edit: Looks like a Tegra 3 in this one, but my bet is meager RAM.
But we go back to the old question of: Why do I have to rely on hacks ( like with cellphones, tvs and so on )? Why am can't it be ready for heavy customization ootb ( and before you tell me that people do dangerous stuff on the roads -- have you driven around lately )?
I feel like having your car valeted was something special when I was a kid, but now it doesn’t really take something special.
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).
Your car …