Intel HEX & S-record Image Audit

A firmware image is the one artefact in the build that nobody re-reads. It gets merged with a bootloader, hand-patched at the last minute, regenerated by a script or an AI-written patch, mailed to a contract manufacturer — and every one of those steps can leave behind a record whose checksum no longer matches its own bytes. The programmer at the flashing station is where you find out.
This extension recomputes them. Open any .hex, .ihex, .s19, .s28, .s37, .srec or .mot file and it runs 16 checks across the image, writing every finding into the Problems panel at the exact line.
What it checks
Record integrity — the two's-complement checksum of every Intel HEX record and the 0xFF-minus-sum checksum of every Motorola S-record, both recomputed byte by byte from the record itself; the byte-count field against the data bytes actually present; records that are not a whole number of hex bytes; record types outside 00–05; S-record count bytes that no longer cover address + data + checksum.
Structure — a missing or malformed :00000001FF end-of-file record; data records appended after the EOF record, which conforming loaders never read; a missing S7/S8/S9 termination record; an S5/S6 tally that no longer matches the number of data records in the file; lines that are neither a record nor blank, such as a merge marker or a generator comment.
Address space — every absolute address the image writes is mapped, honouring type 02 and type 04 extended-address records. From that map it reports overlapping records (two records writing the same absolute byte, where the flashed value depends on the load order of the tool), unwritten gaps between blocks, data records that run past 0xFFFF with no extended-address record in effect, blocks that do not fill whole flash pages, and an entry point (03, 05, S7/S8/S9) that lands outside anything the image writes.
Example output
ERROR L3 record_checksum the record ends in 0x2A but the recomputed
two's-complement checksum is 0xE8
ERROR L4 record_length the byte-count field says 16 but the record
carries 15 data bytes
ERROR L9 address_overlap address 0x08000108 is already written by the
record on line 7
ERROR L10 extended_address the record starts at 0xFFF8 and runs 16 bytes
past 0xFFFF
ERROR L14 data_after_eof this record sits after the end-of-file record
on line 13
WARN L12 start_address the entry point 0x00000200 is not inside any
address range this image writes
The 14-line sample image shipped with this extension (_fixtures/dirty.hex) produces 18 findings, 7 of them errors. The clean sample produces none.
Free and licensed
Auditing one image is free and complete — all 16 checks, no key, nothing truncated, in the editor or in the browser. The licence covers a different job: auditing every image in a build output folder in one pass and exporting a dated Markdown audit report you keep as release evidence. Since 11 September 2026 the EU Cyber Resilience Act's reporting obligations for products with digital elements are in force, and a dated, per-image audit record is the kind of thing a technical documentation file is made of.
$29 once, one licence key per person or team seat, 7-day full refund.
Yardstick: embedded firmware contract work is commonly billed at $90–$150 an hour — one hour of it costs more than this licence.
Free in your browser, running the same 16 rules: https://getreadystack.com/tools/hex-image-audit
Commands
- Audit this image — runs all 16 checks on the active file (free).
- Audit the build folder — every matching image in the workspace, one dated Markdown report (licence).
Intel HEX record types 00, 01, 02, 03, 04 and 05 are all understood. S-record types S0, S1, S2, S3, S5, S6, S7, S8 and S9 are all understood, including 16-, 24- and 32-bit address fields. The page size used by the alignment check defaults to 256 bytes.