How to Use John the Ripper: Complete Tutorial (2026)

What John the Ripper Does

John the Ripper is an open-source password cracker that recovers plaintext passwords from cryptographic hashes by trying candidate passwords from wordlists, mask patterns, or generated character sequences. It runs on Linux, macOS, Windows, and most BSDs, supports more than 470 hash and cipher formats in the jumbo build, and is the closest thing the security community has to a universal cracker.

The history matters. John has been maintained by Openwall since 1996, which makes it older than most of the hashes it cracks. That longevity translates into format coverage. Where Hashcat focuses on the hash types that matter today, John still cracks Lotus Notes ID files, Mac OS X keychains from 10.5, and obscure database authentication blobs that nobody else supports. For penetration testing engagements where you find one weird file in a backup, that breadth is the difference between a finding and a footnote.

Two things make John feel different from Hashcat. First, format auto-detection: you point John at a hash file and it figures out the algorithm. No mode numbers, no lookup tables. Second, the *2john ecosystem: a family of scripts that pull hashes out of encrypted files, archives, and key material. Hashcat needs you to extract the hash yourself; John bundles the extraction and the cracking in one workflow. For a fuller comparison of where each tool wins, our penetration testing tools guide covers the role of each tool in a real engagement.

One opinionated note: skip every "John vs Hashcat: which is better" article that picks a winner. Real pentesters install both and reach for whichever fits the job. The framing is wrong. The right question is "which hash am I looking at, and which tool handles it best."

Installing John the Ripper

The installation depends on your platform, but the result should always be the jumbo build. Verify with john --list=build-info after install. If the output mentions "jumbo," you are good.

Linux (Kali, Debian, Ubuntu, Parrot)

Kali and Parrot ship the jumbo build under john by default:

sudo apt install john
john --list=build-info | head -3

On stock Debian or Ubuntu, the package is also called john, but check the version. If --list=build-info does not say jumbo, build from source instead:

git clone https://github.com/openwall/john.git
cd john/src
./configure && make -j$(nproc)
ln -s ~/john/run/john /usr/local/bin/john

macOS

Homebrew installs jumbo directly: brew install john-jumbo. After install, run john --test to benchmark the build against your CPU and verify everything links correctly.

Windows

Download the prebuilt binary from openwall.com/john and extract anywhere. Run from the extracted run/ directory. WSL also works and tends to feel more natural if you came from Linux.

Once installed, run a self-test to confirm the build works against your hardware:

john --test=10
Will run 8 OpenMP threads
Benchmarking: descrypt, traditional crypt(3) [DES 256/256 AVX2-16]... DONE
Speed for cost 1 (iteration count) of 25
Raw:    8521K c/s real, 1066K c/s virtual

Numbers vary by CPU. The point of --test is not to compare to anyone else; it is to confirm the build initialized correctly and to give you a baseline so you can spot something wrong if a future run is dramatically slower.

Identifying Hash Types Before You Crack

John auto-detects most hash formats, but auto-detection is not magic. When the format is ambiguous (raw 32-character hex could be MD5, NTLM, LM, or several others), John picks one and runs with it. If you guess wrong, you waste hours. Identifying the hash up front saves the run.

For hashes with format markers, identification is trivial:

• $1$ - MD5crypt (legacy Linux shadow)
• $5$ - SHA-256crypt
• $6$ - SHA-512crypt (default on most modern Linux distros)
• $2y$ or $2b$ - bcrypt
• $y$ - yescrypt (default on Debian 12, Ubuntu 24.04+)
• $argon2id$ - Argon2 (best-in-class, deliberately slow to crack)

For raw hex hashes without markers, context decides. NTLM hashes come from Windows SAM files, NTDS.dit dumps, or secretsdump.py output. Raw MD5 typically comes from web application database dumps. If you genuinely cannot tell, run hashid for a ranked guess, then use John's --format flag to lock in the right one:

john --format=NT hash.txt
john --format=Raw-MD5 hash.txt
john --format=sha512crypt shadow.txt

Get the full list of supported formats with john --list=formats. The output runs to nearly 500 entries; pipe it through grep for whatever you are looking at:

