When someone hands you a password-protected ZIP archive, one’s immediate thought is “I need to break the password”. For most modern archives, that is exactly the case, and the password is the whole game. But there is a family of ZIP archives where the password does not matter at all. It can be four characters or forty, random or memorable; if the archive uses the legacy ZIP encryption, the whole thing can be unlocked in minutes without ever guessing the password. This is one of the oldest tricks in our line of work, and it is worth telling the story properly, because it is equal parts computer history and practical forensics.

A word of caution before we start. The attack we are about to describe applies to the classic ZIP 2.0 encryption, the scheme Phil Katz built into PKZIP in the late eighties. Almost nobody should be creating archives with it today. Modern archivers default to AES, which is a completely different situation. So treat most of this article as a fascinating piece of history, with a long and narrow tail of cases where it still bites in real life.

A short history

Phil Katz did something unusual for his time: he documented the ZIP file format completely, in a plain text file called APPNOTE.TXT that shipped with every copy of PKZIP. That openness is a big part of why ZIP took over the world. Hundreds of compatible archivers appeared, and the format became a universal standard. The same openness, however, handed the encryption scheme to cryptographers on a silver plate.

The scheme is a simple stream cipher. It keeps three 32-bit internal values, traditionally called key0, key1 and key2, initialized to fixed constants (0x12345678, 0x23456789, 0x34567890, if you are curious). Every byte of the password updates these three values through a mix of CRC-32 and a small multiplication, and the resulting keystream is then used to scramble the data. It looks reasonable at a glance. It is not.

In 1994, Eli Biham and Paul Kocher published “A Known Plaintext Attack on the PKZIP Stream Cipher”. The conclusion was blunt: the cipher is weak and should not be used to protect anything of value. What makes this paper fun in hindsight is the second name on it. This was early-career Paul Kocher. The same Paul Kocher who a couple of years later invented timing attacks, then differential power analysis, then co-designed SSL 3.0, and who decades later co-discovered Spectre and Meltdown. In his own recollections, the PKZIP cipher was one of the little intellectual puzzles he picked up along the way. Not a bad puzzle to have on your record.

Why the cipher falls: the known-plaintext attack

Here is the key idea: instead of attacking the password, you attack the cipher’s internal state directly.

If you know a small amount of the plaintext (on the order of a dozen bytes) together with the matching encrypted bytes, you can work backwards and recover those three internal values, key0, key1 and key2. Once you have them, you can generate the keystream and decrypt the entire file. The password never enters the picture. This is why password length and complexity are completely irrelevant to this attack. You are not breaking the lock, you are copying the key that the lock produced.

There is one practical complication, and it is the reason the attack is not entirely trivial. Archivers compress the file with deflate before encrypting it, so the “plaintext” you actually need is not the original file, it is the compressed version of it. You cannot just type in a few words you expect to be inside the document. In practice this means you need a copy of one of the files stored in the archive, so the tool can compress it the same way and produce the matching bytes. If you have that one file, the rest of the archive comes for free, no matter how many other files it contains or how strong the password is.

Making it practical: how the plaintext attack works

The 1994 attack was elegant but still needed known plaintext from inside the archive. The next question was obvious: can we need less, or nothing?

Michael Stay, then at AccessData, answered both in 2001 in “ZIP Attacks with Reduced Known-Plaintext”. First, he reduced the amount of required plaintext down to two or three bytes in many cases. Second, and this is the genuinely clever part, he found a way that needs no file from the archive at all.

The trick exploits a weakness not in the cipher but in how some archivers generated the twelve random bytes that every encrypted ZIP entry starts with. WinZip and NetZip produced those “random” bytes using the standard Microsoft Visual C++ rand() function, which is seeded from a value that is only 31 bits wide. That is a small enough space to attack directly. So instead of needing a known file, you attack the predictable header itself. On period hardware, roughly a 500 MHz machine of the day, this took about two hours. This is the foundation of what we call guaranteed recovery: the archive gives up its keys purely because its own random numbers were not random enough.

Where our tools come into this

All of the above stopped being purely academic a long time ago, because both attacks are built into Advanced Archive Password Recovery. Two separate features link directly to the two stories above.

