E39A research notes and cloning

[morfi]

In this thread I want to consolidate some of the knowledge I gathered in the process of an attempt to clone E39A ECM. The main goal was to be able to clone the ECM in full (ie. _all_ calibration files and NVM banks). I don't own any of the commercial tools, such as obdstar, but I believe they only dump flash region(s) from the main MCU (MPC5566) and do nothing with calibration parts from slaves (SC900684AAF), which in my opinion, does not constitute a full clone.

Any matching SC900684AAF dump, pin trace, MON08 work or additional SPI command information would be very useful (its WIP here with low rate of success as far as I can tell)

# Hardware
#########

1. The main processor is a GM-marked SGMPPC6230F7MVR, effectively a Freescale/NXP MPC5566 with an e200z6 PowerPC core:

Code: Select all

| 3 MiB main flash: 0x00000000–0x002FFFFF
 \___ L0 0x00000000–0x00003FFF: NVM bank A
      L1 0x00004000–0x0000FFFF: boot/low software
      L2 0x00010000–0x0001BFFF: boot/low software
      L3 0x0001C000–0x0001FFFF: NVM bank B
      L4–H19 0x00020000–0x002FFFFF: MOD02–06 and MOD01
| 128 KiB SRAM: 0x40000000–0x4001FFFF
| 1 KiB shadow flash: 0x00FFFC00–0x00FFFFFF

2. There are also two identical Freescale SC900684AAF 80-pin QFP devices. Static analysis from MOD07/08 files identifies them as custom CPU08/HC908-family derivatives:

- One contains the MOD07/MOD08 second-MPU software and communicates on MPC5566 DSPI-A/PCS0.
- The other is the external watchdog/safety companion on DSPI-A/PCS1.
- Which physical QFP is PCS0 and which is PCS1 is currently unknown to me (pending tracing)

# Software
########

The resident MPC5566 boot software is part of the low 3 MiB main-flash array. The chip reports Boot Software as part no 12653997, but normal SPS does not provide this as a separate file.
SPS' 12639160.bin (MOD00) is a temporary RAM programming utility used by SPS.

The known programming path is:
- Physical CAN IDs 0x7E0/0x7E8
- GMLAN SecurityAccess algorithm 0xDC
- Enter programming state and unlock
- $34 RequestDownload, using 34 00 <size:u24>
- $36 transfers the RAM routine
- $36 80 executes it

MOD07 contains a duplicated/non-physical 0x80-byte PMF header followed by the real 0x2C00-byte subordinate image. The second-MPU map currently looks like this:

- 0xBE00–0xBFFF: MOD07 tables/header
- 0xC000–0xE9FF: MOD07 application
- 0xEA00–0xEBFF: MOD08 calibration
- 0xEC00–0xFFFF: resident boot/programming API, security bytes and vectors — missing from SPS

+---------------------
| SPS product distribution
+---------------------

Code: Select all

   MOD      Part number    Function                           Physical destination
  ━━━━━━━  ━━━━━━━━━━━━━  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   MOD01       12658499    Primary operational software       0x80000–0x2FFFFF, plus reconstructed PMF header
  ───────  ─────────────  ─────────────────────────────────  ─────────────────────────────────────────────────
   MOD02       12652313    Vehicle-system calibration         0x20000–0x21C37
  ───────  ─────────────  ─────────────────────────────────  ─────────────────────────────────────────────────
   MOD03       12660444    Fuel-system calibration            0x21C38–0x25F87
  ───────  ─────────────  ─────────────────────────────────  ─────────────────────────────────────────────────
   MOD04       12652319    Vehicle-speed calibration          0x25F88–0x26407
  ───────  ─────────────  ─────────────────────────────────  ─────────────────────────────────────────────────
   MOD05       12660217    Engine-diagnostic calibration      0x26408–0x3422F
  ───────  ─────────────  ─────────────────────────────────  ─────────────────────────────────────────────────
   MOD06       12663071    Engine calibration                 0x34230–0x7FFFF
  ───────  ─────────────  ─────────────────────────────────  ─────────────────────────────────────────────────
   MOD07       12638535    Second-MPU operational software    HC08 0xBE00–0xE9FF
  ───────  ─────────────  ─────────────────────────────────  ─────────────────────────────────────────────────
   MOD08       12652302    Second-MPU calibration             HC08 0xEA00–0xEBFF

