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:Hello folks,
Yeah here in California it is absolutely crazy. Luckily I have a shit ton of canned foods and lot's of other staples. You guys be safe out there.

Back to the thread...I just read out a T87 8spd file if you guys want to have a look. I didn't see anything very useful but maybe you'll see more. How is the vin number derived? I didn't spot that anywhere in the file and would like to edit it before I post.
Hmm.. those top digits look like potential part numbers for the TCM: MPC90FLFE043

Found interesting info online:
clarify, while the T87 and T87A are pin-compatible, and use the same CPU, they are not 100% interchangeable. The T87A brought TWO things to us - a secure boot loader (which is why they need be unlocked) and also electrical support for the 9 speed and 10 speed automatic transmissions.

You cannot flash a T87 with T87A software, or vice-versa.
The 'unlock' on the T87A, I imagine they are patching in a modified bootloader into the devices which do not require encrypted calibrations... as least this would make sense for it.
I believe the files get decrypted and saved to flash decrypted, so they are basically patching the bootlaoder so it can read/write raw decrypted files. (I would assume???).. basically what the T87 does compared to the T87A.

Now the question comes... how did they get the base bootloader. I would assume they are using BDM/Jtag to reflash the CPU, or if that has been disabled.. more advanced techniques possible, I can see three possibilities:
1) JTAG/BDM to read entire memory and modify (This can be locked or disabled on boot.. or even permanently disabled so it can never be connected again)
2) They got the signing certificate to generate a valid file to flash (Unlikely.. since they could get customers to use this)
3) Decapping. Paying someone to decap the chip and manually read the base firmware on their R&D unit. Base firmware is then modified and written back to the CPU (If flashing external is not disabled) or placed onto a replacement CPU which is placed onto the board.
4) GM insider has given them the information.
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 »

Ok so.. ECU identification for both E38 and E67 from opened bin files implemented.

It will check the bootblock part number for the initial identification, then proceed to check file length, operating system and also CRC/checksum to ensure file is valid.

The CRC/Checksum I haven't 'fully' got in. I did a bit of a hack and force set the segment locations. I dont 'think' these actually change locations for the E38 or E67, but its not good practice to assume they are always in the same location so will read from the boot block and process.

Read files will also be scanned and validated, unknown operating systems (for now) will be prevented from writing and same for any with invalid CRCs.

Things left:
1) Validate the ECU connected is compatible with the opened file. This is just a simple check of ECU type and OS.
2) Fix custom tuner lock key. I didnt await the user form result which caused an infinite loop of 100+ forms opening until it crashed the application :lol:

Cosmetic changes include docking the log box to the bottom, and a little image of detected ecu on the right.
FlashIdentification.PNG
FlashIdentification.PNG (56.69 KiB) Viewed 4916 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 E67 Kernel/Bootloader Development Extravaganza

Post by kur4o »

Did you managed to explore the relationship between OS p/n and slave p/n. If they mismatch is there a software brick,no brick or hardware brick condition. Reading slave is out of question but how about writing it, is it possible.

I read somewhere that the signed pcms get cpu changed with ?? existing modified boot loader or ??custom one.
edit
also with the custom bootloader the pcm is tied forever to the tuning cable for writing, No other tools will work including factory ones.
Last edited by kur4o on Sun Mar 22, 2020 6:03 am, edited 1 time in total.
In-Tech
Posts: 778
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: GM E38 E67 Kernel/Bootloader Development Extravaganza

Post by In-Tech »

Curious, trying to follow along so I apologize in advance. Why can't the slave be read?
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: GM E38 E67 Kernel/Bootloader Development Extravaganza

Post by kur4o »

It is not exactly impossible, but the time required to do it will be too much for the average person.

The problem is that the main cpu will translate the messages to the slave cpu, they use different processor type and the slave cpu uses some weird language similar to the 68hc11 cpus using stack extensively. Debugging one of these will be pure PIA. One will have to reverse the spi communication that takes place between the 2 cpus, than reverse the code of the slave to find the ram addressing and make some code to send the read request to main cpu, and modify the main cpu code to send the messages to the tool. Dumping data one way as per writing these is much more feasible.
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:Did you managed to explore the relationship between OS p/n and slave p/n. If they mismatch is there a software brick,no brick or hardware brick condition. Reading slave is out of question but how about writing it, is it possible.

I read somewhere that the signed pcms get cpu changed with ?? existing modified boot loader or ??custom one.
edit
also with the custom bootloader the pcm is tied forever to the tuning cable for writing, No other tools will work including factory ones.
I havent looked too closely at the difference between the OS and matching slaves. The ecu doesnt quite brick, it just does not operate correctly with the car. At least I was able to do a OS+Cal write of what would be an incompatible OS, and then put it back to a compatible OS after. Iv only done that the once so will need to try a few other bins and see if a brick condition ever occurs.

Interesting, I was not away of the newer PCM custom kernels being tied to the tuning cable. I have read about the actual processor being swapped, although this seems pretty extreme to do.
In-Tech wrote:Curious, trying to follow along so I apologize in advance. Why can't the slave be read?
It could be done, just alot of work.
Easier option is to rip all the slave OS's from SPS and then just use those.

Im not fluent in the slaves opcodes/architecture either so reverse engineering the bootloader would require starting from scratch. I mean... I dont think it would be too bad to understand once spending a few hours on it but its not on the high priority list. If someone wants to decompile the SPS slave kernel and work out what its doing, then Im sure we could make a custom one.
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 E67 Kernel/Bootloader Development Extravaganza

Post by VX L67 Getrag »

Tazzi, have you seen the list for service numbers matching OS & if you try & flash a complete OS on the non year/model service numbers it will brick... but hot swapping will get it back working.
User avatar
Gampy
Posts: 2330
Joined: Sat Dec 15, 2018 7:38 am

Re: GM E38 E67 Kernel/Bootloader Development Extravaganza

Post by Gampy »

What is Hot Swapping??
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
In-Tech
Posts: 778
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: GM E38 E67 Kernel/Bootloader Development Extravaganza

Post by In-Tech »

Curiosity got the better of me so I put one of these E38's in the mill. Do I need to keep going or is this the flash? Looks to be a Spansion s29cd016j0mqfm01. So, where's the "reset, boot mode" pin? :lol: or is it accessible from the bottom removable cover?
image0.jpeg
image0.jpeg (129.25 KiB) Viewed 4819 times
image4.jpeg
image4.jpeg (144.59 KiB) Viewed 4819 times
I got this somewhere in my travels too, not sure where.
E38_BDM.pdf
(1.21 MiB) Downloaded 448 times
Just found this tonight for the Spansion. You guys probably have all this stuff, I'm just perusing for info :D
S29CL016J_SPANSION.pdf
(479.08 KiB) Downloaded 319 times
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 »

Thats the flash there!
Iv tried pulling pins down low ect but it never goes into a 'recovery' state.

Interest bdm document through, havent seen that one before
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