The Generic Checksum plugin

Tuning Editor ships with the Generic Checksum plugin: a checksum/detection plugin you configure from a JSON file rather than code. Point it at your ECU and it verifies and corrects the integrity checksums the ECU expects — covering firmware the built-in plugins do not. This page explains the algorithms it offers, how it decides pass or fail, how it repairs a value, and how to set it all up in the configuration dialog.

Choosing a checksum algorithm

A checksum reduces a block of bytes to a small number. The plugin offers five families; the right one is simply whatever your ECU already uses, but it helps to know what each is for.

Sum — adds up the bytes (or words) of a region. The simplest check: fast and common in older or low-cost ECUs, but weak, since changes that cancel out can slip past it. Options let you sum byte-by-byte or as 8/16/32-bit words, choose byte order, and (for the sum-to-zero pattern) return the two’s-complement so the region totals zero.
XOR — exclusive-ORs the bytes or words together: a parity-style check, even simpler than a sum and weaker still, but occasionally what a format uses.
CRC — a cyclic redundancy check (polynomial division). This is the workhorse for firmware: it reliably catches the kinds of multi-bit and burst errors a sum misses. A CRC is defined by its width (8/16/32), polynomial, initial value, input/output reflection and a final XOR-out — and because those vary between standards, the plugin ships named presets (below).
Fletcher (16/32) — keeps two running sums, so unlike a plain sum it is sensitive to the order of the data. A good middle ground: stronger than a sum, cheaper than a CRC.
Adler-32 — the variant of Fletcher used by zlib. A fast 32-bit checksum; always 32-bit.

The built-in presets

Rather than entering CRC parameters by hand, pick a preset from the dialog. Twelve are built in: CRC-8, CRC-16/CCITT-FALSE, CRC-16/XMODEM, CRC-16/MODBUS, CRC-16/ARC, CRC-32, CRC-32/BZIP2, CRC-32C, Adler-32, Fletcher-16, Fletcher-32 and Sum-32. Choosing one fills in every parameter; choose (custom) to set them yourself. CRC-32 and the CRC-16 variants cover most ECUs.

How a value is checked: verify modes

Once a value is computed over the region, the plugin decides pass or fail in one of three ways:

Equals stored — compare the computed value to the value read from a store location (a footer or a checksum-table slot). The everyday case.
Equals constant — the computed value must equal a fixed target (for example a CRC residue of zero). Used by self-checking schemes.
Sums to zero — the region, read as words, must total zero; a filler word elsewhere in the block makes it balance.

How a value is fixed: correction modes

When you export a corrected binary, the plugin repairs the checksum in one of three ways, matched to the verify mode:

Write value — write the freshly computed value into the store slot. Use this whenever the checksum is simply stored somewhere.
Compensation — adjust a dedicated compensation word so the block reaches its target (Sum/XOR only, paired with sums to zero). It works word-wise with the sum width equal to the compensation-word width.
Solve CRC patch — GF(2)-solve a patch word inside the region so the CRC lands on a fixed residue (CRC only). The patch word must lie inside a region.

Note — if the checksum’s own bytes fall inside the region it covers, leave Exclude store bytes from region on (the default) so those bytes are treated as zero while computing. If the checksum sits outside the region, it makes no difference.

Profiles and detection

The config is a list of profiles. Each has match rules — a file-size range, magic bytes at an offset, and a section function-name filter. The first profile whose rules fit a file wins, and its name becomes the detected identity shown in the checksum view. Because a user-defined profile has no notion of “stock”, the originality verdict is reported as unknown.

The configuration dialog

On Windows, select Generic Checksum (configurable) in Help › Installed Plugins and click Configure…. A native editor opens on your config.json. Its built-in Help button lays the work out in four steps — Profile, Mapping, Definitions, Save — and every field has a hover tooltip.

1. Profile

Use the Profile picker to select, create (New), rename or Delete a profile. The Match group sets when it applies: Size min / Size max (0x0 means “any”), a Function filter, and a Magic — the offset and the fixed bytes (hex) that must appear there. A magic is the most reliable matcher; add a size range as a second guard and avoid matching everything.

2. Mapping (optional)

If your regions and store use memory addresses rather than file offsets, fill in the first mapping segment: a Base address, the FileOff it maps to, and the Size. Left empty, the plugin works in file-offset mode (address equals offset).

3. Definitions

The Definitions table lists the checksums in the profile, with Add, Edit, Remove and Up / Down (ordering only). Edit opens the Checksum definition editor, where you set:

