Corvette CCM Reverse Engineering Anyone?

[spfautsch]

I've been able to change (write zero) to the VSS*/4000 counter at $b657. I've also been able to erase the option byte at $b6c7 and write bit 2 there for the manual trans.

Edit: This entire paragraph is wrong, disregard. It seems like the 05 unlock is cleared after two 06 uploads are executed, or something... Presumably first being the write and second being the clear command to turn off the eeprom control register (turn off programming voltage). Whatever the case, it doesn't seem to be at all straightforward.

I'm playing around with writing obscene ascii messages to the unused FF bytes, and I'm learning a lot. Fingers crossed I can figure out what the "rules" are with this mode. If anyone has knowledge that applies to flash / mode 5/6 programming that I'm missing I'd love a bit of a nudge in the right direction.

All this considered, I'm somewhat afraid that erasing the odometer may be impossible without a patch to the (uveprom) firmware. Hope to have more, better news tomorrow.

[kur4o]

When eeporm is copied to 7000 area it is also copied after that at 6xxx area.It is there where pcm add stuff and maybe later write to eeprom from there. & 7000 might be some area that survive more with voltage off. Maybe some backup.

[kur4o]

Some more food for the obscene scene.

from ee code

ESERVED:602B clr PPROG ; EEPROM Program Control Register
RESERVED:602E ldaa 0,y
RESERVED:6031 cmpa 0,x
RESERVED:6033 beq loc_605C
RESERVED:6035 ldaa #$16
RESERVED:6037 staa PPROG ; EEPROM Program Control Register
RESERVED:603A staa 0,x
RESERVED:603C ldaa #$17
RESERVED:603E staa PPROG ; EEPROM Program Control Register

ESERVED:6046 loc_6046: ; CODE XREF: MAINsub_4F8D+109Aj
RESERVED:6046 clr PPROG ; EEPROM Program Control Register
RESERVED:6049 ldab 0,y
RESERVED:604C cmpb #$FF
RESERVED:604E beq loc_605C
RESERVED:6050 ldaa #2
RESERVED:6052 staa PPROG ; EEPROM Program Control Register
RESERVED:6055 stab 0,x
RESERVED:6057 ldaa #3
RESERVED:6059 staa PPROG ; EEPROM Program Control Register

From ccm

loc_EAF7:
sei
ldaa #2
staa PPROG ; EEPROM Program Control Register
ldaa #0
staa PPROG ; EEPROM Program Control Register
cli
ldx byte_62F2
ldaa 0,x
cmpa byte_62F1
...................................

ED:EAC4 sei
RESERVED:EAC5 ldaa #$16
RESERVED:EAC7 staa PPROG ; EEPROM Program Control Register
RESERVED:EACA ldaa #0
RESERVED:EACC staa PPROG ; EEPROM Program Control Register
RESERVED:EACF cli
RESERVED:EAD0 ldaa byte_821D
RESERVED:EAD3 staa byte_62F0
RESERVED:EAD6 ldy byte_62F2
RESERVED:EADA ldaa byte_62F1
RESERVED:EADD ldab 0,y
RESERVED:EAE0 cmpb #$FF
RESERVED:EAE2 beq loc_EAEC
RESERVED:EAE4 ldab byte_62F4
RESERVED:EAE7 orab #$20 ; ' '
RESERVED:EAE9 stab byte_62F4
RESERVED:EAEC
RESERVED:EAEC loc_EAEC: ; CODE XREF: sub_EAB8+2Aj
RESERVED:EAEC jmp loc_EBC4
RESERVED:EAEF ; ---------------------------------------------------------------------------
RESERVED:EAEF
RESERVED:EAEF loc_EAEF: ; CODE XREF: sub_EAB8+5j
RESERVED:EAEF dec byte_62F0
RESERVED:EAF2 beq loc_EAF7
RESERVED:EAF4
RESERVED:EAF4 loc_EAF4: ; CODE XREF: sub_EAB8+Aj
RESERVED:EAF4 ; sub_EAB8+80j ...
RESERVED:EAF4 jmp locret_EBDC
RESERVED:EAF7 ; ---------------------------------------------------------------------------
RESERVED:EAF7
RESERVED:EAF7 loc_EAF7: ; CODE XREF: sub_EAB8+3Aj
RESERVED:EAF7 sei
RESERVED:EAF8 ldaa #2
RESERVED:EAFA staa PPROG ; EEPROM Program Control Register
RESERVED:EAFD ldaa #0
RESERVED:EAFF staa PPROG ; EEPROM Program Control Register
RESERVED:EB02 cli

