Corvette CCM Reverse Engineering Anyone?

[steveo]

im busy cleaning up my shop right now so i'm stalled too but i will:
- try to get the arduino i have to work with ALDL

40 57 00 00 69
41 67 02 F6 00 87 00 42 00 00 00 00 88 00 48 AC 12 00 FF FF 0B
40 57 20 89 C0
41 67 02 F6 00 87 00 42 00 00 00 00 88 00 48 FF FF 00 FF FF CC
40 57 FF FF 6B

so what is the seed / key pair there ?
i know a bit about ancient gm seed/key stuff....maybe i can guess

attached is a flashhack exe (copy over your old one and use same libraries) that has the new idle traffic scanner in it (see advanced tab). it uses a new function that establishes a relationship with a running datastream (which is the hard part in reading an existing datastream, since what are we reading? a device? a length? a checksum?) hope it helps a bit. it basically reads forward until it finds a length of a packet that, when read, has a valid checksum.. it's possible in a very rare circumstance that the first message will be incorrect (as it may have a technically valid checksum but not be real), but the second and third messages are exponentially more likely to be correct, i think by the third message, because of factorials, it is more likely that lightning will strike your house 1000 times today than have an error there.

[NomakeWan]

so what is the seed / key pair there ?
i know a bit about ancient gm seed/key stuff....maybe i can guess

40 57 00 00 69
41 67 02 F6 00 87 00 42 00 00 00 00 88 00 48 AC 12 00 FF FF 0B
40 57 20 89 C0
41 67 02 F6 00 87 00 42 00 00 00 00 88 00 48 FF FF 00 FF FF CC
40 57 FF FF 6B

I bolded the keypairs in the CCM ($40) and PCM ($41) polls.

[spfautsch]

im busy cleaning up my shop right now so i'm stalled too but i will:
- try to get the arduino i have to work with ALDL

Unless you're unable to do anything further with the CCM, I have an arduino mega sitting on my workbench and I just dug out my last remaining aldl connector shell. I think I might know what NomakeWan is overlooking. This is something I've wanted to mess with anyway because I'd love to have passive logging to an SD card. And, it's something I might actually have a clue with (the arduino part anyway)!

One more question if you would - I've never looked, but does the eehack logging exchange involve an ask / answer transaction for the entire logging session, or is it something more specialized? I ask because I'm curious if I periodically requested whatever the ccm asks for during run, would the ccm act on the data if silenced? I realize this would slow down eehack's data acquisition, but at this point I'm pretty happy with my tune and would be ok with fewer datapoints for time logged. I can regularly drive 200 interstate miles with the cruise control set, fill up when I get off the freeway, and see 26-29 mpg. As pig rich as it smells when idling, I can't imagine there's anything wrong with the closed loop fuel control considering the cruising mpg.

[NomakeWan]

One more question if you would - I've never looked, but does the eehack logging exchange involve an ask / answer transaction for the entire logging session, or is it something more specialized? I ask because I'm curious if I periodically requested whatever the ccm asks for during run, would the ccm act on the data if silenced? I realize this would slow down eehack's data acquisition, but at this point I'm pretty happy with my tune and would be ok with fewer datapoints for time logged. I can regularly drive 200 interstate miles with the cruise control set, fill up when I get off the freeway, and see 26-29 mpg. As pig rich as it smells when idling, I can't imagine there's anything wrong with the closed loop fuel control considering the cruising mpg.

The whole session is ask/answer. The CCM sends an F0 poll, EEHack responds to it with an F1 Mode 8 request, followed by F4 Mode 1 requests (or in the case of speedlog, F4 Mode 5). Then the next time the CCM wakes up from the Mode 8 and does an F0, EEHack has to do another F1 Mode 8 to shut it up and retain bus master status, and continue.

[steveo]

after the ccm has been silenced with a mode 8 request it shouldn't wake up again until you stop asking for data from the ecm for a few (usually 3) seconds

[spfautsch]

... it shouldn't wake up again

Wake up, or start broadcasting?

No biggie, I'll try to figure it out on my own. I'm interested in if it will process response data it hasn't asked for. If I can make the fuel consumption and aldl derived "gauges" work while logging I'll be one extremely happy camper.

NomakeWan, try this out:



Sketch:

byte M1Cmd[5] = {0xF1,0x57,0x01,0x00,0xB7};

void setup() {

  Serial.begin(9600);
  Serial1.begin(8192);
  
}

void loop() {

  if (Serial1.available()) {

    while (Serial1.available()) {
      byte read = Serial1.read();
      Serial.println(read, HEX);
    }
    
  }

  if (Serial.available()) {
    for (uint8_t i = 0; i < 5; i++) {
      Serial1.write(M1Cmd[i]);
    }
    Serial.read();
  }  
  
}

Serial output is one byte per line without being padded with a leading 0 i.e. 00 in a bin = 0, 01 in a bin = 1 here. You'll have to group the ask / answers appropriately, but I've commented my 01 00 request and response from the CCM

