False-positive risk

PKZIP Checksum-Only — Hashcat Mode 17230

TL;DR — Mode 17230 verifies candidate passwords using only the 12-byte ZipCrypto header check (CRC nibble), without decrypting the full file. This makes per-password verification fast but introduces a meaningful false-positive rate — passwords that pass the header check may still produce garbage decryption. Real-world workflows verify successful candidates by attempting full extraction.

What checksum-only verification does

The 12-byte ZipCrypto header includes a 1-byte CRC nibble that allows quick rejection of wrong passwords. Mode 17230 uses only this check — fast but lossy.

Roughly 1 in 256 wrong passwords passes the CRC nibble check by chance. For large password searches, this means thousands of 'positive' candidates that aren't actually correct.

Production recovery flows use mode 17230 as a fast filter, then verify each candidate by decrypting and checksumming the actual file content. This combines speed with correctness.

When mode 17230 is appropriate

Specialised use cases where the user accepts the false-positive risk: very fast initial scans, comparison against billions of candidates from public breach lists, screening before full verification.

For most owner-recovery workflows, modes 17200/17220 with full verification are preferred — slightly slower but no false positives.

False-positive verification

Any candidate password that passes mode 17230 must be re-verified by full decryption + CRC32 check on the file content. This catches the ~1/256 false positives.

We never deliver a 'recovered' password to a customer without full verification. The honesty risk is too high otherwise.

Frequently Asked Questions

Should I use mode 17230 myself?

If you're running Hashcat manually, mode 17230 is appropriate as a fast first-pass filter, but you must verify successes by attempting full file extraction. Mode 17200 with full verification avoids false positives at the cost of slightly slower verification.

What's the false-positive rate?

Approximately 1 in 256 candidate passwords passes the 12-byte header check by chance, regardless of whether the password is actually correct.

How do recovery services handle this?

Production flows always full-verify mode 17230 candidates before delivering a password. Delivering a false positive to a customer is unacceptable.

Related references

m17200Structurally weak cipher m17220Multi-file favourable

Have a file in this category?

Start with a free analysis. The encryption type is detected automatically; a free check runs through fast techniques before any paid attempt. You only pay if recovery actually works.

Run a free analysis