Corvette CCM Reverse Engineering Anyone?

[steveo]

are you sure that's what's happening? it's not a case of an inappropriate ECM response, it isn't in a key-on state? can you tell that from the current communications somehow ?

i have not connected E5 (edited)to anything, should i?

i have, right now:

- security light between C6 and +12v (confirmed working earlier)
- ground to C11 (key in thing)
- +12v to F1 and F2
- +12v to E4
- ground to E15
- E12 to F5 resistor (no security light, so probably correct)
- ALDL to F12

there are alligator clips and twisty wires involved but i am confident everything is connected.

i plan to build a better idle traffic scanner in flashhack too, might be helpful.

[steveo]

i built a better idle traffic scanner. here's the CCM/ECM datastream right from boot if i just power the whole bus.

flashhack Version 1.1
Scanning ALDL 40 messages with timeout of 10000ms
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:41] 02 00 00 87 00 00 00 00 00 00 88 00 00 D0 3D 00 FF FF
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] D0 3D
IDLE: [DEV:41] 02 00 00 87 00 40 00 00 00 00 88 00 04 69 C7 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 C7
IDLE: [DEV:41] 02 01 00 87 00 40 00 00 00 00 88 00 04 03 72 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 03 72
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 9D 04 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 9D 04
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 36 AF 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 36 AF
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 D0 3F 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] D0 3F
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 69 E8 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 E8
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 03 7C 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 03 7C
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 9D 0C 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 9D 0C
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 36 B6 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 36 B6
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 D0 48 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] D0 48
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 69 F1 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 F1
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 03 82 00 FF FF
IDLE: [DEV:10] 08 87 02 00

edit - here is the CCM with no ECM on the bus:

IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00

[kur4o]

Steveo can you run some pcm patch.

1b8e5
[26 0e] --> 01 01

I still suspect some theft loop. The ccm is not unlocked at just echo the key instead of calculating a key from pcm seed.

The patch will force pcm to get unlocked and hopefully provide good data to ccm[FFFFs].

[steveo]

Steveo can you run some pcm patch.

1b8e5
[26 0e] --> 01 01

I still suspect some theft loop. The ccm is not unlocked at just echo the key instead of calculating a key from pcm seed.

The patch will force pcm to get unlocked and hopefully provide good data to ccm[FFFFs].

i'll try, 1B8E5 is in dead space, though. i assume you mean 0B8E5

[steveo]

that worked! you know that comms code so well.

why though? what was wrong with my ECM that wasn't unlocking, but it was working for spfautch ? maybe because mine is an 8051 rather than a 1333? are they not interchangable?

[kur4o]

I think ccm is just echoing the seed and not converting it to key for the pcm.

