If like last week simply guessing a password is insufficient, then you can bring out the big guns. I'm talking about Hashcat, and advanced system that allows you to automate the cracking of passwords using optimized GPU code.
Rather than manually guessing one password at a time - or even iterating over one password at a time - Hashcat can automate password cracking attempts using various rules. A password of password is unique from one of P@s$w0rd1. There are a slew of rules and configurations that enable Hashcat to stretch a smaller password list by swapping characters and applying transformations like this.
It's also easily paired with a centralized command server like Hashtopolis, that allows you to spread the hashing job out over multiple servers at once. You can leverage several local machines or rent machines from Amazon or a similar cloud provider.
Any way you slice it, Hashcat allows you to attempt several thousand passwords per second. Hashtopolis further allows you to do so on several machines at the same time.
Hashcat Setup
Before we can even begin hashing, we need to have something to crack. This is where our Bitcoin wallet comes in. Locally, a Bitcoin wallet is stored as a wallet.dat file that is partially encrypted using a password of your choosing. Your private key is symmetrically encrypted with a random master key, and that master key is subsequently encrypted with a user-defined password.
We don't want the entire wallet, though, just the parts necessary for guessing a password and verifying that password is correct.
The Openwall Project maintains a tool called John the Ripper that is somewhat similar to Hashcat. The advantage of their tool is that it's open source and includes various additional utility scripts that make our job easier. The bitcoin2join script, for example, takes a wallet.dat file and converts it to a string that's easily processed by either hashing system.
Running this script alone won't crack your wallet. What it will do is convert a large binary blob (your wallet) into a string like $bitcoin$64$f6f42a9e0cb0eda2669fa8.... This string, when provided to Hashcat, is the foundation of our next cracking attempt.
Hashcat Setup
Hashcat has various attacks and hashing modes. Since we're specifically trying to get into a Bitcoin wallet, we want mode 11300. We can also use a "straight" attack mode with a specific list of possible words if we have one.[ref]The Openwall Project also maintains a comprehensive wordlist commonly used to crack many passwords. If you don't have a wordlist to start from, this is a good place to begin.[/ref]
In our case, we put the hash generated from bitcoin2john above in hash.txt and a list of possible passwords into wordlist.txt. Our execution of Hashcat would then look like:
./hashcat64.bin -a 0 -m 11300 ./hash.txt ./wordlist.txt -O -w 3The flags here identify our attack type (straight), hashing mode (Bitcoin), a request to use an optimized kernel, and a high workload profile. The tool allows you to tweak all of these settings - and more - to your desire, so please check out the wiki for more information.
That Takes Forever ...
The only problem with Hashcat is that it takes a long time to process even the most conservative wordlist for a Bitcoin wallet. In many other blog entries I've seen folks complain that Hashcat reports "the next big bang" as the expected completion date for a cracking run.
Given how many possible passwords there are to go through, this is a reasonable estimate for a comprehensive brute force attack. But there are ways we can make things go faster.
First, curating our wordlist helps target the cracking attempt to words we know were likely to be used as part of the password. Hashcat also allows for powerful rule setting to manipulate potential passwords and stretch the number of candidates available - replacing as with @s or 0s with Os, for example. But still, this doesn't speed things up on your machine.
In fact, the problem is often that you're trying to run this on the same machine you use for other tasks. Hashcat uses your GPU for cracking, so you'll likely be overloading the system if you try to crack a password and run a display at the same time. Running things locally means you're limited to that one machine's hardware as well.
Next week we'll cover an approach to farm the cracking job out to multiple cracking machines in hopes we can expedite the job.