Help Getting Started With Ghidra For MPC562 ME9.6.1 VE E77 LY7

[Gatecrasher]

Good catch. I had those labeled, but didn't cross reference them correctly. Thanks.

The OS checksum table location was the same between our example bin here, and an MED 9.1 bin from my old 08 Audi S5. I haven't checked the other GM bins yet.

Dunno if it'll be possible to automate the search for the calibration checksum tables.

I think I figured out the inline checksum thing. I'm traveling for work for a few days. I'll try to cook up a proof of concept when I get back.

[Lucasperks06]

been very busy but still watching

also never really got into the checksums side of things, mainly because ive never had too, but how do you know the locations of them and how many there are?
and what do you do with them when making changes to a file, all ive ever seen is automated checksum validation

[Lucasperks06]

just thought id post this up too, it was posted in another section, its a full read from this same os number that includes the boot too, not sure if you wanted to use this file or not

12628463 gm_bosch_med9.6.1_bench_fullbackup_ext_flash.bin

[Gatecrasher]

also never really got into the checksums side of things, mainly because ive never had too, but how do you know the locations of them and how many there are?
and what do you do with them when making changes to a file, all ive ever seen is automated checksum validation

Sorry to leave you hanging. Been busy with a lot of other stuff, and trying to sort this out a little better so I don't spread bad info. Hopefully kur4o and the others can keep me honest here since some of this stuff is new to me as well.

There's three kinds of checksums in play here. I can get into how they're actually calculated later. Right now I just want to give a summary.

The first one is the GM SPS checksum. That one is easy. It's the first two bytes of any calibration segment. It gets calculated based on a mathematical sum of all the following bytes in the calibration segment.

The second one is the Bosch checksums. They're harder, but not that hard once you know what to look for. There are blocks in the file that have a start address, an end address, a 32-bit sum (not a CRC!) and the 1s complement of that sum. If you change even one bit or byte, say, increasing a rev limiter, you need to update both the Bosch checksum and the GM checksum. If you only do one or the other, either the file won't flash to the ECU, or it won't run once it's flashed.

There's a really funky wrinkle to the Bosch checksums. Some of the blocks that have the checksums, are themselves included in the checksum calculations. Fortunately these are sums and not CRCs or other complex mathematical calculations. So they're actually pretty easy to fix. If my mathematically illiterate ass can figure it out, anyone can. More on that later.

The final bit is the CVN (calibration verification number). This is a CRC32 calculation over the entire calibration segment. This is mainly used for scan tool queries (OBD mode 9, pid 6), so dealers or emissions authorities can tell if the calibration has been tampered with. On my E92 ECM, it was also stored in flash, and the ECM would go into a fault if it wasn't updated. It looks like that's not the case with these Bosch ECMs. It's still valuable to have because it lets you know if your file read was clean or not. I went through a lot of trouble to reconstruct the OS calibration segment from Lucas's HPT dump, and I used the CVN to make sure my final file was accurate.

Getting back to the Bosch checksums. I asked Gemini to write a really crude python script to brute force a bin file and look for 4 bytes of data that are immediately followed by the 1s complement of that same data. The address of the complement is then written to a text file. This is very crude. There are false positives and there is no logic to validate any of it. The addresses are relative to the raw bin file and not the memory map of the running ECM. It does absolutely nothing to help you correct or verify them. Someone smarter and more motivated than me will need to write a proper tool. But this at least gives you an idea of where to start looking.

There's a huge chunk of OS checksum blocks at 0xa0000 that you can use as a starting example.

Code: Select all

        000a0000 00 02 00 14     undefined4 00020014h	<--block start
        000a0004 00 02 6d 2f     undefined4 00026D2Fh	<--block end
        000a0008 13 90 69 c8     undefined4 139069C8h	<--sum
        000a000c ec 6f 96 37     undefined4 EC6F9637h	<--complement
		
	000a0010 00 02 00 00     undefined4 00020000h	<--block start
        000a0014 00 02 7f ff     undefined4 00027FFFh	<--block end
        000a0018 17 8b cc 6b     undefined4 178BCC6Bh	<--sum
        000a001c e8 74 33 94     undefined4 E8743394h	<--complement

		Continue on until 0xa036f

Here's the python script. Usage is python sumscan.py input.bin addresses.txt

sumscan.py

