E92 PCM Reverse Engineering

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
Highlander
Posts: 81
Joined: Sun May 11, 2014 6:36 pm
cars: Z06

Re: E92 PCM Reverse Engineering

Post by Highlander »

antus wrote:it might restart them after boot. its likely watchdog isnt running in the boot recovery mode (if there is one). logic for that might be that if the boot code fails you have a brick, watchdog isnt going to help, and maybe even watchdog will cause problems due to an external factor like something connected to an interupt line stuck high. The main OS might turn them back on after an initial setup, after the boot code is finished. Just because it turns them off, doesnt mean it stays that way for operation. I have nothing to back any of this up, its just a thought and a reason to keep an open mind.
There is a boot pin mode for these ECMs that I wonder if one could trace to the main connectors.

Thanks
User avatar
Tazzi
Posts: 3425
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: E92 PCM Reverse Engineering

Post by Tazzi »

Highlander wrote:
antus wrote:it might restart them after boot. its likely watchdog isnt running in the boot recovery mode (if there is one). logic for that might be that if the boot code fails you have a brick, watchdog isnt going to help, and maybe even watchdog will cause problems due to an external factor like something connected to an interupt line stuck high. The main OS might turn them back on after an initial setup, after the boot code is finished. Just because it turns them off, doesnt mean it stays that way for operation. I have nothing to back any of this up, its just a thought and a reason to keep an open mind.
There is a boot pin mode for these ECMs that I wonder if one could trace to the main connectors.

Thanks
I think IO terminal has that one in a GM ECU pdf they released???
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: E92 PCM Reverse Engineering

Post by bubba2533 »

Ok, I'd like to get back to this since I am at a nice stopping point with my P59 custom OS.

I still haven't figured anything out with the watchdog, but I think I need to jump on to something else. I know I'll need a bench ECU that's more capable than I have now (only power, gnd, and comms) so that I can toggle/modulate inputs like I did with my P59 PCM. So I'll probably try to wire up an adapter to go from ECU to a bunch of breadboards. I wish I did that with the P59 PCM because every time I added a wire to my setup it became harder to work with.

I think once I get it wired up I'll start trying to play around with Mode 23 to see if I can log some ram addresses for inputs.

This would probably be a lot easier if I actually owned something with a E92 ECU haha.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: E92 PCM Reverse Engineering

Post by Gatecrasher »

I'd be happy to pull data from my car, but I don't know how useful it'll be since we're probably on different OS versions. Memory addresses won't line up and such.
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: E92 PCM Reverse Engineering

Post by bubba2533 »

If you have an example Mode 23 request / response that would be helpful.

For example, in the OS I have disassembled it looks like 0x40012d24 is the engine speed in RAM, but I haven't tried to figure out how to convert that into the Mode 23 message.

Based on the disassembly I think this ECU Mode 23 needs a 4 byte address and a 2 byte memory size and I found this online, but it's quite vague.
Memory Address:
The parameter memoryAddress is used to select the starting address of ECU memory from which data is to be
retrieved. A portion of the memoryAddress parameter (most significant bits or bytes) can be used as a
memoryIdentifier.
An example of the use of a memoryIdentifier would be a dual processor ECU with 16-bit addressing and
memory address overlap (when a given address is valid for either processor but yields a different physical
memory device). In this case, a 3-byte memoryAddress parameter can be specified and the most significant
byte of the memoryAddress parameter could then be used to select which physical memory device the tester is
attempting to retrieve data from. Any usage of a memoryIdentifier shall be documented in the appropriate CTS,
SSTS or supplemental diagnostic specification referenced by the CTS or SSTS.
Memory Size:
The parameter memorySize is used to select the number of consecutive memory addresses (in ascending
order) to be read starting at memoryAddress (memorySize includes the starting location). The contents of the
range of addresses defined by memoryAddress and memorySize are provided in the positive response
message. memorySize shall have a value between 1 and 4092 bytes if a 2-byte memoryAddress parameter is
used (4091 if 3-byte addressing is used and 4090 if 4-byte addressing is used). The maximum value comes
from the maximum number of bytes allowed by the USDT protocol, less the bytes for the response service
Identifier and the address information from the request message which is included in the response. An ECU
may choose to limit the maximum value of memorySize based on ECU resources (e.g., the size of the Network
Layer Buffer). If an ECU limits the maximum value of the memorySize parameter, then the maximum allowed
value shall be documented in the appropriate CTS or SSTS.
This is what I have so far in the Mode 23 decompile function in Ghidra:

Code: Select all

/* Read Memory By Address */

void Mode_23_Func(undefined *param_1)

