pcmhacking.net

That's first gen CSE for MPC56xx. MPC5777 in the E99 uses CSE2.

It also has a hardware security module.

Hello !
maybe someone has files for E99
from SPS cache
I parsed the file signature structure
and I can check the validity
I just want to see what keys the files are signed with

kostia111 wrote:Hello !
maybe someone has files for E99
from SPS cache
I parsed the file signature structure
and I can check the validity
I just want to see what keys the files are signed with

Do you need specific e99 files or any type that uses signature will help. I have some that can share.

Thank you !
I have looked at the files.
Each file is signed with two RSA 2048 keys.
The primary public key has not changed.

PS:How interesting the world is!
The computer stores terabytes of information.
But can't factorize the unfortunate 256 bytes,
that separate us from victory!

Attacking the CPU on a hardware level is pretty tough. Going back to Colin O'flyns video with the E41, they really struggled to get the glitching working on the the ECU itself which would be due to all the other circuitry. He did do it, but he did indicate the many hundreds of attempts needed per positive result.

So, it does work, but its a task to replicate. A single variance on the ECU board (capacitor or resistor variance) could change the requirements for the glitching. As a method of getting into the ECU to dump memory and learn information, its absolutely a good way in. But as a method of repeating on multiple ECUs reliably, it wouldn't be viable, at least I personally wouldn't do it that way.

These processor manufactures are doing their best at locking down processors at the silicon level. This doesn't make it impossible to get in (As per Colins BAM paper), but it certainly makes it difficult for tuning companies or the average joe to make a reliable method to replicate.

A fun method I had done on previous radios to dump pins (the old school VPW ones), was memory overflow attacks. The security information was locked in a memory area which could not be read, this contained things like seed/key, serial, pin code, ect. Requesting the address to read for this section resulted in a failed response, whereas, if I did a memory overflow is would dump. When I say memory overflow, Im referring to doing something like this:
- Normal memory request of region: 0x0000 8000
- Overflow request: 0xFF 00 8000

What happens at the silicon level (Or sometimes in the firmware), it will mask off the top byte so it becomes 00, or ignored entirely. But the firmware checks if the address is allowed, which is the full FF008000, which is not in the restricted area thus allows it to run.

The same attacks can be done for RAM regions for both reading and writing, just takes a bit of searching to find openings like the above.

The above unfortunately doesnt work on newer ECUs, this was one of my first attempts, but this is the kind of 'out of the box' thinking to beat these newer protections

Hello,
Does anyone happen to have Slave module 92265196 from a 2014 Chevy SS?

Hiya, here it is decompressed. If not allowed, please delete.


Removed upon outside requests