GM E38 E67 E40 Kernel/Bootloader Development Extravaganza

[Tazzi]

I have hp tuners and an a car with an e37 ecu is there anything i can do to help?

Not at this time, but thankyou!

[crystal_imprezav]

Any interest in E99 development?

[Tazzi]

Any interest in E99 development?

With enough help, sure.
But as this is one of the modern ecus which use signed calibrations, and also I believe use FD CAN too, it will require quite alot of work and help.

[Gatecrasher]

2019 Corvette ZR1 with the E99 used regular CAN.

I think the bigger problem is the software signing. ZR1 was never cracked. We're four model years into the Global B stuff nobody has made any progress on that either. Trifecta said they got into the Cadillac and C8 Corvette ECUs, but they never followed up on their initial claims.

In addition to all that, there's the trust relationship between the gateway and other ECUs in the Global B cars. So even if you could alter the software, you'd have to figure out how to re-authorize it to the rest of the car.

[Tazzi]

2019 Corvette ZR1 with the E99 used regular CAN.

I think the bigger problem is the software signing. ZR1 was never cracked. We're four model years into the Global B stuff nobody has made any progress on that either. Trifecta said they got into the Cadillac and C8 Corvette ECUs, but they never followed up on their initial claims.

In addition to all that, there's the trust relationship between the gateway and other ECUs in the Global B cars. So even if you could alter the software, you'd have to figure out how to re-authorize it to the rest of the car.

Hm, I swear I read that in the factory manual that it was FDCAN? Must be thinking of another GM ECU then?

Not too sure about the global B based modules authorization your referring to though. I haven't messed with Global B enough to know the security side inside out for how it differs to global A.

Ignoring the signing of calibrations at this time, make the assumption you can upload anything you want to it. Unless every single module in the car has the "calibration signature" from every other module in the car saved in its memory, then there is no reason why any module, including gateway module, would know or care.

Now coming back to signatures. At the end of the day, these signatures are verified by internal firmware of the cpu. These cpus have been hardware locked so you can't just modify via jtag/bdm/dev tools, but this does not mean other access methods cannot be used such as high privilege unlocking (27 03), boot time security flaws (before main OS kicks in), recovery OS insecurities ect. Sometimes to most basic points are not attempted, or tried in various manners.

Alot of the big players went the brute force method as far as Im aware, with stripping firmware from the chips manually or glitching access into them. The issue here is repeatability for client ecus. I mean, can you imaging having to resolder a fresh CPU on an ecu with a modified boot/OS to allow tuning? That would just be... shit. This is just all speculations, but repeatability is a real thing that has to be thought of.

Personally my first attempts would be messing with recovery methods, and then higher security level access. If these faulted, then the next step would be ripping the firmware out through decapping, then reverse engineering the firmware to see if there are any potential exploits to gain access.

[Gatecrasher]

The 2019 ZR1 was regular CAN because it was the tail end of the C7 run. Everything after that was FDCAN. I think it's similar to how some of the E67s used Class 2, even though everything else was moving to CAN at the time.

Global B cars use CAN message authentication between modules. I don't know exactly what those are based on, but I know the new central gateways are the authority for them. It would make sense that they're reset after a reflash and/or based on a hash of the calibration checksums.

As far as resoldering the ECU, I think that's exactly what HP Tuners did with their ZR1 ECUs. That's why they cost over $2000. They also admitted that it breaks compatibility with the original GM SPS tools. That would make sense if they replaced the CPU with one that had their own keys rather than GMs keys.

Mode 27 unlocking won't let you install unsigned software either. You need an 822 byte signature bypass ticket that's specific to an individual ECU for that. It looks like Global B uses 32-byte seeds for mode 27 anyway.

Colin O'Flynn did a great series of videos where he used electrical glitching attacks to get into an older E41. https://www.youtube.com/watch?v=Icw7GGriHzY He had mentioned wanting to try an E99, but it doesn't look like he followed through on that.

[Tazzi]

The 2019 ZR1 was regular CAN because it was the tail end of the C7 run. Everything after that was FDCAN. I think it's similar to how some of the E67s used Class 2, even though everything else was moving to CAN at the time.

Global B cars use CAN message authentication between modules. I don't know exactly what those are based on, but I know the new central gateways are the authority for them. It would make sense that they're reset after a reflash and/or based on a hash of the calibration checksums.

As far as resoldering the ECU, I think that's exactly what HP Tuners did with their ZR1 ECUs. That's why they cost over $2000. They also admitted that it breaks compatibility with the original GM SPS tools. That would make sense if they replaced the CPU with one that had their own keys rather than GMs keys.

