John the Ripper Jumbo: The Community-Enhanced Offline Password Cracker

What John the Ripper Jumbo Is and Its Primary Purpose

John the Ripper is a password cracker. The README states that its primary purpose is to detect weak Unix passwords. The Jumbo version is a community-enhanced fork that adds substantial functionality beyond what the core delivers: hundreds of additional hash and cipher types, support for encrypted archives and documents, and contributions from the security community.

The README describes Jumbo's quality model directly: it is easy for new code to be added, and the quality requirements are low. This means functionality arrives quickly, but bugs in contributed code are expected. The project's own description is that you get a lot of functionality that is not necessarily mature. This is the trade-off between feature breadth and production stability.

The project runs on many flavors of Unix, macOS, Windows, DOS, BeOS, and OpenVMS, according to the README. The bleeding-jumbo branch on GitHub is the canonical source. There are no GitHub releases; binary packages are maintained in a separate john-packages repository.

Hash Types Supported Out of the Box and in Jumbo

The core John the Ripper supports and autodetects the following Unix crypt(3) hash types: traditional DES-based, bigcrypt, BSDI extended DES-based, FreeBSD MD5-based (also used on Linux and in Cisco IOS), and OpenBSD Blowfish-based. Kerberos/AFS and Windows LM hashes are also supported in the core, along with DES-based tripcodes.

On Linux systems with glibc 2.7 or later, John 1.7.6 and later additionally supports SHA-crypt hashes, which are used by recent versions of Fedora and Ubuntu, with optional OpenMP parallelization. OpenMP support requires GCC 4.2 or later and must be explicitly enabled at compile time by uncommenting the OMPFLAGS line in the Makefile.

The Jumbo extensions add Windows NTLM (MD4-based) password hashes, various macOS and Mac OS X password hashes, fast hashes including raw MD5, SHA-1, SHA-256, and SHA-512, SQL and LDAP server password hashes, SSH private keys, S/Key skeykeys files, Kerberos TGTs, encrypted filesystems including macOS .dmg files and sparse bundles, encrypted archives including ZIP (classic PKZIP and WinZip/AES), RAR, and 7z, and encrypted documents including PDF and Microsoft Office files.

Basic Usage: Running John and Managing Sessions

The minimum invocation is the john command followed by a password file:

john passwd

This runs through the default cracking mode sequence. To restrict to wordlist mode with word mangling rules:

john --wordlist=password.lst --rules passwd

Cracked passwords are printed to the terminal and saved to `$JOHN/john.pot`. On the next run, hashes already in the pot file are skipped. To display all cracked passwords:

john --show passwd

Cracking sessions can be interrupted and resumed. Pressing q or Ctrl-C saves the session state to `$JOHN/john.rec`. The state is also automatically saved every 10 minutes to protect against crashes. To resume an interrupted session:

john --restore

Session state can be continued even on a different platform, according to the README, which is useful for moving a long-running job between systems.

Binary distributions of John may include multiple executables. The `john-omp` executable uses OpenMP to take advantage of multiple CPUs and cores. Choosing the right executable for the hardware is noted in the README as something users may need to do manually.

Cracking Modes and the Built-In Rule Compiler

John combines several cracking modes in one program. The default mode runs through a preset sequence. The wordlist mode (enabled with --wordlist) tests candidate passwords from a file, with optional rule-based mangling via --rules. Additional modes are documented in the MODES file in the doc/ directory.

A distinctive capability is the ability to define a custom cracking mode using John's built-in compiler. The README describes it as supporting a subset of C. This lets users write their own transformation logic for generating candidate passwords from a wordlist or from scratch, beyond what the predefined rules provide.

The configuration system is documented in CONFIG in the doc/ directory. The README describes John as fully configurable for particular needs. The reference to OPTIONS and EXAMPLES in the doc/ directory covers the full list of command-line options and more complex usage scenarios beyond the basic examples.

The *2john Programs for Encrypted Files and Archives

Many of the hash types added by Jumbo require a preprocessing step. To crack a password from an encrypted ZIP file, a PDF, an SSH private key, or a macOS .dmg, the file must first be processed by a corresponding `*2john` program, which extracts the hash information into a format John can work with.

The README describes the pattern: a corresponding bundled *2john program should be used first, and then its output fed into JtR jumbo. For example, zip2john processes a ZIP archive and produces the hash data that john then attempts to crack. These conversion utilities are in the run/ directory at the top level of the repository.

This two-step workflow is specific to the non-Unix-password targets. For traditional password hash files, the direct invocation (john passwd) is sufficient. The *2john programs extend John's reach to an entirely different category of cracking target without changing the core cracking engine.

John the Ripper vs Hashcat

Hashcat is another well-known offline password recovery tool. It is primarily designed around GPU acceleration and supports many of the same hash types as John the Ripper Jumbo. The two tools represent different optimization targets.

John the Ripper's traditional architecture is CPU-based with OpenMP support for multi-core parallelism. The Jumbo description mentions running on CPUs, GPUs, and even some FPGAs, indicating GPU support is present in the jumbo additions. Hashcat was built from the start around GPU compute, which typically gives it a throughput advantage on hardware where GPU acceleration is available and the hash algorithm supports it.

For a system administrator doing a routine Unix password audit on a server without a discrete GPU, John the Ripper's CPU-oriented default path is practical without special hardware. For a security researcher running large-scale attacks on GPU rigs, Hashcat is more commonly the tool of choice. Both are open-source, and both support a large set of hash types. The right choice depends on available hardware and the specific hash type being targeted.

Johnny GUI, Documentation, and the Bleeding-Jumbo Branch

Johnny is the official graphical interface for John the Ripper. The README notes that it is a separate program; John the Ripper must already be installed to use it. Johnny is oriented toward the JtR core but its basic functionality is described as working across all versions including Jumbo. Documentation for Johnny is at openwall.info/wiki/john/johnny.

The rest of the documentation is organized into separate files in the doc/ directory: INSTALL, OPTIONS, MODES, CONFIG, RULES, and EXAMPLES, among others. The README recommends reading them in that order.

The GitHub repository's default branch is bleeding-jumbo, indicating that the code on the main branch is the bleeding-edge development version. The last push to bleeding-jumbo was on 2026-08-01. Binary packages for users who do not want to compile from source are maintained in the separate openwall/john-packages repository, as linked from the README.

Editorial conclusion

Security professionals and system administrators who need to audit password hashes offline, test password policy enforcement, or recover credentials from encrypted files should evaluate John the Ripper Jumbo. The bleeding-jumbo branch on GitHub is the community-enhanced version; its last push was on 2026-08-01. The README is explicit that the Jumbo additions have lower quality requirements than the core, meaning bugs in contrib code are expected. Before running against any system, verify that you have authorization. The project's homepage at openwall.com/john/ has the latest documentation and binary packages, since the GitHub repository has no releases.

Frequently asked questions

Official sources

1. Issues
2. openwall/john on GitHub
3. Project website
4. README