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

Post by Tazzi »

Ah fuckity fuck fucking fuck.

I see it now... Its extremely poorly explained... but I see it...

See the highlighted below. So its showing address 70000-73FFF... this is 0x4000 difference which is actually 0x10000 for this flashchip which is exactly what was erased.

Even though I requested the address of 70400, any address in that range just deletes the whole area. I assumed I could erase the sector size it says earlier.. but size depends on location.
So a bit of logic is needed in the software side to acknowledge that specifc ranges (Most of the chip) is actually 0x10000 in size.
stupidflashchip.PNG
stupidflashchip.PNG (9.36 KiB) Viewed 8332 times
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 Kernel/Bootloader Deveopment Extravaganza

Post by kur4o »

So it is $4000 dwords which equals $10000 bytes. This sucks.
The bin have the cal data from 1c0000 on. Which means that os is intacked and is fully functioning. If the cal data part is not fully erased the OS might fail to load due to bad checksums.

I see that AA 55 66 66 at the end of os segment and cal data segments might be some check dword for bad flash. If you managed to lie the os[grounding some memory pin if there is any] that these are FFs it might be possible for os to boot into recovery mode.

Anyway you are headed on a brick, with that part erase approach, even it had worked the way you wanted it.
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 Deveopment Extravaganza

Post by Tazzi »

kur4o wrote:So it is $4000 dwords which equals $10000 bytes. This sucks.
The bin have the cal data from 1c0000 on. Which means that os is intacked and is fully functioning. If the cal data part is not fully erased the OS might fail to load due to bad checksums.

I see that AA 55 66 66 at the end of os segment and cal data segments might be some check dword for bad flash. If you managed to lie the os[grounding some memory pin if there is any] that these are FFs it might be possible for os to boot into recovery mode.

Anyway you are headed on a brick, with that part erase approach, even it had worked the way you wanted it.
Yeah spot on, so it was a little unexpected :lol:

Iv seen E38's with erased segments and still work recoverable, thats using a Holden VF OS and calibration which I know has a backup/recover method in them which SPS is able to detect and recover.

But it seems the spare ECU is completely dead. I went over the kernel I used (Saved for later analysis) and I didnt disable the entire write command. The kernel sent all the require commands to do a write, except the final one which does the actual write. The problem with the way that was set, is the next command that gets set would be used as the 'address' to write to. Even though the flash was not erased, it can still set bits to 0 which I believe is exactly what happened.

Pretty sure I have set bytes in the first boot block to 00 by accident.. which is why it no longer wants to run :lol:

And yes, I believe the last 4 bytes do have something related to recover mode. I believe usually when writing to the cal section, it deletes the entire cal and then writes over it. The boot then checks that part of code and if its wrong, it goes into recovery.

If I can recover this dead ecu, I will test that theory.
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 Deveopment Extravaganza

Post by Tazzi »

Also decompiled the kernel used for the slave OS. Decompiles fine using HCS12.

Its only about 0x18F bytes (400) in length which isnt that much. Can see to main function being used, although Im not familiar with that architecture to break down what its doing. Not sure Im willing to put that many hours into a slave OS at the moment. Still need to have the main chip going smoothly.
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 Development Extravaganza

Post by Tazzi »

Managed to read the nor flash on the dead unit... and yeah... it messed with a bunch of bytes in the OS and boot section which is what killed it. :lol:

Probably not too comfortable on attempting again without being able to recover, so part is being able to properly recover bad flash. Will resort to an actual clip on programmer for the flash chip if needed, just need to be able to flash in the event it occurs again.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
VX L67 Getrag
Posts: 2877
Joined: Sun Aug 02, 2009 9:16 pm
Location: Bayside, Melbourne, Victoria
Contact:

Re: GM E38 Kernel/Bootloader Development Extravaganza

Post by VX L67 Getrag »

Wouldn’t hot swapping fix it like it has with other e38’s I’ve had non responsive with flashing incompatible os’s?
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 Development Extravaganza

Post by Tazzi »

VX L67 Getrag wrote:Wouldn’t hot swapping fix it like it has with other e38’s I’ve had non responsive with flashing incompatible os’s?
Unfortunately not, that was the first thing I tried.

The problem is it has corrupted part of the operating system, so it doesn't boot/run correctly. :thumbdown:

Going to see if I cant maybe bridge some pins to jump into recovery mode maybe.
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 Kernel/Bootloader Development Extravaganza

Post by kur4o »

It is worth trying the ground pin method. The recovery code is very small in length and the chance it is intacked is big. It runs at the very start and is some comm loop only. On ls1s it is like $2000 in length and it can accept uploads without unlocked the pcm. There are some specific messages being send, identifying the brick.

Is this pcm have external memory chip or it is part of the processor. Do you have that routine for the slave and the address where it is loaded. I found some slave file and it is also segmented, There is like OS and 1 cal data segment in it. I suspect more on the chip that are not updated.
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 Development Extravaganza

Post by Tazzi »

kur4o wrote:It is worth trying the ground pin method. The recovery code is very small in length and the chance it is intacked is big. It runs at the very start and is some comm loop only. On ls1s it is like $2000 in length and it can accept uploads without unlocked the pcm. There are some specific messages being send, identifying the brick.

Is this pcm have external memory chip or it is part of the processor. Do you have that routine for the slave and the address where it is loaded. I found some slave file and it is also segmented, There is like OS and 1 cal data segment in it. I suspect more on the chip that are not updated.
Yeah Its on todays agenda to try recover. Im not feeling too confident with the bricked ECU since its random byte bytes through the entire bin which have been set to 00 or random values.

Basically my kernel had the following code:
While (TotalFlashedBytes < TotalBytesToFlash)
{
Send Command Request To Program Bytes
//Send Bytes to be flashed.
}

Now the // means that line of code was commented out. So what was happening is the flash chip was being commanded to accept the next line of data for programming. Because I had that line commented out the actual data, the flash chip was accepting the 'command' as the data and randomly 00 places in the flash :lol: :roll:

Was a slight oversight on my behalf, I thought I had disabled the writing completely while testing.

The memory chip is external, next option is to see if grounding pins works.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
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 Kernel/Bootloader Deveopment Extravaganza

Post by ironduke »

Tazzi wrote:Also decompiled the kernel used for the slave OS. Decompiles fine using HCS12.

Its only about 0x18F bytes (400) in length which isnt that much. Can see to main function being used, although Im not familiar with that architecture to break down what its doing. Not sure Im willing to put that many hours into a slave OS at the moment. Still need to have the main chip going smoothly.
Hi there and wow, some amazing reading here.. Most of it is over my head but I am trying to learn.. I figured I'd ask to assist and I'm wondering if you wouldn't mind sending me the slave OS kernel to work with?? I see that you don't want to spend tons of time with it at the moment and I have had some experience with assembly the HCS912 ecu.. Figured I could try and break it down for you..

Another quick question, what are you writing this application in? C#? C++?? Just wondering where I should focus my self teaching towards.. I've done a little in each, more proficient in C++ but not much if any work in communication protocols..

Again, this is fantastic work!!! Thanks for making this a public effort!!!
Post Reply