That's first gen CSE for MPC56xx. MPC5777 in the E99 uses CSE2.
It also has a hardware security module.
GM E38 E67 E40 Kernel/Bootloader Development Extravaganza
- Gatecrasher
- Posts: 278
- Joined: Sat Apr 25, 2020 6:09 am
Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz
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
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
Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz
Do you need specific e99 files or any type that uses signature will help. I have some that can share.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
Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz
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!
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!
Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz
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
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
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz
Hello,
Does anyone happen to have Slave module 92265196 from a 2014 Chevy SS?
Does anyone happen to have Slave module 92265196 from a 2014 Chevy SS?
Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz
Hiya, here it is decompressed. If not allowed, please delete.
Removed upon outside requests
Removed upon outside requests