A friend of mine asked me to have a go at cracking an old Blockchain.com wallet of his from late 2013. He doesn't really know much about it at all, but thinks the password which encrypted the file is lower case & numbers only. He only gave me two possible example passwords, which were words with a few l33t speak modifications.
My own research seems to indicate that Blockchain.com's only other password requirement is that it's 10+ characters long, although supposedly some sub-10 character passwords have worked. I started this journey with BTCRecover, but it doesn't support GPU acceleration for this use case but hashcat does*.
I've tried: brute forcing as much as I can (about 7 characters), a passphrase dictionary attack, english words attack (using prince), and using the l33t speak rule set with my dictionaries.
What do you guys think of my next few ideas (and if you have any suggestions, happy to hear them!):
* the password is mostly lower case letters, so create a rule to substitute one letter with ?a, then 2, then 3.. up to about 4-5. is there any way to automate writing rules like this? essentially a ?a mask in each possible position, then two ?a masks in each position, etc.
* the words used are not strictly English, but possibly l33t slang e.g. pwnd, rekt, etc does anyone have a suggestion of a good l33t dictionary, I can think of a few words but doubt I'd have good coverage?
* spin up a cluster and try to brute force -- not a very good approach and I'm not sure I can really rely on the description of the password from my friend
* purple rain
---
* According to BTCRecover's source code, it seems even V0 wallets have a few different possible iterations on the key generating step (1 or 10 IIRC). I'm assuming that hashcat -m 12700 properly accounts for this. My read of hashcat's 12700 CL file seems to line up roughly with what BTCRecover is doing, and it successfully cracks the V0 test wallets that come with BTCRecover.
My own research seems to indicate that Blockchain.com's only other password requirement is that it's 10+ characters long, although supposedly some sub-10 character passwords have worked. I started this journey with BTCRecover, but it doesn't support GPU acceleration for this use case but hashcat does*.
I've tried: brute forcing as much as I can (about 7 characters), a passphrase dictionary attack, english words attack (using prince), and using the l33t speak rule set with my dictionaries.
What do you guys think of my next few ideas (and if you have any suggestions, happy to hear them!):
* the password is mostly lower case letters, so create a rule to substitute one letter with ?a, then 2, then 3.. up to about 4-5. is there any way to automate writing rules like this? essentially a ?a mask in each possible position, then two ?a masks in each position, etc.
* the words used are not strictly English, but possibly l33t slang e.g. pwnd, rekt, etc does anyone have a suggestion of a good l33t dictionary, I can think of a few words but doubt I'd have good coverage?
* spin up a cluster and try to brute force -- not a very good approach and I'm not sure I can really rely on the description of the password from my friend
* purple rain
---
* According to BTCRecover's source code, it seems even V0 wallets have a few different possible iterations on the key generating step (1 or 10 IIRC). I'm assuming that hashcat -m 12700 properly accounts for this. My read of hashcat's 12700 CL file seems to line up roughly with what BTCRecover is doing, and it successfully cracks the V0 test wallets that come with BTCRecover.