In other news, I have found the first few chunks of the benchmode / GPT mode protocol in the boot block. Guess there was something interesting in there after all.

[hjtrbo]

In other news, I have found the first few chunks of the benchmode / GPT mode protocol in the boot block. Guess there was something interesting in there after all.

Great write up, fancy another one? What is bench/ GPT mode ? What are some things that can be done over & above in car flashing?

[Gatecrasher]

In other news, I have found the first few chunks of the benchmode / GPT mode protocol in the boot block. Guess there was something interesting in there after all.

Great write up, fancy another one? What is bench/ GPT mode ? What are some things that can be done over & above in car flashing?

Bosch supplier boot mode. Basically gives you full read and write access to everything. Flash, EEPROM, all of it. It's similar to the Continental SBOOT described here: https://github.com/bri3d/Simos18_SBOOT (GPT means general purpose timer)

I've seen a few threads on other forums saying Bosch has something very similar. It's usually locked behind pricey tuner tools like KTag or FLEX. I found the serial line protocol. Now I need to find the timer interfaces to figure out what signals need to be supplied. You feed a couple of special signals into the timer circuits to force the ECM into boot mode. It's like booting your PC into the BIOS setup.

This should be common to any Bosch ME9/MED9. It's manufacturer agnostic.

[antus]

I was looking at this for E69 and with minimal tweak it works for E77 as well.
It runs through more than once because some sums contain other sums. So it can iterate until they're all right.
This logic and routine can probably now be defined in univseral patcher.

Not sure if .md is a well used format yet, but it works well in repos and is a nice step up from txt without getting too complex. I'm using this tool to read them, would recommend. https://github.com/alecdotdev/Markpad


> python.exe .\e69_e77_checksum_tool.py .\E69_12622096_fixme.bin --fix
file: .\E69_12622096_fixme.bin (2097152 bytes)
[1] cksum_sum_halfwords signature @ file 0x20198 -> boot shift = 0x0 (file = addr-0x0, cal = addr-0x400000)

checksum records found & verified (66):
rec@file start end stored computed status
00001FF0 00000000 00001FFF 0792E2E8 0792E2E8 OK
0001FFC0 00010000 00013FFF 0B0CF429 0B0CF429 OK
<snip>
000A0320 001A8000 001AFFFF 1615E96C 1615E96C OK
000A0330 001B0000 001B3FFF 1A14B9C6 1A14B9C6 OK
000A0340 001B4000 001B7FFF 1FFFE000 1FFFE000 OK
000A0350 001B8000 001BFFFF 3FFCE425 3FFCE425 OK
000A0360 001F0000 001FFFFF 71C4DF03 7FFF8000 BAD (correct sum=7FFF8000 / ~=80007FFF)
001C3430 005C2FD0 005C342F 00963130 00963130 OK
001C3440 005C2000 005C21AF 009634CC 009634CC OK
001C3450 005C2FD0 005CFFFF 14225A16 14225A16 OK
001C3460 005D0000 005ECF27 A20F711E A20F711E OK
001ECF40 005ECF28 005EEF17 0D3A0000 0D3A0000 OK
001EEF30 005EEF18 005EFFFF 08400000 08400000 OK

66 record(s), 1 mismatch(es).

[fix] corrected 1 record(s):
rec@000A0360 -> sum=7FFF8000 ~sum=80007FFF

re-verify after fix (66):
rec@file start end stored computed status
00001FF0 00000000 00001FFF 0792E2E8 0792E2E8 OK
0001FFC0 00010000 00013FFF 0B0CF429 0B0CF429 OK
0001FFD0 00014000 00017FFF 096FBFAC 096FBFAC OK
0001FFE0 00018000 0001BFFF 093FDCF7 093FDCF7 OK
0001FFF0 0001C000 0001FFFF 10448F71 10448F71 OK
000A0000 00020014 000277EF 1566BE35 1566BE35 OK
<snip>
000A0350 001B8000 001BFFFF 3FFCE425 3FFCE425 OK
000A0360 001F0000 001FFFFF 7FFF8000 7FFF8000 OK
001C3430 005C2FD0 005C342F 00963130 00963130 OK
001C3440 005C2000 005C21AF 009634CC 009634CC OK
001C3450 005C2FD0 005CFFFF 14225A16 14225A16 OK
001C3460 005D0000 005ECF27 A20F711E A20F711E OK
001ECF40 005ECF28 005EEF17 0D3A0000 0D3A0000 OK
001EEF30 005EEF18 005EFFFF 08400000 08400000 OK

