Three bytes in a zip file

Michael Schierl schierlm at gmx.de
Fri Apr 7 11:25:04 UTC 2023


Hello,


Am 06.04.2023 um 23:59 schrieb Larry Doolittle:

> Do you know of any tooling that can help decode zip file contents in general?
> Ideally something that could be absorbed into diffoscope?
> Maybe that one-liner above would be a useful addition to diffoscope.

I don't know.

I would assume that the usual commercial reverse engineering or forensic
applications would also include a dissector for .zip files, but those
could probably not be included into diffoscope anyway.

> I took a quick look for the documentation you quoted.
> That's proginfo/extrafld.txt in Debian's zip source package, right?

I used <https://infozip.sourceforge.net/doc/appnote-19970311-iz.zip>
(yes I am oldschool and still have that old reference documentation on
my hard disk :-D).

But the documentation you quoted looks more recent and contains way more
extra fields than the "old" Info-Zip document. Probably I'll refer to it
in the future :-)

> It sure looks reverse-engineered.  I guess I shouldn't expect anything
> different for a package where upstream source ends in 2008.  :-/

... implementing a previously proprietary file format from the '80s.

> Bad: the only time stamps left in the file are DOS-style implied-local-
> timezone.  So a zip file prepared with TZ=UTC (as needed for reproducibility)
> will unpack to files with future timestamps (if unpacked shortly after being created)
> for non-expert users in half the globe.

Assuming you have "real" timestamps in your ZIP files. When I distribute
ZIP files, I often touch all files to UNIX epoch anyway as I don't want
to leak the exact time I have built/compiled them. But YMMV.

Another option would be to use an UTC-12:00 timezone like TZ=Etc/GMT+12
for building the .zip file to ensure the files are "old enough" for
every place in the world.


Regards,


Michael


More information about the rb-general mailing list