Live data from Hacker News

Hacking a VW Golf Power Steering ECU

blog.willemmelching.nl

1–10 of 174 posts

Re: Hacking a VW Golf Power Steering ECU

#2
This is probably one of the best write-ups I've seen around the basics of automotive control unit reverse engineering.

More modern VW control units are the same in broad strokes - they use UDS on ISO-TP instead of KWP on TP2.0, but this is just evolution of the same fundamentals. And instead of the wacky SGO format inside of FRF update files, they use the ASAM MCD-2 D-ODX format to define flashing layers. Most European automakers are similar.

One interesting difference and trend in automotive control modules (also mentioned in Willem's fantastic write-up) is that many EU modules started adding signature checking and encrypted updates in the late 2000s, while most US and Japanese automakers have only done so in the last 2-3 years.

These encrypted and signature checked updates are by and large still fairly vulnerable - often due to logic errors in the complex upgrade processes and occasionally due to a strange insistence on using RSA using PKCS#1.5 with e=3 and inadequate padding validation.

Re: Hacking a VW Golf Power Steering ECU

#3
post #2

This is probably one of the best write-ups I've seen around the basics of automotive control unit reverse engineering. More modern VW control units are the same in broad strokes - they use UDS on ISO-TP instead of KWP on TP2.0, but this is just evolution of the same fundamentals. And instead of the wacky SGO format inside of FRF update files, they use the ASAM MCD-2 D-ODX format to define flashing layers. Most Europe…

> One interesting difference and trend in automotive control modules (also mentioned in Willem's fantastic write-up) is that many EU modules started adding signature checking and encrypted updates in the late 2000s

Do you mean the XOR encryption used? As someone working on the embedded linux(!= than embedded MCU) side i was very surprised to find such a crude "encryption" scheme employed. On the other hand i reckon there is only so much encryption an 8bit MCU can do. Also tolerance for complex encryption designs must be very low when you are trying to limit the scope of a life critical component.

The anti brute force measure was a bit more refined and almost got the job done.

Regardless, i agree. An great write-up. The binwalk and narrow down of possible CPUs used due to the ASIL-D constraint were really illuminating.

Re: Hacking a VW Golf Power Steering ECU

#4
post #2

This is probably one of the best write-ups I've seen around the basics of automotive control unit reverse engineering. More modern VW control units are the same in broad strokes - they use UDS on ISO-TP instead of KWP on TP2.0, but this is just evolution of the same fundamentals. And instead of the wacky SGO format inside of FRF update files, they use the ASAM MCD-2 D-ODX format to define flashing layers. Most Europe…

>many EU modules started adding signature checking and encrypted updates in the late 2000s

Ah, yeah, and this is irritating if you're a used car owner, particularly an owner of a car that's now lower value. I can't, for example, pick up a cheap used throttle body for my older Volvo because the main ECU will reject it until someone from the stealership charges me a LOT of money to "program" it.

Re: Hacking a VW Golf Power Steering ECU

#5
post #3
post #2

This is probably one of the best write-ups I've seen around the basics of automotive control unit reverse engineering. More modern VW control units are the same in broad strokes - they use UDS on ISO-TP instead of KWP on TP2.0, but this is just evolution of the same fundamentals. And instead of the wacky SGO format inside of FRF update files, they use the ASAM MCD-2 D-ODX format to define flashing layers. Most Europe…

> One interesting difference and trend in automotive control modules (also mentioned in Willem's fantastic write-up) is that many EU modules started adding signature checking and encrypted updates in the late 2000s Do you mean the XOR encryption used? As someone working on the embedded linux(!= than embedded MCU) side i was very surprised to find such a crude "encryption" scheme employed. On the other hand i reckon t…

The XOR encryption was just for the update container. Newer update files usually employ some stronger forms of compression/encryption. However, it's usually some strange in-house crypto, so eventually people figure it out.

bri3d refers to using RSA signatures on the firmware once it's written to the flash. By ensuring the firmware is signed using the manufacturers private key it should (in theory) prevent messing with the firmware, even if all encryption/flashing steps have been reverse engineered.

Some interesting reading: https://github.com/bri3d/VW_Flash/blob/master/docs/docs.md https://github.com/jglim/UnsignedFlash

Re: Hacking a VW Golf Power Steering ECU

#6
post #3
post #2

This is probably one of the best write-ups I've seen around the basics of automotive control unit reverse engineering. More modern VW control units are the same in broad strokes - they use UDS on ISO-TP instead of KWP on TP2.0, but this is just evolution of the same fundamentals. And instead of the wacky SGO format inside of FRF update files, they use the ASAM MCD-2 D-ODX format to define flashing layers. Most Europe…

> One interesting difference and trend in automotive control modules (also mentioned in Willem's fantastic write-up) is that many EU modules started adding signature checking and encrypted updates in the late 2000s Do you mean the XOR encryption used? As someone working on the embedded linux(!= than embedded MCU) side i was very surprised to find such a crude "encryption" scheme employed. On the other hand i reckon t…

> Do you mean the XOR encryption used? As someone working on the embedded linux(!= than embedded MCU) side i was very surprised to find such a crude "encryption" scheme employed.

I'm not a cryptographer - but I don't think there's anything wrong with XOR encryption, and I'm not sure why you're putting it in scare-quotes - XOR with a sufficiently large key is absolutely fine, and with a one-time pad is unbreakable. XOR with very large keys is how critical military encryption systems such as radios work.

Re: Hacking a VW Golf Power Steering ECU

#7
post #3
post #2

This is probably one of the best write-ups I've seen around the basics of automotive control unit reverse engineering. More modern VW control units are the same in broad strokes - they use UDS on ISO-TP instead of KWP on TP2.0, but this is just evolution of the same fundamentals. And instead of the wacky SGO format inside of FRF update files, they use the ASAM MCD-2 D-ODX format to define flashing layers. Most Europe…

> One interesting difference and trend in automotive control modules (also mentioned in Willem's fantastic write-up) is that many EU modules started adding signature checking and encrypted updates in the late 2000s Do you mean the XOR encryption used? As someone working on the embedded linux(!= than embedded MCU) side i was very surprised to find such a crude "encryption" scheme employed. On the other hand i reckon t…

No, this EPS control module is remarkably primitive even by late 2000s standards and several generations behind today's state of the art.

More modern control modules with a bit more resource available to them will use AES as the symmetric encryption (although there are also fixed-key XOR schemes and custom stuff used like this: https://github.com/bri3d/VW_Flash/blob/master/lib/decryptdsg... ).

The keys and even IV are usually fixed across a "model line" of ECUs, so once a decrypted flash memory can be extracted, this isn't much of a protection measure, but it's a lot better than XOR.

Then, in more modern control units, flash areas are also usually protected by both a checksum (usually some CRC permutation, although cute tweaks and random nonsense are common here too) and some form of digital signature.

Re: Hacking a VW Golf Power Steering ECU

#8
post #4
post #2

This is probably one of the best write-ups I've seen around the basics of automotive control unit reverse engineering. More modern VW control units are the same in broad strokes - they use UDS on ISO-TP instead of KWP on TP2.0, but this is just evolution of the same fundamentals. And instead of the wacky SGO format inside of FRF update files, they use the ASAM MCD-2 D-ODX format to define flashing layers. Most Europe…

>many EU modules started adding signature checking and encrypted updates in the late 2000s Ah, yeah, and this is irritating if you're a used car owner, particularly an owner of a car that's now lower value. I can't, for example, pick up a cheap used throttle body for my older Volvo because the main ECU will reject it until someone from the stealership charges me a LOT of money to "program" it.

This is unlikely to be related to encryption but just protectionism on an older vehicle. Generally speaking, until very recently (like 1-2 years ago), non-immobilizer related adaptation processes are just a matter of finding the correct UDS remoteRoutine to invoke, and aren't cryptographically protected at all. It's likely that the thing you're missing is the diagnostic documentation for the correct routine invocations to send, rather than keys or certificates.

Although, unfortunately this too is changing, starting in the 2021 model year VW AG have introduced a rather evil technology called SFD which requires server-signed tokens to perform these kinds of basic adaptations. This is all being done in the name of anti-theft security.

We really need better right-to-repair rules for vehicles.

Re: Hacking a VW Golf Power Steering ECU

#9
This may go without saying, but a word of caution for anyone who wants to try this themselves: doing any sort of automated scanning of ECU hardware (e.g. the equivalent of trying to find undocumented opcodes in a CPU) stands a good chance of bricking the hardware (permanently), so plan to buy several of them if you want/need to go that route.

Re: Hacking a VW Golf Power Steering ECU

#10
As cool as this is, I will never EVER hack/jailbreak car steering. I can't put my faith in unsupported (non-OEM may be a better term for it) software keeping me safe. I watch the tesla autopilot videos of them totally messing up and that is fully supported but still failing too much.

But cool POC for sure.

Post reply on HN