rar2john works for rar 4.10 multipart rar

[sjpotter]

so I downloaded rar 4.10 via archive.org image of rarlabs site, and it seems to be problematic for a multipart rar file

I create a 100MB file of 0s

dd if=/dev/zero of=tmp bs=1M count=100

I create a multipart rar archive

rar a -m0 -hppassword -v10m test.rar tmp

I run rar2john on them which generates this hashes file

test.part01.rar:$RAR3$*0*a2b2dd9f4894c104*6e0306bbc06f4d2160ee0f979b2a86e7:0::::test.part01.rar
test.part02.rar:$RAR3$*0*82a956ec85b7e110*c50b2aa602b45fb804aad0570c894827:0::::test.part02.rar
test.part03.rar:$RAR3$*0*74404479a24aaf24*d8b5eeeda68881ffed4b87dccf33e05e:0::::test.part03.rar
test.part04.rar:$RAR3$*0*ce8c626a7506965c*91e0398fcbaeb02e2b14e5529c6a5969:0::::test.part04.rar
test.part05.rar:$RAR3$*0*e7d3c84afa2ffb9f*f98f1baffacd94d27f01d1f5479b6f22:0::::test.part05.rar
test.part06.rar:$RAR3$*0*c1d2ccee51bf945f*7c71236a43ab772136845b1501ce042b:0::::test.part06.rar
test.part07.rar:$RAR3$*0*b5cecc223b818e94*665528870a54a1ee5244bf6130496b4f:0::::test.part07.rar
test.part08.rar:$RAR3$*0*06ec0d9bcfde0d8e*ac39db7461924d2e21d9a9a8d601a28c:0::::test.part08.rar
test.part09.rar:$RAR3$*0*22969d6c2105e890*91a23aebe5051db072e4ee5a70c9391e:0::::test.part09.rar
test.part10.rar:$RAR3$*0*d47ded8e0793a07d*1e7bcc27b6525d3b2304d6774be2d4c5:0::::test.part10.rar
test.part11.rar:$RAR3$*0*54fea8823a0a9149*bdbb61b6890d67b05bde2b9337f0aa37:0::::test.part11.rar

this is the first clue to me that something isn't right, as the salts are all different, I'd assume they all have to be the same, but I guess it could use the same password for each file with a different salt?

but, when I try to have josh crack it by giving it the password, it fails

$ john hashes --mask=password
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 11 password hashes with 11 different salts (rar, RAR3 [SHA1 128/128 AVX 4x AES])
Will run 48 OpenMP threads
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 1 candidate buffered, minimum 192 needed for performance.
0g 0:00:00:03  0g/s 0.3279p/s 3.607c/s 3.607C/s password
Session completed.

now, when I create a single part archive

rar a -m0 -hppassword test.rar tmp

rar2john generates this hash

test.rar:$RAR3$*0*d0b7fdd315f4057c*8cca0883b93eb951a018365e37ac6306:0::::test.rar

this works as expected

~/git/john/run/john hashes1 --mask=password
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 1 password hash (rar, RAR3 [SHA1 128/128 AVX 4x AES])
Will run 48 OpenMP threads
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 1 candidate buffered, minimum 192 needed for performance.
password         (test.rar)
1g 0:00:00:01  0.5917g/s 0.5917p/s 0.5917c/s 0.5917C/s password
Use the "--show" opt

one thing I notice when creating these multipart rar file with 4.10, is that after it seemingly finishes that volume, it does some more work, than modern versions of rar don't say they are doing, namely

Calculating the control sum

I wonder if this data is unexpected by rar2john and is causing the problems?

[magnumripper]

I belive for multipart files you'd need to concatenate them and then run rar2john on the resulting single file.

cat test.part*.rar > all.rar
rar2john all.rar > hashfile

As this file can be very large it would be nice if we supported something like "rar2john --multipart test.part*.rar" instead, but we're not there yet. If we add such an option and a user does something unexpected (to us) such as "rar2john test.part*.rar unrelated.rar" we have no way (I think) of seeing that the last file is separate and should have its own hash.

