For WalletScrutiny I had reviewed Atomic Wallet which has been renamed on the PlayStore to “Bitcoin Wallet Crypto Ethereum” and removed from the AppStore before January second of 2022 but returned at some point later (we found it gone on that date and had not updated the review since).

On June third this year, a hack was made public with losses anywhere between $35 million and $120 million.

With the provider not being of much help to the investigations, affected users seem to take matters in their own hands and so they also reached out to me - after all I had warned of this product as early as January 2022.

It certainly looks shady that still no explanation for the hack surfaced while blame is put on some external hackers. Of course, the provider is trying to not get sued - currently by claiming the court not being in the right jurisdiction.

Anyway, I was asked to look if the version of the app that was used by most at the time of the hack. The earlier one was obfuscated, which was the only grounds for my warning at the time. Given the app was developed using “Cordova”, it’s most likely obfuscated now, too. Any apps that use a JavaScript framework by default are obfuscated as it improves the load time for the app - a compromise that I of course do not appreciate for Bitcoin Wallets.

So we had this to say about the app:

Is the decompiled binary legible?

The answer is “no”. We marked it as “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.

As with other categories, we close this one with the warning:

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.

WalletScrutiny currently does not give much room to share gut feeling but the “Obfuscated!” verdict does a bit of that as we only look for obfuscation where products look worth the effort aka shady. And it’s quite some extra effort to detect if the app is obfuscated using some standard tools and orders of magnitude harder to notice if it was obfuscated manually in ways that look like normal un-obfuscated code. Atomic was obfuscated with standard tools with what looks like simple “minification”.

Now where would I look for backdoors? Clearly, the most common version of the app on the day of the hack is the prime candidate but I would not dismiss other - older versions. If any past version did leak the keys, the keys are leaked and at the attackers’ disposal. They could just monitor the balance and once they lose hope for the total balance to go up, they hit that “empty wallets” key in their evil software and all lose their money.

I was told that primarily wallets with a lot of money were affected which hints at the attackers having insight into the balances.

• A theory that would point to external hackers could be that there is a marginal cost associated to the hack. If for example brute forcing the pin costs $100, the hacker would only empty wallets worth $100 and above.
• A theory that would point to internal hackers would be that the attacker is confident to repeat the theft and is merely waiting for users to re-gain confidence and put in more funds.

My suspicion is that the attacker has all the backups of all the users and is monitoring the balance right now. He took out 90% of the funds that were sitting in 2% of the wallets, expected the remaining funds to drop significantly but to ultimately recover and exceed the prior balance at which point more can be pulled out than if they had pulled out all at once.