E92 PCM Reverse Engineering

[gmtech825]

some in the list are not e92 ecus, but yeah nice catch. That was an AI error when converting to a .txt file. It interpreted a hex value as decimal and converted to hex again. try this one

OsExtra_ranges_by_OS (2).txt

[antus]

Has anyone been able to recover a software brick on one of these PCMs without using boot mode yet? I managed to erase a calibration lock and im getting a seed of 0000, but not able to reliably enter programming mode, either oem or pcmhammer kernel. Whats stranger is while investigating the AI did get the kernel loaded once, and begin to read the flash. But I do not have raw logs of the event, only filtered logs that appear to confirm it happened. So far have not been able to understand how, or reproduce it. I think JTAG/Boot would be able to fix it if I open the case like a sardine can, but it'd be nice to get something in to pcmhammer that can do it for seed=0000 without having to cut it open if it can be reproduced.

[enslaved87]

Has anyone been able to recover a software brick on one of these PCMs without using boot mode yet? I managed to erase a calibration lock and im getting a seed of 0000, but not able to reliably enter programming mode, either oem or pcmhammer kernel. Whats stranger is while investigating the AI did get the kernel loaded once, and begin to read the flash. But I do not have raw logs of the event, only filtered logs that appear to confirm it happened. So far have not been able to understand how, or reproduce it. I think JTAG/Boot would be able to fix it if I open the case like a sardine can, but it'd be nice to get something in to pcmhammer that can do it for seed=0000 without having to cut it open if it can be reproduced.

Been there a couple times with some of my donors.

Try this -
1. Key on and wait a full 10 seconds before any seed request. One attempt per power cycle. A seed probe during the power-on delay makes these refuse the upload until power is cut.
2. Send the functional prelude and wait on it: $28 00, $A2 00, $A5 01, about 280 ms, $A5 03, about 230 ms. These are broadcasts. A physical $A5 that has to be acknowledged is the step that flakes.
3. $27 01. On 67 01 00 00, skip $27 02.
4. $34 and $36 the kernel even when $10 02 timed out and $A5 01 never acknowledged.
5. Read the whole flash and save it. Write a complete known-good calibration back, including the cal-valid bytes, in one pass. A partial cal is how this state gets made.
6. Power cycle. $10 02 answers again and the seed comes back nonzero.

Let me know if it works out.

[fl0wl0w]

Seed of 0000 means you are in the bootloader and already in programming mode. no need to enter programming mode. Just load and execute kernel. Just modify PCMHammer to keep going even if it times out on programming mode responses. That is basically what enslaved procedure is doing. Although it is not required to wait 10 seconds before requesting seed. Sending the key i think won't get a response.

[gixxer92]

For comparison, I’ve completed repeatable, read-only E92 captures using a Macchina M2 on 500 kbit/s CAN. Claude and ChatGPT helped me develop and validate the software. The controller is from a 2018 Tahoe, running OS 12711165, and is currently used in my truck with a 10-speed. This was a normal, nonzero-seed read, not a recovery from a software brick.
1. The tool identified the live controller at 7E0/7E8 and verified its identity and OS.
2. 27 01 returned a nonzero five-byte seed. The calculated key was sent with 27 02, and the ECM replied 67 02.
3. 10 02 received 50; 28 received 68. After 3E, A5 01 received E5.
4. A5 03 timed out. On retry it returned 7F A5 22, but the reader continued.
5. 34 received 7F 34 78 (response pending), followed by 74. The two 36 kernel-upload blocks received 76 and 99. The RAM kernel then ran and reported its version and flash-chip identity.
6. Through the kernel, we physically read 0x040000–0x3FFFFF, then returned the ECM to normal mode with 20 → 60.
7. The ECM identity was rechecked and repeated the read independently. Both captures matched byte-for-byte. No flash erase or write was performed.
The saved files have synthetic FF in 0x000000–0x03FFFF; that region was not physically read on this OS 12711165 capture. The relevant observation for this discussion is that the kernel upload and read succeeded despite the A5 03 timeout/7F A5 22. I can’t say from this test whether the same path works with a 0000 seed.
I ran out of bandwidth already for the week between the two AI's and have to wait until Tuesday to do more. It's like the 90's again with limited text messaging... lol

[kur4o]

gixxer92,

you can improve the sequence to get better reliability and keep bus traffic to minimum to avoid errors.


you can use extended can frames to all nodes
00 00 01 01 fe

first send
10 02
than
28
than schedule periodic 3e message every 1600ms

you can use extended can frames to all nodes
00 00 01 01 fe

than unlock pcm

a5 01

a5 03

than upload mode 34 and 36

That way there will be no idle bus traffic, it will speed reading with less errors.

after reading is done
send mode 20 to reset bus and modules

[enslaved87]

