Cracking ZIP, RAR and 7-Zip archive passwords

A password-protected archive looks like one problem from the outside: you have a .zip, .rar or .7z file and no password. Underneath it is three different problems, because ZIP, RAR and 7-Zip each encrypt differently, and two of them have more than one variant depending on which tool created the archive. Get the extraction and the mode right and this is routine wordlist work. Get it wrong and hashcat either refuses the line outright or silently cracks nothing.

Extract the hash first

None of these formats hand you a usable hash by just looking at the file. You run the matching John the Ripper extractor, which is part of the jumbo build:

zip2john secret.zip > zip.hash
rar2john secret.rar > rar.hash
7z2john.pl secret.7z > 7z.hash

Each one prints a single hash line prefixed with $zip2$, $pkzip2$, $RAR3$, $rar5$ or $7z$ depending on what it finds inside the archive. That prefix is the identification step — it tells you which hashcat mode to reach for, the same way identifying an unknown hash starts from the string's shape rather than a guess. The line these tools produce is accepted by hashcat as-is; you do not need to reformat it.

Picking the mode

If the prefix does not match any of these cleanly, work through finding the right hashcat mode rather than forcing a mode and assuming the lack of a crack means the password is strong — it may just mean you extracted the wrong hash type.

Running the attack

Once you have the right mode, this is the same wordlist-and-rules workflow as everywhere else:

hashcat -m 13600 zip.hash rockyou.txt -r rules/best64.rule
hashcat -m 13000 rar.hash rockyou.txt -r rules/best64.rule
hashcat -m 11600 7z.hash rockyou.txt -r rules/best64.rule

John the Ripper can crack the same extracted files directly, usually without forcing a format flag since it auto-detects from the line's prefix:

john zip.hash --wordlist=rockyou.txt
john --show zip.hash

Why speed varies so much between these three

This is where the format matters more than the wordlist. WinZip's AES mode (13600) and RAR3-hp (12500) both derive their key with a comparatively light SHA-1 or single-pass step, so a GPU clears far more candidates per second than it would against a deliberately slow hash. RAR5 and 7-Zip are a different story: both run the password through an iterated, configurable PBKDF2/SHA-256-based key derivation step before the key ever touches AES, so throughput on identical hardware is dramatically lower than against RAR3-hp or WinZip AES. The same gap shows up between Office/PDF encryption and plain hashes, and it exists for the same reason: iteration count is a deliberate design choice to make brute force expensive, not an accident.

That gap should shape your approach, not just your patience. Against RAR3-hp or legacy PKZIP, a large list plus rules is viable. Against RAR5 or 7-Zip, treat it like you would a strong bcrypt hash: a short, targeted list beats grinding through rockyou at a few thousand guesses a second, and a mask attack past seven or eight characters is rarely realistic on consumer hardware.

The takeaway

Archive passwords fall to the same process every other offline hash does: extract correctly, identify the exact variant from the hash's own prefix, pick the mode that matches, then spend your compute where it counts. The only real trap is treating "ZIP" or "RAR" as one hash type when each is actually a small family, and running the wrong mode in the family wastes a session telling you nothing useful about the password's strength.