Mastering John the Ripper: Ultimate Guide to Password Cracking

What is John the Ripper? (The Full Story)

Imagine you’re a professional safe cracker in a heist movie. You don’t blow up the vault — that’s messy and loud. Instead, you use a master key ring with millions of keys, trying each one super fast until one clicks.

That’s John the Ripper in the digital world: a focused, scriptable toolkit that automates the trial-and-error of guessing secrets (passwords, passphrases, or private-key passphrases) at scale. Where a human would guess a few options, John can generate and test millions — using wordlists, rule-based mutations, masks, and brute-force engines — and compare the produced hashes with the target.

Short history & evolution

John was created in 1996 by Solar Designer as a Unix password auditing tool. It remained small and focused until community contributions expanded it into a modular framework. The most notable branch is bleeding-jumbo (commonly “Jumbo”), which adds hundreds of additional formats, helper extractors (for ZIP/RAR/SSH/etc.), OpenCL hooks, and many performance patches.

What's inside John — components at a glance

• Core engine: orchestrates reading candidate words, applying rules/masks, hashing them with the chosen algorithm, and comparing results.
• Format modules: small plugins that tell John how to parse a hash and how to compute it (md5crypt, sha512crypt, nt, phpass, ...).
• Helpers: extractors like zip2john, rar2john, ssh2john, and unshadow — they convert containerized secrets into John-readable hash files.
• Rule engine: compact, declarative rule language to mutate words (capitalize, append, leet, reverse, duplicate, etc.).
• OpenCL/GPU support (Jumbo): for some formats John can offload hashing to GPUs via OpenCL — though Hashcat often gives broader GPU performance for many formats.

Why John is still useful

• Teaching & transparency: John’s rule engine and clear workflows show how password guesses are constructed and why some rules work better.
• Format breadth: Jumbo supports a wide range of legacy and niche formats — handy for forensic recovery or varied pen-test targets.
• Workflow helpers: The extractors and session features make it easy to build reproducible cracking jobs and share results.
• Compactness: You can do a lot with modest hardware and clever rules — no need to rely solely on massive GPU clusters for common targets.

Real-world examples (quick)

• Recovering a lost ZIP password: run zip2john secret.zip > zip.hash, then run John with a wordlist and session to resume later.
• Auditing Linux accounts: combine /etc/passwd and /etc/shadow with unshadow, then run wordlist+rules across the resulting file to find weak credentials.
• Targeted corporate audit: build a corpus from public corpora related to the company (subdomains, project names) and prepend/append those tokens with rules to increase hit rates against corporate accounts.

Pro Tip: Use the bleeding-jumbo branch for modern needs — it includes extended format and OpenCL support plus helpful extractors. For reproducible research or client work, pin a commit or tag rather than always using the latest master.

Important caution: John is powerful and can be abused. Always have explicit, written authorization for any testing you perform. Unauthorized password cracking is illegal in many places and ethically wrong. When in a professional role, document scope, keep logs, and handle recovered secrets responsibly.

Core Concepts: The Real Foundation Behind Cracking

To truly use John the Ripper like a professional, you must understand these core building blocks. These are not just “definitions” — they determine cracking speed, accuracy, and success rate in real-world engagements.

Step 1: How to Identify Hashes (Like a Detective)

You can’t crack a hash if you don’t know what it is. It’s like showing up to a fight with the wrong weapon — you’ll waste time and compute. Correctly identifying the hash family and any associated parameters (salt, iterations, prefix) lets you choose the right John --formatand the correct cracking strategy.

John needs the correct --format. Below are practical heuristics, tools, and verification steps you should use every time.

# Install hashid (useful quick heuristic tool)
sudo apt install hashid

# Pipe a sample hash to it
echo '$1$abc123$5f4dcc3b5aa765d61d8327deb882cf99' | hashid

# Quick John formats listing
./john --list=formats | grep -i md5
# -> raw-md5, md5crypt, ...

Fast fingerprint heuristics

• Length & charset: 32 hex chars → MD5/NTLM/raw-md5; 40 hex → SHA-1; 64 hex → SHA-256; 128 hex → SHA-512 (but check prefix).
• Prefixes: $1$ → MD5-Crypt (md5crypt); $2y$/$2b$ → bcrypt; $6$ → sha512crypt; $P$ → phpass (WordPress).
• Base64 blocks: long base64 (lots of A–Z/a–z/0–9/+\/) often points to PBKDF2, scrypt or SSH private-key KDF output.
• Bcrypt indicator: strings starting with $2 and containing cost like $2b$12$ → bcrypt with cost 12 (important for work factor).
• Argon2: usually contains $argon2i$ / $argon2id$ header and parameters — high cost and often impractical on CPU-only rigs.

Common formats & quick clues

• $1$... — md5crypt (Linux MD5-Crypt)
• $6$... — sha512crypt (modern Linux shadow)
• 32 hex continuous like 31d6cfe0... — often NTLM / raw-md5
• $P$... or $H$... — phpass (WordPress/PhpBB)
• $2a$ / $2b$ / $2y$ — bcrypt (contains a cost factor)
• Long base64 with headers — PBKDF2 / scrypt / argon2 / SSH

How to verify your guess (always test)

1. Generate a known sample: create a hash using the suspected algorithm on your machine (use OpenSSL, Python, or system tools).
2. Compare structure: does the produced hash share the same prefix/length/char set as the target? If yes, likely correct family.
3. Run a short John test: run John for 30–60 seconds with a tiny wordlist and the suspected --format. If John errors or is extremely slow, you probably picked the wrong format.

Tools & tricks