john --list=formats | tr ',' '\n' | grep -i ssh

For background on hash algorithm differences and when each shows up, our hash cracking tutorial covers the algorithm theory side. This guide stays focused on John-specific commands.

Wordlist Mode: The Default Workflow

Wordlist mode is the 80% case. You have a hash file and a list of candidate passwords. John tries each candidate, hashes it with the target algorithm, and compares against the hashes you provided. The basic invocation:

john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

That command runs through 14 million passwords in rockyou. On a modern desktop CPU against unsalted NTLM, the full pass takes under a minute. Against bcrypt with cost factor 12, the same pass takes weeks. Hash algorithm decides everything.

While John runs, press any key to see status: candidates per second, ETA, current candidate. Press q to abort cleanly. John writes successful cracks to ~/.john/john.pot automatically. View what you have cracked at any time:

$ john --show hash.txt
admin:Summer2024!:::::::
backup:hunter2:::::::
2 password hashes cracked, 0 left

The --show output is shell-friendly: pipe it through cut -d: -f1,2 to extract just user:password pairs for your report. If a session gets interrupted (you closed the terminal, the laptop slept, the cat unplugged the power), resume from the .rec file in ~/.john/:

john --restore

Two flags worth memorizing for wordlist mode. --fork=N splits the work across N CPU cores; on an 8-core machine, --fork=8 roughly 8x your throughput against fast hashes. --session=name tags the run with a label, so you can run multiple sessions in parallel and restore them by name. In practice, every serious crack run uses both: john --wordlist=rockyou.txt --rules --fork=8 --session=engagement-q2 hash.txt.

Going Beyond Wordlists: Incremental and Mask Modes

When the wordlist runs dry and the hash is still uncracked, you have two options. Incremental mode generates candidates from a learned probability distribution. Mask mode generates candidates that match a known pattern.

Incremental is the brute force people imagine when they hear "password cracking." John generates passwords statistically, starting with the most probable character combinations and working outward. The basic invocation:

john --incremental=ASCII hash.txt
john --incremental=Digits hash.txt
john --incremental=Alnum hash.txt

Default character classes are defined in john.conf under [Incremental:*] sections. You can edit them, but for almost every real run the stock ASCII, Digits, and Alnum classes cover what you need. Incremental against fast hashes works for short passwords (5-7 characters). Anything longer becomes a math problem you do not have time for.

Mask mode is what you reach for when intelligence about the password policy is available. Suppose the target organization mandates "8 characters, capitalized first letter, ends in digit-digit-special." That maps cleanly to a mask:

john --mask=?u?l?l?l?l?l?d?d?s hash.txt

The placeholders mirror Hashcat's: ?l lowercase, ?u uppercase, ?d digit, ?s special, ?a all printable. A nine-character mask of the kind above generates roughly 30 billion candidates. Against unsalted NTLM, that finishes in seconds; against bcrypt, you need a different plan.

In practice, mask mode is the most under-used technique among new pentesters. The instinct is to keep grinding wordlists. The win is to spend ten minutes asking the client about their password policy, then encode that policy as a mask. Cracks that wordlists miss for hours fall to a well-targeted mask in minutes.

Rules: Multiplying Your Wordlist

Rules are the feature that turns a 14-million-word list into a 14-billion-candidate attack. Each rule mutates every wordlist entry: append digits, capitalize, leet-speak substitution, reverse the string. One wordlist becomes hundreds of variants per word.

The most useful built-in rule sets:

• --rules=Single - John's stock rules, tuned for speed. Fast, decent coverage, your default.
• --rules=Wordlist - similar to Single but with more aggressive case mutations.
• --rules=Jumbo - the kitchen sink. Every mutation pattern John knows. Slow against expensive hashes.
• --rules=KoreLogic - rules from the KoreLogic team's DEF CON crackme entries. Tuned against real-world corporate password patterns.

The standard combat command for an unknown corporate environment:

john --wordlist=rockyou.txt --rules=Jumbo --fork=8 hash.txt

That runs every rule John has against every word in rockyou, parallelized across 8 cores. On unsalted NTLM, the full sweep finishes in 30-60 minutes on commodity hardware. Expect 60-75% crack rate on a typical corporate dump.

