Most active commenters
  • clipclopflop(5)

←back to thread

Tesla said it didn't have key data in a fatal crash, then a hacker found it

(www.washingtonpost.com)
650 points clcaev | 14 comments | 29 Aug 25 11:15 UTC | HN request time: 0.001s | source | bottom
1. clipclopflop ◴[29 Aug 25 12:45 UTC] No.45063380[source]▶
Years back I bought a model3 infotainment unit on eBay to hack on - it’s absolutely insane at the amount of data contained on them. After gaining access to the system I was able to get the VIN of the car and find the salvage auction from the car it came out of - it had been wrecked. I then was able to get all the location data that gets logged, showing a glimpse of the previous owners life (house, work, stores they went to, etc) as well as the final resting place of the car. The last gps locations logged were at the end of a “T” intersection in North Carolina - google street view gave a nice look at the trees the car most likely hit :>
replies(2): >>45063831 #>>45063943 #
2. foobarian ◴[29 Aug 25 13:26 UTC] No.45063831[source]▶
Neat! What's the hardware like, a Linux-ish computer with SD cards? Or SSD? Which filesystem?
replies(2): >>45063926 #>>45064556 #
3. gwbas1c ◴[29 Aug 25 13:34 UTC] No.45063926[source]▶
I suspect it's Windows, actually, and I'm pretty sure the UI is some form of C#.

They tried to recruit me for the UI. If I lived closer, I would have jumped on it. Not only was I bit of a Tesla fanboy at the time, I used to work across the street from their office and really liked that area. (Deer Creek Road in Palo Alto.)

replies(3): >>45064023 #>>45064127 #>>45064887 #
4. normie3000 ◴[29 Aug 25 13:35 UTC] No.45063943[source]▶
> a glimpse of the previous owners life...

...and potentially death?

replies(1): >>45064565 #
5. flutas ◴[29 Aug 25 13:41 UTC] No.45064023{3}[source]▶
https://github.com/teslamotors/linux
6. dagmx ◴[29 Aug 25 13:50 UTC] No.45064127{3}[source]▶
It’s Linux and the UI is Qt
7. clipclopflop ◴[29 Aug 25 14:24 UTC] No.45064556[source]▶
HW wise, the older units were intel atom based cpu (latest gen is amd I believe?) - the hardware is typical embedded stuff - cpu + eMMC + bt/wifi mcu + cellular daughter card. OS is linux + QT UI stuff. I would expect things have changed for newer HW revisions, but the previous gen did not utilize encryption (dmcrypt) so all data was unprotected at rest.
replies(1): >>45064927 #
8. clipclopflop ◴[29 Aug 25 14:25 UTC] No.45064565[source]▶
I tried to dig up news articles in the area and could not find any reported fatalities - but yea, maybe?
replies(1): >>45065582 #
9. iamjake648 ◴[29 Aug 25 14:49 UTC] No.45064887{3}[source]▶
If this were true, Tesla wouldn't have the only use able car infotainment system in the industry.
10. clipclopflop ◴[29 Aug 25 14:52 UTC] No.45064927{3}[source]▶
Following up on this - the actual 'self driving' part of the HW stack is an entirely separate board with 2x custom ARM chips on it. The HW/SW is much more locked down and the OS/Data is not accessible. I believe a lot of the self-driving info gleaned by types like green were built up from the first generation of Model S cars where the 'self driving' HW was much less defensible and it was much easier to gain access to it.
replies(1): >>45065875 #
11. js2 ◴[29 Aug 25 15:44 UTC] No.45065582{3}[source]▶
https://roadway.report/

HN submission: https://news.ycombinator.com/item?id=41012443

12. pas ◴[29 Aug 25 16:05 UTC] No.45065875{4}[source]▶
what does locked down mean here? this is almost the same situation that happened with DRM stuff like HDCP and the BluRay (?) encryption key (that was then posted all over the net), right?

at best the decryption key is somehow custom to each car, not reproducible (eg. it's made by some random manufacturing process), and then Tesla reads this and encrypts everything in a way so that only that key can open it.

but then do they keep every bit of decrypted data "on die"? (or they encrypt RAM too?)

replies(2): >>45066154 #>>45067312 #
13. bdamm ◴[29 Aug 25 16:27 UTC] No.45066154{5}[source]▶
It is now sort of common for embedded chips to generate on-die encryption keys for external processes (flash) and there could even be a one-time encryption key for the ROM (pushed to the on-die ROM and then wiped from manufacturing). Encryption RAM is basically free because the chip can generate a key internally at each boot. There can even be deeper lock-downs although obviously the deeper you go the less common it is. Getting to the on-die key can be pretty much impossible unless you can find some bootloader attacks, and then you're very much into dangerous territory. In some cases even looking for a bootloader attack can be paramount to disruption of international arms treaties, legally.

I'd expect them to also have fleet keys for stuff like navigation data. And of course, public-key based firmware signing. That's just table stakes these days.

14. clipclopflop ◴[29 Aug 25 17:54 UTC] No.45067312{5}[source]▶
Locked down meaning the storage devices are encrypted and decrypted on-the-fly via the SoC/CPU using a key programmed into the Fuses/OTP (this is usually per device keys), bootrom/loader requiring signed firmware images, limited exposure of external interfaces (attack surface) - from my memory even the Uart interface attached to the SoC was disabled very early on in the boot loader, exposing only one or two messages. I would not expect that ram is encrypted - I cannot think of a single time I have seen that implemented in a device. Maybe it’s time to dig that board out of storage and poke at it a bit more invasively, my understanding is they are not very robust when faced with fault injection :>