John the Ripper jumbo: a Unix password auditor that admits its code is rough

The crypt(3) families it finds before you pass a single option

John the Ripper's stated purpose is narrow: detect weak Unix passwords. Its out-of-the-box value is format detection rather than wordlist quality, because the core build recognises traditional DES-based crypt(3) hashes, bigcrypt, BSDI extended DES-based, the FreeBSD MD5-based scheme also used on Linux and in Cisco IOS, and the OpenBSD Blowfish-based scheme now carried by some Linux distributions and supported by recent Solaris. Kerberos/AFS hashes, Windows LM (DES-based) hashes and DES-based tripcodes ship alongside them. For a system administrator who has just collected shadow file copies from several hosts, that list is the whole first triage: you get the account names to rotate without writing a filter for each Unix flavour. Windows administrators feed the same binary an LM hash dump.

john.pot lives in the home directory, and the home directory depends on your install

Handing the binary a password file is the entire first command, and John walks its cracking modes in the default order until something breaks:

john passwd

Every recovered password goes to the terminal and is appended to $JOHN/john.pot. That path is relative to John's home directory, and which directory it really is depends on how you installed John, so two machines set up by different methods do not share a pot file even when the same binary name sits in $PATH. John reads the pot file on the next run and skips hashes already listed in it, which is what stops a resumed audit from redoing finished work. To pull the stored values back out rather than watch a live session:

john --show passwd

Expect the pot file to keep entries from earlier jobs. It maps recovered hashes to passwords and is not scoped to the file you just cracked, so it grows across a whole audit cycle and is worth archiving as a finding rather than deleting between runs.

Wordlist mode, mangling rules, and a compiler that runs your own code

Restricting the run to wordlist mode drops the automatic formats, but the rules option stays available, so you control how candidates get mangled:

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

John also carries a built-in compiler supporting a subset of C, which the core documentation presents as the way to define a custom cracking mode when the built-in ones do not fit a target. That is a real capability and also a liability: a mode you write in that compiler is your code executing inside the cracker, so it deserves the same review as anything else you put on an audit host. The official GUI, Johnny, drives the same core, and because it is a separate program you need John installed before it does anything.

A second Ctrl-C discards the session instead of saving it

Interruption handling is where a long run quietly loses time. Pressing any key during a session prints status. q or Ctrl-C ends the run after saving state to $JOHN/john.rec. The edge case is documented: if you press Ctrl-C a second time before John has had a chance to complete handling of the first, it aborts immediately without saving anything. On a slow format, a keypress meant for status followed by an impatient second interrupt throws away everything since the last save. The same file is written every 10 minutes by default so a crash can be recovered from, and continuing an interrupted session takes:

john --restore

OpenMP stays off until you edit the Makefile, and GPUs go unmentioned

CPU parallelism is not on by default. On Linux distributions with glibc 2.7+, John 1.7.6+ autodetects SHA-crypt hashes (the ones recent Fedora and Ubuntu use) and offers optional OpenMP, but enabling it needs GCC 4.2+ and an edit before you compile: you uncomment the proper OMPFLAGS line near the beginning of the Makefile. On recent Solaris, John 1.7.6+ autodetects SHA-crypt and SunMD5 the same way, needing GCC 4.2+ or recent Sun Studio, the same uncommented line, plus the OMP_NUM_THREADS environment variable set at runtime to the thread count you want. Note that OMP_NUM_THREADS appears only in the Solaris passage, so the Linux threading story is thinner than the Solaris one. Pre-compiled distributions may ship alternate executables instead of a single john, with john-omp named as the example for multiple CPUs or cores, so the package you install may not expose threading at all. The larger gap is graphics hardware: the repository description claims runs on many operating systems, CPUs, GPUs and even some FPGAs, yet the core documentation section of the README covers only the OpenMP route, so check the separate documentation files before planning GPU throughput.

A bundled *2john has to flatten the file before John ever sees it

Jumbo stretches past password hashes into files, and the conversion step is where that gets awkward. The added non-hash targets include SSH private keys, S/Key skeykeys files, Kerberos TGTs, macOS .dmg files and sparse bundles, ZIP in both classic PKZIP and WinZip/AES flavours, RAR, 7z, PDF and Microsoft Office documents. For the larger of these you run the corresponding bundled *2john program first and feed its output into JtR-jumbo. John therefore never opens the container itself: something else has to pull the key material or the encrypted payload out first. The consequence for an auditor is that a bad conversion surfaces as a hash set John has nothing to work on, so OPTIONS, which covers command line options and additional utilities, and each tool's own help are where you look. One boundary worth stating plainly: every target listed here is a file you already hold.

The project's own words: quality requirements are low, bugs are expected

Jumbo sets expectations bluntly. It is easy for new code to be added, the quality requirements are low, and only lately have contributions been put through quite some automated testing. The consequence stated in the same paragraph is that you get a lot of functionality that is not necessarily mature, which in turn means bugs in the code are to be expected. That is an unusual concession for a security tool to print in its own README, and it changes how you deploy the thing. The repository does carry test infrastructure, with .ci/, .circleci/, .travis.yml and .pre-commit.sh at the top level, and that is what the automated testing claim rests on. What the wording does not claim is per-format validation. The last push on this repository was on 2026-11-02, so the code moves quickly; whether any one format is correct stays your verification burden, and the honest way to discharge it is to cross-check a recovered hash against a second implementation.

A bleeding branch with no releases here, and a licence field left unasserted

Versioning gives you a branch rather than a release. The default branch is bleeding-jumbo, the repository has no GitHub releases, and the release badge in the README points at a separate repository, openwall/john-packages/releases, which is where pre-compiled distributions come from. An upgrade is therefore either a rebuild from a moving branch or a binary pulled from a sibling repository, and pinning a known-good copy matters more than usual given the quality note above. Some distributions also ship alternate executables instead of just john, john-omp being the named example, so a wrapper script that assumes one binary name can break on upgrade. Contributions go through pull requests on GitHub, and discussion belongs on the john-users mailing list rather than in an issue thread. On licensing, the repository's licence field reads NOASSERTION while both a LICENSE file and doc/LICENSE sit in the tree. Read those two files yourself before redistributing anything you build here; this article gives no legal reading of them.

Editorial conclusion

Adopt jumbo if you own the systems and want a fast read on which of your own accounts fall to a wordlist. Do not adopt it as evidence in an audit you have to defend, because the hash implementations are contributed code the project itself describes as not necessarily mature. Before anything else, read doc/INSTALL for your platform and compile the format you plan to rely on, then cross-check one recovered hash against a second tool.

Frequently asked questions

Official sources

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