so i'm getting more work done with understanding the flash routines.

figured i'd start documenting my progress

while googling around i found this on the aussie forums, and some of the modes seemed familiar from readin' the code, although not identical; for example modes 2 and 3 are different... it seems there are some standards for flash ECMs:

Code:
Mode 0 – Clear All ALDL Modes
Mode 1 – Data Frames (There are many different message frames)
Mode 2 – Request 64 Bytes of Memory
Mode 3 – Request 6 Particular Bytes of Memory
Mode 4 – Control Mode
Mode 5 – Enter Download Mode (GM Development)
Mode 6 – Address Of Routine to Execute (GM Development)
Mode 7 – Broadcast Mode (GM Development)
Mode 8 – Disable Bus Chatter
Mode 9 – Enable Bus Chatter
Mode 10 – Clear Malfunction Error Codes
Mode 13 - Security Seed/Key on Flash PCMs
Mode 16 - Flash PCM Write
Now, although there is code for modes 5 and 6 that appear to be related to the flash program, they would not respond in any sane way in $EE

I sniffed a tech tool and found a 0xE4 (length) 0x0D request/response when entering any flash related routine; which corresponded to mode 13. This is definitely a 'challenge/response keyed' ecm.. and I am horrible with math.

First thing i noticed is the key and response is static within a particular bin flash. My test bench ecm always sends/recieves the same code; but my car's ecm has a different 'seed value'. I think it must be generated from some static data in the bin.

I looked at the code and asked kur4o for some insight, he tipped me off where the key/seed are likely stored in memory. I found a 16 bit compare from 0x0E02 on the t-side to the incoming two bytes in a mode 0x02 request that confirms that's where the key is stored..

We noted they are passed from t-side to e-side unmodified, meaning the two halves of the ECM always share a key, which makes life easier.

Code:
(T-Side)
L0E00_M13SEED	=	$0E00 ; 16bit
L0E02_M13KEY	=	$0E02 ; 16bit
Then I read the code again myself.

After some staring and writing pseudo-code, I couldn't figure out where the hell the seed/key math is, or how it works, although it must be simple. Flashing some new bins on my test bench ECM seemed to cycle the key a bit, so i used the opportunity to gather some data and see if i could reverse the math that way.

Then my coffee kicked in and I thought up a great workaround. Since the generated keys are stored in memory and not a register, and not cleared after being generated.. Just grab them with mode 3 requests!

Code:
.. .. .. xx xx ..
f4 58 03 0e 00 [CKSUM] ; low byte of seed
f4 58 03 0e 01 [CKSUM]  ; high byte of seed
f4 58 03 0e 02 [CKSUM]  ; low byte of key
f4 58 03 0e 03 [CKSUM]  ; high byte of key
Seems to work with one caveat, on a cold boot, you have to make a request for the key first before it'll hit the mode 13 subroutine and generate a challenge/response in memory.

So here's the mode 13 synopsis (where ecm_addr is 0xF4 for t-side and 0xE4 for e-side):
Code:
request seed: you->ecm [ECM_ADDR] [MSG_LEN] 0x0D 0x01 [CHECKSUM]
get seed: ecm->you [ECM_ADDR] [MSG_LEN] 0x0D 0x01 [SEED_LOW] [SEED_HIGH] [CHECKSUM]
(or if ecm already unlocked) ecm->you [ECM_ADDR] [MSG_LEN] 0x0D 0x01 0x00 0x00 [CHECKSUM]
sumit key: you->ecm [ECM_ADDR] [MSG_LEN] 0x0D 0x02 [KEY_LOW] [KEY_HIGH] [CHECKSUM]
if unlocked successfully: ecm->you [ECM_ADDR] [MSG_LEN] 0x0D 0x02 0xAA [CHECKSUM]
Now that mode 5/6/etc are working and the ecm is in development mode we can have some real fun......