ECU images may contain several integrity checks over separate or overlapping regions. A check reduces a precisely defined sequence of bytes to a value and compares it, or a resulting residue, with an expectation. After a covered byte changes, correction calculates and stores the value expected for the modified data. The examples here are invented arithmetic, not ECU recipes.
Define the check
Establish each covered range and inclusive or exclusive endpoints, data order and unit size, calculation width, initial value, arithmetic and final transformation, check-field location and byte order, and whether the field is excluded, zeroed or included. Record exact software and whether addresses describe ECU memory, full image or partial file. A format may store a check and complement or check the residue over data and check together.
Different sequences can share a checksum. A pass confirms only the check performed; it does not prove correct software, calibration, signature or programming.
Additive sums and complements
An unsigned n-bit additive sum is S = (initial + sum of covered units) modulo 2n. Overflow wraps. A format may store S, its bitwise complement, its two's-complement negative or another transformation. It may sum 8-, 16- or 32-bit units; multi-byte unit byte order matters.
Worked 8-bit example: data bytes 10 20 30 in hexadecimal, initial value 00, sum to 60. If the stored check is the two's-complement negative, the check is A0: (60 + A0) modulo 100 = 00, where hexadecimal 100 is decimal 256. Change 20 to 25 and the data sum becomes 65; its recalculated check is 9B. The full sum remains 00 modulo 256. This example checks a zero residue including the check; real formats can differ.
Compensation: if a specifically documented, writable and semantically unused byte is inside that same additive region, change +05 can be mathematically offset by changing that byte by −05 modulo 256, leaving the original sum and check unchanged. For example 40 becomes 3B. This works because addition is modulo 256. Word boundaries, data use, other checks and flash behaviour can invalidate the approach. Blank-looking bytes are not proof a location is unused. A preserved checksum or CVN does not prove the data is unmodified.
CRC calculations
A cyclic redundancy check uses polynomial arithmetic over GF(2), where addition is XOR. Its remainder depends on the message and parameters. CRCs detect many error patterns that simple sums miss, but are not cryptographic authentication. Record polynomial, width, initial register, input and output reflection, final XOR and exact bytes and ordering. Stored byte order is a separate choice. Reflected code may use a reversed polynomial representation.
Algorithm test: CRC-32/ISO-HDLC uses width 32, polynomial 0x04C11DB7, initial 0xFFFFFFFF, reflected input and output, and final XOR 0xFFFFFFFF. On ASCII 123456789 the check is 0xCBF43926. This tests that implementation and parameters; it does not establish an ECU uses them. CRC RevEng catalogue.
Correction normally recalculates the specified CRC over final covered bytes and encodes it as the format requires. CRCs are linear or affine under their parameters, so constructed changes can yield a chosen residue in some layouts; there is no universal safe compensating byte.
Multiple checks and dependencies
A file may have block checks, checks covering a table containing other check values, and compatibility information between program and calibration. If B covers A's stored field, calculate and store A first, then B. Draw actual dependencies; nested checks may need a format-specific procedure. EVC describes a compatibility-test structure for some Bosch EDC16/17 systems; that does not establish identical behaviour in every variant. EVC compatibility-test FAQ.
Checksum, hash and signature
A checksum or CRC primarily detects accidental changes. A cryptographic hash identifies a particular backup or file, but an unkeyed hash alone does not authenticate its source. A digital signature can authenticate the signer and detect modification under its verification scheme. Recalculating a checksum or hash does not generate a valid signature for altered signed content; signing requires the appropriate authorised signing capability. NIST Digital Signature Standard.
Correction in practice
- Preserve the original read; identify its exact software, memory coverage and format. Validate the original and investigate failures.
- Edit a copy and keep a byte comparison. Use a checker or correction module explicitly supporting the controller, software and read format; establish which checks the writer handles.
- Correct after dependent edits, in the documented order. Independently verify all supported blocks where possible.
- Compare corrected output with edited input; changes should be explained by documented checksum, complement or supported metadata fields. Save versions, reports, hashes and writer output or log.
Automatic correction depends on tool and module: EVC describes WinOLS checksum plug-ins. A success message does not establish coverage of every integrity or authentication layer.
Related pages
Identification and workflow · Bosch ME7 · Siemens MS43 · MSS54 partial files.
Technical principles and invented arithmetic are editorial explanations and do not assert hardware testing. Sources linked above; checked 10 November 2026.