Corvette CCM Reverse Engineering Anyone?

[kur4o]

There is some empty pad bytes before $b600, since too small to fit code there. on 94 ccm it is alillte more empty space there. It can be used for patching for sure.

If we can dump the eprom and write some patch, at least we will be able to test mode 5 without worrying about aa response. I looked at the dump and it seems there is no checksums applied.

I am sure pcm sends some 4000 ppm signal to ccm, along with cruise control and other modules that need to know exact speed.

If you can simulate the signal you can monitor registers while the mileage increase and when is written to eeprom. On soft shut down or at specific interval or is not stored at all if power is lost to ccm.

If you managed to fix the car, what shall we do next. Reverse the aldl protocol and try some custom modes to write data to ccm, since there is already 2 subroutines in the aldl code that writes data to eeprom. Or the ultimate goal, change mileage.

[spfautsch]

... clearly it knows exactly what your odometer is, and yet the odometer register is off by ~6 miles. So how does it both not know your precise odometer reading and also display your precise odometer reading?

Actually it wasn't off by 6, it was off by 8. Yours had 01 in the first byte which I assumed was the lsb. I'm still not sure what this signifies, but apparently the low 4 bits aren't stored in the triplet structure.

$b5fe: 00 00 01 1f ff 4d ff ff ff ff

I assumed this was to be decoded to 0x1f4d1 but I think it should have been decoded to 0x1f4d0.

It just so happened that mine is as such:

$b5fe: 00 00 01 2b ff 8d ff ff ff ff > 0x2b8d1 = 178385 which happened to be what it reads exactly

But the salvage unit that reads 2675 in-car has:

$b5fe: 00 00 00 00 a7 00 00 00 00 00 > 0x0a70 = 2672

There's another 3 miles stored on it somewhere. Yours has 8, mine 1. I just have to figure out what units they're storing it in because it's not entirely obvious.

There is some empty pad bytes before $b600, since too small to fit code there. on 94 ccm it is alillte more empty space there. It can be used for patching for sure.

If we can dump the eprom and write some patch, at least we will be able to test mode 5 without worrying about aa response. I looked at the dump and it seems there is no checksums applied.

I think you're incorrectly assuming there's any executable code stored in whatever eeprom(s) there are on this thing. I'd wager the title to my car the program code is all in the uveprom. I'm not in any hurry to desolder it and dump. But I will if there's absolutely no other way to confirm where the different memory regions are stored physically.

If you managed to fix the car, what shall we do next. Reverse the aldl protocol and try some custom modes to write data to ccm, since there is already 2 subroutines in the aldl code that writes data to eeprom. Or the ultimate goal, change mileage.

The ultimate goal would be to reprogram these completely with open source tools.

[steveo]

Actually it wasn't off by 6, it was off by 8. Yours had 01 in the first byte which I assumed was the lsb. I'm still not sure what this signifies, but apparently the low 4 bits aren't stored in the triplet structure.

$b5fe: 00 00 01 1f ff 4d ff ff ff ff

I assumed this was to be decoded to 0x1f4d1 but I think it should have been decoded to 0x1f4d0.

It just so happened that mine is as such:

$b5fe: 00 00 01 2b ff 8d ff ff ff ff > 0x2b8d1 = 178385 which happened to be what it reads exactly

But the salvage unit that reads 2675 in-car has:

$b5fe: 00 00 00 00 a7 00 00 00 00 00 > 0x0a70 = 2672

There's another 3 miles stored on it somewhere. Yours has 8, mine 1. I just have to figure out what units they're storing it in because it's not entirely obvious.



I think you're incorrectly assuming there's any executable code stored in whatever eeprom(s) there are on this thing. I'd wager the title to my car the program code is all in the uveprom. I'm not in any hurry to desolder it and dump. But I will if there's absolutely no other way to confirm where the different memory regions are stored physically.



The ultimate goal would be to reprogram these completely with open source tools.

i believe both the eeprom and uv prom would be addressed memory so both should be fully visible in the dump we get via the aldl.

i cant believe gm would leave the memory dump enabled. it defies all logic.

[spfautsch]

i cant believe gm would leave the memory dump enabled. it defies all logic.

To quote Kid Rock, it was 1989, my thoughts were short, my hair was long. Perhaps the guys that engineered this thing weren't exactly the top of the class.