• hashid / hash-identifier: good first guess. They give families, not guarantees.
• John’s --list=formats: shows what formats your build supports — helpful to match names.
• Use helper extractors: unshadow for /etc/shadow, zip2john/rar2john/ssh2john for container formats — they produce John-ready hashes (and reveal format clues).
• Check for KDF parameters: bcrypt/argon2/PBKDF2 usually include iteration/cost parameters in the string — these determine feasibility.

Pitfalls & gotchas

• False positives: hashid might show multiple candidate families. Don’t assume — test a sample hash as described above.
• Encodings: some systems store binary blobs or BASE64-wrapped hashes — decode them first before analysis.
• Salt location: salts can be embedded ($6$...$) or stored separately in a file/DB column — ensure John sees the salt in the expected format.
• Work factor: bcrypt/argon2 with high cost may be practically impossible on CPU — recognize when a GPU or cloud resource is the only option (and check legality/ethics first).

Quick checklist before cracking

• Identify candidate format(s) with hashid and visual heuristics.
• Confirm format by generating a test hash locally.
• Use the appropriate helper extractor if the hash is inside a container.
• Pick initial strategy: single or wordlist+rules for humans, mask for constrained PINs, incremental only as last resort.
• Document the suspected format, KDF parameters, and test results before starting long runs.

Setting Up John the Ripper (Jumbo Edition)

The version shipped in many distros (Kali/Ubuntu apt) is convenient but limited. For real work you want the bleeding-jumbo edition: extra formats, helper extractors, and OpenCL support. Below is a practical, step-by-step setup guide (Linux-first), plus notes for Windows, macOS, Docker, drivers, and common troubleshooting.

Quick installs (options)

# Option 1: Distro package (fast, limited)
sudo apt update && sudo apt install john

# Option 2: Compile bleeding-jumbo (recommended)
git clone https://github.com/openwall/john -b bleeding-jumbo john
cd john/src
./configure && make -s -j$(nproc)
cd ../run
# Run from run/ directory: ./john --version

# Option 3: Use a prebuilt binary (if available) or distro-specific jumbo package (check your repo)

Dependencies & build tips

• Required dev tools: build-essential, autoconf, libssl-dev, zlib1g-dev.
• OpenCL / GPU: Install vendor runtimes before building if you want OpenCL formats: NVIDIA (> driver + CUDA toolkit) or AMD (ROCm/OpenCL runtime). If headers/runtime are missing, John will skip OpenCL builds.
• Optional extras: libpcap-dev (for some helpers), libgmp-dev, and a modern gcc for best performance.

Verify features after build

# from john/run/
./john --version
./john --list=formats | wc -l        # how many formats are supported
./john --list=opencl                 # show OpenCL-capable formats (if built)
./john --list=opencl-devices         # list detected OpenCL devices (if supported)

If --list=opencl returns nothing, the build likely skipped OpenCL support — check that vendor SDKs/runtimes and headers were present during compilation.

NVIDIA & AMD driver notes

• NVIDIA: install the official drivers and CUDA toolkit matching your kernel. For Ubuntu, use the driver PPA or vendor installer; reboot after driver install.
• AMD: ROCm or the AMD OpenCL runtime is required for many cards. ROCm has hardware and kernel-version constraints — check compatibility.
• After driver install, validate with vendor tools (nvidia-smi for NVIDIA, vendor OpenCL utilities for AMD) before building John.

Windows & macOS notes

• Windows: use Cygwin/WSL2 or a prebuilt Windows binary if available. WSL2 + GPU support (NVIDIA) works for many setups — ensure WSL GPU/driver integration is configured.
• macOS: building Jumbo on macOS can be complex due to OpenCL and tooling differences. Consider using a Linux VM or Docker image for reproducible builds.

Docker for reproducible environments

If you want isolation or reproducibility, use a Docker image (or your own Dockerfile) that installs necessary runtimes and builds John. This avoids polluting the host system and makes sharing setups easier.

# Example: quickly run john in a container (CPU only)
docker run --rm -it ubuntu:24.04 /bin/bash
# inside container: install deps, clone, build, run from run/ (repeat steps in container)

Helpers & extra tools to install

• zip2john, rar2john, ssh2john — bundled in Jumbo; used to extract hashes from containers.
• Common wordlists: wordlists/rockyou.txt, SecLists corpora, and custom corpora built from target-specific data.
• hashid or hash-identifier — quick heuristics to guess hash families before testing.

Recommended configuration & workflow after install

• Pin a commit: Jumbo moves fast. For reproducible client work or research, record the commit hash you built from and keep the binary or Docker image.
• Centralize wordlists & potfiles: store wordlists and john.pot in a shared, backed-up location if running multiple jobs or nodes.
• Test run: after build, run quick smoke tests: ./john --test and a tiny wordlist on a known hash to confirm correctness.

Common build & runtime problems

• OpenCL formats missing: missed headers or runtimes during configure; rebuild after installing vendor SDK/runtime.
• Unsupported format errors: you might be using the distro package (not Jumbo) — check ./john --list=formats count and names.
• Permission/drive issues: when running heavy jobs, ensure the filesystem can handle frequent writes (avoid problematic NFS mounts for sessions/potfiles).

Quick verification commands (cheat sheet)

# From john/run/
./john --version
./john --test                    # benchmark modes
./john --list=formats | wc -l     # how many formats
./john --list=opencl              # opencl-capable formats
./john --list=opencl-devices      # detected devices (if present)

Pro Tip: If you need heavy GPU throughput for modern KDFs (bcrypt/argon2 variants), consider Hashcat or a hybrid workflow: use John for format helpers and rules design, then convert hashes and run large GPU jobs with Hashcat.

