What the 64-byte legacy header contains
The classic U-Boot image header stores a big-endian magic number, header CRC32, Unix timestamp, payload size, load address, entry point, data CRC32, operating-system ID, architecture ID, image type, compression ID, and a 32-byte image name. ToolQuill calculates the header CRC with its checksum field zeroed, then separately checks the CRC over exactly the declared payload.
How multi-file images are divided
A legacy multi-file payload begins with big-endian 32-bit component sizes and a zero terminator. Component data follows that table. Each component except the last is padded to a 4-byte boundary. The inspector validates the table and every component boundary before enabling individual extraction; padding is never included in an extracted component.
What extraction preserves—and what it cannot
The complete-payload download preserves compression and any internal multi-file table exactly. Component downloads remove the table and alignment padding but do not decompress the component. The header's load and entry fields are metadata, not proof that those addresses are correct for a board, boot flow, image type, or decompressed size.
Boot-image safety boundary
CRC32 detects accidental corruption; it does not authenticate firmware. A checksum-valid image may still be malicious, incompatible, incorrectly addressed, or unsafe to boot. This tool does not parse FIT images, verify signatures, decompress content, identify a board, validate executable instructions, emulate U-Boot, or establish that an image is complete, trusted, bootable, or safe to flash. Preserve the original and follow the device vendor's recovery process.
Frequently asked questions
Is this the same as a modern U-Boot FIT image?
No. FIT images use a flattened-device-tree structure and can describe multiple configurations, hashes, and signatures. This page intentionally handles only the classic 64-byte legacy header and clearly rejects FIT magic.
Why can the CRC pass while the firmware is untrusted?
CRC32 is not a cryptographic signature. Anyone who changes the payload can calculate a new matching CRC. Use a verified vendor signature or trusted release process for authenticity.
Are trailing bytes part of the payload CRC?
No. The data CRC covers exactly the number of bytes declared in the header. Extra bytes are reported and excluded from preview and extraction rather than silently treated as firmware content.
Will component extraction decompress gzip, LZMA, or another format?
No. The compression ID is reported, but downloads preserve the exact stored component bytes. Use a trusted decompressor after verifying the expected format.
Format reference: U-Boot include/image.h.
Inspect UF2 firmware · Compare decoded firmware maps · Browse electronics tools