Wallet Logo

BitBox02

Latest release: 9.12.0 ( 15th June 2022 ) 🔍 Last analysed 7th August 2022 . Not reproducible from source provided Review might be outdated

Jump to verdict 

Older reviews (show 4 of 4 reproducible)

Help spread awareness for build reproducibility

Please help us spread the word, asking BitBox02 to support reproducible builds  via their Twitter!

Do your own research!

Try out searching for "lost bitcoins", "stole my money" or "scammers" together with the wallet's name, even if you think the wallet is generally trustworthy. For all the bigger wallets you will find accusations. Make sure you understand why they were made and if you are comfortable with the provider's reaction.

If you find something we should include, you can create an issue or edit this analysis yourself and create a merge request for your changes.

The Analysis 

Update 2022-01-22: The provider’s reply to our issue indicates they are not inclined to fix reproducibility for this version and point to this GitHub account that approved reproducibility at the time of the original release. As we do not know this account, we recommend people who don’t know them neither to not use this version and wait for a future release that probably will be reproducible again.

We wrapped the findings from prior reviews in a test script (?) which gave us these results:

$ scripts/test/hardware/bitBox2.sh 9.10.0
...
Hashes of
signed download             e3cf692d4ef288f27f22af2413acd9a43aa0ee445f83729f7b6c1fce55443293  firmware-btc.v9.10.0.signed.bin
signed download minus sig.  03b4f1c845fbb221109684163d1bd6d3b558b446e283d3217867f76074ef8745  p_firmware.bin
built binary                cd8dc14824a99c7b85be06787562238c5e9330becfa49569352500b385a81611  temp/build/bin/firmware-btc.bin
firmware as shown in device f2a3c20ee64147cff85c5a66e8a466bf9c98de2ea281b8211ce6788ec70a81cb
                            (The latter is a double sha256 over version, firmware and padding)

This does not look good. The second and third hash should be the same. Diffing the respective files using diffoscope ~/wsTest/bitbox02-firmware/{temp/build/bin/firmware-btc.bin,p_firmware.bin} yields binary differences all over the place.

The build instructions don’t look like they changed substantially:

$ git diff firmware-btc-only/v9.9.0 firmware-btc-only/v9.10.0 BUILD.md
diff --git a/BUILD.md b/BUILD.md
index c699881c..bbbd065a 100644
--- a/BUILD.md
+++ b/BUILD.md
@@ -175,6 +175,9 @@ Then you can run the tests by executing
+Rust unit tests, if not invoked via `make run-rust-unit-tests`, must be run with
+`-- --test-threads 1` due to unsafe concurrent access to `SafeData`, `mock_sd()` and `mock_memory()`.
+

This version is not verifiable.

(lw)

Verdict Explained

We could not verify that the provided code matches the binary!

As part of our Methodology, we ask:

Unreproducible!

Is the published binary matching the published source code?

If the answer is "no", we mark it as "Not reproducible from source provided".

Published code doesn’t help much if it is not what the published binary was built from. That is why we try to reproduce the binary. We

  1. obtain the binary from the provider
  2. compile the published source code using the published build instructions into a binary
  3. compare the two binaries
  4. we might spend some time working around issues that are easy to work around

If this fails, we might search if other revisions match or if we can deduct the source of the mismatch but generally consider it on the provider to provide the correct source code and build instructions to reproduce the build, so we usually open a ticket in their code repository.

In any case, the result is a discrepancy between the binary we can create and the binary we can find for download and any discrepancy might leak your backup to the server on purpose or by accident.

As we cannot verify that the source provided is the source the binary was compiled from, this category is only slightly better than closed source but for now we have hope projects come around and fix verifiability issues.

But we also ask:

Review Outdated!

Does our review and verdict apply to their latest release?

If the answer is "no", we mark it as "Review might be outdated".

Verdicts apply to very specific releases of products and never to the product as a whole. A new release of a product can change the product completely and thus also the verdict. This product remains listed according to its latest verdict but readers are advised to do their own research as this product might have changed for the better or worse.

This meta verdict is applied manually in cases of reviews that we identify as requiring an update.

This meta verdict applies to all products with verdict “reproducible” as soon as a new version is released until we test that new version, too. It also applies in cases where issues we opened are marked as resolved by the provider.

If we had more resources, we would update reviews more timely instead of assigning this meta verdict ;)