The known-plaintext attack is the direct descendant of Biham and Kocher. You point the tool at the encrypted archive, then give it one unprotected file that lives inside that archive (or an archive that contains it). If the file matches, the attack runs and the archive is usually unlocked in minutes. Password length does not matter here, at all.

The guaranteed WinZip recovery is Stay’s weak-randomness attack, productized. It needs no external file. It exploits the weak random number generator in legacy WinZip 8.0 and earlier, and it works as long as the archive contains at least five encrypted files. The result is guaranteed decryption, typically within an hour, again regardless of the password.

Two things are worth mentioning. First, there is a distinction between decrypting the archive and recovering the original password. These attacks recover the cipher’s keys, which are enough to decrypt everything inside. The plain-text password itself may or may not be recoverable from those keys, and it is genuinely not needed to get your data out. The password is never stored in the archive in any form, so “we cracked the ZIP” and “we found the password” are two different outcomes.

Second, and this is the part that keeps this old attack relevant: it is not strictly a “twenty year old archives only” situation. The vulnerable code lived in ZIP libraries, and some software still ships with ancient ZIP libraries that were bundled once and never updated. An archive produced today by such a product can still use the legacy encryption, or the weak header generation, and remains just as breakable as one from 2001. These products are rare and mostly niche, but in forensics the long tail is exactly where the interesting cases hide.

The AES era, and why buzzwords are not security

At some point WinZip added AES, and the picture changed. It is important to be fair here: the AES itself was never broken. When Tadayoshi Kohno analyzed the new scheme in 2004, the core turned out to be a sound design, AES in counter mode with an HMAC-SHA1 authentication on top. The problems he found were all in the wrapping around it.

The most instructive one was self-inflicted. WinZip had two versions of its AES format, called AE-1 and AE-2. The specification required tools that understood the newer AE-2 to still be able to open older AE-1 files and verify their checksum on the way out. That backward-compatibility rule, which existed to fix a different problem in AE-1, opened a hole of its own. On top of that, the metadata around the encrypted data was not authenticated, and file names were left in the clear.

That last point is important because it is true for both the legacy and the AES formats. The names of the files inside an encrypted ZIP are readable without a password. A file called PinkSlip-Bob.doc tells you what you need to know before you decrypt a single byte. If the names matter, the archive itself has to be hidden or wrapped in something else.

The moral is the one every security engineer eventually learns the hard way. Putting the letters “AES” on a product does not make it secure. The strength of the cipher is only as good as everything wrapped around it.

Where things stand today

If you create a ZIP archive with any current mainstream tool and choose the AES option, none of the fast attacks apply. Your data is protected by the password and the key derivation, and a long, unique password is genuinely your defense. The legacy attacks live on mainly in two places: old archives, and new archives made by old or careless software. For the classic scheme, the modern open-source implementation of the Biham and Kocher attack, bkcrack, keeps the technique alive and is a good way to see it in action.

Practical advice, then, is short. Use AES encryption, not the legacy compatibility mode. Use a long and unique password, because against AES that is the only thing standing between your data and a brute-force attack. And remember that the file names leak regardless, so do not put sensitive information in them.

Shameless plug

If you are on the other side of the problem, with an archive you need to open rather than one you are trying to protect, this is exactly what Advanced Archive Password Recovery is built for. It carries both attacks described above, the known-plaintext attack and the guaranteed WinZip recovery, alongside the usual dictionary and brute-force options for archives that use strong encryption. For the legacy formats, it is often the difference between minutes and never.

Modern ZIP encryption is not the slowest format we support, but it is slow enough to need a GPU-assisted attack to recover passwords of any reasonable length. And that’s exactly what Elcomsoft Distributed Password Recovery exists for. The product builds high-performance clusters out of the hardware you already have, offers zero-overhead scalability, and supports GPU acceleration on the whole queue rather than on selected formats. For ZIP, this is a must; on a single CPU the numbers simply do not work.

And it is a fitting place to end the story. A stream cipher from the late eighties, a paper co-written by someone who went on to shake the whole industry, and a weakness that, thirty years later, still occasionally lets an archive fall open in an afternoon. Not bad for a format that started life as a plain text file called APPNOTE.TXT.