Latest Tweets

cudaHascat 1.0.1: ERROR: this copy of cudaHashcat is outdated. Get a more recent version.

The issue

Recently I was running an automated script in order to check the robustness of some hashes belonging to some users on a deployed system. This automated script was written by me some time ago and it uses the cudaHascat64.bin utility to brute-force the hashes. Unluckily, this version is 1.0.1, and apparently it cannot be used anymore; when trying to execute the binary an error message appeared stating that:

./cudaHashcat64.bin
ERROR: this copy of cudaHashcat is outdated. Get a more recent version.

Crap. So, I decided to download the current version from the oclHascat website, that is, 1.33. But I’ve got another error, this time far more annoying:

ERROR: Shader Model 1.0 – 1.3 based GPU detected. Support for CUDA was dropped by NVidia.

WTF! Well, it seemed pretty obvious that I had to give up the idea of running an updated version of the cudaHashcat.

Debugging

Therefore, the remaining option was clear enough: to debug the cudaHashcat64.bin program and  figure out how to bypass this “outdated version” restriction. First, I ran some trivial checkouts to determine whether this binary was packed or not; it wasn’t! Perfect. So I ran it inside a debugger, instead of using gdb as usual I tried edb instead, quite a charming visual debugger like OllyDBG on Windows. Because the error was claiming that I was trying to run an outdated version, it was crystal clear to look for code snippets calling datetime functions not too far from the entry point. This is shown in the screen shot below:

A call to  time and localtime  to determine how "outdated" this version was.

A call to time and localtime to determine how “outdated” this version was.

So, basically, the lines checking for the right interval of  time before considering this version outdated were:

call localtime@plt
cmp dword ptr [rax+20], 114
jnle 0x40945e

The jnle opcode stands for “Jump if Not Less or Equal”. In the lines above, the code is comparing  a valid interval where the software is still runnable with respect to our current date and time. If the comparison does not succeed, then a jump to the address 0x40945e is made, where the program eventually shows its “outdated” error message and ends.

So, all we need to do is to patch this instruction to transform the jnle opcode to a jle one. According to the opcode mnemonic, jle is 0x0F 0x8E, instead of 0x0F 0x8F. We can patch the instruction on the fly inside our edb debugger, as shown below:

Patching the jnle instruction on the fly

Patching the jnle instruction on the fly

Once the patch is applied, we can see that our jnle instruction now is a jle instead:

The code now is patched; the jnle instruction is now a jle one.

The code now is patched; the jnle instruction is now a jle one.

If we run the code now, there is no more complaining about being an outdated version:

Usage: /oclHashcat-1.01/cudaHashcat64.bin [options]… hash|hashfile|hccapfile [dictionary|mask|directory]…

Try –help for more help.

Making the patch permanent

We need to apply the patch directly on the binary file if we want it to be permanent. In order to do so, we will edit the binary file with an hexadecimal editor and look for the bytes 0F 8F B7 0F 00 00, as shown in the next screenshot:

Looking for the jnle instruction inside the cudaHashcat64.bin binary

Looking for the jnle instruction inside the cudaHashcat64.bin binary

Finally, we have to change the byte 0x8F with 0x8E, as shown below:

The cudaHashcat64.bin binary already patched and ready to run.

The cudaHashcat64.bin binary already patched and ready to run.

Now, if we run the program, we don’t get the outrageous outdated error message and we can still test for robust hashes.