Corvette CCM Reverse Engineering Anyone?

**spfautsch** · 10-31-2021

You've changed the VATS code and then dumped the eeprom without changing the VATS resistor so mode 2 or 3 reads of that region return 0x00 per NomakeWan's documentation. You now need a 11.8k resistor (code 15) to make VATS happy. You should be able to override all the read / compare checks and just blindly erase the VATS code byte(s) and reprogram them back to 0x0B (4.75k / code 11) without the correct resistor though. The module will unlock for mode 6 regardless, but mode 2 / 3 reads are giving you zeros because VATS didn't pass.

Good find, this would surely have come up with someone programming an unknown VATS code unit on a test bench.

Edit: I think working around this might not be terribly complex. I'm just thinking in microcontroller mode at the moment (see next comment).

I'd go further with my help but I'm about 2 hours away from a generic arduino logger proof-of-concept that I hope will help NomakeWan immensely. Already have a "fast forward to first valid message" routine. New thread upcoming on that one.

This is what I have on that:

Code:

0 
10 59 00 00 00 00 97 
n7 
40 57 00 00 69 
n12 
10 59 00 00 00 00 97 
n19 
40 57 00 00 69 
n24 
10 59 00 00 00 00 97 
n31 
40 57 00 00 69 
n36 
10 59 00 00 00 00 97 
n43 
40 57 00 00 69 
n48 
10 59 00 00 00 00 97 
n55 
40 57 00 00 69 
n60 
10 59 00 00 00 00 97 
n67 
40 57 00 00 69 
n72 
10 59 00 00 00 00 97 
n79 
40 57 00 00 69 
n84 
10 59 00 00 00 00 97 
n91 
40 57 00 00 69 
n96 
10 59 00 00 00 00 97 
n103 
40 57 00 00 69 
n108 
10 59 00 00 00 00 97 
n115 
40 57 00 00 69 
n120 
10 59 00 00 00 00 97 
n127 
40 57 00 00 69 
n-124 
0 
10 59 00 00 00 00 97

This is with the micro finding the first valid message via checksum validation. The only issue I have to fix is that my input buffer is a 255 byte ringbuffer and the message pump isn't correctly handling the wraparound from 255 to 0 (yet).

**steveo** · 10-31-2021

but i haven't dumped the eeprom - i programmed that byte to 0 because 0 was in the bin i was writing from, im not getting thar from a mode 2 or 3 ram dump

if that byte is actually 15 i have no idea how it would have ended up that way

i hope you're right about being able to enter mode 5/6 with the wrong vats resistor

**steveo** · 10-31-2021

very interesting, grounding the reman pin actually kills the security light...
edit: despite the security light being on, you're correct, it programs fine. that's helpful.

**spfautsch** · 10-31-2021

That must have been a bin I dumped early on the test bench without a vats resistor, before finding the reman pin.

Probably not an issue though - it will still unlock without vats, though it sounds like the reman pin is disabling vats.

**NomakeWan** · 10-31-2021

Originally Posted by spfautsch

Probably not an issue though - it will still unlock without vats, though it sounds like the reman pin is disabling vats.

This would make sense; you wouldn't want VATS getting in the way at a remanufacturing facility, or on the factory floor. VATS is for a car, which a new/reman CCM is not a part of.

Originally Posted by spfautsch

I'd go further with my help but I'm about 2 hours away from a generic arduino logger proof-of-concept that I hope will help NomakeWan immensely. Already have a "fast forward to first valid message" routine. New thread upcoming on that one.

This is what I have on that:

Code:

0 
10 59 00 00 00 00 97 
n7 
40 57 00 00 69 
n12 
10 59 00 00 00 00 97 
n19 
40 57 00 00 69 
n24 
10 59 00 00 00 00 97 
n31 
40 57 00 00 69 
n36 
10 59 00 00 00 00 97 
n43 
40 57 00 00 69 
n48 
10 59 00 00 00 00 97 
n55 
40 57 00 00 69 
n60 
10 59 00 00 00 00 97 
n67 
40 57 00 00 69 
n72 
10 59 00 00 00 00 97 
n79 
40 57 00 00 69 
n84 
10 59 00 00 00 00 97 
n91 
40 57 00 00 69 
n96 
10 59 00 00 00 00 97 
n103 
40 57 00 00 69 
n108 
10 59 00 00 00 00 97 
n115 
40 57 00 00 69 
n120 
10 59 00 00 00 00 97 
n127 
40 57 00 00 69 
n-124 
0 
10 59 00 00 00 00 97

This is with the micro finding the first valid message via checksum validation. The only issue I have to fix is that my input buffer is a 255 byte ringbuffer and the message pump isn't correctly handling the wraparound from 255 to 0 (yet).

