Updating GM EBCM Checksum
Re: Updating GM EBCM Checksum
You guys are great.
I had to run out of town, but I return tomorrow and I can post some more binaries I have that may help.
The two I originally posted are just the two different ones that are the most similar. I have others that vary by quite a bit, all same OS.
Catchup with you guys tomorrow.
I had to run out of town, but I return tomorrow and I can post some more binaries I have that may help.
The two I originally posted are just the two different ones that are the most similar. I have others that vary by quite a bit, all same OS.
Catchup with you guys tomorrow.
- antus
- Site Admin
- Posts: 8272
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: Updating GM EBCM Checksum
@kur40, I had a look at that file, but the closer I look the cracks appear. I think the 8051 instructions might be small enough that almost any random hex will convert in to op codes. There are nops where I wouldnt expect them, and code flow that doesnt look sain the closer I look. To many jumps for no logical reason like the disassembler is just running away.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Re: Updating GM EBCM Checksum
I attached a few more bins.kur4o wrote:I did some digging that might help you.
AT $C is 4 byte address that points to start of the segment. At $10 is the length of the segment.
At $2c is some range start-end[start points to start of segment, while end points to first byte of checksum].
I found some range pairs in the OS
at $4d7c4
00 07 00 14
00 00 40 14
00 00 00 24
00 00 3F EC
00 06 FF FC
00 07 7F FC
24-3fec boot block
4014-6fffc OS
70014-7fffc CALibration
TOo bad I have no idea what processor runs the code. If processor is known a disassembly can be made giving some clue about type of checksum calculation used.
Do you have more files ripped for comparison.
2328 is same chassis configuration as 2327. Just different engine and I think 4x2 vs 4x4.
2324 is different chassis type from all.
Please forgive as I haven't had time to sit and mentally process what you guys have looked at yet. I will shortly, although my disassembly skills are very minimal.
I did know that the technology(EBCM logic) is mid-2000s, I'm curious how that can be found in the binary? or was it possible to search the bin calid or similiar to find out?
I'm also working some paths to figure out the processor. I'm hoping I can run across some TRW documentation. The EBC460 is newer but should be similar- and is used all over the place.
- Attachments
-
- 22902324.bin
- (32 KiB) Downloaded 151 times
-
- 22902328.bin
- (32 KiB) Downloaded 148 times
Re: Updating GM EBCM Checksum
There are two CPUs on the board. My understanding is limited but I believe one cpu is handling the sensor inputs and low level system calcs, and the other is the slave chip that is flashed with the GM specific cal files.
Either way-
CPU 1-
Infineon Orion D2
G1222
VE228203M04
CPU 2- edit- added info
Texas Instruments
Family is TMS470R1
https://www.ti.com/lit/ug/spnu554/spnu5 ... 2488397980
hoping you guys can do something now that the processors are known.
Either way-
CPU 1-
Infineon Orion D2
G1222
VE228203M04
CPU 2- edit- added info
Texas Instruments
Family is TMS470R1
https://www.ti.com/lit/ug/spnu554/spnu5 ... 2488397980
hoping you guys can do something now that the processors are known.
Re: Updating GM EBCM Checksum
do you think that the checksum may only cover the calibration block? is that typical?kur4o wrote:I did some digging that might help you.
AT $C is 4 byte address that points to start of the segment. At $10 is the length of the segment.
At $2c is some range start-end[start points to start of segment, while end points to first byte of checksum].
I found some range pairs in the OS
at $4d7c4
00 07 00 14
00 00 40 14
00 00 00 24
00 00 3F EC
00 06 FF FC
00 07 7F FC
24-3fec boot block
4014-6fffc OS
70014-7fffc CALibration
TOo bad I have no idea what processor runs the code. If processor is known a dissasembly can be made giving some clue about type of checksum calculation used.
Do you have more files ripped for comparison.
Re: Updating GM EBCM Checksum
Please forgive my limited knowledge in this area, this is probably a bad hack, but could you make the change to fix the tone wheel teeth, then go to a blank area of the code near by and adjust one of the bytes by the inverse amount so that the checksum doesn't need to change?
Re: Updating GM EBCM Checksum
So long as you know where the checksum is, I have previously brute forced the checksum value by continuously flashing and increasing the checksum by one until its accepted.
Takes a long time but does work
Takes a long time but does work
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Re: Updating GM EBCM Checksum
if the checksum is a simple sum, I think this would be adequate. Unfortunately, to the best of my current abilities, I don't think it is a simple sum. It could be a two part deal, but I'm really not sure.turbo_bu wrote:Please forgive my limited knowledge in this area, this is probably a bad hack, but could you make the change to fix the tone wheel teeth, then go to a blank area of the code near by and adjust one of the bytes by the inverse amount so that the checksum doesn't need to change?
Re: Updating GM EBCM Checksum
The problem is, one a bad file is uploaded- the module goes into a 'soft brick' mode and if another bad file is tried it will brick. So you would have to upload a trial, then go back to a known good file, then back to another trial and so forth.Tazzi wrote:So long as you know where the checksum is, I have previously brute forced the checksum value by continuously flashing and increasing the checksum by one until its accepted.
Takes a long time but does work
The checksum is 4 bytes. I'm not sure if it's a double deal where 2 bytes are a CRC and 2 bytes are a sum or something....all 4 bytes don't appear to be a single simple sum though.
The 4 byte CS is really throwing me off though. All the other modules in the truck are 2 byte sums.
I do know from the calibrations I have that when the overall sum of the flash barely changes, all 4 bytes of the checksum change drastically. So again, I'm not exactly sure what's going on.
I've tried a bunch of different summing strategies. I'm fairly handy in excel so I can mess around in there.
Re: Updating GM EBCM Checksum
do you think you could figure out the checksum algo? potentially for pay? I'm not looking for anything for free, but I would like to get my project up and going.Tazzi wrote:So long as you know where the checksum is, I have previously brute forced the checksum value by continuously flashing and increasing the checksum by one until its accepted.
Takes a long time but does work
LMK, thanks.