# Watchdogs
#########

A RAM kernel must service two independent MPC-side watchdog paths:

1. MPC5566 core watchdog: clear TSR[ENW] using mtspr 336,0x80000000
2. External companion on DSPI-A/PCS1 using 16-bit odd-parity commands

The companion is first probed with 0x0000. Depending on response bit 15, the keepalive pair is:

- Bit 15 clear: D401, then DC00
- Bit 15 set: DE01, then D600

.

[morfi]

(reserved for changelog)

[fl0wl0w]

The external watchdog is probably the 20845-007 power IC they use on just about everything with an MPC (E78, E92). It's a very basic spi protocol and does not have any configuration flash.

The HC08 stores the VIN, emissions related DTC info, and some other OBD2 CVNs. Maybe immo stuff, but i have not come across that in main firmware yet. It does have hardware connections to disable the fuel pump and injector outputs which would suggest something to do with IMMO, but as far as i can tell it just needs a few basic spi messages to enable fuel and not some sort of seed/key. They also use this chip in the same configuration on just about everything. If you come across a binary for it, let me know as i would like to take a look and decompile it. From that it should be pretty trivial to figure out how to read/write to it.

From high confidence I can tell you those QFPs are for direct injector drivers and not for the HC08 stuff you are looking for. The HC08 is the SOP-16 chip that is above them in your image.

Here are some links for you.
The 20845-007 power IC has the following SPI protocol https://github.com/FL0WL0W/KernelMPC556 ... Device.cpp
The HC08 has the following protocol for enabling the fuel. I haven't created the rest of the protocol for reading/writing DTCs, VIN, firmware, etc. https://github.com/FL0WL0W/EFIGenieE78/ ... Device.cpp

[morfi]

Thanks a lot for the tip! That might make reading the missing parts far easier.

I have ordered non-custom HC08 NXP ICs (MC68HC908QY4) and will use them as a test cases for developing arduino-based HC08 reader before I put the ECM's chip on the bench.

[kur4o]

Why do you think those extra volatile info is stored on external chip and not main flash that have some virtual eeprom region.

Reading Platform config: e39a-platform.xml [OK]
Loading file: e39a_nbb.xml [OK]
(SegmentSeek-e39a.xml)
e39a OS 12658499 2G4GN5EX5E9282163.bin (e39a_nbb (v 1))

Segments:
OS PN: 12658499, Ver: AA, Nr: 1 [80000 - 2FFFFF], Size: 280000
System PN: 12652088, Ver: AF, Nr: 2 [20000 - 21C37], Size: 1C38
Fuel PN: 12660461, Ver: AB, Nr: 3 [21C38 - 25F87], Size: 4350
Speedo PN: 12652101, Ver: AG, Nr: 4 [25F88 - 26407], Size: 480
EngineDiag PN: 12660339, Ver: AB, Nr: 5 [26408 - 3422F], Size: DE28
Engine PN: 12660332, Ver: AB, Nr: 6 [34230 - 7FFFF], Size: 4BDD0
EEPROM_DATA PN: PCRASTN#, Ver: ABMU [0000 - 3FFF], Size: 4000
Vin: 2G4GN5EX5E9282163
Serial: 86ABMUC122623343
trace code: A1142707
PCM: SEGUGMS3--VAL--V42B-122623343---A2C7303490400---
PCMid2: PTSW-GMS3-V1.60
Checksums:
OS Checksum 1: 8EC9 [OK] Checksum 2: 68C5 [OK] [n/a]
System Checksum 1: 7CB1 [OK] Checksum 2: 0464 [OK] [n/a]
Fuel Checksum 1: 9DCC [OK] Checksum 2: B74D [OK] [n/a]
Speedo Checksum 1: 2991 [OK] Checksum 2: FC38 [OK] [n/a]
EngineDiag Checksum 1: 4DEA [OK] Checksum 2: 0543 [OK] [n/a]
ENG extra1 Checksum 1: F51EA157 [OK] Checksum 2: F54E1454 [OK]
ENG extra2 Checksum 1: F953099F [OK]
Engine Checksum 1: A934 [OK] Checksum 2: DEBF [OK] [n/a]
EEPROM_DATA
Seeking tables... (tableseek-e38.xml) Done
PID search not implemented for this file type
PIDs not found

