pkzip_fmt does not support bzip2 compression type

[russdill]

I have a zipfile with bzip2 compressed entries (compression type 'c'). I was initially confused as to why john wasn't accepting my zip2john generated hash as no useful error message was generated. Fortunately, enabling debugging produced a good trail to follow.

I located a file within the zip with a 'stored' compression type and used that file to allow me to continue cracking the password on the zip.

It'd be useful if john-the-ripper could support either the bzip2 compression method, or if zip2john could ignore compression formats not supported by john-the-ripper. The latter would hopefully produce a useful error message if no files were found within the zip with the supported compression format, or choose a file that used a supported compression format if one exists.

[russdill]

(Side note, I did finally receive a password, but the password did not work on the file I generated the hash for. I'm attempting again with a larger stored file. The data in the hash is much larger, so the process is going at about 1/20th the speed)

[magnumripper]

Thanks for reporting, I wasn't aware of this at all.

[magnumripper]

Bug: We must report unsupported schemes, and/or look further for supported ones. Enhancement: We should support bzip2! Good thing it didn't chug along and seem to work with no chance of ever cracking it though...

[magnumripper]

(Side note, I did finally receive a password, but the password did not work on the file I generated the hash for. I'm attempting again with a larger stored file. The data in the hash is much larger, so the process is going at about 1/20th the speed)

Perhaps if you keep attacking that small file with --keep-guessing option, you'll crack it quicker. But that might be unfeasible if there's too many false positives.

[russdill]

Thanks, ya, I'd never seen a zip file utilizing the bzip2 compression scheme before. I'm guessing it's pretty rare. No idea what drove the creator of this zip to utilize it, the zip really isn't that large. Thanks for the pointer to --keep-guessing.

[magnumripper]

The Info-ZIP command-line program (3.0) doesn't seem to have any option for bzip2, and the -c option is for something else. Could you please share the first few fields from zip2john for that file?

Eg. $zip2$*0*1*0*(...)

Also, what program did you find that supports this?

[magnumripper]

Oh I found it now, from zip -h2

[magnumripper]

zip2john doesn't output a hash (and never did, I tried all the way down to 1.7.8-jumbo-8) for archives using bzip2, so I now removed the bug label. You get (and always got) a proper warning message for such archives:

$ zip -Z bzip2 -e test.zip john.o
Enter password:
Verify password:
  adding: john.o (bzipped 74%)
$ ../run/zip2john test.zip
ver 4.6 test.zip/john.o is not encrypted, or stored with non-handled compression type

So this is now just an enhancement issue: Add support for it. I have yet to encounter such archive in the wild though.

As for the OP, I have no idea how @russdill got an uncrackable hash but there was probably some confusion of some sort.

[magnumripper]

Russ now sent me the archive leading up to OP (thanks!) and indeed zip2john does produce a hash. I need to look further. The compression type 'c' mentioned in OP is nowadays reported as 'type=12'.

[magnumripper]

OK, so we do have a problem when there's a mix of stored and bzip2-compressed files in an archive.

Here's my experimental fix:

diff --git a/src/zip2john.c b/src/zip2john.c
index 86942d005..665c2ffa4 100644
--- a/src/zip2john.c
+++ b/src/zip2john.c
@@ -778,13 +778,18 @@ static int process_legacy(zip_file *zfp, zip_ptr *p)
 
 		scan_for_data_descriptor(zfp, p);
 
+		if (p->cmptype != 0 && p->cmptype != 8) {
+			fprintf(stderr, "%s/%s is not encrypted, or stored with non-handled compression type=%"PRIu16"\n",
+			        zfp->fname, p->file_name, p->cmptype);
+			return 0;
+		}
+
 		// Ok, now set checksum bytes.  This will depend upon if from crc, or from timestamp
 		if (p->flags & FLAG_LOCAL_SIZE_UNKNOWN)
 			sprintf(p->cs, "%02x%02x", p->lastmod_time >> 8, p->lastmod_time & 0xFF);
 		else
 			sprintf(p->cs, "%02x%02x", (p->crc >> 24) & 0xFF, (p->crc >> 16) & 0xFF);
 
-
 		fprintf(stderr,
 		        "%s/%s PKZIP%s Encr: %s%scmplen=%"PRIu64", decmplen=%"PRIu64", crc=%08X ts=%04X cs=%s type=%"PRIu16"\n",
 		        jtr_basename(zfp->fname), p->file_name,

As for the false positives, with the above fix and attacking that archive we should be able to early reject a lot, and there should be no false positives at all.

[magnumripper]

With that fix merged, I'll now remove the bug label, and this issue is again just about adding support for bzip2 to the format.