Cracking Basic Hashes: From Zero to Hero (Step-by-Step, With Tips)

We'll walk a full, practical workflow: verify the format, run a short test, scale safely, monitor progress, save state, and interpret results. Always run a short 30–60s smoke test first so you don't waste hours on the wrong assumptions.

Example target (what we have)

$1$salt123$5f4dcc3b5aa765d61d8327deb882cf99  # (example) md5crypt-style entry — password is "password"

Step 0 — Quick checks before you start

• Confirm format (use hashid or visual prefixes like $1$, $6$, $2b$).
• Ensure the hash file is in John-readable format (use helpers like zip2john, unshadow, ssh2john).
• Pick a conservative initial strategy: --single or --wordlist with a small list + no rules for 30–60s.

Step 1 — Save the hash

echo '$1$salt123$5f4dcc3b5aa765d61d8327deb882cf99' > hash.txt

Step 2 — Run a short dictionary test (smoke test)

Run John for a short time to ensure the format and wordlist behave as expected. Use a session name so you can resume or inspect logs later.

./john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt --session=job1 --format=md5crypt

Step 3 — Monitor progress

• ./john --status=job1 — shows speed (c/s), elapsed time, estimated progress and active mode.
• ./john --show hash.txt — shows cracked accounts in user:password (or hash:plaintext) format and counts.
• Check your potfile (default ~/.john/john.pot) to see saved cracked pairs; John uses this to avoid duplicate work.

Step 4 — Scale up safely

If the smoke test looks good, scale using rules, forks, sessions and (if available) OpenCL/GPU formats.

# Example scaled run: wordlist + rules, 4 CPU forks, session saved
./john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt --rules --fork=4 --session=job1 --format=md5crypt

# Run with session name so you can resume:
./john --restore=job1

Notes: --fork parallelizes across CPU cores; --session saves internal state so you can later run --restore.

Step 5 — Try targeted attacks if dictionary fails

• Rules: apply custom rules to expand realistic variants (years, leet substitutions, common suffixes).
  ./john hash.txt --wordlist=wordlist.txt --rules=custom.rules --session=job2
• Masks: when you know structure (e.g., 3 letters + 2 digits), masks are far faster than full brute force:
  ./john --mask=?l?l?l?d?d --format=raw-md5 hash.txt --session=mask1
• Incremental: last-resort brute force when nothing else works — extremely slow for long lengths.

Interpreting results: what --show gives you

After a successful crack:

./john --show hash.txt
# Output example:
# user:password:hash_count:other_fields
# Or for raw hashes: hash:plaintext

Use the --pot (potfile) to centralize cracked entries. If you run multiple jobs, point them to the same potfile to avoid re-cracking identical passwords.

Best practices, pitfalls & troubleshooting

• Always test format first: wrong format → wasted hours or silent failures.
• Use sessions: --session and --restore let you pause/resume and survive crashes.
• Centralize potfiles: use a single john.pot for multiple runs to prevent duplicate cracking work.
• Watch resources: heavy jobs thrash disks and CPUs — ensure your machine (and filesystem) can handle frequent writes.
• Avoid huge rules untested: big rule sets multiply candidates exponentially — pair them with prioritized wordlists and profile first.
• Respect legality & ethics: only run on data you are authorized to test and keep recovered secrets safe.

Quick cheat-sheet commands

# Smoke test (30-60s)
./john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt --session=quicktest --format=md5crypt

# Scale with rules + 4 forks
./john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt --rules --fork=4 --session=job1

# Resume
./john --restore=job1

# Show cracked
./john --show hash.txt

# Check status
./john --status=job1

Cracking Windows NTLM Hashes (SAM Dump)

NTLM hashes commonly come from Windows SAM exports (local accounts) or from AD database dumps. They represent the user's password in a form based on MD4 (the raw NT hash). Understanding the source and exact format is crucial — it affects whether a hash is crackable and how you should attack it.

Where NTLM hashes come from (quick)

• SAM file on a local machine (> requires system access): tools like samdump2 or impacket-secretsdump extract NT/LM pairs.
• Active Directory dumps (AD database exports): these contain many NT hashes for domain accounts.
• Memory tools: Mimikatz can extract LSASS memory material including hashes on a live system (requires high privileges).

Typical NTLM line (example)

Administrator:500:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::

The important field is the NT hash (the MD4-based value). Note that older LM hashes (left part) may appear; LM is trivial to crack and should be ignored except as an indicator of weak legacy configs.

Save & crack (John example)

# Save to file (example)
echo 'Administrator:500:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::' > ntlm.txt

# Crack with John (NT format)
./john ntlm.txt --format=nt --wordlist=/usr/share/wordlists/rockyou.txt --fork=4

# Show results
./john --show --format=nt ntlm.txt
# -> Administrator:Password123

Hashcat alternative (GPU) — when to use it

For large AD dumps or when you need GPU throughput, Hashcat is often faster. NTLM mode in Hashcat is -m 1000. Example:

# Hashcat example (NTLM)
hashcat -m 1000 ntlm.txt /path/to/wordlist.txt --rules-file=/path/to/rules.rule -O
# -O = optimized kernel (faster but with some limits)

NTLMv1 vs NTLMv2 and captured challenge/response

• NTLM (NT hash): stored hash you crack with dictionary/rules/masks. Extracted from SAM/AD.
• NTLMv2 / challenge-response: when you capture an authentication exchange (network), you often get a challenge/response pair rather than the raw NT hash. Cracking challenge/response is a different process — you need the server challenge and client response; often tools convert these into a hashcat-friendly format for offline cracking.
• If you only have a captured response (no raw NT hash), ensure you convert it correctly (impacket and hashcat docs show formats) and check the feasibility (NTLMv2 with strong client-side entropy can be expensive).