Name — the label shown in the checksum view.
Algorithm (Sum / Xor / CRC / Fletcher / Adler-32) and a Preset (the twelve above, or custom), plus Width.
For CRC: Poly, Init, XorOut and the RefIn / RefOut reflection switches. For Sum/XOR: Word-wise, Big-endian and (Sum) 2’s compl.
Region — the start and length the checksum covers.
Store — the offset, size in bits and byte order of the value read for verification and written for store-value correction.
Verify (Equals stored / Equals constant / Sums to zero) and, for a constant, its target.
Correct (Write value / Compensation / Solve CRC patch) and the Comp word where one is used.
Exclude store bytes from region and Enabled (untick to keep a definition but skip it).

4. Save

Validate checks the document (the status line shows “Configuration is valid.” or the error), and Save writes it — after which the host re-analyses affected files. For patterns the form keeps simple (several magics or regions, extra mapping segments), Edit JSON… opens the raw document; anything you add there is preserved, not discarded. Import…, Export… and Open Folder round out the buttons. The file lives at %USERPROFILE%\Documents\TuningEditor\PluginSettings\generic-checksum\config.json, and the TE_GENERIC_CHECKSUM_CONFIG environment variable can point the plugin at a specific file.

Finding the right settings

Working out an unknown checksum is a process of elimination, and the dialog is built to help:

Start from the closest starter profile and change values, not structure. The verify/correct pairing is the easy part to get subtly wrong, so reuse a known-good shape.
Read the file for what you can. The size is direct; the store is usually the end of a block or a known table; the region is the span the checksum covers.
Use the read-only analysis. The checksum view shows the computed value next to the stored one. When a preset’s computed value matches what is stored, you have found the algorithm and the region. Change one variable at a time.

Warning — confirm a definition reports the right computed/stored values with the read-only analysis before you correct anything, and keep a backup. Correction rewrites bytes.

Starter profiles

The plugin ships five ready-to-read example profiles, one per common pattern — load them with Import… and adapt:

CRC-32 footer — a standard CRC-32 over everything but the last four bytes, stored there big-endian (verify stored, correct write-value). Start here for “one CRC over the whole image.”
16-bit byte sum — every byte summed, truncated to 16 bits, stored at the end. A template for simple sum/xor blocks.
Checksum complement (sum to zero) — 32-bit word-wise sum over a block that must total zero via one compensation word (verify sums-to-zero, correct compensation).
Self-checking CRC — instead of storing the CRC, a patch word inside the region is solved so the residue equals a constant (verify constant, correct solve-CRC-patch).
Memory-address mapping — the CRC-32 footer written with CPU addresses and a mapping segment, for tooling that thinks in addresses.

Configuration reference (advanced)

config.json is a list of profiles. Wide integers are hex strings, enums are lowercase, widths are plain numbers. A minimal profile:

{ "schemaVersion": 1, "profiles": [ { "name": "My ECU", "match": { "sizeMin": "0x100000", "magics": [ { "offset": "0x0", "text": "VENDORTAG" } ] }, "mapping": [ { "baseAddr": "0x80000000", "fileOff": "0x0", "size": "0x200000" } ], "defs": [ { "name": "Flash CRC", "algo": { "kind": "crc", "width": 32, "poly": "0x04C11DB7", "init": "0xFFFFFFFF", "refIn": true, "refOut": true, "xorOut": "0xFFFFFFFF" }, "regions": [ { "mode": "memory", "start": "0x80080000", "length": "0x40000" } ], "store": { "mode": "memory", "offset": "0x800C0000", "width": 32 }, "verify": "stored", "correct": "store" } ] } ] }

match — sizeMin/sizeMax (inclusive, 0x0 = no bound), magics (all must match), functionFilter (case-insensitive substring).
mapping — { baseAddr, fileOff, size } segments; empty = file-offset mode. Needed when regions use "mode": "memory".
defs[].algo — kind (sum / xor / crc / fletcher / adler32) and width; CRC adds poly/init/refIn/refOut/xorOut; Sum/XOR add wordWise / bigEndian (Sum also twosComplement).
defs[].regions — one or more { mode, start, length } (mode file or memory).
defs[].store — { mode, offset, width, bigEndian }.
defs[].verify — stored / constant (with constantTarget) / sumzero; correct — store / compensation / crcsolve, with a compensation word where used.
defs[].excludeStoreFromRegion (default true) and enabled.

Scope & limits

This plugin handles standard integrity checksums and their correction. Each reported checksum covers one contiguous span (a definition may list several regions, computed over their concatenation, but reported as a single span). Developers can build their own checksum plugin from the same open-source example — see build your own checksum plugin.