Recovered a 7z password with hashcat, but it's not the right one

[v01d]

I am trying to recover a 7z file, but have forgotten the password. It's completely AES-256 encrypted (i.e. not even the filenames are available).

Steps:

Generated hash file with 7z2hashcat.pl

Ran a mask attack using

Code:

hashcat -a 3 -m 11600 my.hash masks\rockyou-7-2592000.hcmask

After ~55 hours, hashcat completed with status cracked

The password identified in the hashcat.potfile is rejected by 7-zip

I found a discussion on hash collisions with old Office files here: https://security.stackexchange.com/a/211924

Is 7zip similarly vulnerable to hash collisions?

I would just try the steps in the linked post and see if I could generate more passwords, but given it could tie up my GPU for weeks, I'd appreciate any thoughts!

[Mem5]

Can you compare the resulting hash with 7z2john.py to check it's the same?

[philsmd]

Is the content also compressed ? How does the hash start ? With $7z$1$19$... (see https://github.com/philsmd/7z2hashcat#ex...ash-format) ?

Which version of hashcat do you use ? do you use latest version of all tools (7z2hashcat / hashcat ) ?

[v01d]

Thanks for the replies.

Is the content also compressed ? How does the hash start ? With $7z$1$19$... (see https://github.com/philsmd/7z2hashcat#ex...ash-format) ?

Which version of hashcat do you use ? do you use latest version of all tools (7z2hashcat / hashcat ) ?

hashcat v6.1.1 and latest 7z2hashcat from GitHub as of 23rd August.

Hash file starts with $7z$0$19$0$, so uncompressed?

I will generate a hash with 7z2john to compare (does it matter whether Python or Perl version is used here?)

[philsmd]

you could try with --keep-guessing and see how many false positives you get.

Since it's a crc32 checksum it's not impossible (the decompression errors in case of compression of course would prevent a lot of "wrong results", but since it's not compressed false postives are much more likely, but still quite difficult to get very many because of the 2^19 iteration cost)

[v01d]

you could try with --keep-guessing and see how many false positives you get.

Since it's a crc32 checksum it's not impossible (the decompression errors in case of compression of course would prevent a lot of "wrong results", but since it's not compressed false postives are much more likely, but still quite difficult to get very many because of the 2^19 iteration cost)

So just start the same mask attack again with --keep-guessing? Or is there a way to tell hashcat to start where it finished last time?

[philsmd]

it's not really safe to do it this way, but you could for instance use something like this:

Code:

hashcat --stdout -a 3 [THE_MASK] | grep -n -m 1 '^[THE_FALSE_POSITVE_PASSWORD]$'

then you could get the total number of password candidates and calculate a percentage.

if you have the percentage value, you could for instance start a few percent earlier (to be safer) and use --skip (or short -s) with a value that is the same percentage, but multiplied by the keyspace (which is not the total number of password candidates, see https://hashcat.net/faq#what_is_a_keyspace) and then run the original mask with this skip (-s) value (and of course do not forget to add --keep-guessing).

Again, this is not guaranteed to leave no gaps between the previous run and the new skip/restore value, therefore a --skip value (slightly) below the one calculated is required and this "hack" shouldn't be used in general, because it's a little bit dangerous due to the nature of highly parallelized execution with your OpenCL/CUDA devices. Often there are other means to restore in a more safer way (using --restore and/or --skip with the restore point value etc, but I'm pretty sure you didn't keep the old hashcat.restore file or any screenshots etc)