How a FIT packages boot components
A U-Boot FIT is a flattened device tree with an /images node for stored components and a /configurations node that names combinations to boot. Components may be embedded in a data property or stored after the FDT blob through data-offset or data-position. ToolQuill validates block offsets, token nesting, strings, property bounds, image data ranges, and configuration references before extraction.
What the hash results mean
The inspector compares CRC32 and SHA-1/256/384/512 values over the exact stored bytes of each resolvable component. An unsupported algorithm remains visible but unchecked. A successful hash detects a byte mismatch against the value inside the same FIT; it does not stop an attacker from replacing both the component and its hash.
Why signatures are not marked valid
FIT verified boot relies on a public key held outside the image, normally in U-Boot's trusted control device tree. A signature and key-name hint inside the FIT cannot establish their own trust. Configuration signatures also cover selected nodes and strings, not merely one binary blob, so this page inventories signature nodes without pretending that presence equals verification.
Boot-image safety boundary
This is a read-only container inspector, not a verified-boot decision. It does not verify signatures, import trusted keys, decompress components, apply FDT overlays, evaluate target U-Boot policy, emulate a board, inspect executable instructions, or establish authenticity, compatibility, bootability, rollback protection, or flashing safety. Preserve the original image and use the target vendor's trusted keys, bootloader configuration, and recovery process.
Frequently asked questions
Is FIT the same as a legacy uImage?
No. FIT uses the flattened-device-tree container with named components and configurations. The legacy format uses one fixed 64-byte header and CRC32 fields; ToolQuill provides a separate inspector for it.
Why are MD5 or an unfamiliar hash shown as unsupported?
The tool only reports a match for algorithms it implements unambiguously. Unknown, legacy, or vendor-specific algorithms stay visible rather than being guessed or silently treated as valid.
Can external component data be inspected?
Yes when the supplied file includes the bytes at the declared offset or position and the range fits inside the file. A detached image store or memory address that is not present cannot be reconstructed.
Does extraction decompress gzip, LZMA, LZ4, or Zstandard?
No. The compression property is reported, while extraction preserves the exact stored bytes for deliberate downstream handling.
Format references: U-Boot FIT format and FIT signature verification.
Inspect a legacy U-Boot uImage · Inspect an MCUboot image · Compare firmware memory maps