The changelog indicates firmware 2.8.9 includes bootloader version 2.1.10. When building from firmware 2.8.9 (core/v2.8.9), the embedded bootloader produces a hash:
5df0ff6efe28f68dd4411629c8dc9d430bd5996d5a1e5118091c266e46d375a1
But when building bootloader 2.1.10 directly (core/bl2.1.10) with the command ./build-docker.sh --models T2T1 --targets bootloader core/bl2.1.10, we get a different hash:
a790e46d7a471007d207c9625d231c8a78438abb9d62c179f866e98fb72401f5
What is your Trezor model?
Bootloader 2.1.10 was only updated for T3T1 aka Trezor Safe 5. The correct fingerprint is ed1b9225088ed0c260318cfc61b8661dceb80eff92f9889b0b93b30be9772bfd, which is what you will get if you build that tag with --models T3T1.
T2T1 aka Trezor T is on bootloader 2.1.8, correct fingerprint is 482f6e49e61a85f8e9e9f5bafecccb313eb81efec5f795cca88c36df795e8910.
The signed bootloader is included as a binary in the source distribution. If you look at bootloader built from a random non-bootloader tag (e.g. core/v2.8.9), you’ll get an ad-hoc hash that may or may not match any released or signed version. But that is not the bootloader that is bundled into the firmware.
Thank you for the prompt reply. I greatly appreciate it.
Trezor model T.
I understand that there used to be a way to reproducibly verify the bootloader and this was documented here in archived repo: trezor-core/blob/master/docs%2Fbootloader.md
And made use of a tool called binctl
This is archived - do you think it would still work with current versions?
a newer version of the tool is called headertool and you have it available if you are in poetry shell of the firmware repo.
the reproducible build will be something something build-docker, but you’ll have to look how the script works on the target tag version core/bl2.1.8. there may have been some changes
Again, thank you!
Testing
Hi, again, would there be a handy guide for me to do this? I’m not having much success.
make: Leaving directory ‘/reproducible-build/trezor-firmware/legacy/intermediate_fw’
make: Entering directory ‘/reproducible-build/trezor-firmware/legacy/intermediate_fw’
PRODUCTION=1
BOOTLOADER_QA=0
python …/bootloader/firmware_sign.py -f trezor.bin
Firmware size 45656 bytes
Firmware fingerprint: 67e7080c46966dd80d9ec2a26ca196d7182dfe8442e83c05987d611fdd87a447
Slot #1 is empty
Slot #2 is empty
Slot #3 is empty
HASHES OK
make: Leaving directory ‘/reproducible-build/trezor-firmware/legacy/intermediate_fw’
There are changes in the repository.Docker image retained as trezor-firmware-env.nix__core_bl2_1_8
To remove it, run:
docker rmi trezor-firmware-env.nix__core_bl2_1_8Built from commit 656a86b8a0c501be380c3db8e3560039701f832c
Fingerprints:
482f6e49e61a85f8e9e9f5bafecccb313eb81efec5f795cca88c36df795e8910 build/core-T/bootloader/bootloader.bin
482f6e49e61a85f8e9e9f5bafecccb313eb81efec5f795cca88c36df795e8910 build/core-T-bitcoinonly/bootloader/bootloader.bin
But then apart from the fact that you gave the hash: 482f6e49e61a85f8e9e9f5bafecccb313eb81efec5f795cca88c36df795e8910
How can this be derived from the device itself or from the downloaded firmware from trezor (not the source)
you can install a custom firmware that will calculate and report the firmware fingerprint
that can’t really be done easily. the firmware carries the bootloader in compressed form, so you’d have to do some amount of disassembly, locate the right sequence, uncompress it …
This is the usual way: verify that your firmware build matches the downloaded image, then verify that the build process is putting in the right bootloader.
The bootloader image that you’re looking for is sitting in core/embed/models/T2T1/bootloaders/bootloader-T2T1.bin.