Wallet Logo


Latest release: 9.13.1 ( 9th November 2022 ) 🔍 Last analysed 18th November 2022 . Reproducible when tested

The binary provided was reproducible from the code provided.

As part of our Methodology, we ask:

Does the binary we built differ from what we downloaded?

If the answer is "no", we mark it as "Reproducible when tested".

If we can reproduce the binary we downloaded from the public source code, with all bytes accounted for, we call the product reproducible. This does not mean we audited the code but it’s the precondition to make sure the public code has relevance for the provided binary.

If the provider puts your funds at risk on purpose or by accident, security researchers can see this if they care to look. It also means that inside the company, engineers can verify that the release manager is releasing the product based on code known to all engineers on the team. A scammer would have to work under the potential eyes of security researchers. He would have to take more effort in hiding any exploit.

“Reproducible” does not mean “verified”. There is good reason to believe that security researchers as of today would not detect very blatant backdoors in the public source code before it gets exploited, much less if the attacker takes moderate efforts to hide it. This is especially true for less popular projects.

Show Older Reviews

Help spread awareness for build reproducibility

Please follow BitBox02 and thank them for being reproducible  via their Twitter!


The following Analysis is not a full code review! We plan to make code reviews available in the future but even then it will never be a stamp of approval but rather a list of incidents and questionable coding practice. Nasa sends probes to space that crash due to software bugs despite a huge budget and stringent scrutiny.

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 

The reproducibility of firmware v9.13.1 has been confirmed by sutterseba and Joko.

Steps to reproduce on MacOS (Intel):

Install Docker (4.14.1 (91661) used).

$ cd releases
$ ./build.sh firmware-btc-only/v9.13.1 "make firmware-btc"
firmware.bin created at:

$shasum -a 256 temp/build/bin/firmware-btc.bin
b366dd855d8fb48a9d455275bc4ba0fd80af462d3deaac8c0c5f3a87bf3421f2  temp/build/bin/firmware-btc.bin

This matches the signed firmware, which we can verify by downloading the binary, moving it into the release-folder and running:

./describe_signed_firmware.py firmware-btc.v9.13.1.signed.bin 
The following information assumes the provided binary was signed correctly; the signatures are not being verified.
This is a Bitcoin-only edition firmware.
The hash of the unsigned firmware binary is (compare with reproducible build):
The monotonic firmware version is: 30
The hash of the firmware as verified/shown by the bootloader is:

The test script also yields a positive result:

$ scripts/test/hardware/bitBox2.sh 9.13.1
firmware.bin created at:
Hashes of
signed download             0f64c9ba01bb25500bfd3c96c133daa7da4a688234facbdd42a4f5e54d58e995  firmware-btc.v9.13.1.signed.bin
signed download minus sig.  b366dd855d8fb48a9d455275bc4ba0fd80af462d3deaac8c0c5f3a87bf3421f2  p_firmware-btc.bin
built binary                b366dd855d8fb48a9d455275bc4ba0fd80af462d3deaac8c0c5f3a87bf3421f2  temp/build/bin/firmware-btc.bin
firmware as shown in device 3b14ac4b65f954d19bb5faf66422838e0647a3a29987fda604fd421575bd4dae
                            (The latter is a double sha256 over version,
                             firmware and padding)

This version is reproducible.

(lw, Joko Ono)