7z2hashcat

[zeroprobe]

I receive this error when attempting to get the hash 

"WARNING: only encoded headers are allowed if no raw header is present"

EDIT: Fixed, I combined the multipart archive, installed a 64bit version of Perl and made my page file huge to cope with the 22GB archive.

[zeroprobe]

Damn, I now get "data length too long and it can't be truncated"

[syb3ria]

Hello,
as users before me I get

Code:

Wide character in Compress::Raw::Lzma::Decoder::code input parameter at script/7z2hashcat.pl line 585.

7z Archive size - 38Gb, tried both 7z2hashcat.pl and 7z2hashcat-0.4.exe. Please advice.

[marpolo]

Hi!

I found that sometimes 7z2hashcat produce wrong hash for the 7z archive.
Test file is uploaded here. Password is DDD.
From 7z2hashcat I got such hash output:

Code:

$7z$0$19$0$$8$311a01fdc86ace3a0000000000000000$526341711$48$45$ba92081d93d4188a8166b7cc18ee20bb3374742d42757485f5fa85fbde7787c7d7145286db5eed0b938fa5f072afc384

Hashcat is imposible to find DDD password for this hash.
I think initial hash calculation was wrong for this particular file.

Could anyone recheck this ?

P.S. On some other files from my backup archive I also got some errors
(these files was not too big, around 200 - 500 MB):

several times:

Code:

Wide character in Compress::Raw::Lzma::Decoder::code input parameter at script/7z2hashcat.pl line 585.

and one time:

Code:

WARNING: the file 'qwerty.7z' unfortunately can't be used with oclHashcat
since the data length in this particular case is too long and it can't be truncated.
This happens only in very rare cases

p.s. Other password restore software was able to work with these files, so it seems 7z2hashcat may not work in 100% cases.

Thanks!

[atom]

Yes, I've tried to reproduce. Other software can't crack what came out of 7z2hashcat in your case. So there's a high chance 7z2hashcat has some problem

[syb3ria]

Hello, what about bigger 7z archives? It's not giving any output at all, just exits. Any change this gets fixed?

[philsmd]

Hey.

There are actually 2 known problems which I will try to investigate:
1. a problem with the lzma decompression, done by 7z2hashcat.pl, of the header (in case of a "long" file list), probably related to an issue I found with Compress::Raw::Lzma (but I will need some further investigation)
2. in some rare cases the algorithm changes from crc32 (aes_decrypt ($data)) to crc32 (lzma_decode (aes_decrypt ($data)) depending on the data length (i.e. if 7z thinks it makes sense to lzma compress it)... this needs to be implemented in the cracker/hashcat (this case unfortunately also occurs with the 7z archive provided by marpolo, see https://hashcat.net/forum/thread-4328-po...l#pid32826 , I've checked it in detail, i.e. analysed the whole 7z structure of this archive, thanks btw for this example)

for #2 I've already discussed this with @atom and we came to the conclusion that I could implement this via a hook (the hook concept is already "supported" by hashcat), to make this intermediate lzma decompress step.
Unfortunately the hash format (which we btw 1:1 took from john the ripper) does not have a field to indicate if it was lzma compressed (while 7z2hashcat.pl is able to identify all "coders" and has this information). Therefore, we actually have this info, but can't output it into the hash format without changing it (and when we do so we might end up with 2 different hash formats .... but since jtr seems to also rely on 7z2hashcat.pl now, we might decide to just change the hash format, no matter what).
This would mean that the cracker in the future needs to do the following 3 steps (but by changing the hash format we can reduce the number to 2):
1. try if crc32 (aes_decrypt ($data)) matches
2. try if the AES CBC padding attack works (this reduces the data needed withusein the hash format)
3. try if crc32 (lzma_decode (aes_decrypt ($data))) matches (the hook needs to be implemented)

(you might have already guessed it, but to make it very clear: if we know that we need to use method #1 or method #3, we do not need to try both)

I will probably update 7z2hashcat.pl soon, with some fixes and most importantly some warnings/errors such that the user knows what is going on. E.g for the problem "what about bigger 7z archives?", this might be releated to the known problem #1 (the data probably was lzma compressed to safe additional bytes/disk space), I will try to fix the decompression or at least output a warning/error (instead of the "just exit").

For the hook feature (lzma decompression after the decryption step) I will open a github issue soon and try to implement it.

As you see, there are some very unrelated problems, but we will try to fix them 1 by 1.

Maybe in the meantime, you can let me know if you still experience problems with "Wide character in..." output. They should be fixed with next release version of 7z2hashcat.pl (probably version 0.5 or highter) and I actually already pushed a fix to github (see https://github.com/philsmd/7z2hashcat/co...1241e40d1c).
Attention: I didn't provide a new 7z2hashcat.exe release yet, therefore you currently must use the latest source code (not the release version) to test if this problem still exists. If you think that the error still occurs (even with the fix), then please provide/sent me such a 7z file.
Thanks

[syb3ria]

Hello and thanks for the detailed explanation. Because of it I have just tried archiving few movies in 7z with the simple password ASD. 7z2hashcat with the fix worked like a charm, I was able to extract the hash and find the password in seconds. The archive size is 43GB but which is most important it consist of 26 folders and 121 files only. The archive I'm trying to crack is having 142 folders and 10520 files. Based on this I guess the problem on my side is related to the "long" file list instead to the actual archive size.

While waiting for the fixes I will appreciate if anyone can suggest effective way of attacking 7z if I have some of the files un-encrypted. Thank you.

[philsmd]

Thanks for the info syb3ria. Great that it at least fixed 1 of the problems you experienced.

I have now opened an issue on 7z2hashcat's github page which explains the current state of the LZMA header decompression error (aka the 'not giving any output at all' problem), see https://github.com/philsmd/7z2hashcat/issues/2

It would also be great, if the ones who experience the empty-output-problem (I think you too, syb3ria), if with the latest source code version they get a warning message (to make sure that we are really speaking about the same issue).

Thanks again

(BTW: it might be better to discuss 7z2hashcat.pl related problems on 7z2hashcat's github issue page, such that we do not spam this forum with problems about "an external tool" not included within hashcat's source code).

[philsmd]

Maybe you didn't notice it yet, but we have updated both 7z2hashcat.pl (please use version 0.9 or higher) and hashcat itself (please use the newest beta).

In addition to some bug fixes, they now also support decompressing LZMA1/LZMA data streams. The header decompression problem in 7z2hashcat.pl seems to be fixed too. Currently there are no further known problems (if you find a new problem you should definitely open a ticket on 7z2hashcat github's issue page or hashcat's github's issue page, depending on which tool complains/fails).

Some feedback would also be nice. I know, from - now-closed- github issues, that the problem of @syb3ria was fixed. Maybe also @marpolo can test and give some feedback.
Thanks