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