Using hashcat to find v3 ethereum wallet password
#1
Hey- so I have a big .txt file full of passwords I want to try, and I even wrote a python script that successfully attempts to verify them against an ethereum wallet.

But I'm told hashcat can potentially do it faster? / can utilize the GPU?

My question is that, to verify against an ethereum wallet is a more complex operation than "take the hash of the password and see if it == x". Specifically, you have to take the "scrypt" result of the password+salt, take the 2nd 16 characters of that, concatenated with another string, and take the sha256 of that, _then_ compare that with x.

So, how can I do that via hashcat? Is there a way to write a hashcat program? Or is there some built-in thing in hashcat that does all the intermediate steps?

Given that I really have a very simple setup ("just run hashcat with this .txt file against this .json ethereum wallet file"), is there an example CLI command I could get?

Thanks!
#2
If you had used the forum's search function you could have learnt that ethereum support was added in version 3.6.0.

You can extract the necessary info from your wallet file using this script: https://github.com/magnumripper/JohnTheR...um2john.py
#3
Ok- so I've derived the string from the ripper script... but how do I use it? Do I just copy and paste it as an argument to hashcat? Where to I put the argument for my password list?

I've tried

hashcat {long string generated by ripper script from wallet} -a 0 password.txt

and I get the red error "No hashes loaded". (and a yellow "Line-length exception").

I put the -a 0 because that supposedly sets the attack mode to dictionary? which is what I want?
#4
You need to specify the correct hash mode (-m). To avoid any interference with your shell you best save the string in a text file.
#5
Ok, something weird is happening with this forum. This post keeps on getting deleted and then reappears. So I have two of the same threads going on, but in parallel universes. Whatever, I'll just keep appending to both:

This is the command I've settled on:

hashcat3.6 -m 15700 -a 0 -w 3 hash.txt password.txt

And I get:

hashcat () starting...

OpenCL Platform #1: Apple
=========================
* Device #1: Intel(R) Core(TM) i5-4260U CPU @ 1.40GHz, skipped.
* Device #2: HD Graphics 5000, 384/1536 MB allocatable, 40MCU

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Applicable optimizers:
* Zero-Byte
* Single-Hash
* Single-Salt

Watchdog: Temperature abort trigger disabled.
Watchdog: Temperature retain trigger disabled.

Increasing single-block device memory allocatable for --scrypt-tmto 0.
Increasing single-block device memory allocatable for --scrypt-tmto 1.
Increasing single-block device memory allocatable for --scrypt-tmto 2.
Increasing single-block device memory allocatable for --scrypt-tmto 3.
Increasing single-block device memory allocatable for --scrypt-tmto 4.
Increasing single-block device memory allocatable for --scrypt-tmto 5.
Increasing single-block device memory allocatable for --scrypt-tmto 6.
Cannot allocate enough device memory. Perhaps retry with -n 1.

Started: Mon Jun 19 12:38:08 2017
Stopped: Mon Jun 19 12:38:09 2017

Then, when I try with -n 1, I get:

The manual use of the -n option (or --kernel-accel) is outdated.

Please consider using the -w option instead.
You can use --force to override this, but do not report related errors.

I looked at hashcat --help, and the only thing it says about -w is "enable a specific workload profile, see below", and then there's no further mention of "workload" below?

Any ideas?
#6
try using --scrypt-tmto 4
#7
Ok- so I've tried:

hashcat3.6 -m 15700 -a 0 -w 3 --scrypt-tmto 4 hash.txt password.txt

Now I get:

Increasing single-block device memory allocatable for --scrypt-tmto 4.
Cannot allocate enough device memory. Perhaps retry with -n 1.

Any ideas? Thanks for your help!
#8
try to further decrease scrypt-tmto
#9
Tried it with 4, 3, 2, 1, and 0

4, 3, 2, and 1 all have the same output (shown below). 0 has same output as though I didn't use the --scrypt-tmto argument in at all.
#10
You can try setting -w to something lower. If that doesn't work I'm out of ideas.