Wallet Logo

BITHD Watch 1

latest release: v4.1.7 ( 9th August 2021 ) last analysed  11th December 2021 Reproducible when tested
30th December 2017

Jump to verdict 

Disclaimer

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 

There is currently several red flags about this product.

  • Companion app with terrible rating and accusations
  • No social media links
  • Out of stock product with no word on plans to re-stock

BITHD Watch 1 is the first-generation BitHD watch. As said on Bitpie’s Medium article:

The BitHD watch was unveiled December 30th 2017 as the first generation; the second generation — BITHD Watch 2 was launched on January 18th 2019.

Interface

We assume that this product functions similarly to its successor. It is a wearable hardware wallet with a 0.96 screen display and must be paired with the Bitpie app via Bluetooth.

It’s not clear what the exact difference between the two generations is, but a post from Bitpie Wallet on bitcointalk.org implies that it is more involved with the external design of the watch.

Compare to the first generation, the new generation is lighter, thinner, much more comfortable to wear and come with a magnetic wireless fast charger. It also has a longer battery life and a higher waterproof level.

The bitcointalk.org post linked above links to this article concerning BITHD Watch 1. The article is a guide for setting up this specific product.

Private keys can be created offline - ✔️

This wallet must be paired with Bitpie via Bluetooth before the user is allowed to create a wallet or generate the seed.

Private keys are not shared - ✔️

From the product page:

Assets are stored in cold model, completely kept away from internet. Base on mature technical solution of hardware wallet.

From bitcointalk.org:

  • Unauthorized physical access to wallet protected by PIN
  • Password account – (protect private key leak)
  • No private keys leak risk in case of theft

Device displays receive address for confirmation - ✔️

As shown in the guide linked in a previous section, you can see that the device will display the receive address for confirmation.

Code and Reproducibility - ✔️

At the bottom of their website we can read:

BITHD is based on Trezor source code; and we extend our appreciation and gratitude to Trezor and BWallet.
Open source

and indeed their repository bithd-mcu contains build instructions for all three of their products:

In terms of being a Trezor fork, the repository is …

209 commits ahead, 515 commits behind trezor:master.

meaning it probably has some exclusive features and might miss more recent changes from Trezor.

Anyway, let’s see if we can reproduce builds. The latest signed firmware is v4.1.7. There we find

bithd-v4.1.7-signed.bin 	0a89405429ea6aa5abe8533f538f45bbaff36044b62aefcaaa63ef52bffebde0
razor-v4.1.7-signed.bin 	a4a9a5584f1db23d745434c296aedd3c123fe506c49624076d4726417e900137

We assume the two watches use the same binary, while the razor uses the other.

So we get two binaries for three products …

$ git clone https://github.com/bithd/bithd-mcu
$ cd bithd-mcu/
$ wget https://github.com/bithd/bithd-mcu/releases/download/v4.1.7/bithd-v4.1.7-signed.bin
$ wget https://github.com/bithd/bithd-mcu/releases/download/v4.1.7/razor-v4.1.7-signed.bin
$ echo '0a89405429ea6aa5abe8533f538f45bbaff36044b62aefcaaa63ef52bffebde0 bithd-v4.1.7-signed.bin' > shasums.txt
$ echo 'a4a9a5584f1db23d745434c296aedd3c123fe506c49624076d4726417e900137 razor-v4.1.7-signed.bin' >> shasums.txt
$ sha256sum --check shasums.txt 
bithd-v4.1.7-signed.bin: OK
razor-v4.1.7-signed.bin: OK
$ cat build-firmware.sh            # looks benign
$ pipenv --python 3 install
$ export VERSION_TAG=v4.1.7
$ export DEVICE_MODEL=BITHD_RAZOR
$ pipenv run ./build-firmware.sh $VERSION_TAG
$ cat script/prepare_firmware.py   # looks benign
$ pipenv run ./script/prepare_firmware.py -f ./build/razor-$VERSION_TAG-unsigned.bin
Warning: Your Pipfile requires python_version 3.8, but you are using 3.9.7 (/home/leo/.local/share/v/b/bin/python).
  $ pipenv check will surely fail.
