Problem reproducing the Trezor Safe 3 firmware

[Giszmo]

I try to reproduce the binary found in https://data.trezor.io/firmware/t2b1/trezor-t2b1-2.6.4{,-bitcoinonly}.bin but don't get matching fingerprints.

I'm using ./build-docker.sh --skip-legacy core/v2.6.4 to build.

Full transcript with ascii cast will be on https://walletscrutiny.com/hardware/trezorSafe3/ shortly.

I suspect I might be stripping the signature wrongly?

$ dd if=/dev/zero of=trezor-t2b1-2.6.4.bin.zeroed bs=1 seek=5567 count=65 conv=notrunc
$ dd if=/dev/zero of=trezor-t2b1-2.6.4-bitcoinonly.bin.zeroed bs=1 seek=5567 count=65 conv=notrunc

[matejcik]

right, because the vendor headers of TS3 are smaller! that goes back to #3418, we need to adjust the offsets. TT vendor headers are 4608 bytes each, and TS3 are 512 bytes, so you'd need to change seek=5567 to 5567 - 4608 + 512

...of course, this is going to be fragile because we don't guarantee that the vendor header sizes will stay as they are. there are dynamically sized fields in there. you can use python/tools/firmware-fingerprint.py to extract the fingerprint reliably, but that would mean auditing that this script does what it claims to do, and the "what it does" is kind of complex

wondering if you have an idea about what can be done here?

[matejcik]

i have an idea actually. it's kinda around-the-corner our repo contains the vendor headers. so what you can do is something like:

1. check that both your image and the official image start with the same N bytes, which are also equal to core/embed/vendorheader/<model>/<selected vheader>.bin
2. strip out those common N bytes
3. check that everything else is identical, and then the signature is (with current header structure at least) always on the same offset

[Giszmo]

Ok, sorry for being lazy. I should have included the diff:

$ diffoscope ../trezor-t2b1-2.6.4-bitcoinonly.bin build/core-R-bitcoinonly/firmware/firmware.bin
--- ../trezor-t2b1-2.6.4-bitcoinonly.bin
+++ build/core-R-bitcoinonly/firmware/firmware.bin
@@ -85,19 +85,19 @@
 00000540: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000550: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000560: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000570: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000580: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000590: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 000005a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
-000005b0: 0000 0000 0000 0000 0000 0000 0000 0003  ................
-000005c0: 43e9 fcc7 9929 f447 d877 6ae2 e461 a655  C....).G.wj..a.U
-000005d0: c7e7 cbb0 e3bd f27a 4ace 683d b30b d924  .......zJ.h=...$
-000005e0: d616 d2a2 875c 01a6 2e36 c708 eac7 95e1  .....\...6......
-000005f0: 77d8 eaef 0995 0808 e488 3173 f598 3404  w.........1s..4.
+000005b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
 00000600: 0040 0020 29d9 0608 edd6 0608 31d7 0608  .@. ).......1...
 00000610: 69d9 0608 91d7 0608 b1d7 0608 298e 0808  i...........)...
 00000620: 298e 0808 298e 0808 298e 0808 998a 0808  )...)...).......
 00000630: 298e 0808 298e 0808 d1f2 0608 e988 0808  )...)...........
 00000640: 298e 0808 d988 0808 298e 0808 298e 0808  ).......)...)...
 00000650: 298e 0808 298e 0808 298e 0808 298e 0808  )...)...)...)...
 00000660: 298e 0808 298e 0808 298e 0808 298e 0808  )...)...)...)...

I'm now looking at

$ ls core/embed/vendorheader/T2B1/vendorheader_*
core/embed/vendorheader/T2B1/vendorheader_dev_DO_NOT_SIGN_signed_dev.bin
core/embed/vendorheader/T2B1/vendorheader_dev_DO_NOT_SIGN_unsigned.bin
core/embed/vendorheader/T2B1/vendorheader_prodtest_unsigned.bin
core/embed/vendorheader/T2B1/vendorheader_trezor_btconly_signed_prod.bin
core/embed/vendorheader/T2B1/vendorheader_trezor_btconly_unsigned.bin
core/embed/vendorheader/T2B1/vendorheader_trezor_signed_prod.bin
core/embed/vendorheader/T2B1/vendorheader_trezor_unsigned.bin
core/embed/vendorheader/T2B1/vendorheader_unsafe_signed_dev.bin
core/embed/vendorheader/T2B1/vendorheader_unsafe_signed_prod.bin
core/embed/vendorheader/T2B1/vendorheader_unsafe_unsigned.bin

