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.
A number of other cars' infotainment systems are also based on ASOP. I remember downloading updates for my Hyundai which were also essentially Android images
The head units themselves are very dated and simply could not run recent versions of Android. I have a 2020 and I'm always eyeing up the after market units which are all better in every way.
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.
They’re fine. It’s a car radio, not a critical system.
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.
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.
I'm hoping this comment is a joke? It's kind of nonsensical.
> 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.
Not sure if you’re being sarcastic/satirical or not. If you are, fine.
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.
Whenever we get to talking about three letter agencies, i wish people spent more time thinking about their threat model. Is the TLA surveilling me because they're broadly interested in everybody? OK then, the return on investment isn't there to pull an evil maid attack on public randos. If the TLA is interested in you because of who you specifically are, the average individual can't begin to plug all the possible holes in their lives.
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.
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.
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.
Because it's not open for modification by the general public? (emphasis general, not just technically minded people)
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.
they can set it up to be secure by default and allow bootloader unlock like most android phones. if theres some form of owner authentication before you unlock evil maid attacks are impossible. you also need the ability to do a clean system reset and lock it again as many times as you want (no e-fuse, sorry samsung knox) so its safe to buy a used car even if the previous owner installed some spyware. all of that is tech that exists today.
How could the owner authenticate? With the car key?
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?
Okay, what is fully open? Do you really think the head unit developer would hand you over a huge developer documentation about every bit in the software?
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.
I mean, yes. I would like to know that because it’s an unacceptable state of affairs from my perspective. If the production line relied on just always having someone working who remembered things instead of a proper solution to the Hit By a Bus problem I wouldn’t be buying that brand. It is my anecdata, uninformed opinion much of IT for cars is below average development. I started to wonder about this when I got a hold of two USB images to update a Chevy Camaro in 2010 (open driver’s side door between keys to indicate you were about to install the second USB key) and it feels weird to me this is still so poorly secured. Between the Hyundai/ Kia theft is sue a couple years back and my own experience with multiple long-standing bugs in our Hyundai’s infotainment system, I am suspicious of this ever being fixed.
We can definitely see that on windows with the recent bitlocker exploit. I wonder if any new cases will be solved, or people imprisoned because of hardware in storage that can now be unlocked.
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.
That doesn’t mean you don’t bother to secure the local device. I strongly suspect you have login security in your physical devices. Maybe even full disk encryption.
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’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).
I once came across a similar "solution". The signing algorithm was directly executed from the update package. How would we otherwise be able to update the signature algorithm? Worst part was that it was correct at some point. It was an introduced regression because of a signature change due to " post-quantum safe" signatures now being required by the security team.
By the time post quantum matters for things like firmware packages the thing they've build, even if done well, will have been broken anyway in some other form. But rules are rules, thy must obey and introduce more logical errors and bug in the process.
It's not good that they allow anyone that happens to be in your car briefly root access. It'd be live having an always-on laptop in your office with a open shell on it.
They should have provided some mechanism for the real owner to approve updates if the updates aren't all trusted by default.
Who cares? The valet could do any number of other attacks, like stealing the car, sabotage, adding a tracker, whatever. Threat modeling is important, otherwise security can harm one's own goals. Sometimes you have to briefly trust another person. I'd rather have an open shell inside a locked room when the alternative is no access at all.
How do you validate “the real owner” if having the keys isn’t enough? That sufficient to steal the car.
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.
Mere possession is also enough for someone to steal your laptop, but that still shouldn't allow them to trivially install a secret persistent backdoor, or break your disk encryption.
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.
Surely due to incompetence rather than hacker friendliness though?
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.
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.
Ah but that is expensive and introduces risk of being caught doing clandestine. It is much more convenient to just use the one already installed and accepted.
In fact, put away all this physical access nonsense and just buy it from the data broker.
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.
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?
You know what, you are right on the money with that. I think if you expand to include functional/smoke/e2e tests, that covers pretty much everything documentation is supposed to be.
Just by running them you can measure if they are in or out of sync with the code (well, if they were written correctly).
I think unit tests are documentation in the same way that a Dockerfile is... it's not. The tests don't paint the bigger picture, explain why, etc.
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.
Downtown hotels often don’t have a choice, even if it’s just a Courtyard Inn etc. I har to park my 23 Civic LX at a hotel in DC before for work trip. It was like $80 a day plus tips but I could reimburse it all. Funny thing is the hotel itself was capped at $250ish.
I’ve had my civic coupe valeted at hotels and wasn’t doing staying anywhere special. Business trip where I drove the 100 miles to Baltimore and stayed at the hotel my company put me up in. Also, I’ve had medical appointments places where they valeted your car for free.
I feel like having your car valeted was something special when I was a kid, but now it doesn’t really take something special.
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?
I think the evil valet risk isn't real, but this could be part of a chain-of-attack in some scenarios, mainly rental cars.
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.
Having rented a car and seeing 80 variations of "Ben's iPhone" in the Bluetooth pairing list leads me to believe 99.99% of society isn't worried about this.
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.
No, this is a false dichotomy. It's not either "open to anyone" or "secure from anyone". There are various ways to ensure that only the owner can unlock the software, eg requiring a waiting period before unlocking.
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,...
You could, but if this unit is anything like it is in my CR-V, and its most likely the same, it's an ancient slow OMAP processor and 4GB of RAM (IIRC).
Edit: Looks like a Tegra 3 in this one, but my bet is meager RAM.
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.
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.
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.
Thanks so much for your analysis. This kind of investigation and exposure of lazy work is the reason I love hacker news.
beautifully done.
> AOSP
Android Open Source Project
for those outside the bubble!
A number of other cars' infotainment systems are also based on ASOP. I remember downloading updates for my Hyundai which were also essentially Android images
The head units themselves are very dated and simply could not run recent versions of Android. I have a 2020 and I'm always eyeing up the after market units which are all better in every way.
its not about them being dated, or fast. Its the fact that the head unit will work in 10 years vs the aftermarket one probably dying in 2.
based on aosp was not the notable part
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.
[0] https://www.cyber.gov.au/business-government/asds-cyber-secu...
They’re fine. It’s a car radio, not a critical system.
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.
Isn't NC the absolute lowest in the sensitivity system?
The point is that they want all government employees/politicians/contractors etc to understand the risks of on-vehicle electronics.
And they’ll still get very senior, and supposedly intelligent people saying “it’s just a car”.
It means “not classified”.
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.
I'm hoping this comment is a joke? It's kind of nonsensical.
> 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.
???
Not sure if you’re being sarcastic/satirical or not. If you are, fine.
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.
Whenever we get to talking about three letter agencies, i wish people spent more time thinking about their threat model. Is the TLA surveilling me because they're broadly interested in everybody? OK then, the return on investment isn't there to pull an evil maid attack on public randos. If the TLA is interested in you because of who you specifically are, the average individual can't begin to plug all the possible holes in their lives.
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.
You think there isn’t some boring scientist or engineer with classified access who doesn’t drive a boring civic to work?
but he is boring, why would you spy on him in his car ?
Why not when it's so trivial?
Because he’s talking to himself about work.
Or he's calling his mistress/lover from the safety of his car and now he's open to blackmail.
This is great information, thank you for posting!
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.
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.
Because it's not open for modification by the general public? (emphasis general, not just technically minded people)
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.
they can set it up to be secure by default and allow bootloader unlock like most android phones. if theres some form of owner authentication before you unlock evil maid attacks are impossible. you also need the ability to do a clean system reset and lock it again as many times as you want (no e-fuse, sorry samsung knox) so its safe to buy a used car even if the previous owner installed some spyware. all of that is tech that exists today.
How could the owner authenticate? With the car key?
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?
Okay, what is fully open? Do you really think the head unit developer would hand you over a huge developer documentation about every bit in the software?
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.
Yeah, that's the status quo.
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.
I mean, yes. I would like to know that because it’s an unacceptable state of affairs from my perspective. If the production line relied on just always having someone working who remembered things instead of a proper solution to the Hit By a Bus problem I wouldn’t be buying that brand. It is my anecdata, uninformed opinion much of IT for cars is below average development. I started to wonder about this when I got a hold of two USB images to update a Chevy Camaro in 2010 (open driver’s side door between keys to indicate you were about to install the second USB key) and it feels weird to me this is still so poorly secured. Between the Hyundai/ Kia theft is sue a couple years back and my own experience with multiple long-standing bugs in our Hyundai’s infotainment system, I am suspicious of this ever being fixed.
We can definitely see that on windows with the recent bitlocker exploit. I wonder if any new cases will be solved, or people imprisoned because of hardware in storage that can now be unlocked.
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...
That doesn’t mean you don’t bother to secure the local device. I strongly suspect you have login security in your physical devices. Maybe even full disk encryption.
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’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).
I once came across a similar "solution". The signing algorithm was directly executed from the update package. How would we otherwise be able to update the signature algorithm? Worst part was that it was correct at some point. It was an introduced regression because of a signature change due to " post-quantum safe" signatures now being required by the security team.
By the time post quantum matters for things like firmware packages the thing they've build, even if done well, will have been broken anyway in some other form. But rules are rules, thy must obey and introduce more logical errors and bug in the process.
I'm surprised someone named BobbyTables2 wouldn't go straight for the proper way to check email PGP signatures...
IMHO this is a good sign(!?) that they didn't even think about locking down their systems against the owner.
It's not good that they allow anyone that happens to be in your car briefly root access. It'd be live having an always-on laptop in your office with a open shell on it.
They should have provided some mechanism for the real owner to approve updates if the updates aren't all trusted by default.
Who cares? The valet could do any number of other attacks, like stealing the car, sabotage, adding a tracker, whatever. Threat modeling is important, otherwise security can harm one's own goals. Sometimes you have to briefly trust another person. I'd rather have an open shell inside a locked room when the alternative is no access at all.
You would notice if someone stole your car though.
How do you validate “the real owner” if having the keys isn’t enough? That sufficient to steal the car.
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.
Mere possession is also enough for someone to steal your laptop, but that still shouldn't allow them to trivially install a secret persistent backdoor, or break your disk encryption.
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.
Surely due to incompetence rather than hacker friendliness though?
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.
Maybe turning cars into gigantic computers on wheels was a bad thing? more study required.
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 you have physical access to a car and want to phone home, may I recommend leaving a gps tracking device under the floormat.
It works on more brands of cars too than just one gen of honda civics, and probably quicker to install.
Ah but that is expensive and introduces risk of being caught doing clandestine. It is much more convenient to just use the one already installed and accepted.
In fact, put away all this physical access nonsense and just buy it from the data broker.
This is a good thing because it means I can sign something that will work if I own that hardware
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.
I'd rather see unit tests as documentation.
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?
You know what, you are right on the money with that. I think if you expand to include functional/smoke/e2e tests, that covers pretty much everything documentation is supposed to be.
Just by running them you can measure if they are in or out of sync with the code (well, if they were written correctly).
I think unit tests are documentation in the same way that a Dockerfile is... it's not. The tests don't paint the bigger picture, explain why, etc.
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.
LLMs are great at writing unit tests.
The irony in this is that it's hard to imagine a Civic owner going to a luxury hotel with a valet. Maybe a Type R owner with a stretch...
Downtown hotels often don’t have a choice, even if it’s just a Courtyard Inn etc. I har to park my 23 Civic LX at a hotel in DC before for work trip. It was like $80 a day plus tips but I could reimburse it all. Funny thing is the hotel itself was capped at $250ish.
I’ve had my civic coupe valeted at hotels and wasn’t doing staying anywhere special. Business trip where I drove the 100 miles to Baltimore and stayed at the hotel my company put me up in. Also, I’ve had medical appointments places where they valeted your car for free.
I feel like having your car valeted was something special when I was a kid, but now it doesn’t really take something special.
Mechanics, car wash, anyone who can unlock the vehicle while it’s parked.
On the other hand rom-ing your civic sounds easy
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?
I think the evil valet risk isn't real, but this could be part of a chain-of-attack in some scenarios, mainly rental cars.
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.
Having rented a car and seeing 80 variations of "Ben's iPhone" in the Bluetooth pairing list leads me to believe 99.99% of society isn't worried about this.
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.
Yeah ultimately society really relies on the fact that most people aren't actively trying to be evil.
No, this is a false dichotomy. It's not either "open to anyone" or "secure from anyone". There are various ways to ensure that only the owner can unlock the software, eg requiring a waiting period before unlocking.
The framing of this article sucks.
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,...
full ack
Honda knows how to build great cars but they haven't up-skilled their software knowledge.
The Honda-e had one of the best aquarium simulation software, 90s style. It was sold from 2020 but still.
Previously: Show HN: Honda Civic Infotainment Reverse-Engineering - https://news.ycombinator.com/item?id=36052753 - May 2023 (43 comments)
>>> you could get stuck in a recovery loop and softbrick your device.
Your car …
Relying on users to use an LLM to generate their own docs presupposes that the users have a Claude subscription or whatever. That sucks imo
Could you use this to get a version of lineage OS running on it?
You could, but if this unit is anything like it is in my CR-V, and its most likely the same, it's an ancient slow OMAP processor and 4GB of RAM (IIRC).
Edit: Looks like a Tegra 3 in this one, but my bet is meager RAM.
Yes, but it'll still be using their kernel so not all functionality from lineage might work.
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.
EvilValet, sick
Yeah jealous he even got to name an attack surface. Damn.
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.