GM 16216588 - Hacking

American Delco GM ECUs and PCMs, ALDL, OBD 1.5.
Post Reply
User avatar
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

To sum up where we are at with this:

I got a clean read off a 97 PCM flash chip (desoldered the flash) and we threw together the following proof of concept:

Looking at a full 128k bin (after addressing is corrected):
$2000-$2003 = Calibration ID
$2004-$2005 = CheckSum Store Address
$2007-$200A = Broadcast Code (ASCII x 4 Characters)
$2006-$FFFF = Bank 1 of Calibration
$18000-$1FFFF = Bank 2 of Calibration

So when you combine the hex ranges for "Bank 1 of calibration" and "Bank 2 of calibration", you can sum the full calibration to know show the theory in action:
*I obfuscated the broadcast ID because I was tinkering with changing that to see the checksum change to/fro
sum and calibration id hxd.png
sum and calibration id hxd.png (117.84 KiB) Viewed 6869 times
If some readers are wondering what this means...The "calibration" is the data you are most interested in changing. And the PCM is going to run the same logic as above to sum the hex addresses of calibration to ensure the checksum matches before it'll run the code that lets the vehicle operate. So we now know what blocks of memory need to be read/flashed and we know how to properly calculate the checksum for a successful flash. We are the first group of fools to accomplish this outside of commercially available software (for this PCM) and everything you need to get rolling is no longer a "secret".

The interface cable you need to begin working with this PCM is an AVT-852 REV "E" at a minimum. You need this J1850 4x connection to flash at a reasonable speed. REV "T" adds some I/O channels you could use to track fuel pressure, EGT, etc. if you wanted to include those digital channels in your data logging (which are not available from the PCM because it doesn't track them). You'll appreciate this info if you visit the AVT website and see how confusing it can get for a newb.

What's next:
-Figure out the J1850 communications via AVT interface to read/write these memory blocks
-Figure out how to start building this out in TunerPro. I'm not sure if it can handle doing the checksum of banked code.
-Continue dis-assembly to figure out what's what
User avatar
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

A very helpful member of the community shipped me a couple more PCM's today to play with.

After hooking all 4 i'll have up, I'll verify the seed/key algo on them all and post up that information as well.
User avatar
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

Tested a few more of these PCMs (all with different OSIDs), and verified the security algorithm is $03.

The previously linked App will get you close on the brute force scan. I sent some information to the developer that should help him tweak the algorithms.
User avatar
Tazzi
Posts: 3428
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM 16216588 - Hacking

Post by Tazzi »

Very interesting :) Great work! :thumbup:

What seed/keys do you have so far? Would be happy to double check it :)
I know it the more modern modules, they tend to through a little "magic number" at different intervals which can cause the algo to be correct in some regions but out in others.
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
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

Tazzi wrote:Very interesting :) Great work! :thumbup:

What seed/keys do you have so far? Would be happy to double check it :)
I know it the more modern modules, they tend to through a little "magic number" at different intervals which can cause the algo to be correct in some regions but out in others.
Hey!

Here's my findings so far. The 'suggested key' is what the algorithm math gave us, but that could be an issue with the algorithm or the app code. Just add 2 to each one consistently, and it's working!

PCM 1:
Seed : 4F 99
Suggested Key: C4 D5
Actual Key: C4 D7

PCM 2:
Seed : 03 30
Suggested Key: 5D A6
Actual Key: 5D A8

PCM 3:
Seed : 0C D3
Suggested Key: 4A 60
Actual Key: 4A 62
User avatar
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

I have a quick question that hopefully someone can relate to.

I'm going through the earlier year calibrations and noticed the mapping is a bit different from the later years. For example, graphs are similar but start at a different position. I know for the OBD-I PCM's, they did this too but I only wrote one definition file and would just flash the latest calibration with modifications (turn off the auto trans flag for a manual for example)

So my question is, on these units with the larger memory block, we are still flashing the entire memory, correct? If I put a '99 calibration on every unit, it won't have any recollection of the '96 code that used to be on it, correct? The bank switching has me a little confused but I think I'm still sane at some level. :wtf:
User avatar
Tazzi
Posts: 3428
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM 16216588 - Hacking

Post by Tazzi »

Yeah can confirm those seed/key combos are solid on the same algo :thumbup:

Attached is every possible seed/key combo (Yes, they are alllll good :lol: )
Attachments
SeedKeyList.txt
(1.43 MiB) Downloaded 412 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: 3428
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM 16216588 - Hacking

Post by Tazzi »

quadstar87 wrote:I have a quick question that hopefully someone can relate to.

I'm going through the earlier year calibrations and noticed the mapping is a bit different from the later years. For example, graphs are similar but start at a different position. I know for the OBD-I PCM's, they did this too but I only wrote one definition file and would just flash the latest calibration with modifications (turn off the auto trans flag for a manual for example)

So my question is, on these units with the larger memory block, we are still flashing the entire memory, correct? If I put a '99 calibration on every unit, it won't have any recollection of the '96 code that used to be on it, correct? The bank switching has me a little confused but I think I'm still sane at some level. :wtf:
Id assume for each different operating system (OSID), each willl have everything shifted or in slightly different locations. If thats what you meant?
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: 3428
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM 16216588 - Hacking

Post by Tazzi »

Also happy to chuck up code for that algo if wanted :)
Appears to be the standard ls1 algo.
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
quadstar87
Posts: 86
Joined: Wed Dec 02, 2015 4:13 am

Re: GM 16216588 - Hacking

Post by quadstar87 »

Tazzi wrote:
quadstar87 wrote:I have a quick question that hopefully someone can relate to.

I'm going through the earlier year calibrations and noticed the mapping is a bit different from the later years. For example, graphs are similar but start at a different position. I know for the OBD-I PCM's, they did this too but I only wrote one definition file and would just flash the latest calibration with modifications (turn off the auto trans flag for a manual for example)

So my question is, on these units with the larger memory block, we are still flashing the entire memory, correct? If I put a '99 calibration on every unit, it won't have any recollection of the '96 code that used to be on it, correct? The bank switching has me a little confused but I think I'm still sane at some level. :wtf:
Id assume for each different operating system (OSID), each willl have everything shifted or in slightly different locations. If thats what you meant?
Yea, they are slightly shifted. I guess what i'm wondering is if the complete operating system code is overwritten when you flash a calibration, however.
Post Reply