Effective strategies for NT hashes

• Start with single mode & wordlists: usernames and corpora-first often crack weak passwords quickly.
• Use targeted corpora: company names, product names, common suffixes, and leaked corpora related to the org give higher hit rates than generic lists alone.
• Use rules over massive brute force: rule-based mutations on a good wordlist usually outperform raw brute force for human-chosen passwords.
• Mask attacks: for PIN-like or structured passwords (e.g., 2 letters + 4 digits), masks drastically reduce search space.
• GPU for scale: when cracking hundreds of thousands of NT hashes, move to Hashcat or John OpenCL if supported — GPUs give huge throughput gains for NTLM (MD4) workloads.

Defensive notes (blue team quick wins)

• Disable LM hashes entirely — legacy and trivial to crack.
• Enforce long, complex passwords and password rotation policies where applicable.
• Enable multi-factor authentication (MFA) so compromised hashes alone can't be used to access services.
• Use LAPS (Local Administrator Password Solution) for unique per-host admin passwords to limit lateral exposure.
• Monitor for dump tools and anomalous LSASS memory access — many detections exist for credential dumping (e.g., Sysmon rules, EDR alerts).

Legal & ethical reminder

Extracting and cracking NT hashes requires explicit authorization. In a professional engagement keep signed scope, proof of consent, and handle any discovered credentials securely — never publish or reuse them.

Cracking /etc/shadow (Linux User Passwords)

In Linux systems, password hashes are stored in /etc/shadow (protected file), while user information is stored in /etc/passwd. To crack passwords, you must combine them using the unshadow tool, which prepares John-friendly input.

Common Linux Hash Types (Know Your Enemy)

Modern Linux systems use SHA-512 ($6$) with salts — extremely resistant to brute-force attacks unless users choose weak passwords.

Step-by-Step Cracking

# Step 1: Combine passwd and shadow into one crackable file
unshadow /etc/passwd /etc/shadow > shadow.txt

# Step 2: Run John with rules for stronger cracking
./john shadow.txt --wordlist=/usr/share/wordlists/rockyou.txt --rules --fork=8

# (Optional) Use all formats for auto-detection
./john shadow.txt --format=crypt

# Step 3: Show all cracked passwords
./john --show shadow.txt
# → john:Password123
# → alice:welcome@2025

💡 Why --rules is Powerful

Rules apply realistic password mutations like capitalizing, appending years (2024), or adding symbols. This mimics human behavior and drastically increases crack success without brute-forcing everything.

🔥 Advanced Cracking (Mask + Rules)

Use masks to crack common company-style passwords (e.g., Name@1234):

./john shadow.txt --mask='?u?l?l?l?l@?d?d?d?d' --fork=8

Example pattern above tries passwords like Admin@2023, Linux@1234, etc.

🔒 Blue Team Defense Tips

• Use PAM with SHA-512 & enforce long phrases (12+ chars).
• Enable faillock or faill2ban to block brute-force attempts.
• Use password aging policies and MFA wherever possible.
• Monitor /etc/shadow file access — **any unauthorized read is a critical alert**.

⚠ Legal Reminder

Accessing or cracking /etc/shadow without explicit authorization is illegal. This knowledge is strictly for penetration testing, system recovery, or auditing in controlled environments.

Single Crack Mode: “Is It the Username?” (Advanced)

Single mode is a fast, low-cost first step in most audits — it tries highly likely password candidates derived from account metadata (username, GECOS/full name, home folder, shell, etc.). Because it models human behavior, it cracks a surprising number of weak accounts in seconds and should almost always be the first mode you run.

What single mode uses

• Usernames & name parts (bob → bob, bob123, Bob2024)
• GECOS/full name fields (John Smith → john, smith, johnsmith, jsmith)
• Home directory and common tokens found nearby in /etc/passwd

Simple usage

# Run single-mode on a combined shadow file
./john shadow.txt --single

# Show cracked
./john --show shadow.txt
# -> bob:bob123, alice:alice2024

Advanced tips — get more from single mode

• Enrich account metadata: single mode performs better when it has rich GECOS/full-name data. If you have HR fields or LDAP export, create a synthetic /etc/passwd with meaningful GECOS values and run unshadow to feed John improved context.
• Seed wordlists from single results: after a single-mode run, export cracked passwords (or likely candidates) and use them as a high-priority wordlist seed for --wordlist + rules. This chained approach often finds second-order variants quickly.
• Combine with targeted rules: run single mode first, then create a small ruleset focused on common human tweaks (append years, capitalize, simple leet) and apply it to the single-mode outputs as a compact second pass.
• Use sessions: name the run with --session=name so you can resume and compare how many hashes single mode cracked vs later passes.
• Prioritize high-value accounts: run single on admin/service accounts first — a successful guess here has greater impact and is quick to test.

Practical example — enrich GECOS and chain attacks

# 1) Create a synthetic passwd with helpful GECOS fields (example snippet)
cat > mypasswd <<'EOF'
bob:x:1001:1001:Bob Smith:/home/bob:/bin/bash
alice:x:1002:1002:Alice Johnson:/home/alice:/bin/bash
EOF

# 2) Combine with actual shadow (or a test shadow) - unshadow accepts passwd+shadow
unshadow mypasswd /path/to/shadow > enriched-shadow.txt

# 3) Run single mode on the enriched file
./john enriched-shadow.txt --single --session=single1

