RAR3-p hash with *35 ending won't find password in wordlist
#1
Hello everyone!

I wanted to try hashcat on one of my old RAR files. I knew the password for the RAR and placed it in a wordlist, which was provided then to hashcat, but ultimately, hashcat couldn't recover that password. rar2john gave me a hash like this:

$RAR3$*1*0000000000000000*12b2c880*22304*61431*1*f9...999*35

As you can see, it has the ending *35 which wasn't listed on the "examples of hashes" hashcat site.
Is this format unsupported? Or is rar2john generates a false hash for me?

Thanks for the help!
Reply
#2
Show us your output for hashcat for the attack.
Reply
#3
Here it is:

Code:
OpenCL API (OpenCL 2.1 AMD-APP (3516.0)) - Platform #1 [Advanced Micro Devices, Inc.]
=====================================================================================
* Device #1: AMD Radeon RX 6800 XT, 16256/16368 MB (13912 MB allocatable), 36MCU

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

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Optimizers applied:
* Zero-Byte
* Single-Hash
* Single-Salt

ATTENTION! Pure (unoptimized) backend kernels selected.
Pure kernels can crack longer passwords, but drastically reduce performance.
If you want to switch to optimized kernels, append -O to your commandline.
See the above message to find out about the exact limits.

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 1723 MB

Dictionary cache hit:
* Filename..: .\pass.lst
* Passwords.: 238
* Bytes.....: 1717
* Keyspace..: 238

The wordlist or mask that you are using is too small.
This means that hashcat cannot use the full parallel power of your device(s).
Unless you supply more work, your cracking speed will drop.
For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted.

Session..........: hashcat
Status...........: Exhausted
Hash.Mode........: 23800 (RAR3-p (Compressed))
Hash.Target......: $RAR3$*1*0000000000000000*12b2c880*22304*61431*1*f9...999*35
Time.Started.....: Sat Apr 01 19:13:35 2023 (2 secs)
Time.Estimated...: Sat Apr 01 19:13:37 2023 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (.\pass.lst)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:      114 H/s (108.06ms) @ Accel:1 Loops:16384 Thr:256 Vec:1
Recovered........: 0/1 (0.00%) Digests (total), 0/1 (0.00%) Digests (new)
Progress.........: 238/238 (100.00%)
Rejected.........: 0/238 (0.00%)
Restore.Point....: 238/238 (100.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:245760-262144
Candidate.Engine.: Device Generator
Candidates.#1....: 123456 -> alpha
Hardware.Mon.#1..: Temp: 48c Fan: 36% Util: 13% Core: 210MHz Mem:1982MHz Bus:16

Started: Sat Apr 01 19:13:21 2023
Stopped: Sat Apr 01 19:13:39 2023
Reply
#4
Thanks, but judging by the output of your attack the password is not within your wordlist. If you want to confirm your setup is working correctly try an attack on the example hash.

Code:
hashcat.exe -m 23800 -a 3 $RAR3$*1*ad56eb40219c9da2*834064ce*32*13*1*eb47b1abe17a1a75bce6c92ab1cef3f4126035ea95deaf08b3f32a0c7b8078e1*33 hash?l?l?l
pause

If this yields a result then your password is not correct in conjunction with your hash.
Reply
#5
The given example works as expected. But I assure you that the password is in the wordlist.

I tried using the mask attack and explicitly wrote the correct password as the mask, and the result was the same, hashcat exhausted.

So either rar2john generated a wrong hash or something's wrong with hashcat. Or I don't know...
Reply
#6
As you have mentioned, the possibility of rar2john being at fault could very well be. I would suggest at this time that perhaps the hash it has generated is not valid to be used with hashcat. In that scenario, you are welcome to attempt the password with John to confirm the generation of the hash is correct. Otherwise, hashcat would be working as intended.
Reply
#7
I also have *35 at end of hash and cracked it successfuly.

For hash generating I used john-1.9.0-jumbo.

(04-01-2023, 07:16 PM)kovapatrik Wrote: Here it is:

Code:
OpenCL API (OpenCL 2.1 AMD-APP (3516.0)) - Platform #1 [Advanced Micro Devices, Inc.]
=====================================================================================
* Device #1: AMD Radeon RX 6800 XT, 16256/16368 MB (13912 MB allocatable), 36MCU

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

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Optimizers applied:
* Zero-Byte
* Single-Hash
* Single-Salt

ATTENTION! Pure (unoptimized) backend kernels selected.
Pure kernels can crack longer passwords, but drastically reduce performance.
If you want to switch to optimized kernels, append -O to your commandline.
See the above message to find out about the exact limits.

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 1723 MB

Dictionary cache hit:
* Filename..: .\pass.lst
* Passwords.: 238
* Bytes.....: 1717
* Keyspace..: 238

The wordlist or mask that you are using is too small.
This means that hashcat cannot use the full parallel power of your device(s).
Unless you supply more work, your cracking speed will drop.
For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted.

Session..........: hashcat
Status...........: Exhausted
Hash.Mode........: 23800 (RAR3-p (Compressed))
Hash.Target......: $RAR3$*1*0000000000000000*12b2c880*22304*61431*1*f9...999*35
Time.Started.....: Sat Apr 01 19:13:35 2023 (2 secs)
Time.Estimated...: Sat Apr 01 19:13:37 2023 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (.\pass.lst)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:      114 H/s (108.06ms) @ Accel:1 Loops:16384 Thr:256 Vec:1
Recovered........: 0/1 (0.00%) Digests (total), 0/1 (0.00%) Digests (new)
Progress.........: 238/238 (100.00%)
Rejected.........: 0/238 (0.00%)
Restore.Point....: 238/238 (100.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:245760-262144
Candidate.Engine.: Device Generator
Candidates.#1....: 123456 -> alpha
Hardware.Mon.#1..: Temp: 48c Fan: 36% Util: 13% Core: 210MHz Mem:1982MHz Bus:16

Started: Sat Apr 01 19:13:21 2023
Stopped: Sat Apr 01 19:13:39 2023
Reply
#8
I have just guessed that it was the *35 ending which caused the problem, because it wasn't listed as an example and I didn't know its meaning.

In the meantime I have opened an issue on the john GitHub repository, where they confirmed that john cannot "crack" my old DOS RAR file.

Edit:
I've checked your log once again and hashcat did also got exhausted in your case, which means it didn't cracked it!
Reply
#9
What log? That's your log.

(04-10-2023, 03:16 PM)kovapatrik Wrote: I have just guessed that it was the *35 ending which caused the problem, because it wasn't listed as an example and I didn't know its meaning.

In the meantime I have opened an issue on the john GitHub repository, where they confirmed that john cannot "crack" my old DOS RAR file.

Edit:
I've checked your log once again and hashcat did also got exhausted in your case, which means it didn't cracked it!
Reply
#10
Oh shit xd my bad
Reply