and wonder what next.

[matejcik]

you'll want vendorheader_trezor_btconly_signed_prod.bin for btconly and vendorheader_trezor_signed_prod.bin for universal

the diff looks vaguely correct

[Giszmo]

I'm trying to make sense of this but as far as I can see, the vendorheader files are much bigger than the diff I'm observing and neither contain byte sequences of the diff.

$ diffoscope --diff-context 0 ../trezor-t2b1-2.6.4-bitcoinonly.bin build/core-R-bitcoinonly/firmware/firmware.bin
--- ../trezor-t2b1-2.6.4-bitcoinonly.bin
+++ build/core-R-bitcoinonly/firmware/firmware.bin
@@ -92,5 +92,5 @@
-000005b0: 0000 0000 0000 0000 0000 0000 0000 0003  ................
-000005c0: 43e9 fcc7 9929 f447 d877 6ae2 e461 a655  C....).G.wj..a.U
-000005d0: c7e7 cbb0 e3bd f27a 4ace 683d b30b d924  .......zJ.h=...$
-000005e0: d616 d2a2 875c 01a6 2e36 c708 eac7 95e1  .....\...6......
-000005f0: 77d8 eaef 0995 0808 e488 3173 f598 3404  w.........1s..4.
+000005b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
$ hexdump core/embed/vendorheader/T2B1/vendorheader_trezor_btconly_signed_prod.bin 
0000000 5254 565a 0200 0000 0000 0000 0100 0302
0000010 ff7f 3254 3142 0000 0000 0000 0000 0000
0000020 5653 7eeb fc6e af91 d367 1b82 4ddd 4030
0000030 922e bcdb 376c 4a02 b6d5 af4d 5893 a57e
0000040 8835 6881 4c0b 0f6c ee5a 593c c66e d62a
0000050 ccee 160b 4ffb 5df6 f350 bb5e 9bab d0ba
0000060 077e 4327 639e 365e 6663 c961 7bf3 1448
0000070 ad95 0d9c 2dd8 c250 6b36 4f1d e04a 050b
0000080 5413 6572 6f7a 2072 6942 6374 696f 2d6e
0000090 6e6f 796c 4f54 4749 0018 0018 0050 0000
00000a0 908d 0a01 30c0 0308 42fd 905e 3fff 17cf
00000b0 44b8 32d7 28d8 d08b d09e 31aa 4002 8e95
00000c0 8c90 9a4e ccd3 ccc5 bac5 1f95 6eb9 991d
00000d0 f520 5861 36cd f143 3fc9 3cde 94ea efeb
00000e0 6dbe 9ccd 0233 e667 dbd6 9cbb 77b0 0172
00000f0 0000 0000 0000 0000 0000 0000 0000 0000
*
00001b0 0000 0000 0000 0000 0000 0000 0000 0300
00001c0 857f 749f 8760 2c3a 70ce 2432 db31 e260
00001d0 9b07 f26c b6b0 c3a9 2788 0d50 3421 120f
00001e0 79e7 e051 915e 7ae0 27fb a011 df35 68ab
00001f0 1f48 77b4 ef70 80bd 7465 c089 ec63 0f91
0000200