# 4) Export cracked values to seed a new wordlist
./john --show enriched-shadow.txt --format=crypt > cracked.txt
# (process cracked.txt to extract plaintexts into seed-wordlist.txt)

# 5) Run wordlist+rules with the seeded list
./john enriched-shadow.txt --wordlist=seed-wordlist.txt --rules --session=chained1

When single mode won’t help

• Targets using randomly generated passwords (passphrases with high entropy).
• Systems with strict password policies that force complex, non-name-based choices.
• When GECOS or username fields are empty or sanitized — single mode has less to work with.

Ethics & audit advice

Single mode is noisy in the sense of testing obvious credentials quickly — document every step, the data sources you used to enrich metadata, and ensure your client or target owner agreed to these specific techniques in the engagement scope. Don’t store or share recovered credentials beyond what’s required for remediation reporting.

Creating Custom Rules (Like a Password Wizard)

Default rule sets are useful, but custom rules let you model target-specific behavior. Well-crafted rules turn a modest wordlist into a highly targeted corpus of realistic guesses — often achieving far higher success than brute-force while using much less CPU/GPU time.

Practical rule file (example)

# File: ~/john/custom.rules
# Append recent years (useful for passwords containing years)
Az"2025" Az"2024" Az"2023"

# Common leet substitutions
s a @
s e 3
s i 1
s o 0
s t 7

# Capitalize + add common specials
c Az"!" c Az"@" c Az"#"

# Prepend common numbers / prefixes
^1 ^12 ^123 ^2025

# Reverse / duplicate to catch palindrome or repeated patterns
r
d

What these commands mean (brief)

• Az"2025" — append the literal 2025 to the end of each word (very common human pattern).
• s a @ — substitute a → @ (simple leet mapping). You can chain many substitution lines to simulate multiple leet changes.
• c — capitalize the first character (useful for names or sentence-style passwords).
• ^1 — prepend 1 to the front of each word (common numeric prefixes).
• r — reverse the word; catches backwards patterns (e.g., drowssap).
• d — duplicate the word (e.g., pass → passpass).

How to test rules safely (always do this first)

Rules can explode combinatorially. Before running long jobs, estimate how many candidates a rule set will generate and sample them:

# Print transformed candidates (dry-run) — useful to inspect and count
./john --wordlist=/usr/share/wordlists/rockyou.txt --rules=custom.rules --stdout | head -n 50

# Count total candidates (estimate)
./john --wordlist=/usr/share/wordlists/rockyou.txt --rules=custom.rules --stdout | wc -l

If the candidate count is enormous, split rules into tiers or reduce the wordlist first (use top-n, frequency-sorted lists).

Rule design strategies & patterns

