GM E38 E67 E40 Kernel/Bootloader Development Extravaganza

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

GM E38 E67 E40 Kernel/Bootloader Development Extravaganza

Post by Tazzi »

This first post is for the release and change log updates to NVS ECU Flasher (NEF)
NVS ECU Flasher.PNG
NVS ECU Flasher.PNG (61.66 KiB) Viewed 33242 times
NEF currently supports the following GM ECUs:
- E38 (Reading, Writing and Clone)
- E67 (Reading, Writing) *Do not clone this need updating
It includes file validation through checksum and unique identifier checks to ensure only valid files are accepted for modifying and writing.

ECUs that are on the current development list are:
- E55
- E77
- E39/39a

Future additions and wish list of the application are:
- Recovery mode - yet to test wiping the cals and attempting to write, likely requires some adjustments to the application to proceed in recovery mode.
- Add segment and security details screen for opened file (including seed/key, vin, serial ect).
- Design a XML or other format to accept parameters for definitions

Free license to contributing PCMHacking members :thumbup:


Changelog
08/04/2020 (v1.0.3.19755)
-Boot block no longer erased/written on clone (Fixes E67 first block failure)
-Max retry count added to erase routine
-Max retry count added to write routine
-Other small minor changes

06/04/2020 (v1.0.2.20948)
- Fixed kernel issue (QSPI and partnumber problem)
- Fixed infinite loop trying to read if bad responses
- Calibration validation fix

05/04/2020 (v1.0.1.35045)
- Fixed registration issue
- Changed version control method

04/04/2020 (v1.0.0.0)
- Initial Release
Last edited by Tazzi on Mon Oct 31, 2022 3:09 pm, edited 17 times in total.
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 Kernel/Bootloader Reverse Engineering Extravaganz

Post by Tazzi »

Title really does say it all :thumbup:

Started looking at the write kernel used on the E38's from SPS, I was playing with my own VE and bascially programmed it up as a Pontiac G8, and noticed there were two kernels sent:
1) First was for OS and all other major cals
2) Second was for Slave OS and another cal labelled Engine in SPS, Im yet to compare where exactly that engine cal goes.. in the ECU. Im assumign on of the files actually updates the slave mcu, and the other updates the MPC slave segment.

Anyways, as far as Im aware, legaility wise there 'shouldnt' be an issue sharing the kernel bin, its more the fact of using it without permission. So anyone that wants to tinker and take a look at the kernel in ida, let me know and Ill shoot through a message :)

Now.. to the nitty gritty stuff... The MCU in the E38's is a MPC562, it has NO internal memory, and only has external memory, so to address the external memory, it needs to call to 0x80000000.
After decompiling the kernel in IDA, we see this:
Image

Link to reference manual: https://www.nxp.com/docs/en/data-sheet/MPC561RM.pdf

We have a good 6 regular functions which are all called from the top segment of instructions. I started commented every instruction.. but as I went along.. I started noticing the absence of the CAN register (TOU_CAN) and also calls to the external memory. Theres calls for all sorts of other registers including interrupt Mask2 register (SIMASK2 = 0x2FC048) and time base/control (TBSCR), but the entire CANbus register (0x307000 to 307800) never appears :?

Sub_74C, has a whole section in regards to addressing the QSMCM register (queues Serial Multi-Channel Module), memory address of 0x3050000. As far as I understand.. this might be the serial communication between the actual main CPU and slave CPU. Why its doing anything with that is beyond me.

So Iv come to the conclusion of:
1) Im going mad
2) Or, the memory addresses are actually offset.|
3) Somehow, It has not decompiled correctly, although it does it happily. May need to try something other than IDA and see if the same results are produced.

Even looking at the flow of the kernel.. I dont see enough for/while loops to be performing read/writing to CANbus and also flashing memory. :roll:





Seems the me9 ecus use the MPC chipset as well.

https://webcache.googleusercontent.com/ ... clnk&gl=au
This doesnt talk about kernels at all, but gives a quick indication on what to do with a full E38 bin for loading it properly into ida.

It does speak of configuring the base correctly as its offset to something like 0x400000... wonder if thats whats happening in the kernel too.
Last edited by Tazzi on Sun Apr 05, 2020 3:19 am, edited 1 time in total.
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 Kernel/Bootloader Reverse Engineering Extravaganz

Post by Tazzi »

The plot thickens...

So.. the slave CPU is a motorola MC9S12, the slave kernel sent over canbus is actually compiled for that specifically.
I thought the slave kernel was run on the MPC562 chip, and it then remotely flashed the slave chip, but doesnt seem to be the case!

I think both the MPC and MC9S912 chips can be addressed separately and both listen to the CANBus system.

Now.. looking at the MPC kernel again, that section I referred to for serial/SPI communication, that must be the communication from the MPC to the Slave CPU. Not sure what its doing yet as havent commented each line of that, but that is the only other peripheral it could be speaking to on board.

So.. this begs the question.. if the kernel isnt running the show for controlling CANbus and directly flashing its memory... then is it really needed?? As far as I see, it disables interrupts and timers ect, and anything else that could get in the way.. then sends a couple commands from the QSMCM register which must be to the slave cpu.

It could possibly be telling the slave CPU to ignore incoming requests?? Maybe?? Then an inbuilt kernel in the MPC OS actually does all the flashing?? I guess one way to find out is see what happens if I try flash it without a kernel... :shock:
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 Kernel/Bootloader Reverse Engineering Extravaganz

