How to tell if ZIP is compressed or not?

[meow]

Hi,

I used zip2john yesterday to get the hash for a ZIP file. It turned out to be a PKZIP format file. As far as I can tell, Hashcat currently supports this format, yes? I am uncertain because I came across some discussions about this format specifically that left me with the impression that PKZIP may not be fully supported. Those must have been old forum threads. Or was this in relation to data size limit? There are current discussions in the forums and on GitHub, pointing out that the hash size that Hashcat can handle are limited (to 8 kB compressed WinZip?).

I did get the hash I needed using zip2john. Once I had the hash I was able to brute force it in 3 seconds using Hashcat. But I had to decide between what mode to specify, 17200 for compressed or 17210 for uncompressed. I think my ZIP file was compressed, so it returned some messages about "signature unmatched" (if memory serves me) for one or the other. Once I tried the other mode, it worked like a charm. So my question is, how do you know if a ZIP is compressed or not? How do you decide between 17200 and 17210?

zip2john outputs this first line:

Code:

ver 1.0 FileName.zip/FileName/FileName.zip PKZIP Encr: cmplen=199, decmplen=187, crc=77ED3C74

What is this? What do I see here? Specifically, what is "cmplen" and "decmplen" in English? I have searched the web for a while and not found any indication of what this means, other than that it indicates some kind of properties of the file and that "cmplen" is 0 for when the program fails to extract the hash. I suppose "Encr" stands for "encryption"? Can this string tell me if my ZIP file is compressed or not? That would be very useful then so I know how to use Hashcat with it.

The CRC in the output did not match the CRC of the ZIP file when I check it myself. What does this mean then?

[Snoopy]

im not so familiar with zip2john, why dont you just test it yourself? first plz update zip2john to latest version (my version is 2.0 and i updated it long time ago)

fast test, first line no compression, second line fast compression, as you can see cmplen is "lenght after compressoion, and SHOULD* be significantly lower wenn using compression
* when data is not or bad compressable, like video-files these assumption can be wrong
crc is the crc from the file within the zip, not the zip itself

ver 2.0 0.zip/google-mail.py PKZIP Encr: cmplen=19103, decmplen=19091, crc=5C1551BC ts=6E2C cs=5c15 type=0
ver 2.0 1.zip/google-mail.py PKZIP Encr: cmplen=6422, decmplen=19091, crc=5C1551BC ts=6E2C cs=5c15 type=8

im not quite sure whether the compression is also mentionened in this hash you get, but when hc tells you signature unmatched in seems so
UPDATE
tried some compressions and zip2john always tells type=8 for compression, and these type (0 uncompressed or 8 compressed) you can find in your hashstring, so yeah hahscat can tell whehter your given mode is right or wrong

$pkzip$1*1*2*0*4a9f*4a93*5c1551bc*0*2c*0*
$pkzip$1*1*2*0*1916*4a93*5c1551bc*0*2c*8*

[meow]

Thanks! So 0 for uncompressed or 8 for compressed. That's useful to know.

No, there was no "type" info here. Just the info on the line I posted earlier.

I can see now why you're telling me to update zip2john. I thought I already had the latest version. I downloaded it from the official JTR website (john-1.9.0-jumbo-1-win64.zip). But it's a Windows binary, so there is that. (The more I mess around with hashes, HC and JTR, the more I learn I'm using the wrong OS for the job.)

I can confirm that my ZIP file was uncompressed and the zero type is an indication of that.
$pkzip2$1*1*2*0*c7*bb*77ed3c74*0*33*0*c7*77ed*aee0*712...*$/pkzip2$

As a side note, pasting the hash in has an unexpected result. Why is that? (Another case of using the wrong OS?)

17200 against hash file
Hashfile '.\hash.txt' on line 1 ($pkzip...d2f3432781e*$/pkzip2$): Hash contains unsupported compression type for current mode
No hashes loaded.

17210 against hash file
OK. Success!

17210 against paste
Hash'*1*2*0*c7*bb*77ed3c74*0*33*0*...': Signature unmatched
No hashes loaded.

The safest bet is to put the hash in a hash file, even if it's just a single hash.

I see now what "cmplen" and "decmplen" means. Thanks again! I almost had it, I suspected that "len" may mean length but I wasn't sure and I didn't get the first part of the cryptic label name. So "cmplen" is length when compressed, and "decmplen" is length when decompressed. Given your example I suppose "cmplen=6422, decmplen=19091" means 19091 bytes without compressed and 6422 bytes with compression.

[Snoopy]

Yeah the safest thing to to is to put the hash(es) into a file, for one short hash like md5 (without special chars) its okay on the commandline, but most commandlines/shells dont like special chars like * and you have to escape them (which can be also sometimes very anoying)

cmplen=6422 is the lenght of the compressed file inside the zip (the zip itself is 6548 bytes)
decmplen=19091 is the size in bytes of the originating file and the size after decompressing

JFYI
funny thing i noticed while playing around, the used compression also compresses the pw-hash
-> uncompressed zip, the extracted hash/hahsfile is about 38kb
-> with compression it is about 12kb