.................................................. ...............

SERVED:EBA5 loc_EBA5: ; CODE XREF: sub_EAB8+E8j
RESERVED:EBA5 sty byte_62F2
RESERVED:EBA9 staa byte_62F1
RESERVED:EBAC ldaa byte_821C
RESERVED:EBAF nega
RESERVED:EBB0 staa byte_62F0
RESERVED:EBB3 sei
RESERVED:EBB4 ldaa #$16
RESERVED:EBB6 staa PPROG ; EEPROM Program Control Register
RESERVED:EBB9 staa 0,y
RESERVED:EBBC ldaa #$17
RESERVED:EBBE staa PPROG ; EEPROM Program Control Register
RESERVED:EBC1 cli

and more

ERVED:A7F0 ldab PPROG ; EEPROM Program Control Register
RESERVED:A7F3 bitb #2
RESERVED:A7F5 beq loc_A819
RESERVED:A7F7 cpx #$B600
RESERVED:A7FA bcs loc_A819
RESERVED:A7FC cpx #$B7FF
RESERVED:A7FF bhi loc_A819
RESERVED:A801 pshx
RESERVED:A802 xgdx
RESERVED:A803 subd #$4600
RESERVED:A806 xgdx
RESERVED:A807 ldab 0,x
RESERVED:A809 pulx
RESERVED:A80A bra loc_A81B
RESERVED:A80C ; ---------------------------------------------------------------------------
RESERVED:A80C
RESERVED:A80C loc_A80C: ; CODE XREF: M3_eeprom_sub_A7A8+21j
RESERVED:A80C cpx #$103F
RESERVED:A80F bhi loc_A819
RESERVED:A811 cpx #$1000
RESERVED:A814 bcs loc_A819
RESERVED:A816 clrb
RESERVED:A817 bra loc_A81B
RESERVED:A819 ; ---------------------------------------------------------------------------
RESERVED:A819
RESERVED:A819 loc_A819: ; CODE XREF: M3_eeprom_sub_A7A8+4Dj
RESERVED:A819 ; M3_eeprom_sub_A7A8+52j ...
RESERVED:A819 ldab 0,x
RESERVED:A81B
RESERVED:A81B loc_A81B: ; CODE XREF: M3_eeprom_sub_A7A8+45j
RESERVED:A81B ; M3_eeprom_sub_A7A8+62j ...
RESERVED:A81B stab 0,y
RESERVED:A81E iny
RESERVED:A820 pulx
RESERVED:A821 inx
RESERVED:A822 inx
RESERVED:A823 deca
RESERVED:A824 bne loc_A7C3
RESERVED:A826 rts
RESERVED:A826 ; End of function M3_eeprom_sub_A7A8
RESERVED:A826

Cant help much. You need to decode some of the functions.

[steveo]

i know it's not much help right now but i improved the flashhack mode2 download tool. it will now read a specific region (but you still specify the entire memory size, so it will give you a 0 padded file with the data at the proper offset).

... it also has a checkbox to read via mode 3 (single byte at a time) in case for some reason we run into a GM module that has mode 3 code but not mode 2. this is really slow and stupid but i just had to put it in there. it flies along pretty quickly considering the overhead because flashhack is pretty optimized with regards to timing.

edit: download it at the usual place of course

[NomakeWan]

So I think I may have figured out the issue with my Arduino. It might not be hardware after all. I was reading the datasheet for CCM comms, and noticed that there is a note about how the bidirectional system works.

The CCM transmits an "idle byte" (10 1 bits; start bit high, 8 data bits high, end bit high) prior to the first byte of every message instead of detecting an idle line...

...After successful receipt of the message, the remote device to which the message was directed will respond back to the master device with a message of its own. Before transmitting the message, the remote device waits for an idle link state.

My code currently recognizes the $40 poll request message and instantlytransmits the $41 poll response. My AVR may actually be transmitting too quickly. I don't see how that's possible since serial data is orders of magnitude slower than AVR processing, but it makes sense. My code does not "wait for an idle link state," since I don't really know how to recognize that in code terms.

I have some additional hardware designs to test anyway, so hopefully tomorrow I'll be able to work on it more. If it really is that simple, I'll be pretty happy.

Great work so far on the odometer stuff!

[steveo]

I'm playing around with writing obscene ascii messages to the unused FF bytes, and I'm learning a lot. Fingers crossed I can figure out what the "rules" are with this mode. If anyone has knowledge that applies to flash / mode 5/6 programming that I'm missing I'd love a bit of a nudge in the right direction.

