john
john copied to clipboard
openwall
rar2john: support multi-part archives
Two sub-tasks here:
-
Figure out and document the current support (if any) or lack thereof.
-
Implement full support.
Reference: https://www.openwall.com/lists/john-users/2020/09/18/3
According to comments in that thread, it works fine. We should just document it
According to comments in that thread, it works fine.
Right, but then why did OP say it didn't ("When ever i use rar2john on a single file i get the right hash, but when i use it on parts i don't")? Maybe we should ask OP about this first.
It may not always work. But, it is not broken.
rar a -hpclaudio -v1000k JtR-parts ../Host/JtR
rar a -hpclaudio JtR-full ../Host/JtR
The rar2john tool produces 3 different hashes:
- full has, e.g., HASH-A;
- part01 has, e.g., HASH-B;
- part02 has, e.g., HASH-C;
- part03 has, e.g., HASH-C;
- and so on (up to 69).
Edge JtR build (J1+).
$ /snap/john-the-ripper/current/run/john 1-full.txt --mask=claudio
Warning: detected hash type "RAR5", but the string is also recognized as "RAR5-opencl"
Use the "--format=RAR5-opencl" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 1 password hash (RAR5 [PBKDF2-SHA256 256/256 AVX2 8x])
Cost 1 (iteration count) is 32768 for all loaded hashes
Will run 8 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Warning: Only 1 candidate left, minimum 64 needed for performance.
claudio (JtR-full.rar)
1g 0:00:00:00 2.500g/s 2.500p/s 2.500c/s 2.500C/s claudio
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
claudio@aspire:~/Downloads/Lixo$ /snap/john-the-ripper/current/run/john 1-parts.txt --mask=claudio
Warning: detected hash type "RAR5", but the string is also recognized as "RAR5-opencl"
Use the "--format=RAR5-opencl" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 2 password hashes with no different salts (RAR5 [PBKDF2-SHA256 256/256 AVX2 8x])
Cost 1 (iteration count) is 32768 for all loaded hashes
Will run 8 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Warning: Only 1 candidate left, minimum 64 needed for performance.
claudio (JtR-parts.part002.rar)
claudio (JtR-parts.part001.rar)
2g 0:00:00:00 5.000g/s 2.500p/s 2.500c/s 5.000C/s claudio
Warning: passwords printed above might not be all those cracked
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
Oh, BTW: rar2john non-encrypted-file gives no warning, hint, error, info, whatever. Not sure if there is a bug about it.
It may not always work.
But you haven't found a test case where it doesn't work, correct?
BTW:
rar2john non-encrypted-filegives no warning, hint, error, info, whatever. Not sure if there is a bug about it.
We should probably fix that.
It may not always work.
But you haven't found a test case where it doesn't work, correct?
No.
I think i was the OP. I guess the problem is, I dont know how to correctly get hashes from multiple files and use them. To be fair i am not that used to working with john. Is there some documentation about how to go about it?
Not sure what you need but here are some examples.
# create (overwrite) hashfile.in
./rar2john archive1.rar >hashfile.in
# append (by using double >>) to hashfile.in
./rar2john archive2.rar >>hashfile.in
# several files at once
./rar2john archive1.rar archive2.rar archive3.rar >hashfile.in
# using wildcard instead
./rar2john archive*.rar >hashfile.in
Also, you can load several hashfiles to john at once, eg. ./john hashfile1.in hashfile2.in (or using wildcard ./john hashfile*.in) or you can concatenate many hash files into one, cat hashfile*in >all_hashfiles.in and load that one.
I just tried the method. Grabbing the multiple hashes works fine, apart from the the wildcard method that just returns " unknown file". But when i use john to then crack the password (i obviously know) it still doesn't find one.
P:\john\run>rar2john .\files\tester.part1.rar .\files\tester.part2.rar .\files\tester.part3.rar .\files\tester.part4.rar .\files\tester.part5.rar > .\files\hash3.in
! file name: Interview_test.mp3
! file name: Interview_test.mp3
! file name: Interview_test.mp3
! file name: Interview_test.mp3
! file name: Interview_test.mp3
P:\john\run>john --wordlist=.\files\WL.txt .\files\hash3.in
Warning: detected hash type "rar", but the string is also recognized as "rar-opencl"
Use the "--format=rar-opencl" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 5 password hashes with 5 different salts (rar, RAR3 [SHA1 256/256 AVX2 8x AES])
Will run 12 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Warning: Only 1 candidate left, minimum 96 needed for performance.
0g 0:00:00:02 DONE (2020-09-29 17:53) 0g/s 0.3474p/s 1.737c/s 1.737C/s asdf1234
Session completed
Oh no not at all. Its just an 428 mb .mp3 file, i just didn't think it mattered. If you want it more specific, its from at interview test session we did to make sure our setup worked and sound was good ect.
I confirm that rar2john doesn't work specifically for mutipart RAR3-p archives (hashes start with $RAR3$*1). The example above by @claudioandre-br uses RAR5-hp, which does work.
Here is an example which fails. The file hashes.txt is the output of
rar2john source.part*.rar > hashes.txt
The true password is password42, but JTR will not find it:
$ john hashes.txt --mask=password42
Using default input encoding: UTF-8
Loaded 5 password hashes with 5 different salts (rar, RAR3 [SHA1 AES 32/64])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Warning: Only 1 candidate left, minimum 4 needed for performance.
0g 0:00:00:00 0g/s 9.090p/s 45.45c/s 45.45C/s password42
Session completed
You will also see the same outcome if you only run rar2john on the first or the last part.
This example was constructed as follows:
head -c 2048 /dev/urandom > source/source1.bin
head -c 2048 /dev/urandom > source/source2.bin
rar a -ma3 -ppassword42 -v1k source ./source
Actually, this happens only when all files are split across parts. Here is an example using the same setup, but with no compression (to make reasoning easier), and with a source3.bin file added as follows:
head -c 64 /dev/urandom > source/source3.bin
In that case, JTR will succeed. source3.bin will be chosen as the best candidate for source.part5.rar, being the shortest file in that part, and it is entirely contained in that part, so decryption and decompression will succeed with the right password.
I imagine that files split across parts fail to pass a check of some sort. But that check seems to be neither length nor CRC:
- The unpacked length in
hashes.txtis incorrect. It is the unpacked length of the entire file, but the inline data extracts to only the portion of the file contained in this part of the archive. If I fix the length inhashes.txt, however (in this case, setting it equal to packed length, as there is no compression), the issue persists. - The CRC is correct, as far as I can see: unlike the length above, it is not the CRC of the entire file, but only of the portion contained in this part of the archive. If I rename one part to
source.rarand extract it, ignoring the expected error, the CRC32 checksums of the output match what is inhashes.txt.
Thank you for the research @dshynkev! This is very helpful.
Please also submit your samples, including those JtR doesn't crack yet, via a pull request to https://github.com/openwall/john-samples
On Windows based systems you can join multi-part archives with the copy command before hashing them. Using CMD prompt in the folder containing the pieces:
copy /B Filename.*.rar Filename.rar
copy /B Filename.zip.* Filename.zip
copy /B Filename.7z.* Filename.7z
As an example for older naming conventions, RAR files with a main Filename.RAR, and pieces named Filename.z01, Filename.z02, etc, would be:
copy /B Filename.* Filename2.rar
you can join multi-part archives with the copy command
You'd do the same with eg. cat Filename.*.rar > Filename.rar on linux/unix.
before hashing them
Did you mean to say before running rar2john? Are you saying the output of rar2john Filename.rar will crack just fine then? If that is the case, adding support for rar2john Filename.*.rar > Filename.rar.hash will be trivial. But if I recall correctly it will work in some cases but not always (i.e. not when the chosen archive member is split between two or more archive parts).
Yes, before running rar2john. In my testing so far joining the files using the above method is working, even when it is a single 42mb file in an archve, that is broken into 9 separate ~5mb parts
Running the copy command on the parts, then running rar2john on the single output file is producing the correct hash
(test files created with the latest WinRar 7.01)
even when it is a single 42mb file in an archve
Was that file stored or compressed? We should try both. Also both rar3 and rar5 versions. For zip/7z there may be many more combinations (unless we can establish from specs that this method canonically works).
Then, at least for now, this could be a documentation issue - we don't strictly need to add the functionality to *2john even if that would be nicer (especially given most people don't read any documentation).
Well, I tried as below but failed: Origin files are a.zip.001 - a.zip.008 each 20MB which split archived 2 xlsx files, based on ZipCrypto Deflate. 1: zip2john a.zip.001 xxxx.xlsx PKZIP Encr: cmplen=64282509, decmplen=70502581, crc=483780A5 Error, fread could not read the data from the file: a.zip.001
2: copy /B merged all files correctly into a 150MB zip file . When I open it by 7zip and type wrong passcode ,it shows "wrong password". and then zip2john a.zip > hash.txt I've got a huge one-line-string started and ended by "$pkzip2" but with size of 100MB.
- then I tried to use hashcat to read this hash.txt, and cmd shows: Oversized line detected! Truncated 111788081 bytes Oversized line detected! Truncated 111788081 bytes Oversized line detected! Truncated 111788081 bytes Oversized line detected! Truncated 111788081 bytes Oversized line detected! Truncated 111788081 bytes
I believe the issue comes from that big hash from split archived files.
Yes, before running rar2john. In my testing so far joining the files using the above method is working, even when it is a single 42mb file in an archve, that is broken into 9 separate ~5mb parts
Running the copy command on the parts, then running rar2john on the single output file is producing the correct hash
(test files created with the latest WinRar 7.01)
I believe the issue comes from that big hash from split archived files.
It isn't even related to the split and merge, or zip2john: The issue is that Hashcat can't handle large files. The maximum size is so low it's nearly unusable, I think 320 KB. Not megabytes mind you, but kilobytes. So this is off topic for this issue and for this repo.