14 ms·

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 sam

by bri3d 5y ago

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.

ptsneves 5y ago
> 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.
- pd0wm 5y ago
  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/bri3d/VW_Flash/blob/master/docs/docs.md https://github.com/jglim/UnsignedFlash https://github.com/jglim/UnsignedFlash
- chrisseaton 5y ago
  > 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.
  - formerly_proven 5y ago
    I'm assuming they meant XOR-ECB with a block size of 1/2/4 bytes.
  - j4hdufd8 5y ago
    > XOR with very large keys is how critical military encryption systems such as radios work. Cool! Do you have any references?
    - chrisseaton 5y ago
      For example the TETRA standard for trunked radio, "The key stream bits shall be modules 2 added (XORed) with plain text bits in data, speech and control channels".
      - fanf2 5y ago
        In the TETRA specification they use the term “key stream” to mean the output of a stream cipher, which they call a “key stream generator”. They aren’t XORing directly with a large key - the TETRA key size is 80 bits. See section 6.3.2.2 of https://www.etsi.org/deliver/etsi_en/300300_300399/30039207/02.01.01_60/en_30039207v020101p.pdf https://www.etsi.org/deliver/etsi_en/300300_300399/30039207/...
        chrisseaton 5y ago
        Yes you can programatically generate a key.
- bri3d 5y ago
  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.py 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.
tyingq 5y ago
>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.
- bri3d 5y ago
  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.
  - lillecarl 5y ago
    Seeing the amount of part theft in Stockholm I understand why they do it. Particularly steering wheels, they steal them and send them to the baltics where they put them in vehicles where the airbag has fired.
    - ugjka 5y ago
      Then you solve the problem in the baltics, not use it as excuse to turn your cars into "iphones"
      - tonyedgecombe 5y ago
        What are you proposing, that Sweden invades in order to stop car part theft?
hodgesrm 5y ago
Agree. Absolutely awesome article except for this one little line: > Ensure the patches to the calibration values are safe before using. How would you do that? I've worked on both ends of steering on VW Bugs and Golfs (steering column fixes and tie rod replacements). You don't want to mess either of these up either, but the repairs are (a) well documented and (b) relatively easy to verify you did them correctly. By contrast, I've seen software break catastrophically in the past from "harmless" updates like changing the number of commas in a version string. In this case it's not the kinda doesn't work problem but hitting an unexpected corner case on the freeway that would worry me.
- bri3d 5y ago
  The calibration values were discovered through static analysis, so the code referencing those values can be followed to determine if unexpected side effects may be present. Obviously this process is imperfect, but it's not like blindly throwing bytes in and hoping something comes out. I'm not a big advocate for comma/OpenPilot or EPS patching stuff in general, but I thought the patch in this example was fairly benign and reasonable as these things go - it was a data patch to the calibration area rather than a code patch, and the altered calibration contained relatively straightforward values with clear references and obvious effects.

by bri3d 5y ago

ptsneves 5y ago

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

pd0wm 5y ago
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/bri3d/VW_Flash/blob/master/docs/docs.md https://github.com/jglim/UnsignedFlash https://github.com/jglim/UnsignedFlash
chrisseaton 5y ago
> 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.
- formerly_proven 5y ago
  I'm assuming they meant XOR-ECB with a block size of 1/2/4 bytes.
- j4hdufd8 5y ago
  > XOR with very large keys is how critical military encryption systems such as radios work. Cool! Do you have any references?
  - chrisseaton 5y ago
    For example the TETRA standard for trunked radio, "The key stream bits shall be modules 2 added (XORed) with plain text bits in data, speech and control channels".
    - fanf2 5y ago
      In the TETRA specification they use the term “key stream” to mean the output of a stream cipher, which they call a “key stream generator”. They aren’t XORing directly with a large key - the TETRA key size is 80 bits. See section 6.3.2.2 of https://www.etsi.org/deliver/etsi_en/300300_300399/30039207/02.01.01_60/en_30039207v020101p.pdf https://www.etsi.org/deliver/etsi_en/300300_300399/30039207/...
      - chrisseaton 5y ago
        Yes you can programatically generate a key.
bri3d 5y ago
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.py 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.

tyingq 5y ago

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

bri3d 5y ago
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.
- lillecarl 5y ago
  Seeing the amount of part theft in Stockholm I understand why they do it. Particularly steering wheels, they steal them and send them to the baltics where they put them in vehicles where the airbag has fired.
  - ugjka 5y ago
    Then you solve the problem in the baltics, not use it as excuse to turn your cars into "iphones"
    - tonyedgecombe 5y ago
      What are you proposing, that Sweden invades in order to stop car part theft?

hodgesrm 5y ago

Agree. Absolutely awesome article except for this one little line: > Ensure the patches to the calibration values are safe before using. How would you do that? I've worked on both ends of steering on VW Bugs and Golfs (steering column fixes and tie rod replacements). You don't want to mess either of these up either, but the repairs are (a) well documented and (b) relatively easy to verify you did them correctly. By contrast, I've seen software break catastrophically in the past from "harmless" updates like changing the number of commas in a version string. In this case it's not the kinda doesn't work problem but hitting an unexpected corner case on the freeway that would worry me.

bri3d 5y ago
The calibration values were discovered through static analysis, so the code referencing those values can be followed to determine if unexpected side effects may be present. Obviously this process is imperfect, but it's not like blindly throwing bytes in and hoping something comes out. I'm not a big advocate for comma/OpenPilot or EPS patching stuff in general, but I thought the patch in this example was fairly benign and reasonable as these things go - it was a data patch to the calibration area rather than a code patch, and the altered calibration contained relatively straightforward values with clear references and obvious effects.