• Tiered rules: build a small high-probability ruleset (years, capitalize, common subs) and a larger lower-probability set (complex chains). Run the small set first and only escalate if needed.
• Target-aware rules: incorporate organization-specific tokens (company/product names, locations) as appends/prepends rather than blind numeric suffixes.
• Leetspeak carefully: apply 1–2 substitutions per word rather than all at once — multi-substitution combos grow quickly but are often low-value.
• Short rules for short words: set --max-length or filter short words before heavy mutation to avoid useless long candidates (e.g., 3-letter words generally shouldn't become 20+ char strings).
• Rule ordering matters: place highest-probability mutations earlier (capitals, years) and expensive combinatorial rules later. This maximizes early hits.

Combining rules with other modes

• Wordlist + custom.rules: your most common workflow. Example:
  ./john hash.txt --wordlist=corp-seed.txt --rules=custom.rules --session=seeded
• Single → Rules chain: run --single, export guesses, then feed them through rules as a prioritized seed list for broader passes.
• Masks + rules: when you know structure, run masks to constrain length/charset and then apply a small, surgical ruleset for human tweaks.

Performance & operational tips

• Use --stdout for sampling — it avoids hashing and is fast for inspecting rule output.
• Profile candidate growth: run candidate counts on small subsets of your wordlist to extrapolate total work and cost.
• Centralize potfiles: point multiple runs at the same john.pot to avoid wasteful duplication.
• Favor prioritized wordlists: frequency-sorted lists (top-most likely first) make rules more efficient because high-probability seeds are tried early.
• Limit concurrency wisely: using many --fork workers helps CPU-bound jobs but may saturate I/O when writing potfiles; monitor disk throughput.

Example advanced rule recipes

# admin-target.rule: designed for admin/service accounts
# 1) Capitalize
c
# 2) Append common admin suffixes
Az"!" Az"@"
Az"2024" Az"2023"
# 3) Prepend common numeric prefixes
^1 ^12

# mobile-pin.rule: short numeric focus (pair with usernames or small wordlist)
^+ ^++  # prepend 1-2 digits (example, check your rule syntax for desired prefixes)

Safety, documentation & reproducibility

• Version control your rules: store rule files in Git and tag the commit used for each engagement.
• Document experiments: note which rule sets produced hits and which didn’t — this helps refine future rules.
• Backup potfiles: before applying aggressive rules, snapshot your potfile so you can compare results between passes.
• Respect scope & privacy: only use targeted corpora and rules that are authorized within the engagement agreement.

Quick command cheatsheet

# Dry-run to inspect first 100 transformed candidates
./john --wordlist=small.txt --rules=custom.rules --stdout | head -n 100

# Count candidates (estimate)
./john --wordlist=small.txt --rules=custom.rules --stdout | wc -l

# Run with rules against a target
./john hash.txt --wordlist=corp-seed.txt --rules=custom.rules --session=custom1

# Resume later
./john --restore=custom1

Cracking ZIP Files (All Flags Explained)

ZIPs are tricky because there are multiple encryption schemes and container layouts. The general flow is: extract a John-readable hash with zip2john → choose strategy (wordlist, rules, mask) → run John with sessions/forks → resume/report. Below are practical details, edge cases, and examples that will save you time.

Quick extract & basic run

# Extract hash from the archive (produces one or more hash lines)
./zip2john secret.zip > zip.hash

# Basic cracking with resume support (wordlist)
./john zip.hash --wordlist=/usr/share/wordlists/rockyou.txt --session=zip-crack --fork=4

# Resume later
./john --restore=zip-crack

# Show cracked passwords
./john --show zip.hash

Understanding ZIP encryption types

• ZipCrypto (traditional PKZIP): older scheme, weak and very fast to attack; zip2john will extract a simple hash. Try wordlists & rules first.
• WinZip AES (AES-128 / AES-256): uses stronger KDFs (PBKDF2) and is much slower to brute force. Work factor depends on iteration count; check the extracted hash header to see KDF params.
• Encrypted filenames vs file contents: some archives only encrypt file contents, some encrypt filenames (harder to even list files). zip2john will reveal what it can extract — read the produced lines.

Flags, options & their effects

• --session=name: Save job state so you can resume anywhere. Always use sessions for long runs.
• --restore=name: Resume a saved session.
• --fork=N: Parallelize CPU-bound jobs across N processes (useful for ZipCrypto and other CPU formats). Not all formats benefit equally.
• --format=...: Force a specific format if John misdetects (e.g., some zip-derived hashes). Use ./john --list=formats to find candidate names.
• --verbosity=N: Increase to 5 to print each guess (very noisy) — useful for debugging rule behavior or confirming expected candidates are being generated.
• --potfile=PATH: Centralize cracked outputs; useful when running multiple jobs against the same potfile.
• --wordlist=PATH / --rules: Combine to get realistic candidates quickly (--rules multiplies each wordlist entry).

When to use masks vs wordlists

If you suspect a short numeric PIN or structured password, masks are far faster. For human-chosen passwords, wordlists + rules usually win.

# Mask example (4-digit PIN)
./john zip.hash --mask='?d?d?d?d' --session=zip-pin

# Wordlist + rules (human passwords)
./john zip.hash --wordlist=corp-seed.txt --rules=custom.rules --session=zip-word

Handling multi-file archives & multiple hash lines

zip2john may output one hash per encrypted member. John treats them together; a crack for any member may reveal the archive password. Use--show to see which hash lines correspond to cracked entries and inspect zip.hash (it contains format labels and file IDs).

Performance tips & KDF awareness

• Check KDF work factor: WinZip AES or other modern ZIP KDFs may include iteration counts. High iteration counts make CPU-only cracking impractical.
• Use GPUs when sensible: For heavy workloads and supported formats, OpenCL/CUDA acceleration helps — but John’s GPU coverage is smaller than Hashcat’s. Consider converting to Hashcat if you need exhaustive GPU throughput.
• Profile short candidate sets first: run --stdout with your wordlist+rules to preview candidates and estimate count before a long run:
  ./john --wordlist=small.txt --rules=custom.rules --stdout | wc -l

Resume, logging & safe operations

• Always use --session for long ZIP jobs — it lets you resume after crashes or reboots without losing progress.
• Redirect John logs and keep the potfile backed up so you can audit what was tried and which passwords were recovered.
• Be cautious with verbosity: don't run --verbosity=5 on production-sized runs — it will generate huge amounts of console output.

Edge cases & gotchas

• Encrypted file lists: If filenames are encrypted, you might not even be able to list contents; hash extraction may be limited — inspect zip2john output carefully.
• Strong KDFs: if the hash includes PBKDF2/Scrypt/Argon2-like parameters with large iteration counts, consider whether cracking is economically feasible.
• Corrupted or patched zips: some archives created by certain tools or partially corrupted files produce unusual hash outputs — try opening in a ZIP tool to validate integrity first.

Example advanced workflow

# 1) Extract hashes
./zip2john secret.zip > zip.hash

# 2) Quick smoke test (30s) with a small prioritized wordlist
./john zip.hash --wordlist=top1k.txt --session=zip-smoke --format=zip

# 3) If nothing, run wordlist+rules scaled
./john zip.hash --wordlist=rockyou.txt --rules=custom.rules --fork=6 --session=zip-main

# 4) If you know structure, run mask-only for short PINs
./john zip.hash --mask='?d?d?d?d?d' --session=zip-pin

# 5) Resume or inspect
./john --restore=zip-main
./john --show zip.hash

Legal & ethical reminder

Extracting and cracking archive passwords must be authorized. Only attempt recovery on files you own or have explicit permission to test. Log your steps and protect any recovered secrets.

Cracking RAR Files (RAR3 vs RAR5)

RAR archives come in different generations and container options — and those differences change how feasible cracking is. The typical workflow is: extract a John-readable hash with rar2john → choose a strategy (wordlist/rules/mask) → run John (sessions/forks) → resume/report.

# Extract hash (produces one or more hash lines)
./rar2john secret.rar > rar.hash

# Basic cracking run (wordlist + forks + session)
./john rar.hash --wordlist=/usr/share/wordlists/rockyou.txt --fork=8 --session=rar-main

# Resume
./john --restore=rar-main

# Show cracked
./john --show rar.hash

RAR3 vs RAR5 — what changes

• RAR3 (older): uses weaker KDFs/crypto by modern standards and is significantly faster to attack; many RAR3 archives can be cracked with wordlists + rules or masks.
• RAR5 (modern): uses a stronger KDF (PBKDF2 / HMAC-SHA256 style with iterations and salts) and stronger encryption parameters — this makes each guess much slower and often impractical on CPU-only rigs.
• Solid archives & multi-volume: solid compression and multi-volume layouts can affect how data is encrypted and how many hash lines are produced; inspect rar2john output carefully.

How to tell which RAR you have

Run rar2john and inspect the header it outputs — it often contains labels indicating RAR version or KDF parameters. If you're unsure, try a quick smoke test (30–60s) with a small wordlist to confirm John processes it as expected.

Strategy selection — practical advice

• Start with metadata-driven & single mode: for archives created by people, usernames, project names, or obvious tokens (project2024, client-name) often appear as passwords.
• Wordlist + rules: for human-chosen passwords this is the best first scaled approach — rules model common human tweaks (years, symbols, leet).
• Masks for PINs/short secrets: if you suspect a short numeric PIN or structured password, masks (e.g. ?d?d?d?d) are dramatically faster than wordlists with rules.
• Use GPUs for RAR3; be cautious with RAR5: GPUs (Hashcat or John OpenCL) greatly speed up RAR3-style workloads. For RAR5’s heavy KDF, evaluate whether GPU or cloud resources make the job economically feasible — and always check legal/ethical scope first.

Mask & wordlist examples

# Short PIN (4 digits)
./john rar.hash --mask='?d?d?d?d' --session=rar-pin

# Wordlist + custom rules
./john rar.hash --wordlist=corp-seed.txt --rules=custom.rules --fork=6 --session=rar-seed

GPU & Hashcat considerations

John has some OpenCL support in Jumbo, but Hashcat frequently offers broader GPU format coverage and faster kernels. If you plan heavy GPU runs, consider:

• Converting/formatting hashes for Hashcat (check Hashcat wiki for the correct mode and input format).
• Testing both John and Hashcat on the same small workload to see which performs better for your target format.
• Remembering that RAR5’s KDF may still be very costly even on GPUs — always estimate cost/time before committing large resources.

Performance & feasibility checklist

• Check KDF/iteration parameters from rar2john output.
• Run a short benchmark/smoke test with a small wordlist to confirm the format and measure c/s (candidates per second).
• Estimate total candidates (wordlist size × rule multipliers or mask space) and multiply by c/s to get approximate time — if it’s days/weeks, reconsider strategy.

Session management, logging & safety

• Always use --session for long runs so you can resume after interruptions.
• Back up your potfile and session files periodically to avoid losing progress.
• Use --verbosity sparingly — high verbosity is useful for debugging but noisy for large runs.

Edge cases & gotchas

• Corrupted or specially-created RARs: some archives created by niche tools or partially corrupted files can produce odd rar2john output — always verify archive integrity first with an archiver.
• Multi-volume archives: ensure you have all parts; missing volumes can prevent correct hash extraction or make the password untestable.
• Solid archives: compression options sometimes affect extraction and the helpfulness of rar2john output — inspect the hash lines for details.

Defensive (blue team) tips

• Prefer client-side encrypted containers with strong KDFs and high iteration counts when protecting sensitive archives.
• Use long passphrases (20+ chars) rather than short passwords — they beat wordlist/rule attacks and make mask/incremental infeasible.
• Keep backups and logs secure; a leaked archive plus metadata greatly increases an attacker’s success chances.

Legal & ethical reminder

Only attempt RAR cracking on files you own or have explicit permission to test. Keep a signed scope and treat any recovered data as sensitive — do not publish or reuse recovered credentials.

Cracking SSH Private Keys (Practical Guide)

SSH private keys are often protected by a passphrase. Recovering that passphrase is similar to cracking any other secret — you extract a hash-like representation and run offline guesses. But modern OpenSSH formats use expensive KDFs (bcrypt) which make cracking far slower. Below are practical extraction steps, format notes, strategy, and defense guidance.

Quick extract & basic run

# Extract a John-readable hash from a private key
./ssh2john id_rsa > ssh.hash

# Run John with a wordlist and multiple forks (CPU)
./john ssh.hash --wordlist=/usr/share/wordlists/rockyou.txt --fork=16 --session=ssh1

# Show cracked passphrases (if any)
./john --show ssh.hash

Which key types / formats matter

• Legacy PEM (OpenSSL-style): older RSA/DSA private keys stored in PEM with simple symmetric encryption — easier to crack if weak passphrase.
• OpenSSH new-format (recommended by OpenSSH): starts with -----BEGIN OPENSSH PRIVATE KEY----- and typically uses the bcrypt KDF (configurable rounds via -a), making each guess much more expensive.
• Ed25519 / ECDSA / RSA: all supported; the work factor is determined by the key file's KDF/rounds rather than the algorithm itself.

Detecting KDF / cost parameters

Inspect the private key header: OpenSSH new-format keys contain KDF/bcrypt parameters embedded in the file. If the key uses bcrypt with many rounds (high rounds or -a value), expect each candidate to be slow. Use a quick ssh2john extraction and run a 30s smoke test to measure c/s.

Strategy — which attacks to try (order of operations)

1. Smoke test: extract with ssh2john and run John for 30–60s with a small wordlist to confirm format and get a baseline c/s.
2. Single + seeded lists: if you know username, project names, or related tokens, seed a small prioritized list first — many admins use memorable phrases.
3. Wordlist + small rules: try curated corpora (personal/company tokens) combined with tight rule sets (capitalize, append year) before broad combinatorials.
4. Masks for short passphrases/PINs: if you suspect short structured passphrases (e.g., 6–8 chars), masks are faster than full rules on long lists.
5. Incremental / exhaustive: only as last resort; for bcrypt-backed keys this is often impractical.

Examples: masks & rules for passphrases

# Mask example: 8-char passphrase (3 letters + 3 letters + 2 digits)
./john ssh.hash --mask='?l?l?l?l?l?l?d?d' --session=ssh-mask

# Wordlist + concise rules (capitalize + year)
./john ssh.hash --wordlist=seed.txt --rules='c Az"2025"' --session=ssh-rules

GPU usage & Hashcat notes

John can handle many SSH extractions, but heavy GPU work and some KDFs are better served by Hashcat or specialized tools. If you plan a large GPU run:

• Measure John’s c/s and compare with Hashcat on a small sample (Hashcat often has faster GPU kernels for certain formats).
• Converting some extracted formats to Hashcat-compatible input may be necessary — check Hashcat docs for the correct mode.
• Remember that bcrypt/PBKDF2/argon2-backed private keys are intentionally slow: GPUs help, but cost still scales with the KDF work factor.

Practical performance tips

• Always run --stdout on a small seed + rules to preview candidates before hashing.
• Use --session and --potfile to resume and centralize cracked outputs.
• If using many --fork workers, monitor system load — disk I/O (potfile writes) can become the bottleneck.
• For very slow KDF keys, prioritize high-value keys and short lists — exhaustive approaches often cost more than the value of recovered access.

Defensive recommendations (how to protect SSH keys)

• Use the OpenSSH new private key format with a strong passphrase and a high KDF rounds value:

  # Re-encrypt key with bcrypt KDF and 100k rounds (example)
  ssh-keygen -p -f id_rsa -o -a 100000
  

  The -o option forces the new format; -a sets KDF rounds.
• Use long passphrases (20+ characters) or a hardware-backed key (YubiKey) so offline cracking is infeasible.
• Protect private key files with strict filesystem permissions and avoid storing them on shared or backed-up locations without encryption.
• Disable agent forwarding unless required and monitor for SSH agent requests and suspicious forwarding activity.

Legal & ethical reminder

Cracking private key passphrases must only be performed with explicit authorization (e.g., for recovery of your own keys or within a defined engagement). Always document consent, limit exposure of recovered secrets, and follow responsible disclosure and data-handling practices.

Further Reading & Pro Resources

Want to go deeper? These resources are grouped and annotated so you can pick a learning path — from official docs and code to hands-on labs, advanced rule-writing, and GPU-focused cracking. Follow the suggested order if you’re studying this end-to-end.

Official & core project resources

• Official John Site — primary landing page for John the Ripper. Start here for downloads, news, and the official project perspective.
• bleeding-jumbo GitHub — source code, issues, and pull requests. Clone it to build yourself and inspect format modules, helpers, and the test suite.
• John rules syntax guide — authoritative reference for the rule language. Read this carefully before writing custom.rules; smaller, well-ordered rules outperform massive chaotic lists.

GPU & high-throughput tools

• Hashcat Wiki — exhaustive GPU-focused documentation, example hashes, mask syntax, and tuning tips. Use it if you plan heavy GPU runs or need performance comparisons vs John.
• Hashcat GitHub / community — community-built rule files, masklists, and benchmark results. Great for seeing real-world optimizations.

Hands-on learning & labs

• TryHackMe John Room — guided, hands-on exercises that walk you through extraction and simple cracking workflows. Ideal for beginners who want practical experience in a safe lab.
• VulnHub / CTF writeups — search for writeups that mention John; many real CTFs show clever tricks for extracting hashes and chaining attacks.

Wordlists, corpora & community contributions

• SecLists — a curated collection of wordlists, usernames, and password lists used by many security pros. Use frequency-sorted lists to maximize early hit rate.
• rockyou.txt — classic starter list (great for demos); combine it with rules and prioritized corpora for real testing.
• Targeted corpora — build corpora from company subdomains, product names, or public repos for higher success on org-scoped engagements.

Advanced reading (papers, blogs & deep-dives)

• Openwall blog & mailing list — discussions of John internals, format support, and developer rationale. Great if you want to contribute or understand design decisions.
• Technical blog posts / benchmarks — search for comparative benchmarks (John vs Hashcat) and deep dives on KDFs (bcrypt, argon2, PBKDF2) to understand cost trade-offs.
• Books on applied cryptography and forensics — pick ones that cover hashing, KDFs, and practical password security to round out theoretical knowledge.

Useful utilities & tooling

• zip2john / rar2john / ssh2john / unshadow — bundled extractors; learn them well — they’re the bridge between raw files and John.
• hashid / hash-identifier — quick heuristics to narrow down candidate formats before you test.
• john --list=formats / --list=opencl — indispensable commands to see what your build supports.

Study path (recommended order)

1. Read the John rules guide and skim the Jumbo README on GitHub.
2. Do the TryHackMe John room or a small lab extracting and cracking a ZIP/SSH key locally.
3. Practice writing small rule files, use --stdout to inspect candidate growth, and iterate.
4. Benchmark John vs Hashcat for a few formats you care about (NTLM, md5crypt, zip) to learn performance trade-offs.
5. Version-control your rules and corpora and build a reproducible Docker or VM environment for experiments.

Community & safety

Join community forums (Openwall mailing list, Hashcat Discord/subreddit) for up-to-date tips and shared rule sets — but never share leaked credentials or sensitive corpora publicly. Always follow legal/ethical guidance and get written authorization for any testing.

Final tip: combine documentation + hands-on labs + small reproducible experiments. Read the official docs, practice in a lab, then iterate your rules and corpora based on measured results.