philsmd/7z2hashcat

WARNING: unsupported coder with codec id '0x06f10701' in file '1.7z' found.

megapro17 opened this issue · 2 comments

philsmd commented

Hey @megapro17,

thanks for reporting this issue. I've commited a patch with d50eac8

It was NOT very clear to me what exactly the problem was at the beginning because your description was basically completely missing. I also had to figure out how to produce such archives and what their characteristics and main problem is.

The root of the problem is that:

  1. codec_id: 06f10701 -> AES-256 + SHA-256
  2. your file uses these weird combination of coders/codecs: BCJ2 LZMA2:6m LZMA:20:lc0:lp2 LZMA:20:lc0:lp2 7zAES:19 7zAES:19 7zAES:19 7zAES:19
  3. the final encryption/encryption is still added to all these additional compressors and pre-processors.
  4. we didn't yet add 7zAES to the list of known coders, because that combination is very weird and actually kind of rare and difficult for a password recovery software like hashcat and jtr (john the ripper) to support cascading decryption steps

So in your case the file was using all of this (in addition to the password protection step that is again a 7zAES invokation):
coders:

  1. 7zAES
  2. 7zAES
  3. 7zAES
  4. 7zAES
  5. LZMA
  6. LZMA
  7. LZMA2
  8. BCJ2

To reproduce a minimal file with 2 7zAES invocations, you could use a command like this:
7z a -p -m0=7zAES a.7z a.txt

so basically one is the -p password protection and the extra pre-processor is added with -m0=7zAES.

Therefore a cracker would need to decrypt the stream twice. It's also strange to do it like this because AFAIK (as far as I know) the IV (initialization vector) and salt (<- actually almost always true) are completely the same. Therefore the AES key generated should also be the same one... it adds little extra protection (except that the raw data AES decryption needs to be involved 2+ times, but it should be possible to skip the additional key derivations, because of the same pass+iv+salt combination).

Not sure if any password recovery tool is able to support such archives currently or in the future. It's a very strange way to protect the data with multiple 7zAES pre-processors that add little to none extra protection (if you already have the key).

Do you agree?
I guess that if you really want to crack these type of archives, you would need to request the password recovery software authors (hashcat etc) to implement them or help them code the changes needed.

Thanks

megapro17 commented

It was NOT very clear to me what exactly the problem was at the beginning because your description was basically completely missing. I also had to figure out how to produce such archives and what their characteristics and main problem is.

Sorry for not posting the details, it's because it was an archive with the default ultra settings, no changes, created with 7-Zip 24.07.

You can create it like this: 7z a -mx9 1.7z -p 7z2hashcat64-2.0.exe

That's interesting why recent 7zip behaves like this. It turns out that archives created recently cannot be cracked at the moment.

Thank you for your effort and research