Updating GM EBCM Checksum

Disassembly, Reassembly, Tools and devleopment. Going deep with Hardware and Software.
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: Updating GM EBCM Checksum

Post by RADustin »

Tazzi wrote:
RADustin wrote:
Tazzi wrote: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.
yep, I'm pretty sure its a CRC32 of some type. But I don't know the starting value or the polynomial...or any other little tricks it may have. When the hexsum barely changes and the checksum swings wildly, I think that's the give away it's some type of CRC.

I have a feeling the starting value may be the 0x12345678 that was found earlier. but still don't know the polynomial or if any weird flipping or inverting is going on. I wrote a python program and tried a few different parameters with the CRC. some are close(ish) but not there- they are just guesses in the dark though. Really hoping the assembly can narrow things down.

I originally thought the checksum was being calculated real time or at least on a timed basis, but I don't think this is true anymore. After changing values thru JTAG, if I'm careful, it'll never error out and even pass a modeA2 request with a positive response- even though the CS is bad.
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: Updating GM EBCM Checksum

Post by Gatecrasher »

I haven't had much time to work on this lately. I fired it up last night and looked at the A2 routines. There are some places that seem to reference the calibration headers. I'm going to start picking those apart as time permits.
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: Updating GM EBCM Checksum

Post by RADustin »

did a bunch of CRC checks with the calibrations yesterday. Found some tutorials on XORing two known good files and using that result to try and figure the polynomial since the input and output criteria cancels out. All I can say is it isn't a standard listed polynomial...or isn't a CRC at all.

There's a few brute force CRC tools that will change 4 bytes of data at the end of the file to trick the CRC, that's my next play. That should at least confirm if it is a CRC32 or not- it won't give me the algo but should give me an acceptable file if the algo is CRC based. If this works then I can go back to the XOR file and try to manually figure out the poly. If it doesn't work then it likely isn't a CRC and I'm not sure what else it may be.

I looked at Fletcher32 and Adler32 as well, neither of those are it.

Still hopeful the assembly can turn up some clues.
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: Updating GM EBCM Checksum

Post by RADustin »

Gatecrasher wrote:I haven't had much time to work on this lately. I fired it up last night and looked at the A2 routines. There are some places that seem to reference the calibration headers. I'm going to start picking those apart as time permits.
that'd be awesome.

something really strange showed its face the other day as well with the JTAG. when I disconnect the JLink interface and reconnect it....the bytes that I wrote new data too in the flash revert back to original. I found this by comparing flash dumps. One dump its there, unhook and reconnect, next dump it's gone.

So basically anything I feel like I may have learned from shooting bytes in with JTAG is probably not true...
In-Tech
Posts: 778
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: Updating GM EBCM Checksum

Post by In-Tech »

I'm not sure it will be similar for you. Other "protected mcu's" use the mathco and have unique algo's specified by the end user manufacturer. The only real way to get it without stumbling across it is to dump the mathco(maprom) which is generally high security. This is fairly normal in iso7816
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: Updating GM EBCM Checksum

Post by RADustin »

I can certainly research that.


I did confirm on a failed canbus cal only write that the data does make its way to ram, just the controller is stuck in a dead poll and switches canids to the recovery IDs.

maybe the routine for the switching of canids would be useful to decompile? just a thought. normal ID is 0x643. recovery is 0x328.
Attachments
Failed CS Write.PNG
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: Updating GM EBCM Checksum

Post by Gatecrasher »

I found it.

I'm ok at taking other people's code apart, but absolutely terrible at writing my own code. So I want to challenge myself to write some python code to calculate it. I'll post what I know by Friday evening, whether I figure out the calculator or not.

In-tech was close. It's a hardware based CRC. But it doesn't have any security whatsoever.
In-Tech
Posts: 778
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: Updating GM EBCM Checksum

Post by In-Tech »

Yay :thumbup:
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: Updating GM EBCM Checksum

Post by Tazzi »

Gatecrasher wrote:I found it.

I'm ok at taking other people's code apart, but absolutely terrible at writing my own code. So I want to challenge myself to write some python code to calculate it. I'll post what I know by Friday evening, whether I figure out the calculator or not.

In-tech was close. It's a hardware based CRC. But it doesn't have any security whatsoever.
well done!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: Updating GM EBCM Checksum

Post by RADustin »

Gatecrasher wrote:I found it.

I'm ok at taking other people's code apart, but absolutely terrible at writing my own code. So I want to challenge myself to write some python code to calculate it. I'll post what I know by Friday evening, whether I figure out the calculator or not.

In-tech was close. It's a hardware based CRC. But it doesn't have any security whatsoever.
Man that’s awesome. Cant wait.

Was it in the A2 routines?
Post Reply