Electrum support - aes_decrypt (sha256 (sha256 ($pass), $data)

As you can guess, I have an Electrum wallet whose password I lost. I was considering several options and figured the most efficient way of throwing money at the problem right now should be asking someone to expand hashcat with an Electrum wallet option. I'm not sure of what kind of improvement can be obtained using OpenCL, but I hope for more than an order of magnitude (it should be possible to do around one million tests per second using the code below (or is it 100k/s? I only get 100k/s while the internet is full of people saying they can get 10x that).

Here is a the most optimised cracking function I could find:

       for count, password in enumerate(passwords, 1):
           key  = l_sha256( l_sha256( password ).digest() ).digest()
           seed = l_aes256_cbc_decrypt(key, iv, part_encrypted_seed)
           # If the first 16 bytes of the encrypted seed is all lower-case hex, we've found it
           for c in seed:
               if c > b"f" or c < b"0" or b"9" < c < b"a": break  # not hex
           else:  # if the loop above doesn't break, it's all hex
               return password if tstr == str else password.decode("utf_8", "replace"), count


Basically two sha256 rounds and an aes cbc decode operation.

Anyone interested in this?
I'm able to pull a good ~800-900kH/s using just the CPU code from BTCRecover on my home workstation, what hardware are you using? I don't mean to discourage the addition to hashcat, I just don't understand why you would be so severally limited.

If you really want it added, the best way to get it added would be to follow the algorithm request format detailed i the FAQ here:


If you would like to see an example of a algorithm request that was accepted, you can look here:


If you need help writing up the request, let me know and i can write it up for you. Since additions can take some time, we should focus on getting BTCRecover up and running at full speed for you in the mean time. Do you have all the crypto dependencies? I know that sometimes it falls back to slower implementations if libraries such as pycrypto are unavailable. Does it throw any errors when running?
Hello Chick3nman,

Thank you for confirming I'm an order of magnitude off with btcrecover, I don't know where that is from but I should be able to figure that out myself (yes, I have the crypto library installed and removing it gives me a 15x penality, even if I feel like I should try compiling the library with the AES instructions enabled if there is such an option, the systems I tried it on are pretty good, etc).

I think I should try to keep this thread about hashcat. I don't think I should have any problem opening a github issue asking for a new algoritm and I have no rush (I'm pretty busy and this is very low priority for me at the moment). Maybe I should just make a donation to the project if/when it gets implemented? I just see no way of doing that.
If BTCRecover does not end up working for you, you may also check out JTR. It looks like @Kholia has already done some work to have the algorithm added to JTR and has even created a script(electrum2jtr) and a hash format that could be used for the addition to hashcat.


As for donations, I'm not really sure if it's possible to donate to the project. You would need to talk to @Atom about that.
Please create the github issue and follow the descriptions in the link from the wiki. Is this something useful for other people too? How many people use this wallet?
Thanks, I had no idea JTR just added Electrum support, I need to try that out next. I'm biased, but I believe Electrum to be one of the best clients, and IMHO, the only one it makes sense to use. It's also the sub-category with the most posts/threads on bitcointalk.org. I will create a GitHub issue this week.
(06-27-2017, 11:32 AM)atom Wrote: Is this something useful for other people too? How many people use this wallet?

By my estimation electrum is the most popular offline wallet for bitcoin, litecoin and probably a few other cryptocurrencies.
Should I specify I would like to offer a bounty in the Github issue? What would $500 look like? Maybe I could pay in Bitcoin and use a multisign address to prove it?
6 months later...

AMD released some cpus with both SHA256 and AES hardware instructions, (the latest AMD EPYC line), exploiting them I got to 125 M/s, that is 100x what I was hoping for in my post above.

However looking at hashcat benchmarks for the 1080 leads me to believe I should get ~0.5 G/s with a single GPU.

Again the difficulty is 2x sha256 and 1x aes decode.

Hashcat benchmarks for the 1080 are showing 2.9 G/s for SHA256 (two rounds so make it 1.45 G/s), 140 k/s for 6000 AES rounds (that should translate to 840 M/s AES operations, but it's not that simple because looking at the code the AES structures for Keepass are initialised only once, the key is set only once, etc., so it's likely to be worse than that).

Anyway the AES and SHA256 primitives seems to be already implemented and it's just a matter of gluing them together. I would again be happy to pay someone to do that, and I could open that feature request on github (again I would like to send the money in advance to someone or use a multisign address).


However the reason I skipped github is that I wanted to talk about password generation for a bit first. My current password generation strategy is to start with some initial words list, divided into groups, apply some word mangling to them and feed the mangled groups of words to the password cracking program.

So say you have 10 groups with 10 base words each, once mangled those could be 10 x 150 words (each word in each different group is different, different dictionaries), you need to try 150^10 that of course isn't feasible but that was just an example.

My understanding is that hashcat doesn't allow complex dictionaries because they would kill performances. So I'm sort of back to square one if I can't find a way to combine 6+ dictionaries in a GPU kernel (as the CPU bus is limited from my calculations and would be too slow anyway).

TL;DR: GPU cracking is super cool and fast, but should I focus on it to get a 10x increase in speed when using complex dictionaries?
You can typically easily push enough candidates from your CPU for GPU cracking to be efficient. Complex attacks like that are not too complex for hashcat, you just need to make sure your external candidate generator is efficient enough to supply your GPUs with work.