[solardiz]

I belive for multipart files you'd need to concatenate them and then run rar2john on the resulting single file.

If so, maybe rar2john should refuse to run on the individual parts? Can it detect that?

[sjpotter]

I belive for multipart files you'd need to concatenate them and then run rar2john on the resulting single file.

cat test.part*.rar > all.rar
rar2john all.rar > hashfile

As this file can be very large it would be nice if we supported something like "rar2john --multipart test.part*.rar" instead, but we're not there yet. If we add such an option and a user does something unexpected (to us) such as "rar2john test.part*.rar unrelated.rar" we have no way (I think) of seeing that the last file is separate and should have its own hash.

nope

$ ls test.part*
test.part01.rar  test.part02.rar  test.part03.rar  test.part04.rar  test.part05.rar  test.part06.rar  test.part07.rar  test.part08.rar  test.part09.rar  test.part10.rar  test.part11.rar
$ cat test.part* > test.rar
$ rar2john test.rar > hashes1
$ cat hashes1
test.rar:$RAR3$*0*5dfa9bf867b0e3c2*16e42536b5b5fe89fe3c72e5a6989dee:0::::test.rar
$ john hashes1 --mask=password
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 1 password hash (rar, RAR3 [SHA1 128/128 AVX 4x AES])
Will run 48 OpenMP threads
Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status
Warning: Only 1 candidate buffered, minimum 192 needed for performance.
0g 0:00:00:01  0g/s 0.9709p/s 0.9709c/s 0.9709C/s password
Session completed.
$ file test.rar test.part01.rar
test.rar:        RAR archive data, flags: ArchiveVolume NewVolumeNaming RecoveryRecordPresent EncryptedBlockHeader FirstVolume
test.part01.rar: RAR archive data, flags: ArchiveVolume NewVolumeNaming RecoveryRecordPresent EncryptedBlockHeader FirstVolume

the file output should be expected (as the start of test.rar is test.part01.rar

also if one tries to extract test.rar it fails, so its not making a valid rar file

$ rar x -ppassword ../test.rar

RAR 7.00   Copyright (c) 1993-2024 Alexander Roshal   26 Feb 2024
Trial version             Type 'rar -?' for help


Extracting from ../test.rar

Extracting  tmp                                                        9%
Cannot find volume ../uest.rar
Checksum error in the encrypted file tmp. Corrupt file or wrong password.
Total errors: 1

and similar error if use rar 4.10 to extract

$ ~/rar/rar x -ppassword ../test.rar

RAR 4.10   Copyright (c) 1993-2012 Alexander Roshal   9 Jan 2012
Shareware version         Type RAR -? for help


Extracting from ../test.rar

Extracting  tmp                                                        9%
Cannot find volume /./test.rar
CRC failed in the encrypted file tmp. Corrupt file or wrong password.
Total errors: 1

[magnumripper]

Oh, I remembered incorrectly and that only applies to zip (edit: and RAR5). Sorry.

See #4346

[sjpotter]

Oh, I remembered incorrectly and that only applies to zip (edit: and RAR5). Sorry.

See #4346

over there #4346 (comment) it's claimed that -hp should work. my experience documented here, says they don't.

In #4346 (comment)

there's discussion of file length in hashes.txt being incorrect, but I dont understand what that means (at least with the hashes format I see)

[sjpotter]

so I decided to instrument the unrar source code, some findings. (source code mirrorered here - https://github.com/pmachapman/unrar, license allows one to use it freely to create tools that can unrar just can't recreate the rar algorithm, as that's not what john is doing, this seems fine under the license).

These are RARFMT15 files (makes sense, as next version is RARFMT50, which is post this)

1. the salt as they read it from the start of the file is always consistent, which is never the salt for any of the files in the set as calculated by rar2john

2. the salt as read is alway from byte 20 in all the parts and the salt is length SIZE_SALT30 (or 8 bytes)

Basically all from ReadHeader15(), slow going to try and understand whats going on, but its able to error out early in that function with a bad password with about 30k bytes read.