Menu
▾
▴
#19 Zip 2.0?
Recently I found some classes.dex files inside an Android framework.jar that claim to have been zipped up (using store mode) with Zip 2.0 and requiring a minimum version of Zip 2.0 to extract ... however, I cannot seem to find this version existing anywhere, the earliest version source code posted here is Zip 2.3...
When I attempt to match this files characteristics 1:1 I get an output that says compressed with Zip 3.0 and requires a minimum software version of 1.0 ... where can I find the exact version that will recreate 2.0 for both of these fields?
The term "version needed to extract" refers to the version of the zip specification and not the version of any zip/unzip implementation. See section 4.4.3.1 of APPNOTE.txt at https://pkwaredownloads.blob.core.windows.net/pem/APPNOTE.txt for the details.
That then means you just need an unzip implementation that supports version 2 or better of the APPNOTE.txt specification.
I'm not aware of any unzip implementation that doesn't support version 2 of the spec (which was written in the early 1990s)
If you are having trouble reading your zip file, can you share a link to it? if it isn't too big could you attach it to a post here?
So what? Which part of "minimum" is unclear to you?
According to the APPNOTE:
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
Version Needed To Extract = 2.0 for an archive member means that one
of the following features was used:
File is a folder (directory)
File is compressed using Deflate compression
File is encrypted using traditional PKWARE encryption
I just ran a quick test with Zip 3.0 which seemed to leave that value
at 1.0 (the default) for a directory, which looks to me like a bug, but
I doubt that it would cause any practical effects. A text file which
was stored got 1.0, and a text file which was deflated got 2.0 (both as
expected).
Why do you want to do that? Is there some actual problem which you
are trying to solve?
Which program was used to make the archive in question? I doubt very
much that it was Zip 2.0.
I wouldn't do it, but if you have time to waste, there is a Zip 2.0
kit (source plus VMS (VAX?) binaries) here:
but, as those source files are more than thirty years old (with all the
bugs that that implies), I don't know if you'll be able to make it work
on your (unspecified) system. I also don't know if it "will recreate
2.0 for both of these fields".
You could also modify the Zip source code to put any data you want
into an archive, but whether that would make any sense is a different
question.
CHANGES says that this was fixed in Zip version 3.1d03. Current
development code (3.1e23) works correctly.
I guess it has become an episode of "how do I recreate this original file" more than anything being "wrong" per se. Let me illustrate it better.
Here's the zipinfo -v of the classes.dex files inside a framework.jar - they are created with this "metadata"
When I mod a classes.dex file and re-add it with latest Zip bin it comes out like this ( zip -0 -X framework.jar -v classes5.dex)
When using the 2.0 version you linked it's definitely closer, but he min software version is also off lol - what is going on here?
Comparing the first zipinfo listing with the most recent, the differences are the following fields
All but the "minimum software version required to extract" you would expect to change if you've modified the file.
The " minimum software version required to extract" has changed from 2.0 to 1.0, so I assume that is the one you are concerned with.
classes5.dexis not encrypted, is not a directory and does not use deflate compression. That means the 1.0 version is fine.A root-cause is down to the code that wrote the original zip file and set the version to 2.0 incorrectly.
Regardless, the change from 2.0 to 1,0 doesn't make any difference to the standard zip/unzip utilities.
Is there something special in your workflow that needs this field to match? Can you explain more why it matters?