Honda Civics and the Evil Valet

Android Open Source Project

for those outside the bubble!

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.

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.

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.

> 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.

???

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.

They should have provided some mechanism for the real owner to approve updates if the updates aren't all trusted by default.

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 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?

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.

Edit: Looks like a Tegra 3 in this one, but my bet is meager RAM.

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).