Maybe something in the ccm says theft is not good echo the seed, and pcm can`t figure it and keeps polling ccm for key.

Maybe someone can post ign on log with ccm and pcm on the bus, so we can compare how it goes there.

[steveo]

well whatever it is, i think i have enough info to emulate the ecm and win control of the bus, but the other thing i noticed is if the ccm wakes up it crashes the flash kernel. i wonder if there's a way to fully lock the ccm up. lots of cool experiments to run....

but id still like to know why my ecm didn't work. i think it's valuable info

[NomakeWan]

are you sure that's what's happening? it's not a case of an inappropriate ECM response, it isn't in a key-on state? can you tell that from the current communications somehow ?

i have not connected E5 (edited)to anything, should i?

i have, right now:

- security light between C6 and +12v (confirmed working earlier)
- ground to C11 (key in thing)
- +12v to F1 and F2
- +12v to E4
- ground to E15
- E12 to F5 resistor (no security light, so probably correct)
- ALDL to F12

there are alligator clips and twisty wires involved but i am confident everything is connected.

i plan to build a better idle traffic scanner in flashhack too, might be helpful.

E5 is the other Key-On +12V. +12V should go to it.

Yes, I could tell that from your logs; in all logs from my 94 and 95, the only time the CCM does not send the F0 poll is when the key is off. As soon as the key is inserted and turned to run, the F0 polls begin. So since your broadcast messages look totally normal save for the lack of F0 polls, that looks like a normal key-off state.

the ECM (device 41) is sending a code (D03D) to the CCM which it is echoing (device 40)
the CCM also keeps sending : 08 87 02 00 which is echoed (although in a different order) in the device 41 reply from the ECM
the message the ECM sends to the CCM changes every time and the CCM merely echos it

The $10 broadcast message is for the C68 HVAC system, and contains data the CCM has gleaned from the $41 broadcast from the ECM. This is normal. Additionally there is no return message to a $10 broadcast; it is sent into the void and it's up to the HVAC Programmer to do something about it on its own. There is no handshake or anything like that involved.

[NomakeWan]

maybe because mine is an 8051 rather than a 1333? are they not interchangable?

I was giving this some thought lately--the difference between the Y-body PCM and the F-body PCM. While code-wise, yes, there's the bit where the F-body is its own bus master...there may be an actual electrical difference as well. Beyond just those OBDII-related chips for the totally superfluous rear O2 sensor, I mean.

On the Y-body CCM, there is a 910 ohm pull-up resistor connected to the 64606 chip; this designates it the bus master electrically. The 1333 PCM and Bosch EBTCM (should) have no pull-up resistor connected to the 64606 chip, as no such resistor is necessary on slave devices using 64606 chips. The CCM has a 'master' pull-up just in case an external device gets connected to the bus that's using a discrete slave pull-up 75kOhm resistor.

But F-body cars have no CCM, yet I would assume here that GM would build in the same 'failsafe' that Corvettes have for ALDL bus robustness. So does the 8051 PCM have a 910 ohm pull-up resistor connected to the 64606 chip?

I'm not saying this would cause a conflict per se; I could only imagine there being an issue if someone connects a discrete slave to the data bus of an F-body that has a 1333 PCM. Or heck, maybe I'm wrong and GM just slapped the 910 ohm resistor on every single computer on the bus for giggles.

steveo, since I think you still have an 8051 open on your bench, could you confirm if there is a 910 ohm resistor connected to the DELCO 64606 chip? In spfautsch's photos of his CCM, the 64606 chip is 'topside' PCB while the 910 ohm resistor is on the 'bottomside' PCB. PCM might be the same way.

[spfautsch]

I was just in my basement dumping a bunch of diy-ltcc and pcm / ccm test bench stuff into a new storage tote and thought about this. Sorry I missed all this activity, email notification works sometimes and other times not. This week not. I'll try to catch up asap.

One item I noticed skimming over the last page is the PASSKey - as (my) memory serves you can dump (ccm) memory but the resistor value is not returned unless the security flag is cleared. So trial-and-error is likely necessary to get one working on a test bench. It sounds like NomakeWan has figured that out by now, but let me know if there's anything I can test.

[steveo]

so here's a code sample:

IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] 00 00
IDLE: [DEV:41] 02 00 00 87 00 00 00 00 00 00 88 00 00 D0 3D 00 FF FF
IDLE: [DEV:10] 00 00 00 00
IDLE: [DEV:40] D0 3D
IDLE: [DEV:41] 02 00 00 87 00 40 00 00 00 00 88 00 04 69 C7 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 69 C7
IDLE: [DEV:41] 02 01 00 87 00 40 00 00 00 00 88 00 04 03 72 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 03 72
IDLE: [DEV:41] 02 00 00 87 00 48 00 00 00 00 88 00 04 9D 04 00 FF FF
IDLE: [DEV:10] 08 87 02 00
IDLE: [DEV:40] 9D 04

to quote kur4o:

Ccm sends seed to pcm.
Pcm process seed and convert to key. Respond with some random timer data.
ccm sends key
pcm matches precalculated key with ccm key. If all good pcms sends FFFF.

what i'm observing:

the ECM (device 41) is sending a code (D03D) to the CCM which it is echoing (device 40)
the CCM also keeps sending : 08 87 02 00 which is echoed (although in a different order) in the device 41 reply from the ECM
the message the ECM sends to the CCM changes every time and the CCM merely echos it

[spfautsch]

i have, right now:

- +12v to F1 and F2

Nothing critical here, but the multiple connections to F1+F2 (unswitched battery), C1+D1+E15+E16 (ground) and E13+F12 (aldl) are solely for redundancy in-car in case a wire is damaged. If you look at the pics of the bottom of the board (or open it up, you have my blessing + encouragement) the traces are joined together right on the connector solder pads. Only one wire is needed to any of these on the test bench.