What the MCUboot image header contains
The 32-byte v2 header stores the little-endian magic, load address, complete header size, protected-TLV size, application payload size, flags, semantic version fields, and a reserved word. The payload starts at the declared header size, so any header padding remains part of the hash region rather than application data.
How protected and unprotected TLVs differ
Metadata follows the payload as type-length-value areas. Protected TLVs—such as security counters, dependencies, and measured-boot records—are included in the image hash. The following unprotected area commonly carries the image hash, key identifier, public key, and signature. This inspector checks every declared boundary and retains unknown or vendor-reserved types without guessing their meaning.
What a matching image hash proves
A matching SHA digest establishes that the parsed hash-region bytes correspond to the stored digest. It does not identify who produced the firmware. Signature verification additionally requires the correct trusted key, algorithm configuration, target policy, and—in some modes—decryption. Signature TLVs are therefore inventoried but deliberately not labelled valid.
Firmware safety boundary
This is a read-only format inspector, not a secure-boot verdict. It does not decrypt content, verify signatures or certificate trust, decompress payloads, evaluate rollback policy, inspect MCU instructions, identify a board, emulate MCUboot, parse an entire flash slot without known geometry, or establish compatibility, bootability, authenticity, or flashing safety. Preserve the original image and use the target project's trusted keys and recovery procedure.
Frequently asked questions
Why is an encrypted image hash not compared?
MCUboot validates encrypted images by decrypting blocks before hashing them. Without the correct decryption key, a browser can inspect stored structure and metadata but cannot compare ciphertext with a plaintext image hash meaningfully.
Does “signature TLV present” mean the firmware is signed correctly?
No. It only means signature-shaped metadata exists. Verification requires the intended trusted public key and the exact MCUboot configuration; this page never substitutes presence for cryptographic validation.
What are the bytes after the TLV manifest?
They may be erased slot padding or an MCUboot swap/direct-XIP trailer. Correct interpretation depends on slot size, write alignment, maximum sectors, erased value, and upgrade mode, none of which can be inferred safely from a standalone file.
Can I extract a compressed application?
Yes, as exact stored payload bytes. The download remains compressed or encrypted as declared; no transformation or relocation is applied.
Format references: MCUboot design documentation and bootutil/image.h.
Inspect a legacy U-Boot uImage · Inspect UF2 firmware · Compare firmware memory maps