here are some notes on mode 5/6 and programming

some of this stuff you already know but might help to review or for others that might want to help, some might be broken in the CCM if it's not up to GM's usual standards, some things have names i've invented because of lack of documentation.

mode 5 generally is 'enter programming mode' and mode 6 is 'upload and execute' which you already know.

you call mode 5 and then the ECM executes from a special loop for a very short time that really only is intended to respond to mode 6.

it's standard GM practice that if you make a mode 6 request without calling mode 5 first, or because mode 5 has timed out, it replies with mode 5 and a failure status code to your mode 6 request. if this logic functions for the CCM you can use it to know when you haven't called mode 5 yet, or if mode 5 has timed out and needs to be called again.

as far as the actual code goes, the maximum code segment size you can upload and execute with mode 6 is 167 bytes (because of the aldl protocol's max message size, and the overhead of the memory location specifier bytes, etc)

you can do some really cool stuff with mode 6 just with small code segments since the instruction set for these processors is so compact.

it looks like you already figured it out, but if you don't call 0x39 (return from sub) after your code, undefined things will happen, it keeps executing whatever happens to be in ram.

something that is critical for more advanced operations is being able to upload to ram without actually executing the code

in the other stuff i've worked on, we prefix with a code segment that does execute and returns a proper reply but allows us to continue more programming right away, i did understand partially how it works at one time, but maybe kur4o remembers better, you could do something like this for the CCM for sure. i'd call it your non-execution header. excuse the ugly manual disassembly.

86 AA  (LDAA $AA)
 36 (PSHA)
 18 30 (TSY)
 86 06 (LDAA $06)
 C6 01 (LDAB $01)
 FE FF BC (LDX @FFBC)
 AD 00 (JSR 00,x)
 32 (PULA)
 39 (RTS)

now that you have a method that'll dump something in ram without executing it and return cleanly (your payload is obviously at an offset of 16 bytes due to the size of that header) you can leverage this ability to load larger program segments into ram.

the trick to running a large continuous program is you need to land the end of each uploaded code segment so it writes over the above non-execution header, which is still in ram, and lines up with the existing code you have uploaded. this is done by writing your program into memory backwards, so the final segment you write is the first one, which then does NOT contain your no-execute header, executes.

obviously you have an extra xx bytes of overhead from that above message, so you have to resize your messages appropriately.

flashhack has some carefully designed code that does this automatically for large program segments, so you just have to worry about the program, and a large enough area of RAM to put it in, in fact you can just write an entire program into a bin file and run it by name. it makes decisions based on the program size, but it does require a functional non-execution header like the above to work properly.

i could start working on making a new module for the CCM and give you a place to write your code more easily, so it can take care of the hard part. it shouldn't take long

[steveo]

i could start working on making a new module for the CCM and give you a place to write your code more easily, so it can take care of the hard part. it shouldn't take long

ok that's done , i made kind of a reflash sub-tool with no kernel, kind of like the mode 2 read tool. i'll test it out a bit and get you a copy, then we'll play around with working the bugs out.

just for the hell of it, can you see what happens if you execute the above code with mode 6 on the CCM? if they set that FFBC vector the same maybe we'll get lucky and it'll just work. it should return 06 AA as a reply. more likely it'll crash.

86 AA 36 18 30 86 06 C6 01 FE FF BC AD 00 32 39

[kur4o]

I can confirm that the vector is there and is the same. It jumps to mode6 response that is not referenced in the main code.
In the response it will be [f1] [56+lenghtof message] [06]. [0,y loop] I see it will read all bytes from y pointer and send them on the bus. You need to specify the lenght of the response at the request message.
You can store the length of the repsonse at byte_FC


This one looks as a reading routine built in the ccm code.

The header will be store length to byte_FC, load y with start address of reading, load x with ffbc pointer, jump to sub to 0,x , rtn.

[spfautsch]

Seems like it's crashing - eehack loses connection immediately after which I assume is the ccm spamming the bus for a response from the pcm. Also, mode 6 commands do not generate a reply, even ones that work.

I've been reading the datasheet and it seems like eeprom has to be programmed one byte at a time, so that explains some of what I was seeing. Will experiment a bit more and see if it's possible to write multiple bytes sequentially.

My fear with the odometer is there's an eeprom block protection register that can only be cleared during the first 64 e-clock cycles. It's probably cleared by the initialization routine, but once set cannot be cleared except in test and upload modes. I haven't looked at any of your disassembly work but my fear is that before mode 5 is entered it sets the write protect register to 03 which locks the first 128 bytes of eeprom.