[fmntf]

Kudos to the author! I did some research in my car a few years ago. Unfortunately, the update packages were properly signed. So I reversed the CAN traffic and replaced the infotainment ECU with my own reimplementation. I published my work and findings on medium thinking that nobody could notice them... I have got a job in the automotive industry instead.

[bri3d]

That's pretty cool! I wonder how properly they were really signed - there are _so many_ mistakes even in systems that at least don't use an example key off the Internet.

The most common ones I know of are:

* Out-of-bounds write issues allowing "signature was validated" flags to be overwritten in Flash memory, like https://github.com/jglim/UnsignedFlash

* State machine mistakes, like https://github.com/bri3d/VW_Flash/blob/master/docs/docs.md - allowing Flash to be written again after it was already written, without an erase first.

* File format parsing mistakes, like those in a number of VW AG head units: https://github.com/jilleb/mib2-toolbox/issues/122

* The use of RSA with E=3 and inadequate padding validation, like https://words.filippo.io/bleichenbacher-06-signature-forgery... .

* Failure to understand the system boundaries, like in the second part of https://github.com/bri3d/simos18_sboot where "secret" data can be recovered by halting the system during a checksum process.

* Hardware fault injection issues, as used in https://fahrplan.events.ccc.de/congress/2015/Fahrplan/system... .

Fundamentally this is of course, a very hard problem, since in the "protect against firmware modification" case, the attacker has physical access. But, compared to the state of the art in mobile devices and game consoles, automotive stuff is still way behind.

[fmntf]

The infotainment of the car maker had some oddities: * the binaries were signed with a certificate emitted by a big certification company, repacking an update package could be challenging * the system ran a fork of Windows CE and was co-developed with Microsoft * the SoC documentation was only available under NDA (I was able to find only a one page datasheet)

For those reasons, instead of trying to repack the software for the original ECU, I started to sniff the CAN traffic and analyzing the binaries contained in the software update packages found online. That allowed me to reimplement the communication with other ECUs on a Linux SBC.

[bri3d]

Yes, a full replacement absolutely makes sense in this situation! I don't think there are many Windows infotainment units left these days. Analyzing the binaries to figure out the meaning of the CAN traffic is an awesome (and underutilized IMO) technique - I see people sit and stare at CAN dumps in a vacuum a lot when really, whatever checksum or data they're looking for is often right there in the code.

[fmntf]

Actually there still are a lot of Windows ECUs in the wild. I analyzed the update packets of newer cars than mine (equipped with Uconnect) finding even sndrec.exe and the default page of IIS! Fortunately my company produces Linux-based ECUs, and we use Windows only for Autosar stuff.

[rasz]

Any reason for not linking to that medium post? Did the new employer politely ask you to take it down?

[navanchauhan]

They probably did not want to self-promote. Here is a link to their Medium articles: https://medium.com/@fmntf

[fmntf]

I just do not like self promotion. My employer does not care of my posts, they were published before signing my current contract. I have stopped writing posts by myself since I have now access to tons of documents and specifications.