hashcat Forum

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
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!

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

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 ) ?

Thanks for the replies.

(08-29-2020, 07:55 AM)philsmd Wrote: [ -> ]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?)

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)

(08-29-2020, 02:07 PM)philsmd Wrote: [ -> ]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?

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


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)