41
40 
57
FF
FF
6B
41
67
2
EC
0
4C
4C
1
0
E
90
F6
E3
0
3F
FF
FF
0
FF
FF
1F
F0
56
F1
C9
F1 < start looking here
57
1
0
B7
F1  < response here ??? 
7A
1
8
8
20
3
14
0
10
DF
B3
0
D3
F1
0
77
71
0
3B
59
42
2C
A9
BF
0
0
80
0
0
0
0
0
0
0
0
0
0
0
15
10
59
8
4C
2
0
41
40
57
FF
FF
6B

Have you gotten this far, am I just pounding sand?

[steveo]

i have a 5v uno here that i could work with, although it's single serial port so more tedious to test with

do you want me to write you a function or two for handling aldl comms? i could port you over the super important elements like 'fast forward to first valid message', 'find bus master ID' and 'wait for hole to send mode 8 request', also the checksum/length calcs

your diode/resistor arrangement seems to make sense - is this about right? |< being a diode of course.

[code]
TX ----- |< ----------|---------- (car)
RX ----- (resistor)--/
[code]

[spfautsch]

do you want me to write you a function or two for handling aldl comms? i could port you over the super important elements like 'fast forward to first valid message', 'find bus master ID' and 'wait for hole to send mode 8 request', also the checksum/length calcs

I might enlist your help on that if I can't figure out something simple and fast. But for now I'll play with it because it's the best way for me to learn.

What's the gist of finding bus master id? Is it just listening for a device that's sending the F0 5x Fn cc message?

Am I correct to assume I should be prepared to buffer messages 0xAA + 2 bytes long?

your diode/resistor arrangement seems to make sense - is this about right? |< being a diode of course.

Yes, the TX pin on the arduino is an output and I believe is set to active high when not transmitting. The diode keeps that 5v from killing the bus' floating state and only conducts when TX is driven low.

Nice work on flashhack btw. I always do my best coding after drinking "a lot". The problem is afterwards I rarely remember it. :-)

I'm debating whether to include the odometer triplet in the .xdf (non-decoded of course). I'll get that to you over the weekend or I'm sure you could handle it if you wanted to.

[NomakeWan]

Wake up, or start broadcasting?

No biggie, I'll try to figure it out on my own. I'm interested in if it will process response data it hasn't asked for. If I can make the fuel consumption and aldl derived "gauges" work while logging I'll be one extremely happy camper.

NomakeWan, try this out:



Sketch:

byte M1Cmd[5] = {0xF1,0x57,0x01,0x00,0xB7};

void setup() {

  Serial.begin(9600);
  Serial1.begin(8192);
  
}

void loop() {

  if (Serial1.available()) {

    while (Serial1.available()) {
      byte read = Serial1.read();
      Serial.println(read, HEX);
    }
    
  }

  if (Serial.available()) {
    for (uint8_t i = 0; i < 5; i++) {
      Serial1.write(M1Cmd[i]);
    }
    Serial.read();
  }  
  
}

Have you gotten this far, am I just pounding sand?

Start broadcasting. As steveo points out, the CCM will not remain silent forever after a Mode 8 request. It will eventually "time out" the Mode 8 request (after 5 seconds according to GM's documentation) and return to normal operation. At this point it will send another F0 poll, and that must then be replied to with another Mode 8 request before you can talk to the PCM again.

I have tried the "just use a pulldown and a zener" connection and it did not work for transmit. I'm also using a sliding window to detect the appropriate incoming message. However, that's what I don't understand about your code. You don't appear to have any code whatsoever to detect anything on the line. If I'm reading it correctly, it just shouts F1 57 01 00 B7 every single program loop. Yet the serial monitor log you posted is entirely correct; there is an F0 poll, followed by your F1 Mode 1 Message 00 request, followed by the correct F1 Mode 1 Message 00 response.

How? If the code you posted is your entire code, how did it know to transmit only after the F0 poll?

[steveo]

  if (Serial.available()) {
    for (uint8_t i = 0; i < 5; i++) {
      Serial1.write(M1Cmd[i]);
    }
    Serial.read();
  }

this means if there is data to read on the 9600 baud port (your PC), then you write to the aldl port. you then read a single byte from the 9600 baud port (your PC) to nowhere.

this would technically work, if he is monitoring the serial data, then manually smacking a key in his serial terminal at the correct time to send the message (assisted by the fact that the write would only happen during a time when the bus was not fully saturated and the while() loop has exited)

[spfautsch]

How? If the code you posted is your entire code, how did it know to transmit only after the F0 poll?

I sent it a linefeed on the other serial port. This is simply a hello world that proves it's possible to transmit with two components, non-inverted. And that's not a zener, just a plain small signal diode. A 1N4001 would work as well.

I'll play with your sketch tonight if you haven't figured it out by then.