Intel HEX & S-record Image Audit

Seven errors in one Intel HEX image, and the build that produced it reported success. It was fourteen lines of Intel HEX from an ARM build folder — the sort of file an embedded engineer hands to a flash programmer without opening it. A record-level audit returned eighteen findings, seven of them the kind a programmer refuses outright: a record ending in 0x2A where the recomputed two's-complement checksum is 0xE8, a byte-count field claiming sixteen data bytes over a record that carries fifteen, a generator comment left in the middle of the image, a second record writing address 0x08000108 that line seven had already written, a record starting at 0xFFF8 and running sixteen bytes past 0xFFFF with no type 04 record to raise the base, an undefined record type 0x07, and sixteen bytes appended after the end-of-file record where no conforming loader will ever read them.

None of it is exotic; it is happens to a .hex file between the linker and the bench. Images get merged with a bootloader. A calibration constant gets patched by hand or by a script at the last minute. A build step regenerates part of the file and appends the rest. Every one of those can leave a record whose checksum belonged to the bytes that used to be there, and the format does nothing to stop it: Intel HEX is a text file, and an editor will happily save a record that no longer adds up.

The checksum is one byte at the end of each record, the two's complement of the sum of every byte before it. Verifying it is a loop and an addition. It goes unverified not because it is hard but because nothing in the normal path does it. A hex viewer renders records. A diff shows the lines changed. A chatbot asked to patch a record will confidently return one, and it cannot check a checksum over bytes it never sees. The programmer at the flashing station does check — the wrong moment, because by then the build is signed off and the boards are in the fixture.

Motorola S-records have the same problem with a different formula: the checksum is 0xFF minus the sum of the count, address and data bytes, and the count byte itself has to cover address plus data plus checksum. An S5 or S6 record declares how many data records the file holds. When a file has been cut, merged or filtered after it was built, that tally stops matching — the cheapest proof there is that something touched the image after the toolchain did.

Then there is the part no per-record check can see: the address map. Map every absolute byte the image writes, honouring type 02 and type 04 extended-address records, and three classes of defect fall out. Overlaps, where two records claim the same absolute address and the flashed value depends on the load order of whichever tool reads the file. Gaps, where a section the linker placed never made it into the image and those cells keep whatever was in flash before. And blocks that do not fill whole flash pages, which on page-programmed parts forces a read-modify-write or erases the rest of the page.

Intel HEX & S-record Image Audit runs sixteen such checks over a single file and puts each finding on its line. The clean sample image shipped with it produces none; the patched one produces eighteen. It reads .hex, .ihex, .s19, .s28, .s37, .srec and .mot, in the editor or in a browser tab, and auditing one image is free and complete — no key, nothing truncated. Embedded firmware contract work is commonly billed at $90 to $150 an hour, the honest yardstick for an hour spent adding up records by hand.

Free in your browser, same sixteen rules: https://getreadystack.com/tools/hex-image-audit