Why are there a series of technical challenges behind “OMG buy it”>>>

Working environment: Ubuntu 16.04, NVIDIA graphics card gtx750ti, driver and CUDA have been installed

Recently, when a RAR compressed package was encrypted, it forgot its password and crashed. Fortunately, there is no way out. I searched the Internet for rar files like this, which are encrypted even the file list. It’s relatively difficult to decrypt them. If the file list is not encrypted (that is, you can see the file list when you open it, but you need a password to decompress it, if you want to decrypt this kind of file, you don’t need to look down ), this kind of encrypted rar file is troublesome to decrypt, because you can only write the check code to try to decompress and then compare the file. Fortunately, at that time, for the sake of “safety”, people chose not to see the file list

HashCat

https://github.com/hashcat/hashcat.git

The compilation guidance document is in build.md, and it’s easy to make and compile. After compiling, there will be an executable program of hashcat in the current source code directory

JohnTheRipper

https://github.com/magnumripper/JohnTheRipper.git

Ubuntu16 actually comes with John, but it doesn’t seem to come with rar2john, so I have to compile it myself. In fact, Jhon itself is also a password decryption tool, but here we only use rar2john to extract the encrypted hash of RAR. The compiled guidance document is in Doc/install-ubuntu. The actual compilation is also very smooth. After entering the SRC directory configure, make is OK, just like many open source software. Then you can find rar2john in the run directory

Then I use the RAR command to prepare a test file rar a – HP file.rar test.txt, and input 123 as the password to test the performance of hashcat

Then I use John to extract the encrypted hash of the rar file

rar2john file.rar
file.rar:$RAR3$*0*a64766df3a5c3bc9*0e875d8103a381d7f81a03121c693ef4:0::::file.rar

So far, everything is going well. But when I use hashcat to decrypt, something goes wrong

hashcat -m 12500 -a 3 $RAR3$*0*a64766df3a5c3bc9*0e875d8103a381d7f81a03121c693ef4 ?d?d?d -o out.txt
hashcat (v5.1.0-1671-g1de0857+) starting…

* Device #1: WARNING! Kernel exec timeout is not disabled.
This may cause “CL_ OUT_ OF_ RESOURCES” or related errors.
To disable the timeout, see: https://hashcat.net/q/timeoutpatch
* Device #2: WARNING! Kernel exec timeout is not disabled.
This may cause “CL_ OUT_ OF_ RESOURCES” or related errors.
To disable the timeout, see: https://hashcat.net/q/timeoutpatch
CUDA API (CUDA 9.0)
===================
* Device #1: GeForce GTX 750 Ti, 1554/1992 MB, 5MCU

OpenCL API (OpenCL 1.2 CUDA 9.0.368) – Platform #1 [NVIDIA Corporation]
=======================================================================
* Device #2: GeForce GTX 750 Ti, skipped

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

Hash ‘0*a64766df3a5c3bc9*0e875d8103a381d7f81a03121c693ef4’: Separator unmatched

Yeah?Separator unmatched？

I suspect that the parameter I input is wrong?Theoretically, 12500 corresponds to rar encryption hash. See the official wiki of hashcat

https://hashcat.net/wiki/doku.php?id=example_ hashes
12500 RAR3-hp $RAR3$*0*45109af8ab5f297a*adbf6c5385d7a40373e8f77d7b89d317

I input the example given by the official wiki into my compiled hashcat for decryption, and also report “separator unmatched”. I’m speechless, because according to my experience, hashcat, a mature open source project, won’t have too many problems, unless I’m lucky enough to memorize clone. The latest code is not stable, and it’s more likely that I didn’t find any low-level mistakes in my operation

But after trying several parameter combinations, I still can’t find out the reason. I can only debug hashcat. Hashcat is a C code project. GDB is the first choice for debugging in Linux environment. The executable program I compiled does not have debugging information, so I need to add the – G option when compiling GCC. Originally, I thought that modifying makefile would be a troublesome process. After a simple analysis, I found that makefile supports generating code with debugging information, so I don’t need to modify it by myself. The method is to change debug: = 0 at the beginning of makefile file to debug: = 1

The source code structure of hashcat itself is relatively clear, and it is easy to find the code corresponding to 12500 mode in Src/modules/module_ 12500.c。 The function responsible for parsing is module_ hash_ decode。 However, after some breakpoint debugging, I still don’t quite understand the cause of the error. It seems that a * separator is missing. Until I noticed the hash string passed in:

#0 module_ hash_ decode (hashconfig=0x711360, digest_ buf=0x93a0a0, salt=0x8e45d0, esalt_ buf=0x0,
hook_ salt_ buf=0x0, hash_ info=0x0,
line_ buf=0x7fffffffdf8e “0*45109af8ab5f297a*adbf6c5385d7a40373e8f77d7b89d317*”, line_ len=52)
at src/modules/module_ 12500.c:115

It turns out that the debugging direction I started with was wrong. The line passed in when I called the function_ The content of buf itself is incomplete. Where is the head “$rar3 $”?Or is this normal?So I changed the direction and started to analyze from the outside. I broke the breakpoint directly on the main function and found a problem

(gdb) p argv[3]
$29 = 0x7fffffffdf8e “0*45109af8ab5f297a*adbf6c5385d7a40373e8f77d7b89d317*”

It turns out that there was something wrong with the parameters I passed in… The operation was as fierce as a tiger, and I finally found myself in the middle of the two hundred and five

So, what caused me to enter the program with complete parameter input and the head “$rar3 $” was eaten?I immediately thought of the reason: the information I’m looking for is operated under windows, while under the command line of Linux, $is a special character

I test

Echo “$rar3 $* 0 *”
output results

0*

Echo “\ $rar3 \ $* 0 *”
output results

$RAR3$*0*

So the final solution is obvious. Just add a “\” escape, similar to

hashcat -m 12500 -a 3 \$RAR3\$*0*58c34e824da2ba03*1e760c511a8c6498e32f9514d2ef6764 ?d?d?d?d?d?d -o out.txt

Hashcat in my machine configuration can try an encrypted hash combination of 5K RARs in a second. If it is a pure digital password of 0-9, 3 bits is the third power of 10, and 10 bits is the tenth power of 10. When it comes to such a long number of digits, according to my environment, the decryption speed of 10 ^ 10/5000/60/60/24 in the worst case also needs 20 days