Ran into an issue: "Invalid zip file error - the archive is not encrypted"

[hugmyndakassi]

Hi, I have a file whose contents are definitely encrypted - this much I know.

The issue happens with version:

$ zip-password-finder --version
zip-password-finder 0.5.1

which is the current version on crates.io.

file on Ubuntu 22.04 reports:

Zip archive data, at least v2.0 to extract, compression method=store

unzip as packaged with Ubuntu - version reports as 6.00 (or Ubuntu package as 6.0-26ubuntu3.1) - reports for each of the contained files:

need PK compat. v5.1 (can do v4.6)

The file names don't seem to be encrypted.

7-Zip (pkg: 16.02+dfsg-8) appears to be able to handle the file format, but the password is obviously deemed wrong.

Any idea what I could try, or is this simply not supported, yet? Thanks.

PS: zipdump.py by Didier Stevens also claims ZIP file is not password protected PPS: there is currently not support for zip64 is claimed by zip-rs which you use, so this could already be the issue. I also noticed that the version installable via crates.io lags behind, so going to install from a local checkout ...

[agourlay]

@hugmyndakassi I have not tested zip64 so it might be a support issue.

Thanks for adding post scriptums, the version on crates.io is indeed outdated because of https://github.com/agourlay/zip-password-finder/issues/46

BTW the underlying zip library used is https://github.com/zip-rs/zip

Try 0.7.0 and keep me posted!

[hugmyndakassi]

Hi, I apologize for the confusion. I was misled by the name zip-rs, you're of course right.

Version 0.7.0 has the exact same issue and the only output I can get it to produce is:

$ zip-password-finder -V
zip-password-finder 0.7.0
$ zip-password-finder -p ~/words.txt -i mytarget.zip
Invalid zip file error - the archive is not encrypted

I built the version locally, in case you think that makes a difference.

PS: for reference ...

overall file header:

a directory entry:

the zip file record for the same file as the directory entry above:

[agourlay]

Is it possible for you to share a test archive with me?

[hugmyndakassi]

Is it possible for you to share a test archive with me?

Afraid in this case it's not possible for the original file. But you gave me an idea to try and mimic the original file with a known password to see how to get the same flags in each respective record. If this succeeds, I'll share it here.

[hugmyndakassi]

Just FYI, using a different template in 010 Editor, I was able to get more detailed info in regard to the storage and encryption method. From that I think, it's clear that the file is at least not a ZIP64.

File record:

Directory entry:

[hugmyndakassi]

@agourlay just wondering, are you aware of any tools that purport to crack ZIP passwords and allow you to select a given member (e.g. by path) and provide a plain text version for that?

So, suppose I am looking at an archive which is password-protected, but I am in possession of some of the files contained. Is there a way to aid the cracking process (mainly speed it up) by providing the plain text version for a given member?

[agourlay]

Maybe have a look at bkcrack and check if it could be somehow be applied to your use case.

What is the state of your issue with zip-password-finder?

[RangoZhao]

You can try add '--fileNumber 1' into the command.
May be the first file is directory. It is not encrypted.

[agourlay]

FYI you could try the new 0.8.0 release.

Not only it uses an improved zip crate but I also improved the error messages for your case.

[hugmyndakassi]

Only just saw it now. I'll give it a go and report back. Thank you!

[agourlay]

@hugmyndakassi anything new to report? :)

[agourlay]

0.8.1 is out with various internal improvements

[hugmyndakassi]

I'm sorry, I totally lost sight of this.

[hugmyndakassi]

I'm so sorry. Completely lost sight of this matter,

Invalid zip file error - the selected file in the archive is not encrypted (file_number:0 file_name:directory_name/)

was the first thing I saw. Then I had to find something that wasn't a directory. Presumably there could be a heuristic that ensures that the ZIP file entry is a file or directory, skipping directories automatically.

And then it seemingly worked:

$ zip-password-finder --fileNumber 3 --inputFile ./some_zip_file.zip
Archive encrypted with AES256 - expect a long wait time
Starting 4 workers to test passwords
Generating passwords with length from 1 to 10 for charset with length 62
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
Starting search space for password length 1 (62 possibilities)
Starting search space for password length 2 (3844 possibilities) (62 passwords generated so far)
Starting search space for password length 3 (238328 possibilities) (3906 passwords generated so far)
Starting search space for password length 4 (14776336 possibilities) (242234 passwords generated so far)
Password found: ....

Alas, the "found" four character password did not actually work when attempting to unpack the file with 7-Zip.

[agourlay]

Thanks for coming back ;)

I agree that the file selection is not ideal here, there is room for improvement.

Regarding the wrong password there is already a very similar report https://github.com/agourlay/zip-password-finder/issues/185

I wonder what is special about those archives.

[agourlay]

Please try 0.9.1 which contains a fix for this kind of false positives.

[hugmyndakassi]

Please try 0.9.1 which contains a fix for this kind of false positives.

Hi, this issue seems to be resolved with 0.9.1! However, for now I had to give up after seven hours of runtime:

$ zip-password-finder --fileNumber 3 --inputFile ./some_zip_file.zip
Archive encrypted with AES256 - expect a long wait time
Starting 4 workers to test passwords
Generating passwords with length from 1 to 10 for charset with length 62
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
Starting search space for password length 1 (62 possibilities)
Starting search space for password length 2 (3844 possibilities) (62 passwords generated so far)
Starting search space for password length 3 (238328 possibilities) (3906 passwords generated so far)
Starting search space for password length 4 (14776336 possibilities) (242234 passwords generated so far)
Starting search space for password length 5 (916132832 possibilities) (15018570 passwords generated so far)
[07:00:30] ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 121016000/853058371866181866 throughput:4,608.4044/s (eta:5869776y)

[agourlay]

Happy to hear the "problems" are solved!

Sorry about compute cost, there is not much I can do right now. Can you maybe reduce the charset? Start with larger min password len?

Otherwise can we close this issue?

[hugmyndakassi]

Otherwise can we close this issue?

I think so. Thanks! In fact since I already have the button right below this text box, let me do it.