I see what you're doing here. Pretty neat. Yes, the issue I had had on the original EEHack idle logs is that while it would display a gap time, there was never any gap time between actual messages (that is, there was never a gap between $10, $40 and $41 messages, only after those messages). This shows the actual gap timing. Whether n is nanoseconds or microseconds, it appears to average around 9. Very neat.

I apologize for not responding yesterday. Another race day meant I was out of commission. But I'm back so today I'll be experimenting more with the Arduino to see what's going on. To clarify again, when I mentioned that "the Arduino transmission doesn't appear on the line," I wasn't referring to plugging the Arduino TX directly in. That kills the line completely, which is a different problem (as steveo points out, the Arduino TX idling high is killing the line entirely). The problem I was having was that when I connected the TX line to the bus using a transistor array (which is a rough emulation of the CMOS open drain buffer setup GM uses), that transmission never appeared on the bus. EEHack recorded all the $10 and $40 messages without issue, so the line was live, but the transmissions never appeared.

I do not recall if I did idle logging with the Arduino connected via a diode. I did test the ultra-basic circuit (4.7k resistor between RX and bus, IN914A resistor between TX and bus with stripe towards TX) and the CCM still wasn't happy, but I do not recall if I actually did an idle log with EEHack while it was in that configuration. I will do just that today.

**spfautsch** · 10-31-2021

You might want to do yourself a favor and just drop a delay(1); between the 40 broadcast receive and the transmit. You can use a timer later if you must, but the micro isn't going to be needing that 1ms.

Code:

F1 56 00 B9
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
3553
F0 56 F1 C9
F1 56 08 B1
F1 56 08 B1
F1 56 00 B9
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
9625
F0 56 F1 C9
F1 56 08 B1
F1 56 08 B1
F1 56 00 B9
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
10 59 00 68 02 00 2D
40 57 4D BF 5D
15697
F0 56 F1 C9
F1 56 08 B1
F1 56 08 B1

I'm not sure why the 08 command is being echoed twice, but you can see it sleep for about 4 seconds and then wakes up and starts broadcasting again until the micro sees the F0 query / heartbeat, and then it shuts up for another 4 seconds. Without the delay the CCM ignored the message.

Code:

    if (msgfound) {
      // valid msg rcvd
      if (msg[0] == 0xF0 && msg[2] == 0xF1) {
        delay(1);
        transmit = 1;
        Serial1.write(silence, sizeof(silence));
        Serial.println(millis());
        transmit = 0;
      }
      printMsg(msg, sizeof(msg));
    }

I'll post the whole sketch when I have a chance to clean it up some.

**spfautsch** · 10-31-2021

Without the delay before transmit, eehack sees the entire message, but the CCM doesn't reply / respond to it.

Code:

633ms to 645ms (12ms) :: 405700
::: GAP4ms
649ms to 660ms (11ms) :: 4DBF5D5D
::: GAP132ms
792ms to 804ms (12ms) :: F056F1C9F15608B1
::: GAP21ms
825ms to 836ms (11ms) :: 1059006802002D

Please note if you try this sketch out I set the console baud to 115200 so the transmit buffer is cleared faster,

**NomakeWan** · 11-01-2021

Originally Posted by spfautsch

I'm not sure why the 08 command is being echoed twice, but you can see it sleep for about 4 seconds and then wakes up and starts broadcasting again until the micro sees the F0 query / heartbeat, and then it shuts up for another 4 seconds. Without the delay the CCM ignored the message.

It's because you didn't poison the receive buffer as soon as you matched the appropriate message, if I had to guess. That was the exact problem I made sure to avoid in my code; the Arduino runs so many orders of magnitude faster than the 8192 baud ALDL that it's entirely possible to go through the response code loop multiple times upon receipt of the correct message. So the first thing I do in my code upon matching the message I'm looking for is poison the first byte (oldest byte) of my 5-byte-wide sliding window. This way even if the code loops around again before the end, the contents of my buffer now start with 00, which won't match the checksum, which thus won't allow the code to enter the response loop anymore until the next time a full $40 message is received.

**steveo** · 11-01-2021

regarding delay times, an aldl byte is 1.22ms long, so a 1ms delay is less than one byte worth of dead air after you just blocked events for >1.22ms*pkt length, the cost is insignificant

**spfautsch** · 10-31-2021

Originally Posted by NomakeWan

This shows the actual gap timing. Whether n is nanoseconds or microseconds, it appears to average around 9. Very neat.

Thanks, but no. It was the position of the next message in the ringbuffer. I scrapped that because the code was too ugly and complicated and went to simply resetting the buffer when a valid message is located. This is a brutally quick + dirty proof of concept sketch.