Updating GM EBCM Checksum

[RADustin]

That might have to do with those base memory registers. There's all sorts of stuff in there about protection regions too. I only glanced at it in the manual. It looks like a really messy, poorly explained topic that's not really relevant to the checksum question right now.

is the latest full dump making more sense in assembly? it should be complete now.

[Gatecrasher]

It's making sense. I found the spot in the transfer data routine where it sets the values for a 7F 36 85 (general programming failure). You can get an 85 if there's an flash error while erasing or programming, if there's a hardware/software incompatibility, or if the checksum fails.

It's the subs leading up to setting that value that I'm having trouble with. There's nothing that obviously references the start and end values we found in the extended calibration headers. There's a few feeder subs that have repetitive loops, but I don't know for sure what they're actually doing. I really don't want to do a full disassembly on this routine, but I'm starting to think I might have to. There's just too many nested register references going on.

[RADustin]

when I flash a bad checksum in I don't get a negative mode36 response. everything goes in smoothly and I get a positive Mode36 response. Then I check with a mode A2, and I look for a E2 00(good) or E2 02(bad). If I get a E2 02 I kill the scan tool present messages and wait, then when I restart again the canID of the target will change and I know it's in a recovery type mode. Like normally I transmit on ID 0x243 and the EBCM is 0x643. When in a recovery mode the EBCM flips to ID 0x328 and I use 0x28 to transmit.

not sure if any of this info helps.

[kur4o]

Some calibrations have checksum disable switch. I think that will be faster to figure than the checksums. Or make a patch to skip checksum checks.

[RADustin]

I don't think there is much more I can do with JTAG. I wish I knew more about assembly and such. I'm hoping to take what is figured here and reverse it out to use as a learning tool.

If there is something tedious and simple or whatever to sit and do in assembly I can do that. I think I have a copy of IDA somewhere I need to look on my hard drive.

[RADustin]

Some calibrations have checksum disable switch. I think that will be faster to figure than the checksums. Or make a patch to skip checksum checks.

I assume this would be in the chip bootloader? and also only accessible thru JTAG?

A canbus solution would be best as otherwise it requires disassembling the board from the solenoid coils to gain access to the JTAG port. This isn't something I would want to do on the board in my truck as I have to destroy the coils to get them off.

[Tazzi]

I can only see two options here:
1) Go through all the subroutines to compeltely understand whats going on
2) Brute force option to work out what the algorithm is. Usually the checksum does not move 'too' much by increasing/decreasing a single value by 1, so you should be able to find the correct checksum per single 1 value change quickly, and just keep increasing and brute forcing until you see the pattern.

[RADustin]

when I flash a bad checksum in I don't get a negative mode36 response. everything goes in smoothly and I get a positive Mode36 response. Then I check with a mode A2, and I look for a E2 00(good) or E2 02(bad). If I get a E2 02 I kill the scan tool present messages and wait, then when I restart again the canID of the target will change and I know it's in a recovery type mode. Like normally I transmit on ID 0x243 and the EBCM is 0x643. When in a recovery mode the EBCM flips to ID 0x328 and I use 0x28 to transmit.

not sure if any of this info helps.

played around some more. trying to find when the target(EBCM) checks the checksum of the flash.

I full flashed an OS and a cal, where the OS had a known bad checksum. The flashing process was all positive mode36 responses, with a failed A2 request after the cal flash finished. so basically the entire process went thru, and errored right at the end. It still flashed the OS, even though the checksum was bad, before it flashed the cal- and didn't error before flashing the cal- only after everything was done.

I restored the target to perfect with a good full flash. Then thru JTAG I modified the checksum in the cal, and did an A2 request....and it came back positive(02 E2 00). I dumped the chip(thru JTAG) and confirmed my bad checksum was there and it was. So A2 doesn't seem to calc the checksum on request.

Mode 36 doesn't seem to calc the CS either as I always get positive mode36 response even with bad files. So basically I don't know where/when/what request is calc'ing the checksum. Also power on and offs don't seem to calc it either as it'll always reboot and send canbus messages fine after changing data with JTAG. Maybe there is a counter and after so many ignition cycles it errors out? seems like VWs have this problem with similar hardware.

maybe this test data is useful??? Just trying to provide any direction I can to the assembly.

[RADustin]

I can only see two options here:
1) Go through all the subroutines to compeltely understand whats going on
2) Brute force option to work out what the algorithm is. Usually the checksum does not move 'too' much by increasing/decreasing a single value by 1, so you should be able to find the correct checksum per single 1 value change quickly, and just keep increasing and brute forcing until you see the pattern.

I've changed one byte value by 1 and tried to brute force the checksum by 1. It has run over 10,000 iterations up and down(over 20,000 total) from the known good checksum(before I added 1) and never found the new checksum. With a 32bit checksum and 26 second reflash times, unfortunately I doubt brute force is going to get it.

[Tazzi]

I can only see two options here:
1) Go through all the subroutines to compeltely understand whats going on
2) Brute force option to work out what the algorithm is. Usually the checksum does not move 'too' much by increasing/decreasing a single value by 1, so you should be able to find the correct checksum per single 1 value change quickly, and just keep increasing and brute forcing until you see the pattern.

I've changed one byte value by 1 and tried to brute force the checksum by 1. It has run over 10,000 iterations up and down(over 20,000 total) from the known good checksum(before I added 1) and never found the new checksum. With a 32bit checksum and 26 second reflash times, unfortunately I doubt brute force is going to get it.

Oh forgot you mentioned it was a 32bit checksum (4bytes in a row).
I would assume a 32bit would be a CRC32 or CRC32-CCITT

I know engine computers have the option to bring up 'CVNs' which are the checksum for each segment. EBCM may also support this.
Not sure if it calculates these on the fly, or simply displays the saved value.