GM E38 E67 E40 Kernel/Bootloader Development Extravaganza

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz

Post by Tazzi »

gmtech825 wrote: 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.
This is exactly what makes me think this method would work.

The first block generally indicates the signature and other various information. The fact that its rejected it, makes me believe this is the way in since its probably looking for a non signature/compressed file.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz

Post by Tazzi »

Installer removed due to:
1) Licensing system down while migrating to a windows server
2) The individual which was stupid enough to screenshot trying to use my E38/E67 kernel in an app and claiming it was theirs. You know who you are.. and I know exactly who you are :thumbup:
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
crystal_imprezav
Posts: 9
Joined: Thu May 26, 2016 4:45 am

Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz

Post by crystal_imprezav »

Back to the global-a stuff. Generally most people know how to do the 5 byte seed/key with ease. The 27 FB trick only works on T87 variants and its because it has a different type of bootloader from another supplier iirc. All of them use a form of power glitch like Tazzi mentioned at one point. None of them are de-soldering the BGA and using emfi to unlock every ecu (maybe first ones to get a full boot read through BAM).

Biggest problem in my eyes is even if I could give access to write and/or even read the newer stuff, the tuners wouldn't even know what to do with the raw binary. Its still encrypted and compressed so that must be known to match up to a2l or even reverse the tables. Then it needs to be re-encrypted and compressed to be sent back.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz

Post by kur4o »

crystal_imprezav wrote:
Biggest problem in my eyes is even if I could give access to write and/or even read the newer stuff, the tuners wouldn't even know what to do with the raw binary. Its still encrypted and compressed so that must be known to match up to a2l or even reverse the tables. Then it needs to be re-encrypted and compressed to be sent back.

The idea is to make the pcm accept unencrypted, uncompressed and unsigned flash. Maybe there is some options in the bootloader that enables them. Fix bootloader, write it once and than flash it. Than the code can be fixed as usual. I have seen unencrypted dump of e90 and there is not much different than e92. SOme tables are even t exact the same.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz

Post by Tazzi »

Exactly as Kur4o has said.

Im mentioned multiple methods in this thread, and it appears 1 or more of the ideas are being exploited.

Personally I think we have a recovery boot glitch from multiple power cycles being exploited. Although I feel the real winner that I have not heard of anyone doing is exploiting the 27 03 method which does open up additional abilities/memory regions. The issue here is calculating the keys since they use a different table but that can be done still.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
crystal_imprezav
Posts: 9
Joined: Thu May 26, 2016 4:45 am

Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz

Post by crystal_imprezav »

They power glitch 27 01 on the E41. So it would appear no need to try 27 03.

While you might get the ecu to accept unencryted/uncompressed, i would suspect that may take a lot of code change. IIRC everything but the bootloader is stored encrypted/compressed in the flash and is decoded in RAM. There is no way to send a loader to it in order to try and read and write therefore the only way you would probably be able to accomplish this is to spend even more time trying to glitch the unique BAM passwords but this wont work on MPC5777C ecu's like the E99. If anyone has a full global-a or global-b dump with the bootloader I could probably get a much better idea
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz

Post by Tazzi »

crystal_imprezav wrote:They power glitch 27 01 on the E41. So it would appear no need to try 27 03.

While you might get the ecu to accept unencryted/uncompressed, i would suspect that may take a lot of code change. IIRC everything but the bootloader is stored encrypted/compressed in the flash and is decoded in RAM. There is no way to send a loader to it in order to try and read and write therefore the only way you would probably be able to accomplish this is to spend even more time trying to glitch the unique BAM passwords but this wont work on MPC5777C ecu's like the E99. If anyone has a full global-a or global-b dump with the bootloader I could probably get a much better idea
The bootloader is the first part of code loaded. The CPUs do not support decryption on the fly from saved embedded memory, otherwise they would have done this with the entire operating system/calibrations. This kind of memory feature can be seen in things such as the ESP32 where they can actually decrypt the firmware/instructions from the saved flash on the fly, it does have a specific title but cannot remember exactly.

You can read the bootloader using basic commands, this region is not locked. Trying to read the shadow ram (Where the passwords are stored for locking the processor) are locked unfortunately.

Now, with this all said, things I would look into:
1) decompile bootloader to understand every single last routine. There will likely be engineering/admin based functions/commands to take advantage of (There will be 10s of thousands of opcodees to go though). This is where understanding the recovery methods have been taken advantage of so far.
2) Begin dumping RAM address and see if any look like functions being saved into ram. Reason for this, is if a routine is saved into ram, this can easily be overwritten with basic commands to have a custom routine injected, its just a matter of knowing what the routine is to trigger it.
3) Performing a 2703 and then testing out every single DID read, along with dumping RAM addresses (Including testing shadow) to see what else is unlocked.

Power glitching would have been the entry model if the passwords were all the same, but I believe this was also confirmed on the BAM series that the passwords differ each time. Making a perfect bench setup to attach a specific ecu every single time could potentially work, but if/when the CPU is put to the inside of the circuit board where it would require huge amount of work to get to, or sealing the units like they did with the E92... it no longer becomes viable.

Personally Id start with 2703, simply because it doesnt take much, and at least knocks one off the table
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
crystal_imprezav
Posts: 9
Joined: Thu May 26, 2016 4:45 am

Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz

Post by crystal_imprezav »

How do you figure you could read the boot loader? The e41 and e99 will not take a read/write loader via $34/$36 like all pre global-a. I havent tried, but I highly doubt $35/$36 or $23 will work. If I had a copy of the boot loader, i could easily get through the code in IDA.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz

Post by Tazzi »

crystal_imprezav wrote:How do you figure you could read the boot loader? The e41 and e99 will not take a read/write loader via $34/$36 like all pre global-a. I havent tried, but I highly doubt $35/$36 or $23 will work. If I had a copy of the boot loader, i could easily get through the code in IDA.
Its these assumptions which have prevented people from making progress for years. ;)
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
crystal_imprezav
Posts: 9
Joined: Thu May 26, 2016 4:45 am

Re: GM E38 E67 E40 Kernel/Bootloader Development Extravaganz

Post by crystal_imprezav »

Not an assumption, NRC code 0x11 is pretty clear.
Post Reply