← ALL EXPERIMENTS
ZIP POSITIVE CONTROLS / OWNED TEST FILES

Long ZIP password recovery: when a correct dictionary still reports no result

A dictionary test can miss a correct ZIP password if the recovery module does not support its length. In our John the Ripper 1.9.0-jumbo-1 PKZIP build, the 31-character control was found while the correct 32, 51, 52 and 127-character candidates were not. Every archive independently decrypted with its supplied password.

The experiment: put the answer in the dictionary

Instead of estimating whether a wordlist was “large enough,” we created five traditional ZipCrypto archives ourselves. Each contains the same fictional text payload. The passwords have lengths 31, 32, 51, 52 and 127, use ASCII characters, and are intentionally public test values. No customer files, recovered customer passwords or private hints were used.

For each archive, the wordlist contained one wrong value and the exact known password. We used a separate potfile and session for every control to avoid an earlier recovery making a later result look successful. The tool was John the Ripper 1.9.0-jumbo-1, cygwin 64-bit x86_64 AVX2 AC OMP.

We also decrypted the original archive with Python’s ZIP reader and checked the complete payload and CRC. That independent check matters: an unsuccessful recovery-tool run could otherwise be explained by an invalid archive or an incorrect supposed password.

Observed results

Password lengthCorrect candidate suppliedJohn PKZIP found itFull original-file verification
31YesYesPassed
32YesNoPassed
51YesNoPassed
52YesNoPassed
127YesNoPassed

The locally queried format details reported a 31-character ASCII limit for this build. Openwall’s format information documents the same kind of limit for the referenced PKZIP implementation. This is a finding about the named module and build, not a claim that all John versions, all ZIP encryption schemes or the ZIP format share that limit.

The limit belongs to the recovery path. Our 127-character sample is demonstrably a valid encrypted archive because the known password reads its complete original contents.

Why a short header match is not a recovered password

Traditional ZIP encryption has a small password-check field in its encrypted header. It is useful for screening candidates, but an unrelated candidate can accidentally match. Our separate long-password filter found the correct controls at all five lengths. We still require reading the archive member and checking its complete contents and CRC before calling a candidate verified.

Header screening is not an independent proof of successful recovery. It also must handle the ZIP flags correctly: depending on the data-descriptor flag, the relevant check byte comes from a different field. That is one reason a tested positive control is more valuable than assuming a custom filter is correct.

A practical checklist when a ZIP password was not found

  1. Confirm the archive format and encryption type. ZipCrypto and ZIP AES are different cases.
  2. Check whether the actual recovery module accepts the remembered length and character encoding.
  3. Make a separate, non-private archive with a known password of the same length.
  4. Place that exact password in a tiny wordlist and use an empty, separate result store.
  5. If it is found, validate by reading the original data, not just matching a header.
  6. If it is not found, investigate the setup before claiming the larger wordlist has ruled out the password.

ASCII controls do not certify Unicode handling. Our experiment does not establish a maximum WinRAR or 7-Zip password length, benchmark ZIP AES, or show that every long ZIP password is recoverable. It shows how a tool limitation can invalidate one particular negative test.

Download the positive controls

Each ZIP below is an owned public fixture. Its exact test password is in the downloadable JSON report, together with its SHA-256 fingerprint. Do not reuse these public passwords for a real archive.

The screening implementation is included for inspection. It is a candidate filter, not a replacement for complete decryption validation. Our sample matrix includes a successful control and several expected misses in the named old module; it is not a product ranking.

Sources and further checks

Scope and editorial independence

We operate a recovery service alongside this laboratory. The tests use generated public fixtures, not customer data. Measurements describe the specified software, hardware and samples on the test date. No success rate, ranking position or recovery guarantee is inferred.

Continue your diagnosis