VW_Flash

If it is a crime, then chip tunning companies are having suicidally noisy marketing. Furthermore one of HN users has this repo up https://github.com/bri3d/VW_Flash It is doing what chip tunning companies are doing but in less polished package. If it is a crime, why is it still up?

I did find an older VW "emergency start" product that claims to only work with Bosch MED17 and MED9, and I suspect it's using a memory-access primitive (either UDS or CCP) to release the immobilizer. It's trivial to disable an immobilizer in software by re-flashing the ECU, yes, but modern ECUs have two strong protections against this: * Cryptographic signature checking against update/re-flash payloads (I've done extensive research on these on VW Continental ECUs - https://github.com/bri3d/VW_Flash ) and an even better and more obvious protection: * The ECU application software won't descend into the re-flash software (Customer Bootloader) unless the immobilizer is free (a valid key is present). This is a lot of what helps to reduce surface area from an "emergency start" style attack to an AKL attack - now that the Customer Bootloader won

This year I don't anticipate having much free time, so I'm trying to engage more contributors in side projects, * Automotive ECU tooling, https://github.com/bri3d/VW_Flash * DJI FPV forward/reverse/all sorts engineering, https://github.com/fpv-wtf I've been working a lot with various folks using Discord and contributions are gradually shifting from me towards others, which has been great to see. As the old adage goes, teaching a project is truly the final form of knowing one - much harder than hacking alone, but ultimately more fulfilling. When I started my automotive ECU journey my goal was to demystify the "tuning" scene for a broader software engineering community, and I think I've generally been successful at this.

This week, as most weeks, I split my time outside of the day job and my other hobbies and obligations between a few projects: https://github.com/bri3d/VW_Flash - Flashing tools for select control modules in VW MQB and now PQ35 platform cars. This week I'm working on old stuff: a simpler exploit chain for older Simos ECUs, as well as tweaks to expand support to older DSG control units used in PQ35 platform vehicles. https://github.com/fpv-wtf/msp-osd - I pushed a rearchitect of this on-screen-display overlay system for DJI FPV Goggles last week that seems to have sorted out a lot of issues - I switched from just passing through the OSD drawing messages from the Flight Controller to a system where the video transmitter maintains the OSD character buffer and sends a compressed representation of the screen state. This makes the system much mo

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

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

I have been reverse engineering automotive ECUs for a while now - https://github.com/bri3d/VW_Flash . It's a nice change from my day job in enterprise engineering management, and I've met some fun people and taught several folks a lot of new concepts, which is always extremely rewarding. My latest project has been reverse engineering the data-flash encryption in Simos18 ECUs. After some work, it oddly appears the encryption algorithm used is Mifare Hitag2. I'm hoping to be able to re-encrypt NVRAM channels soon, although the overall data flash "filesystem" / channel-system layout needs some more work before I am ready to release my findings.