7z hash problem, hashcat reports "Salt Value Exception"
#11
It isĀ 7-Zip software, v 19.00 (x64) 2019-02-21

I just generated a new hash compressing a folder, but it resulted in a 588KB file. How do I keep it under the 320KB limit? I didn't change anything in the settings in 7-Zip, so I assume it used the same as last run. Compression method is LMZA2, Dictonary is 16MB, word size is 32, Solid Block is 2GB and encryption method is AES256.

Here's the resulting hash, doesn't look exactly the same:

$7z
$2
$19
$0
$
$16
$46f265faf249bb4d06452b675b80d871
$522565263
$300752
$300752
hash
$286389
$18
Reply
#12
This hash should load with hashcat without problems.


No, 300752 bytes is your data length now... you can't compare it to the hash length, because in hexadecimal it will be at least twice the size (the hash is always in hexadecimal).

in this case data_len is not less than the unpack size... but it's still quite close, not sure what exactly you are compressing to get such results. normally compression works much better and the compressed data is much smaller than the raw data.
Reply
#13
I know this is a couple of years old now, but I've just run into the same problem.

The values from my hash (excluding the 7z data itself) are:

$7z
$2
$19
$0
$
$16
$ce372a5c20db3637e64b7f825364f13c
$1069288323
$159312
$176135
$hexdata
$176135
$10

The 7z file in question contains a bunch of PNG images (photos of documents), so probably hard for additional compression, leading to the situation where it is not compressed. The archive was created by the ZArchiver app on Android.

Commenting out the check mentioned in #6 allows hashcat to run, but it has not yet found the passphrase. I can test with an archive with a known passphrase if that would be useful.
Reply