Custom rules go in ~/.john/john.conf under a [List.Rules:Custom] section. The syntax is documented at the official John the Ripper rules reference; expect a learning curve. For 95% of engagements, the built-in rules outperform anything you would write yourself in the time available. Skip custom rules until you have a specific reason to write them, like a company that mandates "$Season$Year#" passwords and the stock rules are missing the trailing hash.

One example mutation chain. With --rules=KoreLogic applied, the wordlist entry password generates candidates including Password1, P@ssw0rd, password!, password123, P@ssw0rd!, and Password2024. None of those are in rockyou directly. All of them appear in real password dumps. That is what rules buy you.

Cracking Real-World Hash Types

Raw hash files are training-wheel territory. Real engagements give you encrypted files, key material, and database dumps that need preprocessing before John can touch them. The *2john helper scripts handle that preprocessing.

Linux shadow files

The /etc/passwd and /etc/shadow files need to be combined into one input file:

unshadow /etc/passwd /etc/shadow > shadow-combined.txt
john --wordlist=rockyou.txt --rules=Single shadow-combined.txt

Most modern Linux distros use $6$ SHA-512crypt or $y$ yescrypt. Both are slow on purpose. Expect roughly 10,000 candidates per second on a desktop CPU. Wordlist plus rules is the realistic strategy; full incremental is not.

Practice the full pipeline in the Shadow Cracker lab: extract /etc/shadow from a target, run unshadow, and crack the result with John.

ZIP, PDF, Office, and SSH key files

Each file type has a corresponding extractor:

zip2john secret.zip > zip.hash
pdf2john confidential.pdf > pdf.hash
office2john document.docx > office.hash
ssh2john id_rsa > ssh.hash
keepass2john credentials.kdbx > kp.hash

Then crack each output with the standard John command. The lab catalog includes Crack SHA1 Hash for raw-hash practice and dedicated labs for ZIP and PDF cracking under the password-cracking category.

NTLM and Active Directory hashes

NTDS.dit dumps from secretsdump.py come out in a format John reads directly. Filter for the relevant hashes first:

cut -d: -f4 ntds.dit.dump > ntlm-hashes.txt
john --format=NT --wordlist=rockyou.txt --rules=KoreLogic ntlm-hashes.txt

NTLM is unsalted and fast. Even on a CPU, expect millions of candidates per second. Against a typical AD dump, plan for 60-80% crack rate within the first hour using rockyou plus KoreLogic rules. The remaining 20-40% are usually long random or passphrase-style passwords; switch to a longer wordlist or a targeted mask if needed.

Last verified: April 2026 against John the Ripper 1.9.0-jumbo-1 on Kali 2026.1.

John the Ripper vs Hashcat: When to Use Which

Pick John when format flexibility or hash extraction matters. Pick Hashcat when raw speed matters. The honest answer is most pentesters run both; the table below covers the cases where one clearly wins.

The realistic workflow on engagements: use John's *2john to extract hashes from files, identify the format, then send fast hashes to Hashcat for GPU cracking and slow or unusual hashes to John on CPU. Both tools share wordlists and (with minor tweaks) rule files. Keeping them in the same directory and switching between them is normal.

Legal and Ethical Considerations

Authorized penetration testing engagements, CTF competitions, and your own dedicated lab environments are the only safe contexts for John the Ripper. Your scope of work document should explicitly include password cracking as an approved activity. If it does not, get written confirmation before pulling the first hash.

For practice, stick to controlled environments. HackerDNA labs, VulnHub VMs, and local Docker setups of intentionally vulnerable systems exist specifically for offensive learning and carry no legal exposure. Real password dumps from breaches (beyond well-known training sets like rockyou.txt) should not be downloaded or stored, even for "research." The legal exposure is not worth the convenience.

When you crack passwords during an authorized engagement, treat the output as some of the most sensitive data the client owns. Store cracked credentials in encrypted form, share them only through agreed channels, and delete them when the engagement closes. The OWASP project publishes guidance on password storage and authentication that helps when clients ask how to defend against the techniques you just demonstrated.