Corvette CCM Reverse Engineering Anyone?

[steveo]

i found another corvette enthusiast that i've been helping out too, so we have another dump coming.
would it be helpful if we had RPO sheets for any of these to do some feature association? might help figure out a few config flags? or are we already way past that

[kur4o]

i found another corvette enthusiast that i've been helping out too, so we have another dump coming.
would it be helpful if we had RPO sheets for any of these to do some feature association? might help figure out a few config flags? or are we already way past that

I can get rpo codes from vin stored in the file, so it won`t be an issue if there is a need to see the options.

[spfautsch]

I think it's a little soon to say, but here's what I'm basing the two option bytes on, from the A297.DS file:

..PAGE
..HEAD02L CCM ALDL DATA LIST 
..HEAD03L NUMBER OF DATA WORDS - 23
..HEAD04L CCM ALDL MODE 1 DATA LIST (MESSAGE 1)
 BYTE  BIT  DESCRIPTION
 ----  ---  -----------
 1          FIRST PROM ID WORD (MSB)
 2          SECOND PROM ID WORD (LSB)
 3-19       VEHICLE IDENTIFICATION NUMBER

 20    0    REAL TIME DAMPING          0 = NO        1 = YES
       1    ANTI-LOCK BRAKES           0 = NO        1 = YES
       2    ELECTRONIC THROTTLE CONTROL              1 = YES
       3    RESERVE FUEL INDICATION    0 = NO        1 = YES
       4    OVERSPEED WARNING          0 = YES       1 = NO
       5    SPEEDOMETER BIASING        0 = YES       1 = NO
       6    ROUGH ROAD DETECTION       0 = NO        1 = YES
       7    NOT USED

 21    0    ENGINE                     0 = LT1       1 = LT5
       1    TRANSMISSION               0 = AUTO      1 = MANUAL
       2    MAGNETIC SPEED-DEPENDANT VARIABLE ASSIT  1 = PRESENT
       3    HVAC                       0 = C60       1 = C68
       4    LOW TIRE PRESSURE WARINING SYSTEM        1 = PRESENT
       5    SELECTIVE RIDE SYSTEM                    1 = PRESENT
       6    POWER SEAT, DIRVER SIDE                  1 = PRESENT
       7    POWER SEAT, PASSENGER SIDE               1 = PRESENT

 22    0    NOT USED
       1    NOT USED
       2    NOT USED
       3    NOT USED
       4-7  NOT USED

 23    0-7  NOT USED

Bytes 20 and 21 match $b6c6-$b6c8 pretty much exactly. The only "mainstream" head scratcher is the C68 option which seems like was standard equipment after 90 or 92. Everything else that was optionally available before 97 was incredibly rare save the FX3 (selective ride system). NomakeWan's 94 has this and the bit's cleared on the dump he posted. I have a message out to someone with a 92 ZR-1 with the FX3, but he would need hand-holding and his wife is in the hospital with cancer / chemo + covid so I think I'm going to leave him to be with his wife for the moment.

Everything else was either not available, or doesn't make any difference to the unit.

Real time damping wasn't an option until much later afaik.
ABS might have been a delete-able option but would have been a special order
ETC didn't come into the picture until the LS1 in 97
Bits 4-6 are all 1s in everything we have

In byte 21 the engine option was pretty obvious. I think this one is probably the most complained about fault code with a mis-configured ccm.
Transmission seems documented well enough
Electric power steering was also not available until 200?
C68 versus manual A/C controls is still a grey area, but I think not relevant to the function of the module since all our cars have it but none have this bit set
TPMS was a very rare option so may have some bearing on things - good luck finding someone with that option
FX3 seems to not have bearing on the ccm function
The power seat options are irrelevant because there are no inputs / outputs it could possibly effect

I'm still open to discussion on how to handle the reman pin location and whether to include (odometer) in the .xdf. An "experimental" version is attached.

[NomakeWan]

Any idea if the C68 programmer responds to anything? I seem to recall you telling me it wasn't attached to the aldl, but my 95 fsm show pins 9 & 10 connecting to the bus.

The C68 programmer never responds to anything and has no ability to talk on the bus. For diagnostic purposes, you can connect a jumper between pin 4 on the HVAC control head and pin 14 on the ALDL connector to allow a Tech 2 to talk to the HVAC Programmer via the E&C Bus. Check section 8A-52-0 of your FSM. The two connections between C9/C10 on the HVAC Programmer and the ALDL are only there to receive the $10 CCM broadcast message and nothing else.

Alright a question probably only this thread could answer…. So I am wanting to do the 24x torque head coil conversion kit for my 92 corvette. Based on what the company told me it only works on 94-96 corvettes because of CCM comparability issues. From what I have been told after doing a idle CCM data pull it’s almost identical to the 94 CCM. Why would that kit not work for a 92 if the CCM’s are so similar.

Would what y’all are doing reverse engineering the CCM’s solve this issue in the future?

Torqhead is correct. As we discussed via PM, your '92 has a different diagnostic message from the 94-96 Corvette. It is three bytes shorter. The CCM's poll request message, however, is identical. To be clear, this means that the message the CCM sends to the ECM is the same as the 94-96, but the reply from the ECM is different. Since the reply is what Torqhead has to account for, that's why their setup won't work for the earlier cars.

Additionally, Torqhead's modified '411 PCM only has connectors for the PCM found in the 94-96 Corvette, not the ECM found in the 92-93 Corvette. So they are absolutely correct that their system would not work for you.

However, should we be able to figure out how to fake that message ourselves with open-source hardware and software, that means we would be able to provide anyone with a 90-96 Corvette the ability to have a working dash with any aftermarket computer, whether that be Torqhead, Holley, Haltech, etc etc etc. So hopefully we can figure that out. Torqhead clearly knows some of the things we'd like to know already, but as they're in the business of making money, I don't think they'd be willing to share that information freely.

[steveo]

this is really awesome. nobody hacks body control modules.

for the reman pin i would not think its dirtier information than anything else we do with these modules. im in a country where reverse engineering for repair purposes is legal. totally your find and your call. but if you are that worried maybe just start really detailed rumors and let someone else do it.

if the general cared that much they would have put some proper protection on it.

my main concern is scumbags rolling odos back

[steveo]

speaking of odometers, i see you managed to wipe it, but did you actually decipher it? if not, i'd like to help with that too, give me what you've found so far ? i enjoy code breaking this old stuff

[spfautsch]

speaking of odometers, i see you managed to wipe it, but did you actually decipher it? if not, i'd like to help with that too, give me what you've found so far ? i enjoy code breaking this old stuff

What I've found is pretty much contained here. PM me if you want a more intelligent explanation, sometimes I omit very important details when I'm excited from cracking 30 year old engineering.

my main concern is scumbags rolling odos back

Edit: Me also, but keep in mind you have to take 1/3 of the interior apart to remove this module. It's slightly easier than pulling the engine and just a bit more difficult than replacing all four wheel bearing hubs in an afternoon. (end edit)

I have no idea where this could go. If you look on ebay the ccms that are there all have the mileage stated as if it's some measure of value. Personally I would like to keep mine correct to wear as a badge of courage. But who knows if the run-of-the-mill C4s will ever come to be coveted by car collectors. Plastic and unreliable electronics considered.

I'm posting this for those who understand the protocol. Please don't post a public dissertation about how I accomplished it if you figure it out.

TX+F15605B4
RX+F1570500B3
TX+F15A040020002071
RX+F15604B5
TX+F15605B4
RX+F15705AA09

Looks like I will be putting mine back together in the next few days once I run some "free" miles up on the salvage ccm. :-D

[NomakeWan]

I'm posting this for those who understand the protocol. Please don't post a public dissertation about how I accomplished it if you figure it out.

TX+F15605B4
RX+F1570500B3
TX+F15A040020002071
RX+F15604B5
TX+F15605B4
RX+F15705AA09

That is insanely cheeky, I like it.

[BlackW1dow]

The C68 programmer never responds to anything and has no ability to talk on the bus. For diagnostic purposes, you can connect a jumper between pin 4 on the HVAC control head and pin 14 on the ALDL connector to allow a Tech 2 to talk to the HVAC Programmer via the E&C Bus. Check section 8A-52-0 of your FSM. The two connections between C9/C10 on the HVAC Programmer and the ALDL are only there to receive the $10 CCM broadcast message and nothing else.


Torqhead is correct. As we discussed via PM, your '92 has a different diagnostic message from the 94-96 Corvette. It is three bytes shorter. The CCM's poll request message, however, is identical. To be clear, this means that the message the CCM sends to the ECM is the same as the 94-96, but the reply from the ECM is different. Since the reply is what Torqhead has to account for, that's why their setup won't work for the earlier cars.

Additionally, Torqhead's modified '411 PCM only has connectors for the PCM found in the 94-96 Corvette, not the ECM found in the 92-93 Corvette. So they are absolutely correct that their system would not work for you.

However, should we be able to figure out how to fake that message ourselves with open-source hardware and software, that means we would be able to provide anyone with a 90-96 Corvette the ability to have a working dash with any aftermarket computer, whether that be Torqhead, Holley, Haltech, etc etc etc. So hopefully we can figure that out. Torqhead clearly knows some of the things we'd like to know already, but as they're in the business of making money, I don't think they'd be willing to share that information freely.

Thanks for the response, and it makes some more sense now! Please let me know if I can contribute to the cause anymore. I should have a EPROM dump for another user tomorrow.

[NomakeWan]

If you've already got a dump on the way, then I think you're good. The rest is stuff the analyzing group needs to do. I'm still working on Arduino stuff, while others are working on analyzing the actual code. Hopefully one of them can figure out the $41 CCM poll response through reverse-engineering the dumps. That would be fantastic since there's still several unknowns (bytes 8, 9, 16, 17, 19 and 20 for the 94-96, bytes 8, 9, 16 and 17 for the 92-93).

[steveo]

i could probably help with your tool too nomakewan, i will have an ECM and CCM on the same test bench some time soon and can do some testing/analysis. i feel like the ECM's response to that poll might be better figured out by analysis of the ECM code since we have already done a ton of groundwork there, and i'm sure most of the unknown bytes you're looking for are well defined addresses in memory of EE

[NomakeWan]

i could probably help with your tool too nomakewan, i will have an ECM and CCM on the same test bench some time soon and can do some testing/analysis. i feel like the ECM's response to that poll might be better figured out by analysis of the ECM code since we have already done a ton of groundwork there, and i'm sure most of the unknown bytes you're looking for are well defined addresses in memory of EE

Oh, duh, good point; this is the reply from the ECM, so of course the ECM would have it defined. One would just have to find the routine that fires off data when it receives the $40 poll message. Good point!

I was out all day today but hopefully tomorrow I can run those experiements I was planning on. I'll keep you all posted.

[spfautsch]

One thing I would like to see more of are eeprom dumps from cars with PASSKey codes other than 9 and 15. The code isn't scrambled or anything like that, but there are two bytes that follow it that would be nice to have more examples of.

NomakeWan on the C68 option I changed that on the remanned CCM yesterday before I put some miles on it. It seems like it does change the broadcast messages. Attached is an idle log from before changing the bit with engine off, and more (look for the notes I wrote between sessions). My gut tells me this option was for functionality that never made it into production on the C4s. I'll change this in my original CCM later on so more can be tested.

Also, one of the option bits I missed was 'rough road detection'. This is something I've never heard of, but appears to be enabled in all these dumps - if the datastream definition is as accurate as I think it is.

I also figured out that the unit only seems to write the odometer to eeprom after a start. It also wrote 32 miles at some point while the engine was running because I drove 44 in one trip. I spent the better part of yesterday afternoon sitting around waiting for it to update, and then figured I'd need to drive it a few more miles to get that to happen. Lo and behold after idling for a short time it wrote out the remaining 12.75 miles to $b657.

I'm planning on putting the car back together starting tonight. After that I intend to figure out how to make the PASSKey authentication work on the test bench and I'll get the remanned unit headed towards steveo.

[steveo]

i'm excited to play with a CCM. i have my old 8051 test bench ecm rigged up now. it'll be good to do some hands-on comms experiments with a really active ALDL bus too. sounds like getting programming working will be pretty easy. i think i'll take your idea and do a full read, compare, erase/write as required, then read to verify. should be pretty quick.

[spfautsch]

Cool, I was somewhat worried about sending it to you for fear you might smash it with a hammer after all the difficulty they've caused you. :-)

I've learned a little about the vats / passkey validation. Evidently the status is stored in eeprom. Either that or there's tank circuit that keeps ram powered up, but there aren't any big caps on this thing so I'm leaning towards eeprom.

Whenever a vats validation fails the code enforces a 2:30 "penalty period". Any vats attempts during this period will fail even with the correct resistor, as well as resetting the penalty period. If power is removed from the unswitched battery input before the timer expires there will be a 2:30 penalty period after power is restored. There's no apparent special sequence of events - as long as the correct resistor is present when the two ign circuits go high vats is de-activated presumably for the current run cycle.

I have noticed however that the unit doesn't go to sleep after the normal 20 seconds unless it sees the key-in circuit go open in addition to a door ajar circuit.

I'm done messing with it for now so I'll get it headed your way in the next day or so. It's programmed for a #11 key, and I'll send a 4.7k resistor soldered onto some pins so you can test with / without vats active. I also hooked up my 8051 PCM on the test bench to verify that comms work. It also still has junk scribbled in the unused FF bytes of the eeprom, and the c68 bit is on. Feel free to erase the unused stuff and modify whatever's in the .xdf.

I've wired a jumper from the chime 1 output on pin c14 to the reman pin. Even though I asked for 'radio silence' on this, I was somewhat hoping someone would figure it out. Edit: Sorry NomakeWan, I missed your response. Thanks - I hope the chime box inputs are 5v ttl, but even if not, all the outputs are protected so I don't think any circuitry can get "hurt". Anyway, this makes these easily un-lockable by simply turning this pin on from the aldl. It would be a shame if a picture of this board leaked out... :-O