$ diffoscope --diff-context 0 ../trezor-t2b1-2.6.4.bin build/core-R/firmware/firmware.bin
--- ../trezor-t2b1-2.6.4.bin
+++ build/core-R/firmware/firmware.bin
@@ -92,5 +92,5 @@
-000005b0: 0000 0000 0000 0000 0000 0000 0000 0003  ................
-000005c0: a241 f757 eb62 57d7 1987 4119 2db4 66c4  .A.W.bW...A.-.f.
-000005d0: ee1d 44f1 0b61 3017 f35c 99e8 455d 66e4  ..D..a0..\..E]f.
-000005e0: e195 d49d f383 2899 070f ebc8 b803 0f12  ......(.........
-000005f0: 8f41 86ef 08e8 c095 3cc6 5b8a 2d68 640e  .A......<.[.-hd.
+000005b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
+000005f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
$ hexdump core/embed/vendorheader/T2B1/vendorheader_trezor_signed_prod.bin 
0000000 5254 565a 0200 0000 0000 0000 0200 0302
0000010 ff7f 3254 3142 0000 0000 0000 0000 0000
0000020 9496 5f4c 5574 5cbd 20e0 7c82 397b ebcf
0000030 4e04 2844 d858 5f3f dacd 7cb5 0bfc 2d9d
0000040 b4c5 15bd 8f77 8c62 d2b2 f179 ea5b 9b79
0000050 a817 1bc1 28bc 6f9a 11ee fa16 0622 7003
0000060 077e 4327 639e 365e 6663 c961 7bf3 1448
0000070 ad95 0d9c 2dd8 c250 6b36 4f1d e04a 050b
0000080 5406 6572 6f7a 0072 4f54 4749 0018 0018
0000090 0045 0000 6063 1410 fc14 1fff 3048 0100
00000a0 0988 80e2 1fd9 6c41 1879 fe5b 8c23 a40d
00000b0 7c81 ecbc 50ff 9780 540d d20e 3340 c836
00000c0 8253 7b70 5ec1 b103 423f 209c 710f 1833
00000d0 fa60 681d 3c88 4c38 0000 0000 0000 0000
00000e0 0000 0000 0000 0000 0000 0000 0000 0000
*
00001b0 0000 0000 0000 0000 0000 0000 0000 0300
00001c0 dc72 c432 8085 e6c5 238f ad72 525d 81ec
00001d0 aea7 a0d1 c99f a648 131c da4a fe5d 6963
00001e0 c463 f389 40be 340d 9a6b d9cb 85f8 5bb9
00001f0 aae6 c478 86b4 52fe 44bf 5ad8 2475 0820
0000200

Now nulling it in the downloaded binary to reproduce would not be right. I would say, adding this data from the repository as part of the build process should be the right approach as this should in fact contain the expected vendorheader as per the repository and not something different assuming the vendorheader is something auditable for a code reviewer.

[matejcik]

you're getting confused.

your best bet is to follow this:

we need to adjust the offsets. TT vendor headers are 4608 bytes each, and TS3 are 512 bytes, so you'd need to change seek=5567 to 5567 - 4608 + 512

The other thing is an idea for a more stable instructions that don't need to adjust the seek value every time we change the vendor header.

---

adding this data from the repository as part of the build process should be the right approach

that's indeed what is happening

and not something different

cf.:

1. check that both your image and the official image start with the same N bytes, which are also equal to core/embed/vendorheader/<model>/<selected vheader>.bin

assuming the vendorheader is something auditable for a code reviewer.

vendor header is pure data that you can manually decode per this structure

[Giszmo]

Success. Thanks. Will update the review asap.

$ sha256sum *.zeroed build/core-R{,-bitcoinonly}/firmware/firmware.bin | sort
ac2aadad8850f6d23763e543ddd2604e5760eeb7c7ec747f1c1015246125207c  build/core-R-bitcoinonly/firmware/firmware.bin
ac2aadad8850f6d23763e543ddd2604e5760eeb7c7ec747f1c1015246125207c  trezor-t2b1-2.6.4-bitcoinonly.bin.zeroed
c723a55315ed5528db602d8ef0eebeb4a8a9ed96a0e237122398a999fab5e75e  build/core-R/firmware/firmware.bin
c723a55315ed5528db602d8ef0eebeb4a8a9ed96a0e237122398a999fab5e75e  trezor-t2b1-2.6.4.bin.zeroed

Please remind me: The build script ends in

Fingerprints:
7558899d0e9a551738c5e29b4b27741d00a472fc8f9e47eddbfc983fc236cddd build/core-R/bootloader/bootloader.bin
5ac16cb5002aa607908be376378a7fd1a1bc18f7b05e7a047cb1365840cc93ef build/core-R/firmware/firmware.bin
7558899d0e9a551738c5e29b4b27741d00a472fc8f9e47eddbfc983fc236cddd build/core-R-bitcoinonly/bootloader/bootloader.bin
013d595fc621c12324afd90721c6a37d055d853f6af54d5432e27e6a425656dd build/core-R-bitcoinonly/firmware/firmware.bin

but those fingerprints match none of the sha256sums above. I think this is the code that generates these fingerprints:

        click.echo(firmware_headers.parse_image(data).digest().hex(), file=output)

I see those fingerprints are referenced in https://github.com/trezor/data/blob/master/firmware/t2b1/releases.json

[matejcik]

but those fingerprints match none of the sha256sums above. I think this is the code that generates these fingerprints:

Correct and correct. A "fingerprint" is a hash of a firmware header that is not affected by signatures. It fully identifies the firmware image contents, but not who signs it -- that is THE reproducible thing. So it needs to be more clever than a plain sha256sum.

The dd exercise hacks the image so that it can be compared byte-for-byte to the official one. Easier to audit, but it's a hack.

[matejcik]

fwiw, the fingerprint is the payload that gets signed