Corvette CCM Reverse Engineering Anyone?

**steveo** · 10-03-2021

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** · 10-04-2021

Originally Posted by 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

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** · 10-04-2021

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** · 10-05-2021

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** · 10-07-2021

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

**steveo** · 10-08-2021

that logic is roughly how the f-body VATS works too, it's probably a standard implementation

i was thinking i'd steal your idea for writing the eeprom with that textbook method for the 8051 as well. it might be nice to have a flash routine that writes the entire e-side and t-side eeprom from whatever is in the bin file, for someone that wanted to store a table or two in there that would be easily changed without a complete bin erase/rewrite.

**steveo** · 10-08-2021

oh and i'd never leak a picture of YOUR board, don't worry. but if i manage to find another 'vette CCM somewhere with some custom wiring i'll definitely post a pic, because it may or may not be someone else that found that top secret remanufacturing pin.

**NomakeWan** · 10-14-2021

I have an update! Was finally able to get access to the '94 again, and so I grabbed a new dump of the CCM, and got an idle scan while it was running.

For reference, odometer was 119,905 when this dump was taken just now.

Arduino project got sidelined due to other projects getting in the way. I hope to be able to get back to it again by this coming weekend.

**spfautsch** · 10-14-2021

Thanks, that's incredibly helpful on the odometer storage.

(0x1d460 = 119904) + (0x06 * 0.25 = 1.5) = 119905.5

I'm probably not going to post any more elaborate explanations of the odometer storage going forward. Primarily because I want there to remain some mystery in it's storage mechanism, but also because I'd rather disclose the location of the reman pin and leave the odometer to those who choose to do their homework or ask for help at the price of providing documentation of the validity of their request. If you have genuine interest in knowing it's function PM me and I'll share information commensurate with how much I trust you and your motives.

Meanwhile, I've discovered what I described to steveo as a "rotten easter egg" in the firmware. Once completely re-assembled and having some miles racked up on it, I've come to understand the following:

There are numerous rules regarding when the CCM enters sleep state. Key left in ignition being one. But I've painfully discovered that once the CCM has seen the engine running (i.e. a drive cycle) it will remain awake until it sees the left / driver's side door pin switch indicate it's been opened and closed. No vss counts / distance traveled need be observed. Once the CCM has seen engine RPM (presumably via the PCM's 41 response message) the unit will stay away for hours, days, possibly weeks or months until the left / driver's side door is opened. This is generally not a problem on a semi-daily driver or any other car operated somewhat normally. But once the battery has been drained to about 11.8 volts there's another module not directly related to the CCM that will start cycling a relay off and on again until the battery is drained to about 7.5 volts, where said module ceases to function. In terms of 12v FLA batteries, this is well beyond the point of no return.

Note how I park the car normally.

IMG_20211013_191155036.jpg IMG_20211013_191207026.jpg

Made necessary by the amount of crap stored in my garage, my parking methodology was meant to prevent my wife from dooring the f**k out of my side mirrors and / or doors when exiting her daily driver. Normal parking procedure involves backing into the garage at an angle, cutting the wheels to the right, exiting the vehicle and then rolling it several feet back into final position by hand before setting the parking brake through the open side window. During the colder months I would regularly perform this procedure and then leave the engine running while I maneuvered around to the passenger side of the car and rolled the driver's window up with my leverage aid device before shutting it off and removing the key.

What is a "leverage aid device" you ask?

IMG_20211013_192417861.jpg

It's the same device I used to depress the clutch pedal in order to start the car about a million times during the development of the diy-ltcc controller. Not once was the driver's door opened through the numerous multi-hour long development + test sessions where I would shake out bugs in the firmware startup routines. In the year and a half since I've come to learn my neighbors found much loathing in hearing the sound of my car's exhaust note late at night.

I'm fairly certain this "rotten easter egg" explains 95% of my battery drain issue. Laugh if you must.

So here's the reman pin connected to output pin c14. Inboard on the unpopulated 40 pin IDC header, fourth from the end.

IMG_20211007_134727479.jpg