Is it possible to determine which specific version of which specific program created a given ZIP archive, based on its metadata?

And also, is the outcome of a ZIP / RAR compression affected by the hardware/software (O.S. version) configuration of the computer used for the task?

The goal: On file-sharing networks, small files (pictures, e-books...) are usually shared as compressed archives. Over time, parts of these archives can become unavailable, and since most people who downloaded the original archive extracted the individual files and then deleted them, even someone who does have all the missing files can no longer share the original archive, so anyone attempting to download it at that point will get stuck with an unusable partial file. Some such archives can have many sources but not a single complete one. If someone who has all the files from the original archive creates a new archive, if it's different from the original archive even by a single byte it won't be identified by the same hash, and those people won't be notified so that new archive won't be shared efficiently.

I have already managed to re-create uncompressed ZIP / RAR archives, so as to share them again, by copying the contents of missing files and editing their metadata to match that of files in available parts, until the archive's hash matches that of the original; I have also managed to re-create a few not-too-old RAR archives. But I'm at a loss when it comes to compressed ZIP archives, as there are many utilities that can create them, each seemingly using its own set of algorithms and parameters. Also, some of those archives were created 10+ years ago, making it even more tricky to find out what was used to create them. And if the answer to the second question above is “yes”, then it would be next to impossible to re-create those 10+ years old archives on my ~2017 computer; if the answer is “no”, then I may have a shot, provided that I can actually track down the corresponding executable (preferably as CLI, or at least “portable” GUI, which is another caveat — I looked at old versions of WinZIP which I still have on CDs, they seem to require a full-blown install to be usable, no CLI version is included, contrary to WinRAR which includes rar.exe as a CLI equivalent).

Example: One such incomplete ZIP archive has a size of 372MB, with 18MB missing. Based on the files' timestamps, it was probably created around 2003. I identified a picture set contained within a missing part in another archive: fortunately, the timestamps seem to be exactly the same, but unfortunately, the compression parameters aren't the same, the compressed sizes are different and the binary contents won't match. So I uncompressed that set, and attempted to re-compress it as ZIP using WinRAR and 7-Zip (currently installed versions), testing with all the available parameters, and checked if the output matched (each file should have the exact same compressed size and the same binary content when examined with a hex editor), but I couldn't get that result. So the incomplete archive was probably created with different software and/or version, using a different compression algorithm. Now, is it possible to know exactly, by examining the general header, individual files' headers, and other structures, what specific application was used to create it, and with which exact parameters, so as to re-create the original? Again, does the hardware have any bearing on the outcome, for instance, if using a mono-core or multi-core CPU, or a CPU featuring or not featuring a specific set of instructions? The header of the ZIP file mentioned above is as follows :

50 4B 03 04 14 00 02 00 08 00 B2 7A B3 2C 4C
5D 98 15 F1 4F 01 00 65 50 01 00 1F 00 00 00

I tried to search for information about the ZIP format header structure, but so far came up with nothing conclusive with regards to what I'm looking for.

Yet another caveat with RAR archives is that they don't seem to have a complete index of their contents in the header or footer (contrary to ZIP archives), if I'm not mistaken, each file is referenced only by its own header, making it even more difficult to figure out what used to be in the missing parts, if the archive is a bit complex and has many subfolders.

EDIT: As I replied in a comment below, the goal is not so much to know with certainty which version of which program was used to generate a particular archive, but being able to re-generate that archive from a partial download and the individual files corresponding to the missing parts. If, for instance, the archive was created using WinZIP X.Y, but 7-Zip X.Y released a year later happened to implement the same version of the ZIP algorithm, while giving control over key settings which produced that specific compression outcome, then it should do the trick just as well. But so far, the few programs/versions I tested all produced different results.


No. There is no way to determine a version or program that created a zip file. There is field in the local file header that lists the minimum version to extract. However, that would only eliminate some very old versions of some programs.

As to the output of the archive being affected by the hardware, the answer is also no. While the speed of the compression or decompression will be affected, the compression/decompression algorithm is always the same, as it us software based and is unchanged.

