Wallet Logo

Bither - Bitcoin Wallet

latest release: 2.0.1 last analysed  3rd March 2021 Obfuscated  
3.7 ★★★★★
322 ratings
27th February 2014

Jump to verdict 

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 

This app is an open source Bitcoin wallet with most of its information to be found not on their website but in the App description and on GitHub.

There they clearly claim:

Bither Cold Wallet

  1. Cold wallet running on offline mode (Backup phone).

and with an offline wallet, the private key clearly has to live exclusively on that Cold Wallet phone, making the product a non-custodial wallet.

But can we reproduce the build? There are build instructions. Let’s see how that goes. Those instructions are from 2015 …

$ git clone git@github.com:bither/bither-android.git --recursive
$ cd bither-android/

You must use gradle (v1.10)

… that’s scary. v1.10 is from 2013. So as we won’t install gradle system-wide on version 1.10, we hop into docker now:

$ docker run --rm -v$PWD:/mnt --workdir=/mnt -it walletscrutiny/android bash
root@72c683aa390c:/mnt# apt update
root@72c683aa390c:/mnt# apt install gradle          
root@72c683aa390c:/mnt# gradle wrapper
root@72c683aa390c:/mnt# sed -i 's/4.4.1/1.10/g' gradle/wrapper/gradle-wrapper.properties 
root@72c683aa390c:/mnt# ./gradlew assembleRelease
Downloading https://services.gradle.org/distributions/gradle-1.10-bin.zip
Unzipping /root/.gradle/wrapper/dists/gradle-1.10-bin/948peyqp7eyfqxj7mcl7th1vs/gradle-1.10-bin.zip to /root/.gradle/wrapper/dists/gradle-1.10-bin/948peyqp7eyfqxj7mcl7th1vs
Set executable permissions for: /root/.gradle/wrapper/dists/gradle-1.10-bin/948peyqp7eyfqxj7mcl7th1vs/gradle-1.10/bin/gradle
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: http://gradle.org/docs/1.10/userguide/gradle_daemon.html.

FAILURE: Build failed with an exception.

* Where:
Build file '/mnt/build.gradle' line: 1

* What went wrong:
A problem occurred evaluating root project 'mnt'.
> org/gradle/initialization/BuildCompletionListener

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.


Total time: 3 mins 46.707 secs

Poking around we see:

root@72c683aa390c:/mnt# cat build.gradle 
buildscript {
    dependencies {
        classpath 'com.android.tools.build:gradle:2.3.2'

and this gradle plugin requires gradle 3.3+, not 1.10. The build instructions are clearly lacking and this is where we give up. This wallet is not verifiable.

To make matters worse, the app also uses proguard obfuscation:

root@72c683aa390c:/mnt# cat bither-android/build.gradle 
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

Verdict Explained

The binary contains active obfuscation!

As part of our Methodology, we ask:

Is the decompiled binary legible? If not, we tag it Obfuscated!  

When compiling source code to binary, usually a lot of meta information is retained. A variable storing a masterseed would usually still be called masterseed, so an auditor could inspect what happens to the masterseed. Does it get sent to some server? But obfuscation would rename it for example to _t12, making it harder to find what the product is doing with the masterseed.

In benign cases, code symbols are replaced by short strings to make the binary smaller but for the sake of transparency this should not be done for non-reproducible Bitcoin wallets. (Reproducible wallets could obfuscate the binary for size improvements as the reproducibility would assure the link between code and binary.)

Especially in the public source cases, obfuscation is a red flag. If the code is public, why obfuscate it?

As obfuscation is such a red flag when looking for transparency, we do also sometimes inspect the binaries of closed source apps.

As looking for code obfuscation is a more involved task, we do not inspect many apps but if we see other red flags, we might test this to then put the product into this red-flag category.

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.