WalletScrutiny

WalletScrutiny's avatar
WalletScrutiny
_@WalletScrutiny.com
npub1j9kt...uswx
Know your wallet like you made it! Our goal is to improve the security of Bitcoin wallets by examining products for transparency and potential attacks.
image WalletScrutiny turned 6! We've come a long way over the years. In the beginning, we only looked into Android wallets - 40 of them - and now we've grown to more than 6000 products across many platforms. Your favorite hardware wallet? We got you covered. Desktop? Probably, too. And desktop is a lot of work as here we found many open source and reproducible products!
We’ve been busy but quiet these last months. @btc_remnant improved the site a lot by adding new features around #nostr based build verifications. We hope other projects in the nostr ecosystem like @franzap @Zapstore will see the value of these verifications and start integrating them. The more products that build on reproducibility, the more users can truly apply the principle of β€œDon’t trust - verify.” Binary transparency shouldn’t remain a niche feature - it needs to become the default. If you run software that touches your private keys - be it nostr clients or bitcoin wallets - without binary transparency, only whoever built the binary really knows what code you’re running. image @dannybuntu and @keraliss checked the reproducibility of almost 300 binaries. The 304 verifications by @WalletScrutiny Bot are all the old verifications we had migrated to nostr. And the backlog keeps growing as we cover more and more products with frequent updates. Are we doing something valuable for the space? A @Spiral grant says yes, and community endorsements confirm it - but the project itself also needs scrutiny. We recently introduced "verification endorsements": image This is a simple contribution many could provide. If you read a verification and it looked plausible and complete and you trust the author, mark the verification as verified. If you ran the documented commands yourself on your hardware and got to similar results, please endorse the verification! Even more importantly label verifications as invalid and leave a comment about what's missing when you find issues! Don't be shy! Our goal is to document all steps such that all mildly technical users (you should be comfortable with a Linux shell) can reproduce our findings. If that's not the case, please provide your feedback and we will improve βœ‹. And if you maintain one of the products we check, share your own verification as a template for others!
The ByBit Hack Report [1] reveals interesting details. While many blame ETH and its complexities, it's important to note that a combination of circumstances made this attack possible. But the core issue clearly was a central point of failure. Multi Signature was used but all signers used the same hacked, remote server. The server was trusted, supposedly running a well audited open source web wallet software but "open source" is not enough as the source run on that compromised server did not match the well audited code. At WalletScrutiny we so far do not list web wallets because it is hard if not impossible to attest to the integrity of web wallet code when the server can serve different code every other second or depending on your IP address. We are investigating options to list progressive web apps that give the user more control of what is being run. While standard PWA manifests primarily contain metadata, a security-focused implementation could leverage several mechanisms to establish stronger integrity guarantees: Extending manifest files with cryptographic commitments to all resources Implementing Subresource Integrity (SRI) checks to verify each script matches expected hashes Using a trust-on-first-use (TOFU) signature model where developer keys are stored after initial verification Creating transparent, user-controlled update processes that display cryptographic verification before applying changes Such an approach would significantly reduce trust requirements in the server after initial installation, as the PWA could verify the integrity of updates against developer signatures before execution. Static analysis could also differentiate between PWAs with secure update mechanisms versus those with silent automatic updates. While not eliminating all risks, this model would provide a more verifiable path than traditional web wallets, potentially bringing them closer to the verification standards we apply to other wallet types. [1] https://docsend.com/view/s/rmdi832mpt8u93s7
At least some 300,000 machines reachable on the internet are vulnerable to a remote code execution vulnerability that appears to be rather easy to execute on all of those. The vulnerable package is cups-browsed - a tool for printing - which does get installed by default on many desktop linux systems but who knows ... maybe you are running some media server with your bitcoin wallet and your printer reachable via the same RaspberryPi? Check your machines. Android appears not to run cups but if you run Linux or Mac, you might want to double-check if you're one of the lucky 300,000 that get to update their system **now**.
We have long been working on testing desktop wallets but it's really tricky as there is just so many binaries floating around for what claims to be the same product. Even Bitcoin Core is showing 8 download options depending on your operating system or distribution channel preference: image With snapcraft obviously being tricky: image Either way, for desktop wallets, most of the time people have download links and want to verify those downloads, so Chris is working on a binary checker. It's still only a draft merge request and clearly needs a design but what it will enable is actually pretty cool: WalletScrutiny calculates the hash of the file dropped onto it and if it's an apk, it also determines the appId which allows finding the right product. If the hash is known, the verdict is immediately displayed. If not, the page invites the user to upload the file for analysis. The attestations for artifacts will live on nostr as signed events and nostr will also be used to advertise the existance of new binaries for reviewers.
Not all metal backups are made equally. If you use metal to not have to also worry about your bitcoins when your house is on fire, don't use this product: image But running these tests must have been great fun, right @Jameson Lopp? If we add these backup solutions to our website, we would certainly heavily lean on Jameson Lopp's work as a hydrolic press and acids isn't what we had planned to play around with ourselves for now. Jameson are you planning to test more products any soon? Adding "backup tools" to WalletScrutiny might get excessive if we don't draw lines like you did. If it's not at least claiming to be heat resistant, we won't bother to list it or else we end up listing a million different ways to print on paper.