As some other threads specify the hc08 chip containing slave data[ ETC], I can suggest that e39a also have slave data stored on that chip. You can get files from sps, but boot part of slave will be missing[only OS and CAL of slave are available for flashing.

[morfi]

I'm mostly interested in os/cal/boot from slave. While I can get latest files from SPS, they not neccessairly must be 1:1 to whats on the ECM Im cloning, thus getting these files directly from the chip is what Im after.

Another thing I want from the slave kernel is to RE it to find out if it supports flash read over CAN/SPI

[kur4o]

On e38 slave, which uses hc08 too, flashing is done through spi bus, main cpu relays some code and slave OS and cal data. FLashing gets triggered by calibration number. On e39a I bet it uses similar logic. Reading over spi is another matter. Main hurdle is to execute custom code on demand, even though there might be some backdoor left for debugging.

[antus]

I don't think it'll support read. That was dropped on the E38 and is very unlikely to have been re-added in later PCMs. Because the slave is throttle related it looks like it was considered an ultra secure system is much less flexible than the main cpu. I tried to implement read with my own kernel in E38 but was not successful in getting arbitary code execution without the slave reseting itself. You seem to have made some good progress in this area and found more watchdogs so you might be able to. It seems you need to upload and execute in one hit and hold the slave open because it resets it memory if you upload code and don't use it straight away. So its a one shot chance to upload and take over the slave side. The slave re-maps memory so the boot sector is not available while it is running. It seems you need 'BDM' for that, which isn't BDM, its a different single wire protocol, but that can read it out. This is all based on the E38 but I expect E37a will be the same. USB-JTAG-NT software can speak the protocol that implements HC08 read. I am not sure if the maker of that software has identified the connections yet for E37a, if he has not and if you need the help he may be willing. Once you've done that you can learn more about the SPI receive side and reboot process in to your own kernel.

[fl0wl0w]

You can find how to read out using the 1 wire protocol in the HC08 datasheet, but it might require some sort of password to enable read.

It probably did more on the E38, but on the newer designs, the HC08 only looks loosely throttle related. It has a single TPS input and can disable the throttle output, but as far as i can tell it does not have accelerator or a second TPS input unless that gets passed over SPI. The throttle disable output is also the same output that disables the fuel pump. The MPC controls the throttle hbridge pwm and open/close. Then there is a separate fuel injector disable output. It really looks security related, but just sending it some simple hardcoded SPI messages seems to keep it happy. It seems to be used for some storage as well. To me it just kind of looks like a crappy obfuscation to prevent some very naive attacks at circumventing emissions. if you remove it, no throttle no fuel. If you reflash the MPC, emmisions dtcs stick. You turn off emmisions dtcs, if they already triggered then they stick.

I will agree there is probably no GM way to read it. That's the way they built the MPC bootloader as well, write only, but with the ability to load and execute code in RAM. Altho there may be no reason to read it from our perspective either. From what i can tell GM stuck this design in a ton of ECMs and the OS is probably the same on all of them and rarely changes. All it needs is the proper calibration section which should be easily generated from the MPC firmware. Things like VIN, and CVN numbers are probably all that need to be set to create a full clone.

[antus]

I think they really want to avoid a WOT failure at all costs. They need to know it's running and running properly and reset it and recover if anything unexpected happens. That seems to be its entire purpose, when otherwise they could have controlled ETC from the main CPU pretty easily. This was 2013, but I am not sure when the accident happened and the saga begun. Perhaps GM just took the safety by design approach from before this even happened. But it really looks like there was a GM memo to say "make absolutely sure this cannot happen to us" at some stage https://www.edn.com/toyotas-killer-firm ... sequences/