66 record(s), 0 mismatch(es).

wrote: .\E69_12622096_fixme_resum.bin (0 mismatch(es) remaining)

Edit: Updated the docs and the tool for another type of checksum, tool now at 1.1

[Lucasperks06]

thanks for getting back to me, and no stress on taking your time man its all good haha.
i think im understanding it alot better now, as a few days ago i knew absolutely nothing about checksums

so the gm checksums, there just the first 4 bytes of any calibration segment, so im assuming that this should have 3 checksums for each cal segment? or just the one at 1c2000 does the whole lot?
and they are calculated based off every single bit in the calibration? so once a single bit is changed, the calculation for that checksum is different, hence why it needs to be changed.
seems pretty simple.

these bosch checksums, im guessing there just a bigger style checksum, including a start, end, sum and complement, instead of the gm one which has 4 bytes
so each of those checksums are for each block its referencing, and im guessing that the start and end dont change when the file is changed, only the sum and complement.
and is the complement just whatever is needed to be added to the checksum to make the whole sum = ffffffff ?

also when you said "Some of the blocks that have the checksums, are themselves included in the checksum calculations", are you referring to the bosch checksums that are located in the calibration? if thats the case i can see how thats a bit of a pain, as when you adjust the bosch checksum youve now gotta adjust the gm checksum for that adjustment, but should all be doable

so i can see how locating these types of checksums are pretty easy if ive got it right, are these how all bosch checksums are setup. using a script is pretty smart i like that idea if thats how there all setup, saves alot of time.
only thing im not getting is when your saying the 1's complment the sum, should we be adding 1 to the sum so instead of ffffffff its 00000000?

im guessing thats what causes checksums errors too, if the calculation dosent = 00000000 then it knows somethings wrong.

so is the ecu calculating the sum of that particular block, and then double checking it against what the checksum sum says, and if its not what it should be then it wont start etc...

or

this might be stupid but thought id ask cause it makes some sense in my head, when you make adjusments to your file, for these bosch checksums, is the sum altered automatically based off the changes you made, and the complement stays the same, requiring you to adjust it as thats what causes the error. because if the sum and complement isnt changed, youll still get 00000000, so surely it has to automatically change the sum based on what you changed right? or am i way off hahaha

and this cvn checksum, is it just for seeing if the cal has been tampered with? is it necessary to update it?

but i think im understanding this alot better now

so realistically if all bosch checksums are setup like this all of them should be found relatively easily, especially with a script.

and antus i havent used that script yet ive still gotta get python on my computer and work it all out (i used to do a bit so shouldnt be too hard) but thats awesome thanks man, so does that locate checksums and validate them automatically?

and also i know we already figured this out but thought id post this too

Screenshot 2026-07-04 013451.png

[antus]

The sums were because kur4o was looking for a way to find a code signature that can be used in universal patcher to find the sums so support can be added. So now that can be done. The AI noted that having the bit inverted sum as well as the sum means a sum change cancels itself out for any additional sum over the top so it is possible to keep looping over the sums and fix all of them. This will only be needed for calibration changes or code patches which I assume is the end goal of this. I thimk bosch just like checksums, more so than delco/delphi. Then GM have their own segment sums, so they're in there to. Another company using the same PCM might not include those ones or have some of their own. Python is really useful for AI written tools, would recommend installing it. The AIs can use powershell or something else, but python is the go-to. If you install it and run that tool over your bins you'll see how it finds and calcs the sums. You dont need that right now but you will at the other end of this journey if you want to patch anything.

[kur4o]

Just a note how inclusive checksum can be calculated real easy.

Not 100% sure, since it was long time ago, but anyone interested can find it in Universal Patcher source code, since it is already covered.

What needs to be done is calculate sum skipping the checksum location, than add 1 to sum and write result.

After that it auto cancels it to zero and result matches.

Bosch crap also follows strict logic which is calculated first.

order will be segments bosch checksum, segment ACdelco checksum, than move to OS checksums, which are done 1 by one.

As a complete bosch crap I have seen bins that don`t have range defined only chks pairs, and range needs to be figured in code, usually a single chks buried at end of bin.