Прошивка — это программное обеспечение, которое управляет устройством, например аппаратным кошельком. Её сборка воспроизводима, если один и тот же исходный код, заданное окружение и инструкции дают полностью одинаковые, заранее определённые файлы. Недостаточно, чтобы программы просто одинаково работали: сравниваются сами данные. Для подписанных выпусков нужно также точно определить, как обрабатывается подпись.
Производитель может опубликовать код, который способен прочитать программист. Но в кошелёк обычно устанавливают уже готовый машинный файл, часто называемый бинарным. Между этими двумя формами находится этап сборки. Независимый человек может повторить его и сравнить результат с выпуском производителя. Проверяется совпадение байтов, отдельных единиц данных, например с помощью криптографического хеша — отпечатка, вычисленного из содержимого. Утверждение относится к заданным результатам, таким как файл прошивки, а не автоматически ко всем временным файлам и журналам. [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Другой хеш подписанного обновления означает атаку?+
Не обязательно. В файле могут отличаться данные подписи или заголовки, которые процедура проверки заранее учитывает. Нужно сверить версию, модель и точную инструкцию. Однако необъяснённое различие не является успешной проверкой, и его нельзя обходить произвольным удалением данных.