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 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

In-Tech wrote:I will be able to sniff the CAN lines later this week and can get you the kernel's if that helps save you some time or is within your time frame. ;)
All good, I still need to cut open the E92 I have here first to see processor and flash chip/s too. Going to be some delicate angle grinding on this one!
All I know is its still powerpc :lol:
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 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

So.. cutting open the E92 is a little more tricky then expected!

Back plates off, but now have to either cut mass amounts of solid metal to get through to the top or desolder all the case joining points which is seeming to be quite annoying as the case is absorbing the heat so quickly!!!

Its going to happen regardless... I will get through this bugga!
IMG_20201110_073205.jpg
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 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

It may... or may not fire up again after the abuse I just put it through. It certainly was not designed to be pulled apart!

So our lucky processor is a: SGMPPC7241F8MVR 3M17W
Reading online others have labelled it a MPC5674.

Datasheet: https://www.nxp.com/docs/en/data-sheet/MPC5674F.pdf
Reference manual: https://www.nxp.com/webapp/Download?colCode=MPC5674FRM
Architecture core reference manual: https://www.nxp.com/webapp/Download?colCode=E200Z760RM

And has 4mb of flash!

Looks like the variable length encoding (VLE) is usually favored in compilers even when using assembly to minimise the code size. I guess the next step is to see if she boots up.. and if so log a TIS write and take a look at the GM kernel.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: GM E38 E67 Kernel/Bootloader Development Extravaganza

Post by kur4o »

I will give you some head start. It is used on 2018 pcm with the enhanced key unlock. I took a quick look at it and there is some marking for different revisions of mpc90** processor. Suppose there is different code for each processor revisison. Not sure if it matches the pcm you have. There is also 2 earlier version of the flash routines with minimal changes.

Still beta version of disassembly, didn`t have time to look for some improvement.
This one dumps bin data to 40007000 ram at 4k chunks.

DO you have some pics of the front side of board. That pcm is definitely unrepairable, unless you have new cases laying around.

I see some empty header at the bottom. Might be some port for connecting external debugger.
Attachments
e92.rar
(44.12 KiB) Downloaded 188 times
ironduke
Posts: 579
Joined: Thu Feb 13, 2020 11:32 pm
cars: Mainly GM trucks, a Cruze and an Equinox for dailys..

Re: GM E38 E67 Kernel/Bootloader Development Extravaganza

Post by ironduke »

I have the s p s write kernel and a couple bins, would that help at all?? Wish I could do more than just stand by the sidelines, lol..
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: GM E38 E67 Kernel/Bootloader Development Extravaganza

Post by kur4o »

ironduke wrote:I have the s p s write kernel and a couple bins, would that help at all?? Wish I could do more than just stand by the sidelines, lol..
You can send me whatever you like. It will definitely help to get some initial boost. I do have some files but can`t easily identify them yet.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 E67 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

kur4o wrote:I will give you some head start. It is used on 2018 pcm with the enhanced key unlock. I took a quick look at it and there is some marking for different revisions of mpc90** processor. Suppose there is different code for each processor revisison. Not sure if it matches the pcm you have. There is also 2 earlier version of the flash routines with minimal changes.

Still beta version of disassembly, didn`t have time to look for some improvement.
This one dumps bin data to 40007000 ram at 4k chunks.

DO you have some pics of the front side of board. That pcm is definitely unrepairable, unless you have new cases laying around.

I see some empty header at the bottom. Might be some port for connecting external debugger.
Oh wow! Nice jump start is always good! Thankyou for that!
The enhanced key unlock,( I am assuming you are referring to 5byte seed/key? ) is something Iv been working on with a couple others and is now ready for implementation :thumbup:

I ended up confirming the processor type based on the errata code (3M17W) which does show up as a processor revision for the MPC5674.

I wouldn't have thought their would be different flash routines for the same ecu, but gm could have done something funky??

Yeah of course, here are a couple front board pics!
IMG_20201111_075407.jpg
IMG_20201111_075353.jpg
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 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

And yes, I did just cut off the front plugs. I got impatient and no longer could be bothered to desolder the plugs on the PCB :lol:
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 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

Doesnt look like she boots anymore. Ill double check my pinout but Id say shes cooked :lol:

Time to order another couple! Keen on getting an E41, E99, T87 and T87A while Im at it.

*edit
Looks like ECUs like the E99 use CAN FD (Flexible Data Rate). I dont think I own any tools which even support that :wtf: :lol:
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 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

Side tracked looking at T87 and T87a TCM controllers.
The T87a is a 5byte seed/key ecu, and also uses signed calibrations hence needs to be 'unlocked' which is basically editing the boot block area I believe to allow using unsigned cals.

Whats interesting is a kernel can be loaded into ram on the T87, but when trying to execute in ram on a T87A.. it will send back a "7EA 03 7F 36 12 AA AA AA AA ".
Basically its the controller saying "Get fucked, Im not doing it".

This is actually controller by the controller itself to whether it will run the code. Probably going through the OS and searching for the 34 routine would indicate the if statement to whether a execution (0x80) is accepted.

Now, looking at the datasheet (https://www.st.com/resource/en/referenc ... ronics.pdf)

The SRAM area is 0x4000_8000 to 0x4002_FFFF (160KB). There is also a 32KB standby powered SRAM at 0x4000_0000 to 0x4000_7FFF.
So theres to possibilities I can think of:
1) There is a specific main SRAM area which accepts the code upload and will execute (Im thinking this is least likely)
2) The standby SRAM might be unprotected, or from what I understand of the standby sram information..is an application can be loaded into standby sram, then put the ecu into standby, boot backup and hope it runs?
3) Put ecu into as recovery state (interrupt flash of cals or OS) and try upload to those locations. The 'recovery' state technically is run by the bootcode.. so this might be the exploit point.

Bit of food for thought :thumbup:
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Post Reply