[xandrius]

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.

[Aerolfos]

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.

[tancop]

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.

[krater23]

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?

[krater23]

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.

[ACCount37]

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.

[tclancy]

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.

[krater23]

Oh, don't understand me wrong. I've never seen a better organized embedded development process than in automotive. Review rules, reproducable builds, sometimes good unit tests(not just senseless stupid shit that wastes developer time), a test department in another room that develops test software to automate hardware in the loop tests, huge hardware in the loop test rigs that are running the newest build 24/7. IT in cars is all other than below average. It's not the move fast and break things shit of silicon valley. And it's not the 'we ship it with the next update' shit of the game industry.

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.

[Cider9986]

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

[brookst]

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.