openremap checksum

Detect which checksum schemes an ECU binary satisfies — and whether the known family schemes are OK or STALE. Detection only; the command never corrects anything.

New here? Read the plain-English introduction first.

It is the same detection you can call from Python code or JSON-RPC.

Usage

openremap checksum <FILE> [OPTIONS]

Options

Example

openremap checksum ecu.bin
openremap checksum ecu.bin --json

What the output looks like

The command prints a header line (file name, size, how many known family schemes matched and how many generic sweep matches were found), then one block per matched family scheme. Generic matches are listed at the end when any exist.

  OpenRemap — Checksum Detection
  ecu.bin  •  1,048,576 bytes  •  <n> known family scheme(s)  •  <m> generic match(es)

  Bosch ME7 main checksum: OK   (stored E090F65E, expected E090F65E)
  Bosch ME7 multipoint: 18 block(s) verify, 8 bootrom descriptor(s) not verifiable
  Bosch ME7 rolling: 3/3 slot(s) verify

  IronFelix family profiles
  ──────────────────────────────────────────────────────────────────────────────
  VAG Bosch ME7.XX (subtype 6)       3/3 checks ok   multipoint 18 ok / 49 unverifiable

(Angled <n>/<m> counts depend on your file; the lines above use values from an example run.)

How detection works

Two layers:

1. Sweep — a closed config space (11 algorithm families × init values × final XOR × regions × store locations × direct/complement forms) at native speed. A per-page scheme matching ≥ 90% of non-erased pages is a strong signal; a single whole-file match is weak evidence.
2. Known family schemes — Bosch ME7 (main + multipoint + rolling + multirange) and the IronFelix family profiles (VAG ME7.XX subtypes, M3.x, Hyundai/China M7.9.x, Citroen ME7.4.5, Sagem), plus the Siemens GS20/SMG2 TCU profiles — ported from the open-source community projects ME7Sum, IronFelix, NefMoto and the MS4X wiki.

Most freely-downloaded dumps carry stale or stripped checksums and yield no matches. OK/STALE verdicts on the family profiles are the trustworthy signal.

ME7 firmware may use three different checksum types on top of the main sum (some files use all of them):

The rolling/multirange structures are located by pattern-matching the C166 machine code inside the firmware itself (NefMoto port), so they work across firmware variants without a family database.

subtype is the IronFelix ME7.XX sub-classification (1/2/3/5/6); different subtypes use different CRC-32/sum8 zone layouts. Every family check is reported as ok, stale (stored value differs from the recomputed one), or absent (structure missing in this file).

Family profiles

The vag_me7xx and me3x profiles are validated against the real corpus in tests/data/ECUs/ (ME7.1: 116/137 files fully OK; M3.8: 18/20); gs20 is validated on the real GS20 factory + tuned pairs; the others are validated on synthetic fixtures (no corpus files yet).

GS20 corpus quirk: one "corrected" tuned file in the corpus is STALE — its author wrote the CRC value byte-swapped (0x190B as 19 0B instead of LE 0B 19). The detector correctly reports it as stale; trust the factory file (OK) and the plain modified files (stale as expected).

JSON output

With --json the full report is printed as JSON. The top-level fields are file, file_size, schemes (the generic sweep matches), and one per-family field: me7_main, me7_multipoint, me7_rolling, me7_multirange, ms43, denso, ironfelix (each null or absent when the scheme does not apply to this file).

Sources

The family schemes are community knowledge, ported from open-source projects. Attribution:

Related commands