Mode 27 unlocking won't let you install unsigned software either. You need an 822 byte signature bypass ticket that's specific to an individual ECU for that. It looks like Global B uses 32-byte seeds for mode 27 anyway.

Colin O'Flynn did a great series of videos where he used electrical glitching attacks to get into an older E41. https://www.youtube.com/watch?v=Icw7GGriHzY He had mentioned wanting to try an E99, but it doesn't look like he followed through on that.

Ah ok, I must be thinking of the later series ECUs then. SInce Pete and I are just about to release the OBDX GT, which technically could communicate with a FD CAN ecu, although I have not added the firmware to do so due to flash limitations, but its why its peaked my interest lately.

Ok, would have to monitor the can traffic to see whats happening at the gateway module. I don't believe it would be much of a problem since normal diagnostic request are still performed as per usual, thus any commands so long as its addressed to the module correctly will pass through. Monitoring an SPS session after flashing would be the real identification of any further commands/security steps taken to save any additional data between modules.

That Colin O'Flynn video is fantastic. He did go to make a document about his findings which were successful. He didn't post the data he got but basically explained exactly what he did and where to place glitcher ect. But this is still just for extracting firmware, I don't think this would be very reliable to do on a commercial basis so wouldnt think that commercial places would even entertain this idea.

Alright, so the mode 27 your thinking of is the standard 27 01. Im referring to 27 03, which is effectively engineering access, used to gain access to other areas of the ECU and allow thing like read/writing the seed/key. This is the kind of access which might allow poking around ram fir executing custom code.

[Gatecrasher]

I hate to be argumentative, but 27 03 is DVT access. Dynamic vehicle test at the assembly plant. This is straight from the leaked GM protocol docs. There's provisions to have it disabled entirely in ECUs that are sold as service parts.

There's a 27 FB that's for developer access, but I've only found two modules that support it so far.

I really, really don't think it'll help with the Global B stuff. The CPU on this thing is so locked down that Freescale will only release the security data sheets to specific, individually approved customers. Being under their normal NDAs isn't enough. I'd be shocked if the workaround was as simple as fishing out the DVT key and reading some RAM addresses.

With all that said, I might know where to get a cheap-ish ZR1 ECU. I'd have to see if it's still available. It might be fun to play with if for no other reason than to document exactly how the damn thing works.

[Tazzi]

I hate to be argumentative, but 27 03 is DVT access. Dynamic vehicle test at the assembly plant. This is straight from the leaked GM protocol docs. There's provisions to have it disabled entirely in ECUs that are sold as service parts.

There's a 27 FB that's for developer access, but I've only found two modules that support it so far.

I really, really don't think it'll help with the Global B stuff. The CPU on this thing is so locked down that Freescale will only release the security data sheets to specific, individually approved customers. Being under their normal NDAs isn't enough. I'd be shocked if the workaround was as simple as fishing out the DVT key and reading some RAM addresses.

With all that said, I might know where to get a cheap-ish ZR1 ECU. I'd have to see if it's still available. It might be fun to play with if for no other reason than to document exactly how the damn thing works.

Im all for all ideas and thoughts! So keeping them coming. Its the only way to think outside the box.
Just like you said, leaked. Its not common knowledge and its likely never been tested. Hence... we don't know what access it allows. I know messing with radio systems, it did certainly allow greater access.
27 01 allows basic access to an ECU (just in general).
27 03 allows further access (DVT), which then allows security clearance for things like seed/key/serial ect. Keeping in mind these were never designed to allow end user to change, and as the name suggests , for 'testing', there could be ram addresses that get opened up that allow read/write access that they use for debugging which could allow execution of custom code.

The other method of attack mentioned is from a corrupted OS write. These ECUs typically do not have ram chips large enough to accept an entire OS flashed, so while mid writing of the OS, stopping the flash should leave the system in a corrupted state and resort back to the bootloader. The bootloader is the one that is controlling the signiture information, but it might go to a reduced security in the event of a bricked system to just get it up and running.

Lots of theories at this time, just stuff I have had luck with in the past.

[gmtech825]

The other method of attack mentioned is from a corrupted OS write. These ECUs typically do not have ram chips large enough to accept an entire OS flashed, so while mid writing of the OS, stopping the flash should leave the system in a corrupted state and resort back to the bootloader. The bootloader is the one that is controlling the signiture information, but it might go to a reduced security in the event of a bricked system to just get it up and running.

Lots of theories at this time, just stuff I have had luck with in the past.

I have an e41 that was interrupted during an OS write I believe. It responds to commands still and accepts data transfers but isn't happy with anything I send it. I send the factory signed cals or OS system to it and it just spits back a x78 and x85 response after the first block transfer. If you have any ideas you want to try out on it let me know.