tl;dr –If hashcat crashes/hangs your system, your wallet scrypt settings more than likely want more RAM than your GPU has. You’ll only be able to crack with a CPU (adding -D 1 # where # is the number hashcat assigns your CPU will select all available CPU devices, or -D 1 -d <number> for an individual CPU) and the hash rate will still be slow 😦

—————————————————————————————————————————————-

Since writing about cracking various Ethereum wallets using the JSON file, a few people have mentioned that their systems hang/blue screen when they start the crack, so I thought I’d talk about why this is.

scrypt is an anti-GPU algorithm and depending on the scrypt parameters (N, r and p) there’s a fair chance you’ll have to resort to CPU cracking. If you’re a glutton for detail you can find more on these parameters in scrypt’s RFC here, however at a high level they relate to work factor/iteration count, underlying hash blocksize and parallelization factor, respectively. When deciding whether we can crack scrypt with GPUs, the most important factor is N (note that the JSON file will refer to N as n, however I’ll stick to correct notation).

So the reason some of your systems hang when starting hashcat is because the N results in hashcat trying to use more RAM than your GPUs have.

Understanding scrypt Workloads

There are a couple of calculations required to derive the RAM required to GPU crack and remember these are GPU RAM requirements, not system ones.

Step 1: Calculate Single Computation per GPU

size_scrypt = (128 * r) * N

Step 2: Calculate Parallel Computations per GPU

Threads per compute unit * number of compute units = Number of parallel computations

Step 3: Calculate RAM requirement per GPU

size_scrypt * number of parallel computations

When GPUs Can and Can’t Crack

Please note that manufacturers refer to the basic unit of scheduling differently, so the “Threads per compute unit” will differ. NVIDIA cards have a warp size of 32 (a warp has 32 threads) and AMD cards have wavefront size of 64 (a wavefront has 64 threads)… When it comes to “compute units”, NVIDIA cards have stream multiprocessors (SM) and AMD cards just use “compute units” (CU). This’ll be put into context further down…

First let’s use the example from the wallet I used in my previous post.

Last time I checked, a Vega 64 has less than a terabyte of RAM! So this will crash and burn, often ending in a BSOD if the system doesn’t handle the memory failure well.

So how do I CPU crack?

Whenever you start hashcat it will list the devices and show what’s being used.

By default my CPU is skipped and my GPU is being used.

You can check your platform/device info by running hashcat -I (upper i) which you can then use to identify the CPU(s) you wish to try and crack with. By running hashcat –help you can see that it lists 3 device types and CPU is device 1.

So if hashcat -I identified that the your CPU was listed as device number 5, you would add -D 1 -d 5 in your hashcat command to select that device.

In my case I have one CPU device listed so I’ll tell hashcat to use device type 1 (CPU), after which hashcat detects my only available device.

As my CPU is listed as device 1 CPU devices are device type 1 in hashcat, so all I do is add that to the end of my usual hashcat command with -D 1 to select all available CPU devices. Adding -D 1 -d 1 in my case would also work, however I only have one CPU anyway. Generally it’s easiest to just use -D 1 to catch everything, see https://hashcat.net/forum/thread-5660.html for related reading.

…and as you can see the GPU is skipped and the CPU is used instead.

Wrap Up

When cracking scrypt, take these factors into account when working out what hardware you can crack with. Whether you end up on GPU or CPU the hash rates either way will likely be shockingly poor, but depending on the dictionary size, potential known variables (e.g. password length/partial values etc), don’t necessarily rule out CPU cracking.

If you’re CPU cracking and have zero knowledge of the password you may find that cracking scrypt is worth a crack, pun fully intended. For example on my laptop using a standard small wordlist (rockyou) it’ll take my CPU 15 days (if it even cracks at all of course)…

However when you start adding rules, of which my favourite is OneRuleToRuleThemAll (shameless plugging, my post about that is here), you may decide it’s slightly on the longer side…

FAQ

So I do the math and that’s how much RAM my system needs?

No. It’s the RAM your GPU has, not your cracking rig.

If my GPU is a little short will it overflow into system RAM after to compensate?

No.

But I run multiple cards on SLI/CrossFire, so if I stack cards I can exceed the requirement right?

No. The requirement is not cumulative, it’s per GPU so each card needs the calculated amount.

How do I CPU crack?

Add -D 1 to use all available CPUs, or -D 1-d <number> for a specific one. In my example above I want to use all CPUs (I only have one anyway) so I’d add -D 1 to my usual hashcat command.

Check your platform/device info by running hashcat -I which you can then use to identify the CPU(s) which you can use with -d . This can then be combined with -D 1 (device type CPU) to select your required device.

E.g. if the CPU you want is listed as device number 4, you would add -D 1 -d 4 to the hashcat command.

If I can only CPU crack, can I reduce/override my scrypt settings to 1024*8*1 so I can GPU crack it?

No. Changing N will change the iteration count, which will change the hash. Hashcat will speed up greatly if you reduce the numbers to make you think you’re #winning, but it won’t crack the hash even if you’ve got the plain in your dictionary.

So what you’re saying is if I’ve forgotten the password to my Eth wallet with £30,000 inside, it might take years to crack if at all?!?!

Yup.

(although of course if you do recover that £30,000 because of this post, my cut is £2,000 and my address is 0xCA388D10a935d29ccbA9E39b33066C48c3357028) haha! 😂😂😂

I have a keystore where N is 262144 (I know the password) and hashcat either gives me a false positive or doesn’t find the password although it is on the list. Everything works perfect on keystores where N is 1024.
Anything similar happening to you?

I haven’t experienced that no. As long as you haven’t modified any parameters, it should be ok. Hashcat won’t find it if parameters are changed but what do you mean by false positive? Please post your hashcat command (obfuscating hash of course).

Thanks for the reply! Regarding the false positive, that was my mistake of transcribing the password (hashcat found the correct password!). I did however find a sample keystore on github (https://github.com/hashcat/hashcat/issues/1228) and in this case hashcat doesn’t find the password “testpassword” even though I did put in on the list. I tried unlocking using mytherwallet and the password works there. The command I ran is:

@Stealthsploit
Unfortunately, all this information about the -D parameter in hashcat is completely wrong. If we look at the –help output of hashcat it clearly says that -D (or the equivalent long command line parameter: –opencl-device-types) should/can be only used to select a group/type of devices.
Hashcat currently supports 3 different types of devices: CPU, GPU and also FPGA, DSP, Co-Processor. By selecting the type of devices with -D x we can choose if we want to enable CPUs, GPUs etc… (by default only GPUs are enable if the system has at least one GPU, if not: the CPU device type/group will be whitelisted).

Therefore, only a comma-separated list of device types are allowed for the -D parameter (some examples are: -D 1 or -D 2 or -D 1,2).

The -d command line argument (or the equivalent long form of it: –opencl-devices) is completely different and it can be used to select a (or more) specific devices from the list of available/enabled devices (and device types).

This blog explains the -D parameter incorrectly. e.g. “adding -D # where # is the number hashcat assigns your CPU” is not true at all. This is a misleading statement, because a user would for instance try -D 5 (ATTENTION: this is not correct) or something similar, even though -D currently only allows an integer from 1 to 3 (to whitelist a specific group/type of devices).

Would be great if the blog would be corrected (there are unfortunately many places where the -D parameter was descriped completely incorrectly) to avoid us struggling with this parameter in the future. Thx

The blog posts should provide all the info you need. Many wallets are being created with stronger scrypt parameters by default now, so depending on what yours are, it may not be practical to attack the hash unless you’re 99% sure of the password already.