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:
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.
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:
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:
Once the patch is applied, we can see that our jnle instruction now is a jle instead:
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:
Finally, we have to change the byte 0x8F with 0x8E, as shown below:
Now, if we run the program, we don’t get the outrageous outdated error message and we can still test for robust hashes.