固件是控制设备运行的软件，Hardware Wallet 也需要固件。如果相同的源代码、规定的环境和操作步骤能够生成事先指定且完全一致的文件，就称为可复现构建。程序表现相同还不够，检查的是数据本身。对于带签名的发布文件，还必须明确如何处理签名部分。
厂商可以公开供程序员阅读的代码，但通常安装到钱包里的是已经转换为机器形式的文件，也叫二进制文件。构建就是连接这两种形式的过程。独立验证者可以重复构建，将结果与厂商发布的文件比较。检查要求字节一致；字节是数据的基本存储单位。通常会使用密码学哈希，即根据内容计算出的指纹。这个结论针对事先指定的输出，例如固件文件，并不自动包括所有工作文件和日志。 [1] [4]
假设两位开发者要验证同一次更新。只知道项目名称不够，还要使用同一个 commit，也就是准确指定的代码修订版本。他们还需要知道所用库和编译器的版本；编译器负责把代码转换为机器形式。编译选项、相关环境设置以及钱包型号也是操作步骤的一部分。这些信息应当提前规定，或在构建过程中记录。否则，两个人都认真操作，仍可能得到不同的文件。 [1] [2]
出现差异不一定表示有人改变了程序功能。编译器可能把工作文件夹的路径写进用于排查错误的信息中。如果两位开发者把项目保存在不同位置，文件就可能不同。规定统一路径，或者使用工具支持的路径统一方法，可以解决这类问题。这项规则必须是明确的构建步骤之一。不能在检查失败后随意删除无法解释的差异，只为了让结果一致；那样会使验证失去意义。 [3]
数字签名可以验证文件是否与相应密钥生成的签名相符。确认这把密钥属于厂商，则是另一项信任前提。可复现构建回答的是不同的问题：这个文件是否对应指定的源代码？两种检查相互补充。不过，官方更新可能带有本地构建没有的签名数据。如果不了解文件格式就直接比较整个文件，即使程序正确构建，也可能看到差异。 [5]
Trezor 文档介绍了如何选择版本和型号、构建固件，再与官方文件比较。本地结果没有与厂商发布文件相同的签名，因此操作步骤先将严格指定的签名字段置零。旧格式的头部也有区别；头部是文件开头包含相关信息的部分。具体结构取决于型号和版本，不能未经检查就把一个设备的步骤用于另一个。原始签名需要单独验证；比较调整后的副本不能取代这项检查。 [5]
首先应确认，比较的是否确实是相同代码修订、相同型号和相同固件变体。接着检查工具、库和规定的文件转换步骤。应保留原始文件及差异记录。原因可能是环境或说明有误，也可能是分发的程序被改动。不一致本身既不能确定责任人，也不能说明具体原因。在解释差异并重新检查之前，不能把构建标记为已经验证。 [1] [4]
如果公开的代码本来就有错误，每次重新构建都可能原样保留它。大家共同使用的不可信编译器也可能向所有结果加入同样的恶意修改；重复使用它，不等于独立审查了这件工具。封闭的二进制组件还会限制可从现有代码重建的范围。电脑上的文件一致，也不能证明某个钱包是真品，或设备实际运行的就是这份固件。检查文件来源是安全工作的重要部分，但不是完整的安全证明。 [6] [1]
一份“已验证”的报告，只有说明谁做了检查、构建哪个代码版本、针对哪种型号、采用什么步骤，才真正有用。还应列出比较的文件、哈希函数、结果，以及签名数据的精确处理方式。其他人才能检查或重复这项工作。更多独立验证者能降低对单一发布者的依赖，但仍需要审查代码、更新过程和设备本身。 [2] [4]
两个相同结果，一个不同哈希
两位开发者使用相同代码修订，在相同环境中为同一型号构建固件。两份文件的 SHA-256 指纹一致，但官方签名版本的指纹不同。如果文档严格定义了签名字段，他们就按规定转换副本，再比较一次。此时一致性针对的是这样界定的内容。原始签名仍然需要单独验证；其他无法解释的差异不能直接删掉。
要获得更完整的理解，请将本词条与以下词条结合阅读： Hardware Wallet, Private Key, Cold Storage, Secure Element. 反向关联还来自： COLDCARD RNG Incident (2026).
01普通用户必须自己构建固件吗？+
理解验证结果并不要求你成为程序员。但要留意独立报告有没有说明具体版本、型号和比较过的文件。相同哈希不能证明没有错误：同样的恶意代码或编译器也可能生成相同文件。代码审查与是否信任设备，仍是需要分别考虑的问题。
02签名更新的哈希不同，就意味着攻击吗？+
不一定。文件可能包含不同的签名数据或头部，而验证步骤已经考虑了这些区别。需要核对版本、型号和具体操作说明。不过，无法解释的差异不能算验证成功，也不能靠随意删除数据来绕过。