Repository navigation
Minizip fails to extract password protected zip file #527
Description
We are observing that minizip is failing to extract a password-protected file, even if a valid password is provided.
In case of an invalid password, the library throws an error stating invalid password.
Need to look into this issue ASAP.
We are observing this issue on the Windows version of the library.
Activity
nmoinvaz commentedon Oct 23, 2020
You will have to provide more details.
pp771 commentedon Oct 23, 2020
Can you tell me under which scenario "PASSWORD_ERROR" is thrown, we get error code '8' for "PASSWORD_ERROR"?
We have confirmed that Winzip is successfully able to extract the file using the same password.
nmoinvaz commentedon Oct 23, 2020
That is not a error number I am familiar with.
pp771 commentedon Oct 26, 2020
Ignore the earlier message, The error number is -108 i.e. MZ_PASSWORD_ERROR(-108).
And the api failing is unzOpenCurrentFilePassword(uf, password);.
The API is expected to return UNZ_OK(0).
pp771 commentedon Oct 26, 2020
nmoinvaz commentedon Oct 26, 2020
What version of the library are you using? What type of encryption is the zip using?
pp771 commentedon Oct 26, 2020
There is no issue when encrypted using minizip. The issue is with other libs encryption.
pp771 commentedon Oct 26, 2020
The issue is observed with "2.9.1", "2.10.0".
pp771 commentedon Oct 26, 2020
As per xceed API, by default algo is "xemCompatible". We do not set anything explicitly.
nmoinvaz commentedon Oct 26, 2020
I don't use Xceed. Please make sure you are using the latest version of minizip library as older versions may have bugs related to this. Attach a zip file and the password.
Eswcvlad commentedon Nov 26, 2020
I actually have the same issue after trying to upgrade from 1.2 to the latest version with both legacy and new APIs and it seems like I've figured out, what is causing it.
Here is an example archive (password is "123"):
compressed.zip
It is encrypted with basic ZipCrypto, has data descriptors and NTFS file time extra fields.
Decryption is actually correct, but the problem is in the verification. It should use bytes from the original "last mod file date/time" fields in the local file header, but instead it uses the converted file_info.modified_date as the baseline, which can get overwritten from NTFS/UNIX time extra fields. And, as an example in the archive above, timezone is different in the NTFS extra field, so there is a mismatch.
So, as expected, when I comment the
mz_zip_ntfs_to_unix_time(ntfs_time, &file_info->modified_date);line in mz_zip.c it works fine as it starts using the original field for verification.
nmoinvaz commentedon Nov 27, 2020
Hmm. I'm not sure how I want to fix that. I don't want to add a new field for
modified_timetomz_file_info.Fixed mismatching NTFS date/time causing decryption failure. #527
nmoinvaz commentedon Dec 1, 2020
This should be resolved in the
devbranch now.Eswcvlad commentedon Dec 2, 2020
Looks like it fixed the issue for me. Thanks!
Not sure though, if it is the same issue @pp771 was having.
pp771 commentedon Feb 10, 2021
This issue is not fixed for our encrypted files. We still get the -102 error code with the latest Minizip 3.0 version. However, the same encrypted files are getting decrypted using other libs and tools like Zip-archive, Winrar.
Please look into this.
nmoinvaz commentedon Feb 10, 2021
Please provide an example zip and more debug info.
nmoinvaz commentedon Feb 10, 2021
Also feel free to track down the issue yourself and submit a PR.
kippler commentedon Dec 23, 2022
oops. I'm sorry. I had posted the comment in the wrong place. Your code has no problems. I'm so sorry again.
nmoinvaz commentedon Dec 23, 2022
Can you submit a PR?