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:semi short lived excitement lol.

flashed a cal(cal only) with a bunch of data changed and managed to brick the damn thing. :rant:

JTAG 'works' but this tool still won't write to flash. Once I close the JTAG terminal and reopen, all the 'written' data reverts.
So it returns back saying aaccepted using CANBus?
yep- I made a successful flash with one byte changed and the CS updated. Canbus still was fine.

Then made a second flash with a whole bunch of bytes changed(CS updated) and the canbus has never spoken again. When checking the flash with JTAG this flash went in 100%.

So unless I can figure out how to get JTAG to play nice, I'll be buying another EBCM for the bench. I'm single handedly increasing the value of these things.
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 »

Changing some values inside of cal *can* result in a semi brick state where it reads the invalid data into the operating system and results in infinite loops or boot loops ect.
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 »

that's probably what happened. I'll have to be more careful.

I bought another EBCM to bench flash to work with...and I'm also going to try openOCD with my JLink to see if that works better over JTAG. Like I said, JTAG could save this thing, but if it doesn't I have another on the way.

Still excited the checksum is figured- almost in disbelief. I guess in the end it wasn't really a crc. Just a conditional XOR that is truncated at 32bits each cycle....but I guess it does have that left shift which kind of looks like a CRC in a way. The math is confusing, but the program works so I'm moving forward for now.

It would be nice to see the assembly. I'd really like to start getting more into that to get more independent on projects such as this.
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: Updating GM EBCM Checksum

Post by Gatecrasher »

Now that you can calculate the correct CRC, have you tried flashing the tweaked cals via SPS? I think it's possible to do that by replacing the files in the SPS cache folder.
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: Updating GM EBCM Checksum

Post by RADustin »

yep! I made two flashes so far. I corrected the checksum in my trial1 file, which was a single byte changed. Flashed, all was good. Then I bricked it with a file that I changed every 0x60 in the file to 0x78...whoops. I'm using my arduino based flasher tool, that was written off the SPS utility file that I used to attempt the checksum brute force with earlier. Cal only flashes it works great. For full flashes I use SPS and just the files it grabs from acdelco since normally I'm full flashing back to 'stock'. I haven't tried to swap the files within SPS but it would work.

Would the assembly info lead to a data range within the cal that I shouldn't ever modify? or are these 'do not touch' areas scattered throughout the cal? I wish I had the $$ to drop on a brand new unit from GM. I could dump it with JTAG and since it has an empty file, then I know all empty spots are good to mess with.

Pretty sure I found the location of the tooth counts in RAM. I just need to find where this loads in from ROM.
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: Updating GM EBCM Checksum

Post by RADustin »

the checksum math is weird. as in it doesn't seem very robust.

the left shift is like multiplying by decimal 2. then it raises that value to the power of the next addresses value. what's interesting is if the next address value(32bit word) is 0, then the running calc goes to 1. The XOR mask is only applied if the last (or very first) seed is equal to or larger than 0x8000 0000(because of the &). with a starting seed of 0xFFFF FFFF, this guarantees that the first iteration of the calc will be XOR masked....but again as soon as 0x0000 0000 pops up, everything is back to 1.....so on many cal files I'm not even sure the initial value means much.....as well as the data before the 32bits of 0s assuming they are offset correctly to cleanly enter the calc.

interesting either way. This is the first time I've been successful at something this complicated lol.
RADustin
Posts: 162
Joined: Fri Oct 17, 2014 9:44 am

Re: Updating GM EBCM Checksum

Post by RADustin »

stumbled on the locations to change for the abs tone ring teeth so looks like we're in business. Truck accepted flash no problems. Preliminary testing looks good, will do more tomorrow to confirm 100%. Then it'll be full system testing to ensure my issues are resolved.

:driving:
User avatar
Gatecrasher
Posts: 272
Joined: Sat Apr 25, 2020 6:09 am

Re: Updating GM EBCM Checksum

Post by Gatecrasher »

Kick ass. Good luck with the testing!
04colyZQ8
Posts: 380
Joined: Thu Jan 16, 2014 12:41 pm
cars: 2004 Colorado 4.8L swap
86/90 Jimmy 6.5L diesel swap
80 Chevrolet Silverado TBI swap
88dodge W100 LPG conversion

Re: Updating GM EBCM Checksum

Post by 04colyZQ8 »

This is very interesting! Does mode 23, read vpw as well? Or just can bus? What interface are you using to read the bdm? I really want to fix my bricked bcms that use the tms470 processor
In-Tech
Posts: 778
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: Updating GM EBCM Checksum

Post by In-Tech »

I could be in the wrong thread but something woke me up from a sleep :)
Since we know GM generally follows a very similar structure...and I think someone mentioned p12 peripheral being called. This was used in the TMS370 in the late '90's crapola and was used as a call in code to XOR every value after the value (xxxx, xx in the 8 bit stuff) . Then depending on the push/pop reply for the stack and also a return or exception return, it could come and go. I just thought I would post for future if not help now :)
Post Reply