Post by Tazzi »

Ok yep... Im beginning to think the actual OS has it built into it now.
Look at below, can see it sends the kernel in two parts which is accepted. The tool requests the OS to check if it needs updating.. which it does in this circumstance. It then sends the next update 0x34 request and begins sending the OS file.

Now.. the kernel itself does NOT setup or touch the CAN registers at all... like nada.. zilch... nothing. Im sure its doing something internally.. but.. its certainly not running in a loop to be searching for CAN messages and handling them like i would expect.

Code: Select all

00 00 07 E0 34 00 00 15 40 [0009] FramePad - prepare 0x1540 bytes
00 00 07 E0 [0004] TxDone 
00 00 07 E8 7F 34 78 [0007] -wait Im slow
00 00 07 E8 74 [0005] Not Padded - sweet as, good to go
00 00 07 E0 36 00 00 3F C4 30 00 3F C5 1C 00 3F C6 40 FF FF FF FF FF FF .. [4098] FramePad - First part MPC kernel
00 00 07 E0 [0004] TxDone 
00 00 07 E8 76 [0005] Not Padded -accepted
00 00 07 E0 36 00 00 3F D4 28 FF FF FF FF FF FF FF FF FF FF FF FF FF FF .. [1362] FramePad  -last part MPC kernel
00 00 07 E0 [0004] TxDone 
00 00 07 E8 76 [0005] Not Padded -accepted 

Kernel is sent and accepted... next part is flashing

00 00 07 E0 1A C1 [0006] FramePad -request OS
00 00 07 E0 [0004] TxDone 
00 00 07 E8 5A C1 00 C0 87 9F [0010] Not Padded -OS = C0879F (needs updating to C0A212)
00 00 07 E0 34 00 0F FE [0008] FramePad -prepare 0xFFE
00 00 07 E0 [0004] TxDone 
00 00 07 E8 74 [0005] Not Padded - accepted
00 00 07 E0 36 00 00 3F 90 90 20 33 00 01 20 00 C0 A2 12 41 41 00 00 00 .. [2058] FramePad -first part of OS, sent to addy 3F9090
00 00 07 E0 [0004] TxDone 
00 00 07 E8 7F 36 78 [0007] Not Padded - Im slow mate, hold up
00 00 07 E8 76 [0005] Not Padded - alllll goood
00 00 07 E0 36 00 00 3F 90 90 20 33 00 01 20 00 C0 A2 12 41 41 00 00 00 .. [4098] FramePad - next part, addy 3F9090
00 00 07 E0 [0004] TxDone 
00 00 07 E8 7F 36 78 [0007] Not Padded 
00 00 07 E8 76 [0005] Not Padded 
00 00 07 E0 36 00 00 3F 90 90 54 CC 06 FE 7D 03 64 30 4E 80 00 20 39 00 .. [4098] FramePad -next part, addy 3F9090
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 Kernel/Bootloader Reverse Engineering Extravaganz

Post by Tazzi »

The memory layout shown below.. this shows where the above log is putting the data.

So the kernel goes into (2parts): 0x3FC430,0x3FD428, both within the ram address (3F8000 to 3FF000)
Which is 0xFF8 in size between them, which equals 4088 bytes which is exactly the first chunk of data of the kernel sent... so this shows it loads the data correctly, increasing the ram address.

Next, where it begins to flash the actual OS files and cal files, it send to address 0x3F9090, which is still within the ram address. BUT... when its flashing, it never updates this ram address, it always sends to the same address.

What I think is happening, is there is an inbuilt kernel, which will accept specific files which match the sps file structure. Usually these files will actually state the cal number, and indicate things like where its going in memory and stuff like that. So that then matches up with what we are seeing, where the same ram memory address is used the whole way through :thumbup:
Attachments
memorye38.PNG
memorye38.PNG (144.64 KiB) Viewed 36655 times
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 Kernel/Bootloader Reverse Engineering Extravaganz

Post by Tazzi »

Next on the list... test the theory... :thumbup:

Assuming that works.. the checksum needs to be worked out for the files so they can be modified.
Otherwise, at least this is a very easy way of performing factory OS flash. Makes me wonder if it has an inbuilt read kernel too...
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
Gareth
Posts: 2505
Joined: Fri Mar 14, 2014 8:37 pm
Location: Bacchus Marsh, Vic

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Post by Gareth »

Following this with great interest :thumbup:
According to chemistry, alcohol is a solution...
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Post by Tazzi »

Biggvl wrote:Following this with great interest :thumbup:
Im currently coding up to flash with sending the MPC kernel first.. and then flash segments to make sure its all working.

Then remove out the kernel.. and see if it still works :D
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
delcowizzid
Posts: 5493
Joined: Sat Feb 28, 2009 8:38 pm
Location: Wellington NZ
Contact:

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Post by delcowizzid »

Always digging deep good stuff mate
If Its Got Gas Or Ass Count Me In.if it cant be fixed with a hammer you have an electrical problem
Dylan
Posts: 3355
Joined: Mon Aug 02, 2010 6:35 pm
cars: VR Commodore V8

Re: GM E38 Kernel/Bootloader Reverse Engineering Extravaganz

Post by Dylan »

I don't know what you're doing but I love it.
Post Reply