Wallet Logo

ABCore

latest release: Varies with device last analysed  2nd March 2020 Reproducible when tested  
1thousand

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 

This app is a full node for Android, so running it on your phone is probably not recommended unless you have unlimited data and don’t mind your phone down- and uploading GBs of data at a time.

The provider recommends not to use it as a wallet but to run it to back a wallet that allows setting custom full nodes.

On their Git repository there are no build instructions. Lets see how far we get:

The current version on Google Play is 0.76.

$ git clone https://github.com/greenaddress/abcore
$ cd abcore/
$ git checkout v0.76alphaPoC 
$ docker run -it --volume $PWD:/mnt --workdir /mnt --rm mycelium-wallet bash
root@455390a45b9d:/mnt# yes | /opt/android-sdk/tools/bin/sdkmanager "build-tools;29.0.2" # this might not be necessary
root@455390a45b9d:/mnt# ./gradlew -x test clean assembleRelease
root@455390a45b9d:/mnt# exit
$ mv app/build/outputs/apk/prod/release/app-prod-release-unsigned.apk .
$ sha256sum fromGPlay.apk # for future reference
c1ecc53c4d3ec880c57167b9e54cb81af3edf5c3088289a8d570f8c5f3717c44  fromGPlay.apk
$ apktool d -o fromBuild app-prod-release-unsigned.apk 
$ apktool d -o fromGoogle fromGPlay.apk 
$ diff --brief --recursive fromGoogle/ fromBuild/
Files fromGoogle/apktool.yml and fromBuild/apktool.yml differ
Only in fromGoogle/original/META-INF: ABCORE.RSA
Only in fromGoogle/original/META-INF: ABCORE.SF
Files fromGoogle/original/META-INF/MANIFEST.MF and fromBuild/original/META-INF/MANIFEST.MF differ

This looks good. This app is reproducible.

(As the provider doesn’t recommend using this app as a wallet and as it uses tons of resources, please investigate well if you want to use this as an actual wallet on your phone or maybe better only as a bitcoin full node on your Android TV.)

(lw)

Verdict Explained

The binary provided was reproducible from the code provided.

As part of our Methodology, we ask:

Does the app we built differ from what we downloaded? If not, we tag it Reproducible  

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

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 app 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.