Ethereum Wallet Cracking Pt. 2 – GPU vs CPU

First of all, happy new year everyone! 😀

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.

{“dklen”:32,“n”:1024,”r”:8,”p”:1} – cracking on a GTX 1080

Step 1: (128 * 8) * 1024 = 1024 * 1024 = 1,048,576 bytes = 1 MB

Step 2: 32 (NVIDIA card) * 20 (a 1080 has 20 SMs) = 640 parallel computations

Step 3: 1MB * 640 = 640 MB RAM required per GTX 1080

As a GTX 1080 has 8GB of RAM which is > 640 MB so we can crack the above wallet without issue. Now let’s look at another example wallet:


{“dklen”:32,“n”:262144,”r”:8,”p”:1} – cracking on a Radeon RX Vega 64

Step 1: (128 * 8) * 262144 = 1024 * 262144 = 268,435,456 bytes = 256 MB

Step 2: 64 (AMD card) * 64 (an RX Vega 64 has 64 CUs) = 4,096 parallel computations

Step 3: 256MB * 4,096 = 1,048,576 MB RAM = 1,024 GB RAM required per Vega 64

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 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…




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?


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?!?!


(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! 😂😂😂

This entry was posted in crypto, password cracking, Pentest. Bookmark the permalink.

9 Responses to Ethereum Wallet Cracking Pt. 2 – GPU vs CPU

  1. Pingback: Ethereum Wallet Cracking | Stealthsploit

  2. Dindolo says:

    Why do you write that ethereum is scrypt based ? It is not ethash ?


    • I haven’t said that Ethereum is scrpyt based, it is Ethash you’re correct. These posts are based around certain Ethereum wallets, the paper versions of which are secured with scrypt.


  3. Jim says:

    Hey Stealsploit.. I’ve got a big Eth wallet to crack also.. Keep your on these bad boys..

    Liked by 1 person

  4. cosimo says:

    Hi Stealthsploit, thanks for the great tutorial!!!

    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).


      • cosimo says:

        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 ( 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:

        hashcat64.exe -m15700 $ethereum$s*262144*8*1*ab0c7876052600dd703518d6fc3fe8984592145b591fc8fb5c6d43190334ba19*d172bf743a674da9cdad04534d56926ef8358534d458fffccd4e6ad2fbde479c*2103ac29920d71da29f15d75b4a16dbe95cfd7ff8faea1056c33131d846e3097 -D 1

        Not that it matters much at this point since I found the “false positive” password that I needed already.
        Thanks again for the awesome articles!

        Liked by 1 person

  5. Mark Buffet says:

    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).

    See the output of hashcat –help:
    -d, –opencl-devices | Str | OpenCL devices to use, separated with commas | -d 1
    -D, –opencl-device-types | Str | OpenCL device-types to use, separated with commas | -D 1
    – [ OpenCL Device Types ] –
    # | Device Type
    1 | CPU
    2 | GPU
    3 | FPGA, DSP, Co-Processor

    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


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s