$EE Flash tool progress

[steveo]

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:

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.

(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!

.. .. .. 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):

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......

[steveo]

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.

I take that back, it was a timing issue. Works first time every time.

[steveo]

looks like you need to use mode 0x05 to enable any of the mode 6 comms with a simple request to both the t-side and e-side. you send 0x05 and you get back 0x05 0xAA if successful.

it appears that 0x05 does a whole bunch of checks, and probably sends something other than 0xAA if it's unsafe to program (car running or whatever)

[kur4o]

I was wondering all day what algorithm is used.
Dig through alot of bins to get the seed key pairs.
Than I remeber i have a list with 256 gm algos for seed key request used with obd2 pcm, with short description stating they were developed in 1993. I look through them and still couldn`t figure out anything.
After staring at the pairs for a long time I found some patterns and here is the algorithm
swap algorithm;
seed digit =key digit or vice versa
7=8
6=9
5=a
4=b
3=c
2=d
1=e
0=f

example seed 5c60
key a39f

Funny thing I found if PCM denies mode 5 and 6 it sends answer $33, which is also used in OBD2 PCM which means Security access denied.
I guess $aa means security access granted.

05 mode do some big loop routine, still very unclear what`s the purpose for it.

Have you figure out how mode 6 works. Do you think it can be used to modify single memory bytes.


There is some list for ALDL modes from EFilive v4 program

11 write programm data
10 download and execute 3 byte address
0f examine memory 3byte address
0e memory dump 64/3 byte address
0d security access mode
0c modify memory
0b normal communication
0a clear codes
09 resume
08 suspend
07 command message (MODULE TO MODULE COMMUNICATION)
06 download and execute
05 download
04 device contol
03 examine 2 bytes address
02 memory dump 64/2bytes address
01 request aldl frame
00 normal communication

Mode 0c is used for writing vin and CALid to PCM eeprom memory

[steveo]

After staring at the pairs for a long time I found some patterns and here is the algorithm
swap algorithm;
seed digit =key digit or vice versa
7=8
6=9
5=a
4=b
3=c
2=d
1=e
0=f

nice work buddy!! i was fully staring at it in 8 bits... i never thought to look at it in 4 bit nibbles, where it becomes so clear.

i might just keep my mode3 method for eehack, though, i think it's hilarious that it works so well

05 mode do some big loop routine, still very unclear what`s the purpose for it.

i'm staring at it too. i have no idea. once entering mode 5 the ecm seems to happily resume normal operation.

Have you figure out how mode 6 works. Do you think it can be used to modify single memory bytes.

i'll bet it can, it seems to be used for loading a certain amount of indiscriminate code into ram which you can pass execution to.

i have a log of a tech flash routine, so i know what it looks like...

it seems that message 0x00 and 0x01 are used to load executable code into ram for execution? it seems to load a chunk of the bin file itself into ram before it flashes? im not sure, it might also be how it erases EEPROM since there's no specific instruction for that.

you->ecm: 
f4 d8 06 01 6d 86 aa 36 18 30 86 06 c6 01 fe ff bc ad 00 32 39
33 1d 2d 08 18 38 32 39 bd 01 93 1f 2e 80 f9 a7 2f 9b 2e 97 2e 39 37 c6 55 f7 10 3a 53 f7 10 3a c6 50 f7 18 06 c6 a0 f7 18 06 33 39 3c ce 10 02 1d 00 08 38 39 3c ce 10 02 1c 00 08 38 39 36 20 03 36 86 0a 37 4d 27 0b c6 4b bd 01 93 5a 26 fa 4a 26 f5 33 32 39 37 fc 10 0e fd 10 16 33 7f 10 22 20 07 b6 10 23 84 80 27 05 86 80 b7 10 23 39
e9 -> f4 57 06 aa 05

if you look closely at it, you'll see that 33 1d 2d 08 and so on are taken right from an $EE bin file; this forms a 128 byte chunk. this continues until all of the code from the bin from 0x0000-0x01FE is written backwards, THEN it seems the flash procedure begins using message 0x03 chunks? this may be a bootstrapping procedure, as obviously execution from flash memory is impossible once it's erased.

my theory is it then passes control flow to that code, then it uses messsage 0x03 to send chunks of the bin file itself 128 bytes at a time into ram, including an offset parameter; then perhaps the executable code sent earlier reads it and flashes it.

the flash data itself is written as follows using message 0x03,:

F4 DE 06 03 00 BD 02 1a (ADDR) (ADDR) (NUMBER OF BYTES) [ 128 BYTES OF DATA ] CKSUM

[steveo]

i love a good mystery. mode 6 is obviously used to transmit data, but the flash routine itself is still elusive; and it makes very little sense that it would be obvious.. you can't flash something you're already running on.

so the e-side and t-side code and data starts at 0x2000, and 0x0000-0x1FFF is addressed as RAM, correct?

so what the hell is in the first 8KB of the bin that can never be addresed during normal operation? im not sure how a 68k works in this respect, is that boot code?

my disassembler won't recognize it, but at least the first 400 bytes or so seem to be code. it's possible some of this code is used to bootstrap the ecm into an alternate operating mode to be run during flash read/write. i think im on the right track digging into that a bit more. the tech tool definitely sent a bunch of data from that section of the bin.

it's also possible 0x0000-0x1fff is addressed to the onboard flash memory of the 68k chip (which does have its own small flash, afaik) and that's what runs during flashing. that might make some sense; flash the external by passing control flow to the small onboard flash, which contains just enough swag to manage communication?

then there's the big hunk of glaringly obvious string table at 0x3C89 which is a smoking gun for sure, as a pointer to anything that might be an actual flash routine... but i can't find references to it in other parts of the code (yet!).

..2.9..ERASING FLASH ON TIME SIDE. ..PROGRAMMING FLASH ON TIME SIDE. @.ERASE VPP HI ERROR - TIME SIDE. @.ERASE VPP LO ERROR - TIME SIDE. @.PROGRAMMING VPP HI ERROR - TIME SIDE. @.PROGRAMMING VPP LO ERROR - TIME SIDE. @.FLASH ERASE FAILED - TIME SIDE. @.FLASH PROGRAMMING FAILED - TIME SIDE. @.FLASH FAILED TO PGM TO ZERO - TIME SIDE..FLASH ERASED OK - TIME SIDE. @.FLASH PROGRAMMED OK - TIME SIDE. @.FLASH MAY NOT BE PROGRAMMED WITH THE ENGINE RUNNING - PLEASE TURN OFF ENGINE @.IMPROPER MANUFACTURER - TIME SIDE @.IMPROPER DEVICE CODE - TIME SIDE ADDR= RD= WR=