Can any of the uveprom based ECMs be dumped thusly?

[NomakeWan]

I am sure pcm sends some 4000 ppm signal to ccm, along with cruise control and other modules that need to know exact speed.

That's not it. No modules connected to the CCM require the CCM to broadcast vehicle speed. The Cruise Control Module on the Y-body has a direct 4000 ppm signal input straight from the PCM, and has no connections to the CCM whatsoever.

[spfautsch]

Actually kur4o is correct. The actual hall effect sensor connects to the (our) PCM on a31 and a32. Then it converts it to 4000ppm and outputs it throughout the vehicle on b8. The CCM (and any other modules that need it) gets this conditioned signal on e2, not the actual hall effect sensor. Otherwise the CCM would also need to be programmed for diff gear ratio. This is completely independent of the aldl.

Edit: I think I see the method behind the madness on the odometer storage. I'll need to run up some test bench miles to confirm, but it looks like a 1 in the third (possibly first) byte indicates one of the three odometer bytes has been filled to capacity (FF) and incremented again and is flagged as "skip". If the first byte is not 0 the ff is a part of the stored value. I'm hearing two border collies barking and having trouble focusing, but I'll post more details when I can confirm. This would allow for storing about 268 million miles in four eeprom bytes with minimal single byte erases.

[NomakeWan]

Actually kur4o is correct. The actual hall effect sensor connects to the (our) PCM on a31 and a32. Then it converts it to 4000ppm and outputs it throughout the vehicle on b8. The CCM (and any other modules that need it) gets this conditioned signal on e2, not the actual hall effect sensor. Otherwise the CCM would also need to be programmed for diff gear ratio. This is completely independent of the aldl.

Yeah, I had to re-read what he typed a few times before I realized my mistake. I was reading it in the context of our current discussion, which was regarding ALDL comms via the CCM. But he wasn't talking about that at all, he was talking about the PCM independent of the CCM, a completely different unrelated topic.

My bad. Anyway, the local electronics shop didn't have the components I needed......so I ended up buying a huge kit that had them plus a bunch of other random shit I can keep in my lab for a rainy day. Sucks paying $16 more than intended, but at least I'm good to go. Should have a new interface ready by tomorrow.

EDIT: As to the memory dump, there are only two address spaces that are rejected by the memory dump routines (both Mode 2 and Mode 3). These are:

$1000~$103F: CPU registers. These are restricted because attempting to access them via ALDL could lead to the CPU crashing.

VATS: All VATS memory locations are restricted and will return 00 unless the correct key for the vehicle is inserted and the ignition is set to run. My dumps were all done with the key in and the ignition in run, so these locations should be populated. My datasheet doesn't specify the memory locations, but it should be fairly trivial to find them by just taking a dump with the key in and ignition on, then immediately taking another with the VATS connector disconnected. I can do that later.

[spfautsch]

TX+F15605B4
RX+F1570500B3
TX+F15605B4
RX+F15705AA09

kur4o you were right on the money dude!

Time to void a warranty.

[kur4o]

That`s pretty awesome.

Now it is time to wipe out some eeproms.

[spfautsch]

We'll see (erasing eeproms). Before I get too far along I wanted to share a picture of the reman pin. But my lawyer (who also happens to be my wife) has advised me to proceed with caution. So you're not going to get lead right to the pot o' gold.

Spoiler alert, it's a deceptive aspect you won't be able to find with passive forensics.

reman-pin.jpg

I'll give one more hint - it is floating, but it's not floating at 12 volts.

Here's what I've learned. While mode 5 is active 02 requests stop working, and mode 5 seems to timeout after about 1 second. Mode 6 requests inside that timeframe (and outside it) give no reply. I've tried uploading nop commands as well as plain ascii to the $00 scratchpad area and to the last few digits of the (ram) VIN with no apparent success.

I feel like I've only conquered 5% of the problem and it was completely non-trivial. I'm open to any suggestions, especially protocol focused interrogation. I have no interest in profiting from this endeavor, but I will stop at nothing until I can minimally change a few bytes of ram.

[NomakeWan]

TX+F15605B4
RX+F1570500B3
TX+F15605B4
RX+F15705AA09

kur4o you were right on the money dude!

Time to void a warranty.

F1 57 05 AA

ohhhhh snap