Firmware is the software that runs a device, such as a hardware wallet. Its build is reproducible when the same source code, specified environment and instructions produce exactly matching, predefined files. The program merely behaving the same way is not enough. The check compares the data itself; signed releases also need clear rules for handling the signature.
A manufacturer can publish code for programmers to read. What you usually install on the wallet, however, is a finished machine-readable file, often called a binary. Building the software is the step between those two forms. Someone independent can repeat that step and compare the result with the release. The check looks for identical bytes, the individual units of data, often using a cryptographic hash: a fingerprint calculated from the contents. It covers specified outputs, such as the firmware file, not automatically every temporary file and log. [1] [4]
Imagine two developers trying to verify one update. Knowing the project name is not enough: they need the same commit, meaning an exact revision of the code. They also need the versions of the supporting libraries and the compiler, the tool that turns code into machine form. Its options, relevant environment settings and the wallet model are part of the procedure too. These details must be specified beforehand or recorded during the build. Otherwise both people can work honestly and still produce different results. [1] [2]
A difference does not necessarily mean someone changed what the program does. A compiler may include the path of its working folder in information used to investigate errors. If the developers keep their projects in different places, their files may differ. A prescribed path or a supported way of making paths consistent can resolve this. The rule must be a known part of the build procedure. Deleting unexplained differences after a failed check just to obtain a match defeats the purpose. [3]
A digital signature lets you check that a file matches a signature made with the corresponding key. Associating that key with the manufacturer is another part of the trust involved. A reproducible build asks a different question: does the file correspond to the specified source code? The two checks complement each other. An official update may contain signature data that a local build lacks. Comparing whole files without understanding their format can therefore produce a mismatch even when the program was built correctly. [5]
Trezor documentation describes choosing a version and model, building the firmware and comparing it with the official file. Because the local result is not signed like the manufacturer’s release, the procedure first zeroes precisely specified signature fields. Older formats also differ in their headers, the opening parts of files containing information about them. The layout depends on model and version, so instructions for one device cannot simply be applied to another. The original signature is checked separately; comparing adjusted copies does not replace that check. [5]
First establish whether the comparison used the same revision, model and firmware variant. Then check the tools, libraries and prescribed file transformations. Keep both the original files and the record of the difference. The cause might be an environment or instruction error, or a change to the distributed program. A mismatch alone identifies neither a culprit nor a cause. Until the difference is explained and the check repeated, the build should not be described as verified. [1] [4]
If the published code already contains a flaw, every rebuild may faithfully preserve it. A shared untrusted compiler could also insert the same malicious change into all results; using it again is not the same as independently checking the tool. Closed binary components limit what can be rebuilt from available code. And a matching file on a computer does not establish whether a particular wallet is genuine or actually runs that firmware. Checking a file’s origin is an important part of security, not complete proof of it. [6] [1]
A “verified” report becomes useful when you can identify who ran the check, which revision they built, for which model and with which procedure. It should state the files compared, hash function, results and exact treatment of signature data. Other people can then inspect or repeat the work. More independent builders reduce reliance on a single distributor. Review of the code, update process and device itself is still needed. [2] [4]
Two matching results and one different hash
Two developers build firmware from the same revision for the same model in the same environment. Their files have matching SHA-256 fingerprints, but the official signed version has a different one. If the documentation precisely defines the signature fields, they apply the prescribed transformation to copies and compare again. A match then covers that defined content. The original signature still needs its own verification; other unexplained differences must not simply be removed.
For the clearest picture, read this entry together with Hardware Wallet, Private Key, Cold Storage, Secure Element. The reverse links also lead from COLDCARD RNG Incident (2026).
01Do I need to build the firmware myself as a user?+
You do not need to be a programmer to understand a verification result. Check that the independent report identifies the specific version, model and files compared. A matching hash alone does not prove an absence of flaws: the same malicious code or compiler can produce matching files. Reviewing the code and deciding whether to trust the device remain separate questions.
02Does a different hash for a signed update mean an attack?+
Not automatically. The file may contain different signature data or headers that the verification procedure already accounts for. Check the version, model and exact instructions. An unexplained difference is not a successful verification, however, and must not be bypassed by arbitrarily deleting data.