Wallet Logo

BRD Bitcoin Wallet Bitcoin BTC

Latest release: 4.18.0 ( 18th March 2022 ) 🔍 Last analysed 2nd November 2022 . No source for current release found
3.4 ★★★★★
33632 ratings
5 million
21st July 2016

Jump to verdict 

Older reviews (show 0 of 3 reproducible)

Help spread awareness for build reproducibility

Please help us spread the word discussing transparency with BRD Bitcoin Wallet Bitcoin BTC  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-11-02: The repository has not been updated in a long time and the provider has not reacted to our enquiry to do so. This product is not verifiable.

Update 2022-04-07: This product’s provider appears to be partnering with Coinbase and with their latest update they now encourage and help their users to migrate to Coinbase Wallet, a browser extension based self-custodial wallet. The article is not (yet) talking about BRD Bitcoin Wallet Bitcoin BTC being in sunset mode or obsolete but some consolidation appears to be going on.

Update 2021-06-29: The provider informed us that the latest code can be found in a new repository. Apparently the new repository is a fork of the old repository where they changed the license from open source to some look-dont-touch license. For us, both provide the same degree of transparency so we have to revert the last change in verdict. This app does indeed share up to date source code although the git tag and the Play Store version name do differ.

Update 2021-06-27: As pointed out here, the provider stopped updating the public source repository and thus is to be considered closed source. The current version on the Play Store is 4.10.0 from yesterday. The latest version available on their GitHub is 4.9.1.1 from 2021-03-03.

This wallet claims not to be custodial and we found its supposed source code but we found no claim of verifiability and so verification was difficult.

Update: The team reacted quickly to our reach-out after our first analysis via this issue on their GitHub.

Now we find a tag build-3.14.3.3 and can try to compile that:

$ git tag | grep 3.14.3
build-3.14.3.3
$ git checkout build-3.14.3.3
...
HEAD is now at a332b4d5 Merge branch 'pablobu/DROID-1497' into 'release/3.14.3'
$ git submodule update --init --recursive
$ docker run -v $PWD:/mnt -it beevelop/cordova bash
root@e34a31867b99:/tmp# cd /mnt/
root@e34a31867b99:/mnt# yes | $ANDROID_HOME/tools/bin/sdkmanager "platforms;android-28"
root@e34a31867b99:/mnt# ./gradlew :app:assemble
root@e34a31867b99:/mnt# ls app/build/outputs/apk/brd/release/*.apk
brd-release-3.14.2.1.apk  output.json

Now that doesn’t look promising, given we need version 3.14.3 and indeed the diff is huge and goes across many code files.

The content of AboutActivity for example confirms its the wrong version. Many of the differences look harmless like this:

diff -r fromBuild/smali/com/breadwallet/presenter/activities/settings/AboutActivity.smali fromPlayStore/smali/com/breadwallet/presenter/activities/settings/AboutActivity.smali
157c157
<     const-string v4, "3.14.2"
---
>     const-string v4, "3.14.3"

But with these diffs we can’t give it a pass:

Binary files fromBuild/lib/arm64-v8a/libcore.so and fromPlayStore/lib/arm64-v8a/libcore.so differ
Binary files fromBuild/lib/armeabi-v7a/libcore.so and fromPlayStore/lib/armeabi-v7a/libcore.so differ
Binary files fromBuild/lib/x86/libcore.so and fromPlayStore/lib/x86/libcore.so differ
Binary files fromBuild/lib/x86_64/libcore.so and fromPlayStore/lib/x86_64/libcore.so differ

Diffoscope yields user directories in its 397662 lines of diff:

│ ├── readelf --wide --decompress --hex-dump=.rodata {}
│ │ @@ -1,7610 +1,7450 @@
│ │  
│ │  Hex dump of section '.rodata':
│ │ -  0x001622e0 2f557365 72732f61 6a762f64 6576656c /Users/ajv/devel
│ │ -  0x001622f0 2f627265 61647761 6c6c6574 2d616e64 /breadwallet-and
│ │ -  0x00162300 726f6964 2f636f72 652f4a61 76612f43 roid/core/Java/C
│ │ -  0x00162310 6f72652f 7372632f 6d61696e 2f637070 ore/src/main/cpp
│ │ -  0x00162320 2f636f72 652f7375 70706f72 742f4252 /core/support/BR

This looks like NDK being the culprit for part of the diff, apart from it being the wrong version. Hopefully with Docker this can be improved.

Our verdict

We conclude that we hope for a quick resolution of the issues but for now this wallet remains not verifiable.

(lw)

Verdict Explained

Without public source of the reviewed release available, this product cannot be verified!

As part of our Methodology, we ask:

Is the source code publicly available?

If the answer is "no", we mark it as "No source for current release found".

A wallet that claims to not give the provider the means to steal the users’ funds might actually be lying. In the spirit of “Don’t trust - verify!” you don’t want to take the provider at his word, but trust that people hunting for fame and bug bounties could actually find flaws and back-doors in the wallet so the provider doesn’t dare to put these in.

Back-doors and flaws are frequently found in closed source products but some remain hidden for years. And even in open source security software there might be catastrophic flaws undiscovered for years.

An evil wallet provider would certainly prefer not to publish the code, as hiding it makes audits orders of magnitude harder.

For your security, you thus want the code to be available for review.

If the wallet provider doesn’t share up to date code, our analysis stops there as the wallet could steal your funds at any time, and there is no protection except the provider’s word.

“Up to date” strictly means that any instance of the product being updated without the source code being updated counts as closed source. This puts the burden on the provider to always first release the source code before releasing the product’s update. This paragraph is a clarification to our rules following a little poll.

We are not concerned about the license as long as it allows us to perform our analysis. For a security audit, it is not necessary that the provider allows others to use their code for a competing wallet. You should still prefer actual open source licenses as a competing wallet won’t use the code without giving it careful scrutiny.

The product cannot be independently verified. If the provider puts your funds at risk on purpose or by accident, you will probably not know about the issue before people start losing money. If the provider is more criminally inclined he might have collected all the backups of all the wallets, ready to be emptied at the press of a button. The product might have a formidable track record but out of distress or change in management turns out to be evil from some point on, with nobody outside ever knowing before it is too late.