For comparison, I’ve completed repeatable, read-only E92 captures using a Macchina M2 on 500 kbit/s CAN. Claude and ChatGPT helped me develop and validate the software. The controller is from a 2018 Tahoe, running OS 12711165, and is currently used in my truck with a 10-speed. This was a normal, nonzero-seed read, not a recovery from a software brick.
1. The tool identified the live controller at 7E0/7E8 and verified its identity and OS.
2. 27 01 returned a nonzero five-byte seed. The calculated key was sent with 27 02, and the ECM replied 67 02.
3. 10 02 received 50; 28 received 68. After 3E, A5 01 received E5.
4. A5 03 timed out. On retry it returned 7F A5 22, but the reader continued.
5. 34 received 7F 34 78 (response pending), followed by 74. The two 36 kernel-upload blocks received 76 and 99. The RAM kernel then ran and reported its version and flash-chip identity.
6. Through the kernel, we physically read 0x040000–0x3FFFFF, then returned the ECM to normal mode with 20 → 60.
7. The ECM identity was rechecked and repeated the read independently. Both captures matched byte-for-byte. No flash erase or write was performed.
The saved files have synthetic FF in 0x000000–0x03FFFF; that region was not physically read on this OS 12711165 capture. The relevant observation for this discussion is that the kernel upload and read succeeded despite the A5 03 timeout/7F A5 22. I can’t say from this test whether the same path works with a 0000 seed.
I ran out of bandwidth already for the week between the two AI's and have to wait until Tuesday to do more. It's like the 90's again with limited text messaging... lol

Save your tokens brother. All the recipe's are already OSS and the kernels (and source for them) exist here as well. If you want to still burn tokens, point your agent at that git and build your own fork from the proven path.

https://github.com/enslaved87/sCANtool-public

[gixxer92]

For comparison, I’ve completed repeatable, read-only E92 captures using a Macchina M2 on 500 kbit/s CAN. Claude and ChatGPT helped me develop and validate the software. The controller is from a 2018 Tahoe, running OS 12711165, and is currently used in my truck with a 10-speed. This was a normal, nonzero-seed read, not a recovery from a software brick.
1. The tool identified the live controller at 7E0/7E8 and verified its identity and OS.
2. 27 01 returned a nonzero five-byte seed. The calculated key was sent with 27 02, and the ECM replied 67 02.
3. 10 02 received 50; 28 received 68. After 3E, A5 01 received E5.
4. A5 03 timed out. On retry it returned 7F A5 22, but the reader continued.
5. 34 received 7F 34 78 (response pending), followed by 74. The two 36 kernel-upload blocks received 76 and 99. The RAM kernel then ran and reported its version and flash-chip identity.
6. Through the kernel, we physically read 0x040000–0x3FFFFF, then returned the ECM to normal mode with 20 → 60.
7. The ECM identity was rechecked and repeated the read independently. Both captures matched byte-for-byte. No flash erase or write was performed.
The saved files have synthetic FF in 0x000000–0x03FFFF; that region was not physically read on this OS 12711165 capture. The relevant observation for this discussion is that the kernel upload and read succeeded despite the A5 03 timeout/7F A5 22. I can’t say from this test whether the same path works with a 0000 seed.
I ran out of bandwidth already for the week between the two AI's and have to wait until Tuesday to do more. It's like the 90's again with limited text messaging... lol

Save your tokens brother. All the recipe's are already OSS and the kernels (and source for them) exist here as well. If you want to still burn tokens, point your agent at that git and build your own fork from the proven path.

https://github.com/enslaved87/sCANtool-public

Thanks for that, Enslaved. I’ve been following your work here and over on the Gen 5 HPTuners forum. Awesome work so far!

My work has gone in a few different directions that may be useful to compare. I currently have around 1,800 BIN files indexed. Within that collection, I’ve identified 74 distinct E92/E92A BINs covering 11 operating systems. Some share the same OS but have different subsystem segments.
Some of my reverse engineering has been with intent of integration with Holley and MaxxECU driving the 8HP and GM 8/10 speeds. I have see Custom ECU is ahead in this as well. They have released a few GM E38 OS's driving the transmissions, that "were a never were able to" previously. Add in the dash configurator and they are well ahead of most. I do most of this for the fun, but fun is not cheap when I'm running the two AI's monthly.

Over the last couple of weeks, I’ve been recording raw CAN traffic with the M2 alongside HP Tuners Scanner. So far, I have around 100 solid matches between scanner values and positions in the captured scan traffic. Since some channels appear in more than one recording, that works out to about 45 different scanner channels. A few more look promising, but I’m not ready to call those known yet.

One thing I found interesting is that the byte positions can move depending on which channels are selected in HP Tuners. The same information is still present, but it isn’t always in the same position when the scanner channel list changes.
I’m using a 64 GB SD card in the M2 now, so it can collect millions of CAN frames during a session. It has been pretty cool watching the software work through all that data and match it back to the HP Tuners channels.

I may also have one kernel-related finding worth comparing. On my late E92A, one of the kernels I tested was able to physically read the F800 areas that your reader currently fills with FF, apart from two eight-byte ECC holes. That may be a kernel difference or an early-versus-late controller difference, so I wouldn’t assume it applies everywhere.

