El firmware es el software que controla un dispositivo, como una Hardware Wallet. Su compilación es reproducible cuando el mismo código fuente, el entorno definido y las instrucciones generan archivos previamente especificados e idénticos. No basta con que el programa se comporte igual: se comparan los propios datos. En las versiones firmadas también debe estar claro cómo se trata la firma.
El fabricante puede publicar código que un programador puede leer. Sin embargo, lo que normalmente instalas en la cartera es un archivo terminado en formato de máquina, llamado binario. La compilación conecta ambas formas. Una persona independiente puede repetirla y comparar su resultado con el archivo publicado. Busca bytes idénticos, es decir, las mismas unidades de datos, normalmente mediante un hash criptográfico: una huella calculada a partir del contenido. La afirmación se refiere a resultados concretos, como el archivo de firmware, no automáticamente a todos los archivos de trabajo y registros. [1] [4]
Imagina a dos desarrolladores verificando una actualización. El nombre del proyecto no basta: necesitan el mismo commit, una revisión exacta del código. También deben conocer las versiones de las bibliotecas utilizadas y del compilador, la herramienta que convierte el código en formato de máquina. Sus opciones, los ajustes relevantes del entorno y el modelo de cartera forman parte del procedimiento. Esos datos deben fijarse de antemano o registrarse durante la compilación. De lo contrario, ambos pueden trabajar correctamente y obtener resultados distintos. [1] [2]
Una diferencia no implica necesariamente que alguien haya cambiado el funcionamiento del programa. El compilador puede incluir la ruta de la carpeta de trabajo en la información que permite investigar errores. Si cada desarrollador guarda el proyecto en un lugar diferente, los archivos pueden diferir. Una ruta prescrita o un método admitido para unificarlas puede resolverlo. Esa regla debe formar parte conocida del procedimiento. Borrar diferencias inexplicadas después de una comprobación fallida solo para conseguir una coincidencia vacía de sentido la verificación. [3]
Una firma digital permite verificar que un archivo corresponde a una firma creada con la clave pertinente. Atribuir esa clave al fabricante es otra parte de la confianza necesaria. La compilación reproducible plantea otra pregunta: ¿corresponde el archivo al código fuente definido? Ambas comprobaciones se complementan. La actualización oficial puede contener datos de firma ausentes de la compilación local. Comparar los archivos completos sin conocer su formato puede dar una diferencia aunque el programa se haya compilado correctamente. [5]
La documentación de Trezor describe cómo elegir versión y modelo, compilar el firmware y compararlo con el archivo oficial. Como el resultado local no lleva la misma firma que la publicación del fabricante, el procedimiento pone primero a cero campos de firma definidos con precisión. Los formatos antiguos también difieren en sus cabeceras, las partes iniciales que contienen información sobre el archivo. La estructura depende del modelo y la versión: no se puede trasladar sin comprobar una guía de un dispositivo a otro. La firma original se verifica aparte; comparar copias ajustadas no sustituye esa comprobación. [5]
Primero hay que determinar si se compararon la misma revisión, el mismo modelo y la misma variante de firmware. Después se revisan las herramientas, las bibliotecas y las transformaciones prescritas. Deben conservarse los archivos originales y el registro de la diferencia. La causa podría ser un error del entorno o de las instrucciones, pero también una modificación del programa distribuido. La discrepancia por sí sola no identifica responsables ni causas. Mientras no se explique y se repita la comprobación, no corresponde declarar verificada la compilación. [1] [4]
Si el código publicado ya contiene un fallo, cada nueva compilación puede reproducirlo fielmente. Un compilador compartido y no fiable también podría añadir la misma modificación maliciosa a todos los resultados; volver a usarlo no equivale a verificarlo de forma independiente. Los componentes binarios cerrados limitan además lo que puede reconstruirse con el código disponible. Un archivo coincidente en el ordenador tampoco demuestra que una cartera concreta sea auténtica o ejecute ese firmware. Comprobar el origen del archivo es una parte importante de la seguridad, no una prueba completa. [6] [1]
Un informe que dice «verificado» resulta útil cuando permite identificar quién hizo la comprobación, qué revisión compiló, para qué modelo y mediante qué procedimiento. Debe indicar los archivos comparados, la función hash, los resultados y el tratamiento exacto de los datos de firma. Así otras personas pueden examinar o repetir el trabajo. Más compilaciones independientes reducen la dependencia de un único distribuidor. Sigue siendo necesario revisar el código, el proceso de actualización y el propio dispositivo. [2] [4]
Dos resultados iguales y un hash diferente
Dos desarrolladores compilan firmware de la misma revisión para el mismo modelo y en el mismo entorno. Las huellas SHA-256 de sus archivos coinciden, pero la versión oficial firmada tiene otra. Si la documentación define con precisión los campos de firma, aplican la transformación prescrita a copias y comparan de nuevo. La coincidencia abarca entonces ese contenido definido. La firma original sigue necesitando su propia verificación; otras diferencias inexplicadas no deben eliminarse sin más.
Para obtener la imagen más completa, lee esta entrada junto con Hardware Wallet, Private Key, Cold Storage, Secure Element. También enlazan con esta entrada COLDCARD RNG Incident (2026).
01¿Tengo que compilar personalmente el firmware?+
No hace falta ser programador para entender el resultado. Comprueba, eso sí, que el informe independiente identifique versión, modelo y archivos comparados. Un hash coincidente no demuestra ausencia de fallos: el mismo código malicioso o compilador puede generar archivos iguales. Revisar el código y decidir si confiar en el dispositivo siguen siendo cuestiones separadas.
02¿Un hash distinto de una actualización firmada significa un ataque?+
No automáticamente. El archivo puede contener otros datos de firma o cabeceras que el procedimiento ya contempla. Hay que comprobar la versión, el modelo y las instrucciones exactas. Una diferencia sin explicar no es una verificación satisfactoria y no puede eludirse borrando datos arbitrariamente.