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