Prepare to add metadata ...
Firmware size 417940 bytes
Firmware fingerprint: 2f142a5bd6e4cd2d3309895a4ed6ed539d67f9969260c5cbec2f524406527e84
$ diff <(xxd build/razor-v4.1.7-prepared.bin) <(xxd razor-v4.1.7-signed.bin)
1c1
< 00000000: 5452 5a52 945f 0600 0000 0001 0000 0000  TRZR._..........
---
> 00000000: 5452 5a52 945f 0600 0304 0501 0000 0000  TRZR._..........
5,16c5,16
< 00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
---
> 00000040: 3a68 2f7d 8f3b 9d0a 855c 020c 925a 777d  :h/}.;...\...Zw}
> 00000050: e9f9 ca1d df66 bebc 1692 9fe0 4d21 2b5d  .....f......M!+]
> 00000060: a387 4242 6efb bf92 1baf 7f88 31a0 607a  ..BBn.......1.`z
> 00000070: 70a0 7832 b203 915d c6fe 2b1b c0e9 b051  p.x2...]..+....Q
> 00000080: 7e42 3955 a18b 4d4c 109d edc9 d96c 5f75  ~B9U..ML.....l_u
> 00000090: ab25 510e 477e 0ff1 7402 9610 dd5a b1ad  .%Q.G~..t....Z..
> 000000a0: db9d 87ca d82e d7c4 6215 c238 5c0d 2a9a  ........b..8\.*.
> 000000b0: 1651 0194 0edc 3ccf c2de 1a58 f82c e7ef  .Q....<....X.,..
> 000000c0: d60b 546a bf6c 3791 69b0 1e3c fbea 5bd8  ..Tj.l7.i..<..[.
> 000000d0: d889 7096 540d 28fa ff7e f0de f8ea 641f  ..p.T.(..~....d.
> 000000e0: a47b aaa5 7529 8945 7bc1 e5f3 871a 4c34  .{..u).E{.....L4
> 000000f0: 4270 57cf 09e3 845a 38cc aac1 224d b386  BpW....Z8..."M..

On to checking the watches …

$ export DEVICE_MODEL=BITHD_BITHD
$ pipenv run ./build-firmware.sh $VERSION_TAG
$ pipenv run ./script/prepare_firmware.py -f ./build/bithd-$VERSION_TAG-unsigned.bin
Warning: Your Pipfile requires python_version 3.8, but you are using 3.9.7 (/home/leo/.local/share/v/b/bin/python).
  $ pipenv check will surely fail.
Prepare to add metadata ...
Firmware size 417788 bytes
Firmware fingerprint: 0f948e16337b0607d7b1218598e8af096b4a0566c54572c081ea5dded8ce9547
$ diff <(xxd build/bithd-v4.1.7-prepared.bin) <(xxd bithd-v4.1.7-signed.bin)
1c1
< 00000000: 5452 5a52 fc5e 0600 0000 0001 0000 0000  TRZR.^..........
---
> 00000000: 5452 5a52 fc5e 0600 0304 0501 0000 0000  TRZR.^..........
5,16c5,16
< 00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
< 000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
---
> 00000040: ea75 7244 687a 9eb6 2acc cf55 e2fb 8f8f  .urDhz..*..U....
> 00000050: a643 02b1 63ab c178 aa7e bd1b 547f 30b2  .C..c..x.~..T.0.
> 00000060: ef50 4e54 99ac d4b1 a1e4 ef04 77e8 5ac7  .PNT........w.Z.
> 00000070: 6967 21b8 e9d2 fad7 9ec8 36e8 a759 913a  ig!.......6..Y.:
> 00000080: fec0 db08 68fc 4289 ac45 7330 c797 9380  ....h.B..Es0....
> 00000090: 7d9c b4a3 c0db 3ce5 c559 f463 f33b 75e8  }.....<..Y.c.;u.
> 000000a0: cc4d a067 4441 03fe 5299 6602 c431 d6ac  .M.gDA..R.f..1..
> 000000b0: 4ab9 3d1a 1612 0d1e 7ec5 7c45 b91b f659  J.=.....~.|E...Y
> 000000c0: 8bad c208 9526 0da8 9627 5c53 c2e5 0ed3  .....&...'\S....
> 000000d0: b0ad bed4 1676 bab5 d190 8077 83b0 1c63  .....v.....w...c
> 000000e0: c3c7 2044 de40 21f2 ab85 8ae2 50a2 eb17  .. D.@!.....P...
> 000000f0: f149 9128 d745 65e3 af54 5dd3 418b f5ba  .I.(.Ee..T].A...

So both the razor and the bithd firmware yields the expected diff from the signatures. This firmware is reproducible.

(ml, dg, lw)

Verdict Explained

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 not, we tag it Reproducible

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.