The Siemens MSS54 used in BMW M applications is a useful example because its documented 32 KiB partial contains two separate protected segments. The description here follows the MSS54-XDFs checksum helper documentation and its implementation, at commit dd845dd. It describes that project's partial-file convention; identify the ECU, file and tool before applying it.
What is actually checked?
| Segment in 32 KiB partial | Data included, offsets inclusive | Stored CRC | Following suffix |
|---|---|---|---|
| Slave | 0x0000–0x3FFB | 0x3FFC–0x3FFD | 0x3FFE–0x3FFF |
| Master | 0x4000–0x7FFB | 0x7FFC–0x7FFD | 0x7FFE–0x7FFF |
Each data range is 0x3FFC, or 16,380 bytes. The source identifies slave-first and master-second ordering; its extraction convention and conversion from a full read are documented in MSS54 partial files and checksums. The tool expects a 32,768-byte MSS54 partial; its separate MSS54HP handling uses a different layout. A full 512 KiB dump is not accepted by the helper. Do not transplant these offsets into other file layouts.
Algorithm and stored byte order
For each MSS54 segment, prepend the single byte F0 to the segment's 16,380 data bytes, then calculate the reflected 16-bit CRC in the linked implementation: initial register 0000, reflected polynomial A001, final XOR 0000. The stored two-byte result is big-endian: the high byte comes first. Although the project calls this CRC-16/MODBUS, its specified initial value is 0000, so do not blindly choose a standard MODBUS preset that starts at FFFF. Reproduce the exact parameters and prefix.
For each input byte, XOR it into the low end of the register. Repeat eight times: shift right one bit and, if the bit shifted out was 1, XOR the register with A001. Process F0 first, then the entire segment in file order. The source excludes the stored CRC and suffix from the 16,380-byte calculation.
A repeatable calculation
The following is a synthetic test segment, not an ECU dump or calibration: set offset 0x0000 to 02 and every other byte through 0x3FFB to 00. Run the stated calculation over F0 followed by those 16,380 bytes. The result is EBFE, which would be stored as bytes EB FE at 0x3FFC–0x3FFD in this example.
Now change the byte at partial offset 0x0100 from 00 to 01. Recalculate the same entire range: the result is 4C7F. If the format and all other integrity requirements have been established, ordinary checksum correction replaces the stored two-byte result with 4C 7F. The changed data did not need to be undone: the stored value was updated to describe the new data. Recalculate again and compare calculated 4C7F with stored 4C7F. This illustrates the documented algorithm; these invented bytes are not a working vehicle image.
Recalculation versus compensation
Recalculation leaves the calibration edit in place and updates the stored CRC. The project also documents a compensation approach: add another carefully chosen change inside the same CRC-covered segment so the resulting CRC equals the original. This is possible because a 16-bit CRC maps a much larger set of possible messages to only 65,536 values. The project's candidate search tests changes and calculates the CRC until a suitable value is found. A CRC match is a collision, not a reversal of the calibration edit.
Only use a location shown to be available for the exact image and purpose. A run of zeroes can be code, data, reserved space or subject to another check; its appearance alone is not evidence it is safe. A compensation that restores one CRC does not demonstrate that other checks, signatures, calibration identifiers or diagnostic values also match. The project's reported CVN result is an empirical example and its explanation is explicitly a hypothesis, not a general rule.
Checking a real file
- Keep the original read and confirm the helper's partial layout, ECU identity, file size and slave/master ordering.
- Use its inspection mode on the original; investigate any mismatch before editing. Preserve the original report.
- Edit a copy, then use the helper's documented
--fix-checksumsoperation to calculate stored checks for the modified file, with a separate output. Check the output again and compare changed bytes with the edit. - Verify any other applicable checks and programming requirements using documentation for the ECU and writer. Record input and output hashes and tool version.
The algorithm and layout are attributed to the cited project. The synthetic calculation was independently evaluated for this article; ECU operation and programming were not tested.