{
  byte bVar1;
  short sVar2;
  bool bVar3;
  bool bVar4;
  longlong lVar5;
  undefined *puVar6;
  int iVar7;
  char cVar8;
  uint uVar9;
  int iVar10;
  uint uVar11;
  
  lVar5 = (longlong)(int)param_1;
  puVar6 = (undefined *)FUN_0032624c();
  sVar2 = *(short *)param_1;
  iVar7 = Convert_Mem_Address(lVar5 + 3);
  bVar1 = param_1[8];
  if (sVar2 != 7) {
                    /* subFunctionNotSupported */
    Diag_Response(lVar5,0x12);
    return;
  }
  if (*(ushort *)(param_1 + 7) - 1 < 0x10) {
    cVar8 = Check_Address_Range?(iVar7,bVar1);
    if ((cVar8 == '\0') &&
       ((Security_Access_Unlocked == '\x01' ||
        ((cVar8 = FUN_002d49e8(), cVar8 == '\0' && (cVar8 = FUN_00324b20(), cVar8 == '\x01')))))) {
                    /* requestOutOfRange */
      Diag_Response(lVar5,0x31);
    }
    else {
      bVar3 = false;
      bVar4 = false;
      uVar11 = 0;
      uVar9 = (uint)bVar1;
      if (uVar9 != 0) {
        do {
          iVar10 = (uVar11 & 0xff) + iVar7;
          cVar8 = FUN_002ff4f8(iVar10);
          if (cVar8 == '\0') {
            bVar3 = true;
          }
          cVar8 = FUN_003040f0(iVar10);
          if (cVar8 == '\0') {
            bVar4 = true;
          }
          uVar11 = uVar11 + 1;
        } while ((uVar11 & 0xff) < uVar9);
        if ((bVar4 && bVar3) && (Security_Access_Unlocked != '\0')) {
                    /* requestOutOfRange */
          Diag_Response(lVar5,0x31);
          return;
        }
      }
      uVar11 = 0;
      if (uVar9 != 0) {
        do {
          puVar6[uVar11 + 7] = *(undefined *)(iVar7 + uVar11);
          uVar11 = uVar11 + 1 & 0xff;
        } while (uVar11 < uVar9);
      }
      *puVar6 = 0;
      puVar6[1] = bVar1 + 5;
      puVar6[2] = 99;
      puVar6[3] = param_1[3];
      puVar6[4] = param_1[4];
      puVar6[5] = param_1[5];
      puVar6[6] = param_1[6];
      Diag_Msg_Ready? = 1;
    }
    return;
  }
                    /* requestOutOfRange */
  Diag_Response(lVar5,0x31);
  return;
}
It looks like the function "Check_Address_Range?" that I have is doing the verification of the address and size requested and returning a bool based on the check. It seems like perhaps if the security is unlocked then it allows for a larger memory address access.

I have tried to understand how that function works to potentially figure out how to format the message address, but haven't figured it out as of yet. Obviously I could just try to send a bunch of messages until I get a positive response and then that could tell me more about how that function works, but I haven't done that.

Either way lots more work to be done, but I'll eventually figure it out.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
kur4o
Posts: 950
Joined: Sun Apr 10, 2016 9:20 pm

Re: E92 PCM Reverse Engineering

Post by kur4o »

I can give you examples for e78, e92 should be close. If you want unrestricted ram access, you we will need to patch the OS so it skips the checks.

[00 00 07 e0] [23] [40 00 00 00] [00 10]
000007e0=pcm header
23=mode
40000000=read address
0010=size in hex[most can take from 1 to 16 bytes]
gmtech825
Posts: 187
Joined: Fri Feb 24, 2017 11:27 am

Re: E92 PCM Reverse Engineering

Post by gmtech825 »

kur40 is correct, just don't forget the payload size [07] after the [23] . I'll add that 7f 12 response means you've formatted the request incorrectly. 7f 31 response is because the address is either restricted or the size you've requested is too large. if the size requested + the address lands in a restricted area you will also recieve the 7f 31 response. the e92 I've looked at have a max read size of 0x10.

good luck, anyone tried to decompile an e92A yet? I'm not having fun with that one right now.
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: E92 PCM Reverse Engineering

Post by Gatecrasher »

Ghidra made short work of it. There's SO much code in there.
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: E92 PCM Reverse Engineering

Post by bubba2533 »

Ok, it looks like I'm getting positive responses to Mode 23 requests. This is with nothing connected to the ECU, so I'm not really able to learn much yet but it's good progress once I get I get things connected.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: E92 PCM Reverse Engineering

Post by Gatecrasher »

FYI, this VIN change utility works great. https://www.customecm.com/custom-software

The VIN change stuck through a full power cycle on an E92. It would stick through ignition cycles on an E92A, but would revert after a full power cycle. I was told sometimes you have to leave the ignition off for over 10 minutes to get it to work on those. I still couldn't get it to stick, so I took a risk and tried something I found in the utility file. Sending 0x7E0 07 AE 28 80 00 00 00 00 seems to force it to commit all pending changes to emulated EEPROM. The VIN is permanent now. I had no problem bench programming it with the SPS account I have for my car. Didn't need a BCM hooked up either.

Gonna see if I can find the skip shift logic and shut that off.
Post Reply