7z hash problem, hashcat reports "Salt Value Exception"

[NotMyName]

Hello. I used both 7z2hashcat64-1.4.exe and 7z2john.pl to extract the hash from a 7z achieve I've bone-headedly forgotten the password for, both generate the same hash file. When I try to load the file, hashcat reports "salt-value exception" and won't load the hash. The starting string for the hash is "$7z$2$19$0$$16$" if that helps. Using hashcat 6.1.1 on a Win10 machine. Any idea what the issue might be?

I *think* I have a good idea of the words/characters I used for the password, I've been looking for a python script or something that tries to open the 7z file directly using a combination of those words/symbols (rather than extracting the hash), but I can't find anything that works. I'm in tech, but don't know much about hashes beyond generating SSLs for certs. Any advice is appreciated!

[philsmd]

difficult to say... you could try to run the example hash from https://hashcat.net/wiki/example_hashes AS-IS first and if that works try to adapt it and see which "field" when changed make the hash not work within hashcat.

Maybe you could also mention how long the hash is and the lengths of some fields too (see https://github.com/philsmd/7z2hashcat , length of encrypted data, length of decrypted data, length of data for CRC32, coder attributes) etc

[NotMyName]

Thanks for the quick reply! Hash file is 280KB, it's super long. As for the additional data, do I just take the initial string I posted and match it against the table values on the github page? So...

7z
2 = LZMA2
19 - iterations
0 - salt length
blank/empty - hex output of salt
16 - initialization vector
2fbe9f37cc866475ef04ea4983b85041 - initialization vector in hexadecimal
1427480282 - CRC32 checksum
143152 - data length
146985 - output length of AES decrypt
146985 - length of data for CRC32
0b - decompressor attributes

[NotMyName]

Using the example 7z hash WITHOUT the "-O" option appended failed, but when I added that option it cracked the example:

Code:

Session..........: hashcat
Status...........: Cracked
Hash.Name........: 7-Zip
Hash.Target......: $7z$0$19$0$salt$8$f6196259a7326e3f0000000000000000$...703f96
Time.Started.....: Wed Oct 21 10:08:07 2020 (1 sec)
Time.Estimated...: Wed Oct 21 10:08:08 2020 (0 secs)
Guess.Base.......: File (hashcatDic.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:        2 H/s (9.66ms) @ Accel:4 Loops:4096 Thr:64 Vec:1
Recovered........: 1/1 (100.00%) Digests
Progress.........: 3/3 (100.00%)
Rejected.........: 0/3 (0.00%)
Restore.Point....: 0/3 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:520192-524288
Candidates.#1....: hash -> hashcat
Hardware.Mon.#1..: Util: 19% Core:1283MHz Mem:2000MHz Bus:16

[NotMyName]

I'm not clear on what you suggest to do now that I cracked the example hash in relations to my hash that's reporting the salt issue. Am I trying to get the working example hash to report the identical error by manipulating the fields to determine which field is causing the error?

[philsmd]

It seems with your configuration this specific check triggers:
https://github.com/hashcat/hashcat/blob/...600.c#L591

so the data specified in the hash is smaller than the expected decrypted data. Which is kind of weird . Are you sure that 146985 is the right value and is present twice in your hash line ?

Not sure when this could happen. We might need to remove or change this check... but we also need to understand when this happens. Most probably when the compression made the raw data larger, instead of smaller !? So compression basically made it worse

can you verify that this is also where it fails for you by compiling hashcat with that check commented out ?

I have no clue what you mean with the "-O" check, I can't reproduce this problem here.

Does the benchmark work for you without errors (hashcat -m 11600 -b) ?

[NotMyName]

Here it is exactly (hash omitted):

Code:

$7z$2$19$0$$16$2fbe9f37cc866475ef04ea4983b85041$1427480282$143152$146985$<hash omitted>$146985$0b

I don't have module_11600.c in my modules, there are only module_11600.dll & module_11600.so. I'm on Windows 10, I downloaded 6.1.1, extracted the folder and just execute the exe from the command line in the folder. Is module_11600.c only present in the Linux version?

Running without the trailing -O option results in this:

Code:

C:\Users\...\hashcat-6.1.1>hashcat.exe -a 0 -m 11600 7zhash.txt hashcatDic.txt
hashcat (v6.1.1) starting...

OpenCL API (OpenCL 2.1 AMD-APP (3004.8)) - Platform #1 [Advanced Micro Devices, Inc.]
=====================================================================================
* Device #1: Ellesmere, 8128/8192 MB (4048 MB allocatable), 36MCU

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

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

Applicable optimizers applied:
* Zero-Byte
* Single-Hash
* Single-Salt

ATTENTION! Pure (unoptimized) backend kernels selected.
Using pure kernels enables cracking longer passwords but for the price of drastically reduced performance.
If you want to switch to optimized backend kernels, append -O to your commandline.
See the above message to find out about the exact limits.

Watchdog: Temperature abort trigger set to 90c

Initializing backend runtime for device #1...
C:\Users\...\hashcat-6.1.1>

So it seems to go away at the initializing backend runtime, just returns me to the command prompt.

hashcat -m 11600 -b produced a very not good response, my monitors all went immediately blank and my Video Card fans went to full speed. I waited for a few minutes to see if the video would return, but the noise of the fans started concerning me and I restarted the machine.

[philsmd]

well, that seems to be a completely different issue. probably an issue with your hardware / configuration / setup.

I'm pretty sure if you test with a modern NVIDIA rig or similar that shouldn't be the case.

I try to focus on the problem with the 7-Zip hash here but of course you should also try to find a solution for the other problem (I think it doesn't have to do anything with 7-Zip and other algorithms might also be affected, just run hashcat -b).

Back to the original problem, I think we need to create a similar test hash for which we know the password that also has the exact same problem "output length of AES decrypt > data length" (compressed size > decompressed size, packed size > unpacked size).

With a full example that has exactly that problem it's much easier to troubleshoot.


The files I mentioned of course talk about the source code of hashcat ("hashcat sources" here https://hashcat.net/hashcat/ or better the most recent version @ https://github.com/hashcat/hashcat) of course you do not find the souce code in the binary release version. That's why I said it would be great if you could compile it yourself.

There are even build instructions for windows in the github repository: https://github.com/hashcat/hashcat/blob/...D_MSYS2.md and https://github.com/hashcat/hashcat/blob/..._CYGWIN.md (depending if you are using MSYS2 or CYGWIN)

[NotMyName]

Yep, I think it's probably a driver issue or something. I'm running an Radeon 8GB DDR5 card, does what I want it to do, but not NVIDIA.

I'd be happy to help create a test hash, just tell me what you need me to do. I think I recall all the steps I went through when I created the file in 7zip. I may not have created a compressed file since then, so maybe the previous settings are still selected in the program.

I haven't messed with compilers and the like, besides compiling Marlin for my 3D printer. I'll give it a go.

[philsmd]

do you use 7-Zip software from https://www.7-zip.org/ to compress the file ?

I also noticed that your initialization vector is using the full 16 bytes while the 7-Zip application only uses 8 normally.

I think it would be enough to have an example hash which has exactly that property (data length < output length of AES decrypt) and a data length of course under the 320 KB limit to make it load in hashcat.

I'm not sure if this is easy to generate, because in my experience the compressed data is always smaller or equal size compared to the raw data (the LZMA2 algorithm is able to detect that case and not generate huge output if uncompressed data is smaller, I think).
Maybe this can only be generated with an alternative program ? or if this optimization is turned off ?