Can the OS or software affect the output? It could on minor, not specific levels. Again, the compression/decompression algorithms are the same. If there is extra metadata for Windows based file permissions, then its likely, but not guaranteed, that a Windows machine created it. The same goes for *Nix .dot files. That points to *Nix machine, but not always.

  • Alright then, thanks for the quick and straigthforward reply. So, is it possible to at least narrow down the most likely programs that may have been used, on a given time period ? Is the compression outcome bound to be different for every single version of every single program, or are the same algorithms commonly shared between several contemporary implementations, or several minor revisions ? (If a file was made with WinZIP, but 7-Zip used the same algorithm back then, it would be easier to download multiple versions of 7-Zip to test in batch, than to install multiple versions of WinZIP.) – GabrielB Feb 22 at 3:23
  • 1
    @GabrielB Maybe I did not make myself clear enough. You have basically a 0% chance of finding out what made it. I doubt the zip algorithm has changed much, if at all, since version 2 in the 90s. – Keltari Feb 22 at 3:52
  • Maybe I did not make myself clear enough. The goal here is not to find out what made it, per se, but to complete the existing archive by re-compressing files it is known to contain in the exact same way as they were originally. So far I failed to do that, by trying various combinations of settings made available in utilities I have on my system, mostly WinRAR & 7-Zip. Made a quick test with an old version of 7-Zip (2007) and a recent one, compressed the same folder with default ZIP settings, result markedly different. Either the algorithm has changed, or the default settings have changed. – GabrielB Feb 22 at 6:01
  • If you're still around : When you wrote "I doubt the zip alrorithm has changed much, if at all, since v2 in the 90s", well, that seems doubtful, as I can see that two contemporary softwares (WinRAR 5.40, 7-Zip 16.04) create completely different compressed streams, no matter what settings are used. What I am wondering is : is that at all predictable ? Or at least would it be possible to narrow down a list of the most likely utilities corresponding to a specific time frame -- for instance, what would have been the most common utilities used to create ZIP files around 2003, or 2006 ? – GabrielB Jun 1 at 15:01

There is one solution that the community worked out for this - but it's a matter of luck if it was implemented in your case.

If the original file was created using torrentzip then there is a checksum at the end of the file and you can use torrentzip to recreate the file, confirm the checksum and then copy the file back into the active share and rescan.

I've had a scenario like this at the moment - where the original seeders have left and the peers are at 96%. i have all of the missing files required, but need to ZIP them up so they exactly match and the download can continue for everyone.

You start with a hex editor (i used frhed http://frhed.sourceforge.net/en/ but you can use what you want) and check the end of the ZIP file. if it has the ascii text TORRENTZIPPED-xxxxxxxx then you are probably in luck.

if this is the case, create a folder with all of the files that need to be in the ZIP. use the standard windows zip folders to create a ZIP file with the same name as you are using with your file sharing. at this stage you will have all of the files AND the new ZIP file in the same folder. from the command line, run torrentzip zipfilename.ZIP and it will re-add all the files and create the checksum signature at the end of the ZIP file.

Use your hex editor to look at the end of the file. if the 8 digit HEX checksum is the same, you've been successful.

I was lucky in my case that the original ZIP files were created using torrentzip so i was able to re-create them and everything worked out exactly as you would have expected.

During my initial testing, i made sure i understood the exact procedure by taking a ZIP file that was 100% all ok, unpacked it, re-zipped it, used torrentzip and confirmed the checksum. i then used a utility to do a checksum on both files (i use Implbits HashTab http://implbits.com/products/hashtab/) and confirmed i was able to recreate an identical file. i then went to work with the other incomplete ZIP files.

hope this helps. cheers.

  • Interesting reply, I upvote it even though it doesn't apply for any of the archives I'd like to complete. In your case, were those ZIP archives actually compressed, or simply packed ? As I wrote, I've had success re-generating both ZIP and RAR archives containing uncompressed files, by copy-pasting the binary contents and completing the metadata, with a bit of guesswork. With compressed data it's much more difficult, especially for ZIP files, as there are many tools in many versions, with apparently many different "flavors" of ZIP compression, and no way to find out what was used originally. – GabrielB Jun 1 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.