pcmhacking.net

Use educated guesswork, and write your own program to do the calcs. CRC is intentionally completely different with any changed bit or byte, so 'close' is not a thing. Its either correct or its not.

If you write an app that uses a crc library you can load all your data as an array then more easily change that start and end values and try again untill you get a match (hopefully). Its more likely to be sum than crc, but it depends on the year of the bcm your looking at.

Also comparing bins of the two most similar but not identical calibrations and finding changed bytes should give you a shortlist of possible sum locations. It may not be the first two but it'd be near the start, or maybe the end. Its possible theres more than one segement and sum, too.

I know this is an old thread, but I'm bumping it because it directly addresses something I'm working on. It sounds like 04colyZQ8 may have been working on something very similar.

I'm working on the calibrations for an 09 Colorado BCM. I was able to dump the whole thing using a BusPirate and JTAG. So if I take the lighting calibration, for example, and load it into my hex editor, I can see the 2 byte checksum in the first two bytes is 0xDA9D. If I run a select all the subsequent bytes from 0x02 until the end of the calibration, then run a 2s complement checksum-16 on it, I get 0xE387. This is all 100% unaltered from how I got it out of the donor vehicle, and I've got a high level of confidence that the dump is accurate since the code is disassembling perfectly and all the embedded part numbers and other references line up with their expected values.

The calibration is attached. I picked lighting as the example just because it was small.

If I take the BCM 09 Colorado bin you posted, select everything except the first 2 bytes I get 0x2563 for a 16 bit big endian sum.. this what you get??
If I do a 2's compliement on that I get oxDA9D which is the first 2 bytes..

0x1C79 is a 16 bit sum but not the same thing..

Gatecrasher wrote:I know this is an old thread, but I'm bumping it because it directly addresses something I'm working on. It sounds like 04colyZQ8 may have been working on something very similar.

I'm working on the calibrations for an 09 Colorado BCM. I was able to dump the whole thing using a BusPirate and JTAG. So if I take the lighting calibration, for example, and load it into my hex editor, I can see the 2 byte checksum in the first two bytes is 0xDA9D. If I run a select all the subsequent bytes from 0x02 until the end of the calibration, then run a 2s complement checksum-16 on it, I get 0xE387. This is all 100% unaltered from how I got it out of the donor vehicle, and I've got a high level of confidence that the dump is accurate since the code is disassembling perfectly and all the embedded part numbers and other references line up with their expected values.

The calibration is attached. I picked lighting as the example just because it was small.

Ironduke is on the right track there!

Impressed you dumped the flash manually. Whats the processor on your 09 colorado BCM?

Thanks! I guess I need to find a tool that has some different sum / checksum tools. I'm using an ooooold version of Hex Workshop.

What I really need to do is write my own damn tool. This seems like it'd be a good learning experience.

The processor is a TI TMS470PLF111. It's an ARM7TDMI core, so it worked with OpenOCD. It's only in the 09 and up Colorado and H3 BCMs. 08 and prior use a different chip that I haven't been able to identify. I think it's also used in some GMT800 BCMs. Where would be a good sub-forum to start a thread about that?

Gatecrasher wrote:Thanks! I guess I need to find a tool that has some different sum / checksum tools. I'm using an ooooold version of Hex Workshop.

What I really need to do is write my own damn tool. This seems like it'd be a good learning experience.

The processor is a TI TMS470PLF111. It's an ARM7TDMI core, so it worked with OpenOCD. It's only in the 09 and up Colorado and H3 BCMs. 08 and prior use a different chip that I haven't been able to identify. I think it's also used in some GMT800 BCMs. Where would be a good sub-forum to start a thread about that?

Anychance you could take a picture of the BCMs guts? Not sure Iv seed a TI TMS on a BCM previously.. GM usually uses the same chipsets over an entire series of vehicles as they recycle parts in multiple cars.

Could just make a topic in "Off Topic" like I did for this thread.

Gatecrasher wrote:Thanks! I guess I need to find a tool that has some different sum / checksum tools. I'm using an ooooold version of Hex Workshop.

What I really need to do is write my own damn tool. This seems like it'd be a good learning experience.

The processor is a TI TMS470PLF111. It's an ARM7TDMI core, so it worked with OpenOCD. It's only in the 09 and up Colorado and H3 BCMs. 08 and prior use a different chip that I haven't been able to identify. I think it's also used in some GMT800 BCMs. Where would be a good sub-forum to start a thread about that?

I have the same checksum ability problem and have been using hexworkshop 4.23 for yeeeeeeeeears, lol and am curious what tool you guys are using

ironduke wrote:If I take the BCM 09 Colorado bin you posted, select everything except the first 2 bytes I get 0x2563 for a 16 bit big endian sum.. this what you get??
If I do a 2's compliement on that I get oxDA9D which is the first 2 bytes..

0x1C79 is a 16 bit sum but not the same thing..

I'm using Hex Editor Neo.. found it awhile ago and I like it.. It has a checksum tab that has a pretty good list, you can do custom crc's too but that's over my head and I haven't needed it.

Looks like you need the Professional version in order to get their checksum module. $45 isn't bad at all. I might have to pick that up.

Gatecrasher wrote: Where would be a good sub-forum to start a thread about that?

I think "Disassembly and Resassembly" but its original intention how that relates to reverse engineering, I think i'll update the areas name/comment, and also move this thread there.