Once I get everything cleaned up and documented properly, I plan to put the useful parts on GitHub (I think I've found most of what is out there).
I’d definitely be interested in comparing notes, and I’m happy to pass along anything that may help your project.

[enslaved87]

For comparison, I’ve completed repeatable, read-only E92 captures using a Macchina M2 on 500 kbit/s CAN. Claude and ChatGPT helped me develop and validate the software. The controller is from a 2018 Tahoe, running OS 12711165, and is currently used in my truck with a 10-speed. This was a normal, nonzero-seed read, not a recovery from a software brick.
1. The tool identified the live controller at 7E0/7E8 and verified its identity and OS.
2. 27 01 returned a nonzero five-byte seed. The calculated key was sent with 27 02, and the ECM replied 67 02.
3. 10 02 received 50; 28 received 68. After 3E, A5 01 received E5.
4. A5 03 timed out. On retry it returned 7F A5 22, but the reader continued.
5. 34 received 7F 34 78 (response pending), followed by 74. The two 36 kernel-upload blocks received 76 and 99. The RAM kernel then ran and reported its version and flash-chip identity.
6. Through the kernel, we physically read 0x040000–0x3FFFFF, then returned the ECM to normal mode with 20 → 60.
7. The ECM identity was rechecked and repeated the read independently. Both captures matched byte-for-byte. No flash erase or write was performed.
The saved files have synthetic FF in 0x000000–0x03FFFF; that region was not physically read on this OS 12711165 capture. The relevant observation for this discussion is that the kernel upload and read succeeded despite the A5 03 timeout/7F A5 22. I can’t say from this test whether the same path works with a 0000 seed.
I ran out of bandwidth already for the week between the two AI's and have to wait until Tuesday to do more. It's like the 90's again with limited text messaging... lol

Save your tokens brother. All the recipe's are already OSS and the kernels (and source for them) exist here as well. If you want to still burn tokens, point your agent at that git and build your own fork from the proven path.

https://github.com/enslaved87/sCANtool-public

Thanks for that, Enslaved. I’ve been following your work here and over on the Gen 5 HPTuners forum. Awesome work so far!

My work has gone in a few different directions that may be useful to compare. I currently have around 1,800 BIN files indexed. Within that collection, I’ve identified 74 distinct E92/E92A BINs covering 11 operating systems. Some share the same OS but have different subsystem segments.
Some of my reverse engineering has been with intent of integration with Holley and MaxxECU driving the 8HP and GM 8/10 speeds. I have see Custom ECU is ahead in this as well. They have released a few GM E38 OS's driving the transmissions, that "were a never were able to" previously. Add in the dash configurator and they are well ahead of most. I do most of this for the fun, but fun is not cheap when I'm running the two AI's monthly.

Over the last couple of weeks, I’ve been recording raw CAN traffic with the M2 alongside HP Tuners Scanner. So far, I have around 100 solid matches between scanner values and positions in the captured scan traffic. Since some channels appear in more than one recording, that works out to about 45 different scanner channels. A few more look promising, but I’m not ready to call those known yet.

One thing I found interesting is that the byte positions can move depending on which channels are selected in HP Tuners. The same information is still present, but it isn’t always in the same position when the scanner channel list changes.
I’m using a 64 GB SD card in the M2 now, so it can collect millions of CAN frames during a session. It has been pretty cool watching the software work through all that data and match it back to the HP Tuners channels.

I may also have one kernel-related finding worth comparing. On my late E92A, one of the kernels I tested was able to physically read the F800 areas that your reader currently fills with FF, apart from two eight-byte ECC holes. That may be a kernel difference or an early-versus-late controller difference, so I wouldn’t assume it applies everywhere.

Once I get everything cleaned up and documented properly, I plan to put the useful parts on GitHub (I think I've found most of what is out there).
I’d definitely be interested in comparing notes, and I’m happy to pass along anything that may help your project.

Off to a good start man! Thats a healthy pile of bins.

I've got ~34 OS's characterized and mapped. Honestly, I'm not entirely sure how many there ACTUALLY are in the production realm. I can tell you that it took me a long time to get that quantity on disk and that was with the help of several of the awesome people on the forum!

The FF thing on read is affectionately known as 'skip-tails'. One of my nemesis. Was implemented as a crash guard around the ECC holes. That said, I JUST looked back at this issue (sCANtool kernel bug) with fresh eyes and have patched the issue. Thus all readable bytes are now saved. Pull the updates from git and give it another shot.

I'll send you a PM of the OS Id's i've got, and then you can check vs your stash.

One side note, the two document streams that have dramatically expedited this process are the GM PPEI documents and all relevant documents from NXP. Without those, this would have taken light years trying to hunt and poke the disassembly.

[antus]

Thanks enslaved87, I was able to recover it, though im not exactly sure what happened. I changes the unlock process and delays but also had issues with both of my j2534 interfaces on that bus. After power cycling the interfaces it booted up and vin and key had become readable. So I read and wrote the pcm which didnt show any flash damage and the write succeeded but probably didnt change anything. So all up and running and i'm happy with the e92 code about to be merged in to develop in pcmhammer but still none the wiser about the state the pcm or one or both of the j2534 interfaces were in.