[Bug]: zip2john not parsing valid pkzip encrypted zip archive

[s3inlc]

A zip archive encrypted with Keka (https://www.keka.io/) is using the old pkzip encryption format. But zip2john does not produce any hash. I assume it misreads it at some point as another archive type, because when I enforce it to use the process_old_zip() function, it is able to parse the file data and it produces a hash which can successfully be cracked.

Steps to reproduce

• Encrypt a file with Keka
• ./zip2john test.txt.zip produces no output.

System configuration

Archive generated on macOS, zip2john tested on Windows and macOS showing the same behavior.

An example archive is attached, the password is hashcat. test.txt.zip

[kholia]

Perhaps the following commit caused this breakage?

commit e36b04604bca4e46f01c3d4548c75c1e87e3b934
Author: Dhiru Kholia <dhiru.kholia@gmail.com>
Date:   Fri Nov 3 17:27:12 2017 +0530

    Add support for PKWARE's SecureZIP

In particular, the following line seems to be problematic,

+ } else if (flags & 1 && (version == 51 || version == 52 || version >= 61)) {    /* Strong Encryption?, APPNOTE-6.3.4.TXT, bit 6 check doesn't really work */
+     // fseek(fp, filename_length, SEEK_CUR);
+     // fseek(fp, extrafield_length, SEEK_CUR);

[kholia]

The version >= 61 check is shaky and wrongly triggers in case of Keka generated archives.

I don't have a solution (currently) to retain support for Strong Encryption while not breaking things. I need to experiment a bit more.

[s3inlc]

Thanks for looking into the issue. Let me know if you need anything more at a later point.

[magnumripper]

@kholia how about this?

diff --git a/src/zip2john.c b/src/zip2john.c
index a0c873cfa..445744e1b 100644
--- a/src/zip2john.c
+++ b/src/zip2john.c
@@ -395,7 +395,8 @@ bail:
                fseek(fp, filename_length, SEEK_CUR);
                fseek(fp, extrafield_length, SEEK_CUR);
                fseek(fp, compressed_size, SEEK_CUR);
-           } else if (flags & 1) { /* old encryption */
+           }
+           if (flags & 1) {    /* old encryption */
                fclose(fp);
                fp = 0;
                process_old_zip(fname);

This way, it does go into "Strong encryption" but once that fails (bails), it continues trying old encryption.

[magnumripper]

Without my patch, I got results from 19 of my old bunch of test zip files. With it, I get 22 results (of which 19 are the same as the old). This should be good to go.

[s3inlc]

I pulled the changes from the repository and now it's providing a correct hash extracted from the zip file built with Keka.

[kholia]

Thanks @magnumripper for fixing this :+1:

[s3inlc]

Thanks for providing a fix that quickly, nice work :) I guess I can close this issue then.