John the Ripper
John the Ripper Description
John the Ripper jumbo - advanced offline password cracker, which supports hundreds of hash and cipher types, and runs on many operating systems, CPUs, GPUs, and even some FPGAs.
John the Ripper is designed to be both feature-rich and fast. It combines several cracking modes in one program and is fully configurable for your particular needs (you can even define a custom cracking mode using the built-in compiler supporting a subset of C). Also, John is available for several different platforms which enables you to use the same cracker everywhere (you can even continue a cracking session which you started on another platform).
Out of the box, John 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 (now also used on some Linux distributions and supported by recent versions of Solaris). Also supported out of the box are Kerberos/AFS and Windows LM (DES-based) hashes, as well as DES-based tripcodes.
When running on Linux distributions with glibc 2.7+, John 1.7.6+ additionally supports (and autodetects) SHA-crypt hashes (which are actually used by recent versions of Fedora and Ubuntu), with optional OpenMP parallelization (requires GCC 4.2+, needs to be explicitly enabled at compile-time by uncommenting the proper OMPFLAGS line near the beginning of the Makefile).
Similarly, when running on recent versions of Solaris, John 1.7.6+ supports and autodetects SHA-crypt and SunMD5 hashes, also with optional OpenMP parallelization (requires GCC 4.2+ or recent Sun Studio, needs to be explicitly enabled at compile-time by uncommenting the proper OMPFLAGS line near the beginning of the Makefile and at runtime by setting the OMP_NUM_THREADS environment variable to the desired number of threads).
"-jumbo" versions add support for hundreds of additional hash and cipher types, including fast built-in implementations of SHA-crypt and SunMD5, Windows NTLM (MD4-based) password hashes, various macOS and Mac OS X user password hashes, fast hashes such as raw MD5, SHA-1, SHA-256, and SHA-512 (which many "web applications" historically misuse for passwords), various other "web application" password hashes, various SQL and LDAP server password hashes, and lots of other hash types, as well as many non-hashes such as SSH private keys, S/Key skeykeys files, Kerberos TGTs, encrypted filesystems such as macOS .dmg files and "sparse bundles", encrypted archives such as ZIP (classic PKZIP and WinZip/AES), RAR, and 7z, encrypted document files such as PDF and Microsoft Office's - and these are just some examples. To load some of these larger files for cracking, a corresponding bundled *2john program should be used first, and then its output fed into JtR -jumbo.
There is an official GUI for John the Ripper: Johnny.
Despite the fact that Johnny is oriented onto JtR core, all basic functionality is supposed to work in all versions, including jumbo.
Johnny is a separate program, therefore you need to have John the Ripper installed in order to use it.
John the Ripper is an actively developing program. John the Ripper (community jumbo version) comes with a lot of helper utilities. Among these utilities are programs for generating (extracting) a hash. This hash is used to crack the password in John the Ripper. Third-party password cracking programs such as Hashcat also work with hashes extracted using the utilities from the John the Ripper package.
Author: Solar Designer
John the Ripper Help
john [OPTIONS] [PASSWORD-FILES]
--help Print usage summary --single[=SECTION[,..]] "Single crack" mode, using default or named rules --single=:rule[,..] Same, using "immediate" rule(s) --single-seed=WORD[,WORD] Add static seed word(s) for all salts in single mode --single-wordlist=FILE *Short* wordlist with static seed words/morphemes --single-user-seed=FILE Wordlist with seeds per username (user:password[s] format) --single-pair-max=N Override max. number of word pairs generated (6) --no-single-pair Disable single word pair generation --[no-]single-retest-guess Override config for SingleRetestGuess --wordlist[=FILE] --stdin Wordlist mode, read words from FILE or stdin --pipe like --stdin, but bulk reads, and allows rules --rules[=SECTION[,..]] Enable word mangling rules (for wordlist or PRINCE modes), using default or named rules --rules=:rule[;..]] Same, using "immediate" rule(s) --rules-stack=SECTION[,..] Stacked rules, applied after regular rules or to modes that otherwise don't support rules --rules-stack=:rule[;..] Same, using "immediate" rule(s) --rules-skip-nop Skip any NOP ":" rules (you already ran w/o rules) --loopback[=FILE] Like --wordlist, but extract words from a .pot file --mem-file-size=SIZE Size threshold for wordlist preload (default 2048 MB) --dupe-suppression Suppress all dupes in wordlist (and force preload) --incremental[=MODE] "Incremental" mode [using section MODE] --incremental-charcount=N Override CharCount for incremental mode --external=MODE External mode or word filter --mask[=MASK] Mask mode using MASK (or default from john.conf) --markov[=OPTIONS] "Markov" mode (see doc/MARKOV) --mkv-stats=FILE "Markov" stats file --prince[=FILE] PRINCE mode, read words from FILE --prince-loopback[=FILE] Fetch words from a .pot file --prince-elem-cnt-min=N Minimum number of elements per chain (1) --prince-elem-cnt-max=[-]N Maximum number of elements per chain (negative N is relative to word length) (8) --prince-skip=N Initial skip --prince-limit=N Limit number of candidates generated --prince-wl-dist-len Calculate length distribution from wordlist --prince-wl-max=N Load only N words from input wordlist --prince-case-permute Permute case of first letter --prince-mmap Memory-map infile (not available with case permute) --prince-keyspace Just show total keyspace that would be produced (disregarding skip and limit) --subsets[=CHARSET] "Subsets" mode (see doc/SUBSETS) --subsets-required=N The N first characters of "subsets" charset are the "required set" --subsets-min-diff=N Minimum unique characters in subset --subsets-max-diff=[-]N Maximum unique characters in subset (negative N is relative to word length) --subsets-prefer-short Prefer shorter candidates over smaller subsets --subsets-prefer-small Prefer smaller subsets over shorter candidates --make-charset=FILE Make a charset, FILE will be overwritten --stdout[=LENGTH] Just output candidate passwords [cut at LENGTH] --session=NAME Give a new session the NAME --status[=NAME] Print status of a session [called NAME] --restore[=NAME] Restore an interrupted session [called NAME] --[no-]crack-status Emit a status line whenever a password is cracked --progress-every=N Emit a status line every N seconds --show[=left] Show cracked passwords [if =left, then uncracked] --show=formats Show information about hashes in a file (JSON) --show=invalid Show lines that are not valid for selected format(s) --test[=TIME] Run tests and benchmarks for TIME seconds each (if TIME is explicitly 0, test w/o benchmark) --stress-test[=TIME] Loop self tests forever --test-full=LEVEL Run more thorough self-tests --no-mask Used with --test for alternate benchmark w/o mask --skip-self-tests Skip self tests --users=[-]LOGIN|UID[,..] [Do not] load this (these) user(s) only --groups=[-]GID[,..] Load users [not] of this (these) group(s) only --shells=[-]SHELL[,..] Load users with[out] this (these) shell(s) only --salts=[-]COUNT[:MAX] Load salts with[out] COUNT [to MAX] hashes, or --salts=#M[-N] Load M [to N] most populated salts --costs=[-]C[:M][,...] Load salts with[out] cost value Cn [to Mn]. For tunable cost parameters, see doc/OPTIONS --fork=N Fork N processes --node=MIN[-MAX]/TOTAL This node's number range out of TOTAL count --save-memory=LEVEL Enable memory saving, at LEVEL 1..3 --log-stderr Log to screen instead of file --verbosity=N Change verbosity (1-5 or 6 for debug, default 3) --no-log Disables creation and writing to john.log file --bare-always-valid=Y Treat bare hashes as valid (Y/N) --config=FILE Use FILE instead of john.conf or john.ini --encoding=NAME Input encoding (eg. UTF-8, ISO-8859-1). See also doc/ENCODINGS. --input-encoding=NAME Input encoding (alias for --encoding) --internal-codepage=NAME Codepage used in rules/masks (see doc/ENCODINGS) --target-encoding=NAME Output encoding (used by format) --force-tty Set up terminal for reading keystrokes even if we're not the foreground process --field-separator-char=C Use 'C' instead of the ':' in input and pot files --[no-]keep-guessing Try finding plaintext collisions --list=WHAT List capabilities, see --list=help or doc/OPTIONS --length=N Shortcut for --min-len=N --max-len=N --min-length=N Request a minimum candidate length in bytes --max-length=N Request a maximum candidate length in bytes --max-candidates=[-]N Gracefully exit after this many candidates tried. (if negative, reset count on each crack) --max-run-time=[-]N Gracefully exit after this many seconds (if negative, reset timer on each crack) --mkpc=N Request a lower max. keys per crypt --no-loader-dupecheck Disable the dupe checking when loading hashes --pot=NAME Pot file to use --regen-lost-salts=N Brute force unknown salts (see doc/OPTIONS) --reject-printable Reject printable binaries --tune=HOW Tuning options (auto/report/N) OpenCL options: --devices=N[,..] Set OpenCL device(s) (see --list=opencl-devices) --force-scalar Force scalar mode --force-vector-width=N Force vector width N --lws=N Force local worksize N --gws=N Force global worksize N --subformat=FORMAT Pick a benchmark format for --format=crypt --format=[NAME|CLASS][,..] Force hash of type NAME. The supported formats can be seen with --list=formats and --list=subformats. Valid classes: dynamic, cpu, opencl, ztex, mask, omp, all, enabled, disabled.
John the Ripper's command line syntax
When invoked with no command line arguments, "john" prints its usage summary.
The supported command line arguments are password file names and options. Many of the supported options accept additional arguments.
You can list any number of password files right on the command line of "john". You do not have to specify any options. If valid password files are specified but no options are given, John will go through the default selection of cracking modes with their default settings.
Options may be specified along with password files or on their own, although some require that password files be specified and some do not support operation on password files.
All options are case sensitive, can be abbreviated as long as the abbreviations are unambiguous, can be prefixed with two dashes (GNU-style) or with one dash, and can use "=" or ":" to indicate an argument (if supported for a given option).
The supported options are as follows, square brackets denote optional arguments:
"single crack" mode
Enables the "single crack" mode, using rules from the configuration file section [List.Rules:Single]. If --single=Single_2 then the rules from [List.Rules:Single_2] section would be used. A rule or set of rules (including with pre-processor) can also be provided directly on the command line. See --rules for more details.
Add static word(s) for all salts in single mode. Adding e.g. "Rockyou" will have the same effect as having that word in all gecos fields in the whole input file (except the latter would eat memory).
Same as --single-seed except words are read from a wordlist file.
Add static word(s) like above, but per username. FILE is a wordlist in user:password[s] format. A line of "root:geheim" in a file used with this option would have the same result as having that word in the gecos field of all users named "root" in the input file. If the wordlist is very large, sorting it will speed up loading.
Override config file setting for SingleRetestGuess. Setting this to false stops Single mode from re-testing guessed plaintexts with all other salts. This is normally only needed for attacking massive, salted, input files eg. where you intend to use the --loopback option later instead.
Disable the dupe checking when loading hashes. This can be used when loading massive input files that you know don't contain any dupes, for speedup.
wordlist mode, read words from FILE,
or from stdin
much like stdin, but supports rules
These are used to enable the wordlist mode. If FILE is not specified, the one defined in john.conf will be used.
Set the terminal up for reading status/quit keystrokes even if we're not the foreground process. The downside is we might get race conditions so you may end up with strange problems hard to reproduce.
suppress all duplicates from wordlist
Normally, consecutive duplicates are ignored when reading a wordlist file. This switch enables full dupe suppression, using some memory and a little extra start-up time. This option implies preload regardless of file size, see the --mem-file-size option.
use (a) pot file as a wordlist
This mode implies –dupe-suppression. This is a special variant of wordlist mode. Parse the file as a .pot file, so only the actual password part of each line will be used. If FILE is not specified, the active .pot file will be used. This is very effective for applying rules to further permute words that has been successful, or without rules after a run using --salts in case the cracks are successful on other salts than the ones that has already been attacked. Note that by default, some rules are applied too (see john.conf "LoopbackRules"). To disable that for a run, just use --rules=none.
Expect/use a character encoding other than the default. See doc/ENCODINGS.
Use --list=encodings for a list of supported encodings.
Enables word mangling rules that are read from the specified section, which defaults to [List.Rules:Wordlist] if not given.
A rule or set of rules (including with pre-processor) can also be provided directly on the command line. To do so, first letter following the = must be : then the rest of the command argument is interpreted as the literal data for the rule(s) itself. Multiple rules can be provided. Each rule should be separated with a semicolon (;) character. So --rules=:'$[a-z]$[0-9];u' will use the 2 rule lines: $[a-z]$[0-9] and u
When rules are entered on the command line, any time a semicolon is used IN a rule, then it must be preceded by a \ character, to escape it.
So --rules::'$\;$[0-9]' is just one rule, while –rules=:'$\;$[0-9];Az"tst"' is two rules, and --rules=:'$;$[0-9]' would 'try' to generate 2 rules, BUT the first will be invalid since it is just the $ character.
Stacked rules. Adds a second pass of rules, applied after normal processing.
Example: "--single --rules-stack=ShiftToggle" will run single mode's normal rules fully through the first (no-op) rule in the toggle ruleset. Only then will the latter set move on to its second rule, the main rules are rewinded, and so on. In other modes, eg. "--wordlist --rules –rules-stack=best64", the stacked rules (best64 in this case) will do a full pass before the base rule moves to its second rule. This option also works fine with ALL modes that normally don't support rules at all, eg. "--mask=password?d?d?d --rules-stack=KoreLogic" (although that will disable any GPU-side mask accleration). You can even use --wordlist --rules-stack=SomeRule without using any base rule. The difference is in how it iterates: Normal --rules will run all words through the first rule before moving the second rule, while --rules-stack will apply all rules to the first word before moving on to the second word from the list. Please note that when using (rule x rule) you very quickly end up with huge numbers of rules: Running the "all" ruleset twice as "--rules=all --rules-stack=all" will produce a whopping 53 trillion rules. This feature is best used with very carefully picked rulesets that are made to work together.
"incremental" mode [using section MODE]
Enables the "incremental" mode, using the specified configuration file definition (section [Incremental:MODE]). If MODE is omitted, the default is "ASCII" for most hash types and "LM_ASCII" for LM hashes.
external mode or word filter
Enables an external mode, using external functions defined in section [List.External:MODE].
just output candidate passwords
When used with a cracking mode, except for "single crack", makes John output the candidate passwords it generates to stdout instead of actually trying them against password hashes; no password files may be specified when this option is used. If a LENGTH is given, John assumes that to be the significant password length and truncates longer words (like a few formats, eg. DEScrypt, do). If you instead say --max-length=LENGTH, longer candidates will instead be rejected.
Please note that session save/resume is inherently unreliable when using --stdout piped to some external program: Buffering by OS and/or by the receiving program may cause a resume too far into the keyspace. It's supported, but only as a "best-effort" functionality.
restore an interrupted session
Continues an interrupted cracking session, reading state information from the specified session file or from $JOHN/john.rec by default.
give a new session the NAME
This option can only be used when starting a new cracking session and its purpose is to give the new session a name (to which John will append the ".rec" suffix to form the session file name). This is useful for running multiple instances of John in parallel or to be able to later recover a session other than the last one you interrupt.
john.log file will also be named NAME.log (whatever 'NAME' is), so that any logging of the session work will end up in this file.
print status of a session [called NAME]
Prints status of an interrupted or running session. Note that on a Unix-like system, you can get a detached running session to update its session file by sending a SIGHUP to the appropriate "john" process; then use this option to read in and display the status.
make a charset, overwriting FILE
Generates a charset file based on character frequencies from $JOHN/john.pot, for use with the "incremental" mode. The entire $JOHN/john.pot will be used for the charset generation by default. You may restrict the set of passwords used by specifying some password files (in which case only the cracked passwords that correspond to those password files will be used), "--format", or/and "--external" (with an external mode that defines a filter() function). Note that you can combine this with the --pot=FILE option.
show cracked passwords
Shows the cracked passwords for given password files (which you must specify). You can use this option while another instance of John is cracking to see what John did so far; to get the most up to date information, first send a SIGHUP to the appropriate "john" process.
If --show=left then all uncracked hashes are listed (in a John 'input' file format way). =left is just that literal string "=left". When using --show=left you normally need to supply the --format option too.
parse hashes and show meta-information in JSON
or in old custom format
Shows the formats/types of input hashes contained in the input file. See doc/SHOW_FORMATS.md
show lines in the input file that fail valid()
Shows the input hash lines which fail the valid() function (ie. these hashes have something wrong with them and would not be processed).
When using this mode, you will want to run against a solid file, that is made up of just one type hash. Also, the --format=xx flag is not required, but if not used, then the first valid line of the file will be used as the format type.
run tests and benchmarks for TIME seconds each
Tests all of the compiled in hashing algorithms for proper operation and benchmarks them. The "--format" option can be used to restrict this to a specific algorithm. Using --test=0 will do a very quick self-test but no benchmark.
Perform self-tests just like with --test except it loops until failure or until aborted by user. This is mostly for debugging.
benchmark using regular test vectors
This is used together with --test. By default the benchmark is made using mask mode, which with some OpenCL or ZTEX formats is accelerated fully or partially on device-side. Adding this option switches back to the legacy style benchmark, using test vectors.
skip self tests
Tells John to skip self tests. Basic integrity checks will be done but test vectors will not be verified. This option is useful to run many small attacks in a row against slow hashes. Usually it is not needed. It affects --test option: --skip-self-tests and --test together perform only benchmarks.
[do not] load this (these) user(s)
Allows you to select just a few accounts for cracking or for other operations. A dash before the list can be used to invert the check (that is, load information for all the accounts that are not listed).
load users [not] of this (these) group(s)
Tells John to load (or to not load) information for accounts in the specified group(s) only.
load users with[out] this (these) shell(s)
This option is useful to load accounts with a valid shell only or to not load accounts with a bad shell. You can omit the path before a shell name, so "--shells=csh" will match both "/bin/csh" and "/usr/bin/csh", while "--shells=/bin/csh" will only match "/bin/csh".
In Jumbo, the --users/groups/shells options above allow a single wildcard (eg. "admin*", "*root" or "admin*group") and when wildcard is used, the text matching also becomes case insensitive.
load salts with[out] at least N passwords
load M [to N] most populated salts
This feature aids in exploiting re-used salts. For example, you can attack all re-used salts using "--salts=2" faster and then crack the rest using "--salts=-2". Total cracking time will be about the same but you will likely get some passwords cracked earlier. If MAX is listed, then no salts having more than MAX hashes are loaded. This is so that if you have run --salts=25 you can later run --salts=10:24 for excluding the salts already attacked.
Alternative #M syntax: Instead of requiring a certain number of hashes per salt, we simply say "load the most re-used salt" or "load the M to N most re-used salts".
Regardless of syntax, the re-use counts are considered before sorting out already cracked hashes, so a resume or a later attack using same --salts option will pick the same set.
load salts with[out] cost value Cn [to Mn] for tunable cost parameters (comma separated values/ranges per param.)
The option --cost= can be used to crack only hashes with similar tunable costs, to avoid a slowdown caused by expensive cost parameter settings of some hashes if there are other hashes which are less expensive to compute.
This feature allows you to focus on salts with lower cost values first.
For formats with different tunable costs, you can specify a comma separated list of values/ranges.
--cost=-2 (cost of first cost parameter must be smaller than 2)
--cost=2,10:20 (cost of 1st parameter is >= 2, of 2nd between 10 and 20)
--cost=0,10:20 (first cost parameter ignored, 2nd between 10 and 20)
--cost=0,-3 (first cost parameter ignored, 2nd smaller than 3)
Few formats have more than one tunable cost parameter. Many saltless hashes and several salted hashes lack any tunable cost parameters. For these, a dummy cost of 1 is reported.
The --list=format-details and --list=format-all-details options will list the tunable cost parameters supported by a given format.
pot filename to use
By default, John will use john.pot. This override allows using a different john.pot-like file (to start from, and to store any found password into).
enable memory saving, at LEVEL 1..3
You might need this option if you don't have enough memory or don't want John to affect other processes too much or don't need it to load and print login names along with cracked passwords. Level 1 tells John not to waste memory on login names; it is only supported when a cracking mode other than "single crack" is explicitly requested. It has no negative performance impact - in fact, it sometimes speeds things up.
Please note that without the --save-memory=1 option (or higher), John will waste some memory on potential login names even if the password hash files don't happen to contain any login names. (The complete lack of login names isn't known to John when it starts parsing the files, so it has to record the fact that each individual entry doesn't have a login name unless you specify this option.) Levels 2 and 3 reduce use of performance optimizations involving large lookup tables, and thus have a negative performance impact. You should probably avoid using them unless John doesn't work or gets into swap otherwise.
this node's number range out of TOTAL count
This option is intended to allow for some trivial manually-configured parallel and distributed processing. For example, to split the workload across two nodes (which could be machines, CPU cores, etc.), you'd specify "--node=1/2" on one invocation of John and "--node=2/2" on the other. (If you do this on just one machine and with the same build of John, you will also need to specify different "--session" names for the two simultaneous invocations.) The nodes are assumed to be same speed (if this is not the case, one will get ahead of the other and is likely to be done sooner, unless you're using a cracking mode and settings such that the session is not expected to ever "complete" - which is fine.)
If your nodes are of very different speed, you may compensate for that by allocating ranges of node numbers to individual invocations. For example, if you use OpenMP-enabled builds of John on two machines, OpenMP is supported (with good scalability) for the hash type you're cracking, and one of the machines has twice more of similar speed CPU cores than the other, then you may use "--node=1-2/3" on the twice bigger machine (let it be nodes 1 and 2 out of 3 nodes total) and "--node=3/3" on the smaller one.
Efficiency of this approach to parallel processing, as currently implemented, varies by cracking mode and its settings (efficiency is higher for incremental mode and for wordlist mode with many rules, and lower for other cracking modes and for wordlist mode without rules or with few rules), hash type (efficiency is higher for slower to compute hashes), salt count (efficiency is higher for higher salt counts), and node count (efficiency is higher for lower node counts). Scalability may be limited. The highest node count you can reasonably use varies by cracking mode, its settings, hash type, and salt count. With incremental mode, efficiency in terms of c/s rate is nearly perfect (there's essentially no overhead), but some nodes may currently receive too little work - and this problem is exacerbated by high node counts (such as 100 or more) and/or restrictive settings (such as MinLen and MaxLen set to the same value or to a narrow range, and/or a charset file with few characters being used). With wordlist mode, for high efficiency the rule count (after preprocessor expansion) needs to be many times higher than node count, unless the p/s rate is low anyway (due to slow hash type and/or high salt count).
Since there's no communication between the nodes, hashes successfully cracked by one node continue being cracked by other nodes. This is mostly OK for saltless hash types or when there's just one salt (since the same number of hash computations is to be made anyway - namely, only one per candidate password tested), but it is a serious drawback when many different salts are present and their number could potentially be decreasing as some hashes get cracked.
fork N processes
This option is only available on Unix-like systems. It is an easy way to make use of multiple CPUs or CPU cores - you simply specify the number of John processes that you'd like to run. You may use "--fork" as an alternative to OpenMP, for formats currently lacking OpenMP support, or/and along with OpenMP (e.g., on a machine with 64 logical CPUs you might choose to run with "--fork=8" for 8 processes and use OpenMP to run 8 threads per process).
You may use "--fork" along with "--node" to use multiple machines while also running multiple John processes per machine. For example, to use two similar 8-core machines you may run "--fork=8 --node=1-8/16" on one of the machines and "--fork=8 --node=9-16/16" on the other. For a more complicated example, if you have an 8-core machine and a 64-core machine with similar per-core performance, you could run an OpenMP-enabled build on both of them and use "--node=1/9" (without "--fork") on the first machine (8 threads in 1 process) and "--fork=8 --node=2-9/9" on the 64-core machine (8 threads in 8 processes, for 64 threads total on this machine). The node numbers range assigned to each John invocation must be a multiple of the "--fork" process count. You'd usually have the number of nodes in the range exactly match the "--fork" process count, but you can use other multiples to compensate for major differences in per-process performance between different machines. For example, on a machine where each process is twice faster than on another, you'd reasonably allocate two virtual node numbers per each "--fork" process, e.g. with "--fork=8 --node=9-24/24".
When running with "--fork", multiple ".rec" files are created, which are then read back by "--status" and "--restore" if you use those options.
Just like with other options, you must not specify "--fork" along with "--status" or "--restore", because these read the main (unnumbered) ".rec" file first, which contains the right "--fork" option in it, resulting in further (numbered) ".rec" files being read as appropriate.
Under the hood, "--fork" makes use of the same functionality that "--node" does, so the same efficiency and scalability limitations apply.
Despite of those, "--fork" is often much more efficient than OpenMP - especially for fast to compute hash types (such as LM hashes), where OpenMP overhead is often unacceptable.
Similarly to "--node", there's almost no communication between the processes with "--fork". Hashes successfully cracked by one process continue being cracked by other processes. Just like with "--node", this is mostly OK for saltless hash types or when there's just one salt, but it is a serious drawback when many different salts are present and their number could potentially be decreasing as some hashes get cracked.
To have the cracked hashes (and possibly salts) removed from all processes, you may interrupt and restore the session once in a while.
force hash type NAME
Override the hash type auto-detection. You can use this option when you're starting a cracking session or along with things like: "--test", "--show", "-list" or "--make-charset". Note that John can't crack hashes of different types at the same time. If you happen to get a password file that has more than one hash type, you have to invoke John once for each hash type and you need to use this option to make John crack hashes of types other than the one it would autodetect by default. For normal use, you'd use a full exact format label such as "--format=crypt-md5".
Mainly for test and list purposes (see --list=WHAT), you can use a single wildcard, as in "--format=mysql-*", "--format=raw*ng" or "--format=*office", or group aliases such as "dynamic", "cpu", "omp", "opencl", "ztex" as a well as the special "all" that will include even formats listed as disabled in john.conf (so "./john -test=0 -format=all" will ensure you actually test all formats regardless of config). While on the subject of disabled formats, aliases "enabled" or "disabled" can also be used, eg. for listing which of them are.
There's also a special way to match any substring within the "algorithm name" (the string shown within brackets, e.g. "[DES 128/128 AVX-16]") using @tag syntax as in e.g. "--format=@DES" or "--format=@AVX".
Similarly you can match a substring in the "format name" (the longer name, not the label) using #tag format. For example, if you forgot which format handles the IPMI hashes, you can say --format=#ipmi and the correct formats (in this case RAKP and perhaps RAKP-opencl) will be used. Regardless of method, the matching ignores case.
Several formats can be specified at once separated by commas, and prepending a format, wildcard or class with a "-" will exclude instead of include (eg. "--format=#ipmi,-cpu" for again finding the RAKP format but this time rejecting the CPU version so will end up finding "RAKP-OpenCL" as long as your build supports OpenCL. Prepending a format, wildcard or class with a "+" will instead promote it to a "requirement": "--format=#ipmi,+opencl" will also find RAKP-opencl (there would be a slight difference in case eg. a ZTEX version were also available).
The order given of any "include" parts of a format list will be honored and this can be used for merely changing format precedence while otherwise keeping auto-detection. This means eg. "--format=ztex,opencl,cpu" for a crack session will end up in auto-detection among all formats, just like no format option was used, except it will prefer ztex over opencl and only use a CPU format unless a ZTEX or OpenCL format was available.
The ad-hoc dynamic, or "dynamic compiler" format can not be used in a format list or with wildcards, only on it's own. This is because the expression may need to include commas, wildcard etc.
"--format=crypt" may or may not be supported in a given build of John. In default builds of John, this support is currently only included on Linux and Solaris. When specified (and supported), this option makes John use the system's crypt(3) or crypt_r(3) function. This may be needed to audit password hashes supported by the system, but not yet supported by John's own optimized cryptographic routines. Currently, this is the case for glibc 2.7+ SHA-crypt hashes as used by recent versions of Fedora and Ubuntu, and for SunMD5 hashes supported (but not used by default) on recent versions of Solaris. In fact, you do not have to explicitly specify "--format=crypt" for hashes of these specific types unless you have other hash types (those supported by John natively) in the password file(s) as well (in which case another hash type may get detected unless you specify this option).
When benchmarking "--format=crypt", it will default to benchmark DES. The "--subformat=TYPE" can be added for benchmarking other types, given they are supported by the system. Currently supported TYPEs are md5crypt, bcrypt, sha256crypt and sha512crypt.
Incidentally "--format=crypt" is also a way to make John crack crypt(3) hashes of different types at the same time, but doing so results in poor performance and in unnecessarily poor results (in terms of passwords cracked) for hashes of the "faster" types (as compared to the "slower" ones loaded for cracking at the same time). So you are advised to use separate invocations of John, one per hash type.
max. size of wordlist to preload into memory
For performance reasons, Jumbo preloads the wordlist file into memory instead of reading line by line, when rules are in use. The default max. size file for this to happen is shown among the --help options. A special value is --mem-file-size=0. This will force loading to memory regardless of file size (take care not to exceed your physical memory limits, or things will just run much slower). NOTE if --save-memory > 2, default preload will be disabled.
Use 'c' instead of ':' as field separator
This option allows for using an arbitrary character that doesn't interfere with field contents. A popular alternative is using the TAB character and this has special parsing (write it, literally, as --field-separator-char=tab).
Other non-printable characters can be written in hex \xHH notation (the TAB character can also be specified with --field-separator-char=\x09). Note that a side effect is that the pot file will get this field separator too.
disable log file
This will turn off logging to file (default john.log) in case you are sure you wont need it. The log can sometimes become huge (such as when working with many 'fast' rules on a fast format).
Log to screen (stderr) as well as (unless you also use --no-log) to file.
Normally, dynamic mode will only load hashes with tags in the input file (for example, $dynamic_0$368dc60082c8b47e697826b282b94e3d) or when a specific format is requested (eg. --format=dynamic_0). If C is 'Y' or 'y', then the dynamic format will always treat bare hashes as valid. You can permanently enable this option by editing john.conf and setting "DynamicAlwaysUseBareHashes".
show status line on every crack
This will automagically emit a status line at every cracked password. This is mostly for testing.
emit a status line every N seconds
This will automagically emit a status line every N seconds. This is mostly for testing.
force min/max keys per crypt to N
This option is for certain kinds of testing. There is a performance impact. Many formats perform the crypts in batches of several (sometimes thousands or even tens of thousands) candidates. This option forces it down from the format's default. For most purposes, you would use 1. One good example is for studying which rules give most "hits": Without this options, you can't know for sure which rule produced a successful guess when analyzing the log file.
request a minimum candidate length in bytes
request a maximum candidate length in bytes
shortcut for setting both to N
These options limit the length of candidates that will be tried. In wordlist mode (after applying rules, if any), a word that is not within the requested limits will be rejected (as opposed to truncated). Most other modes also honour these settings. For example, you can fully exhaust a short keyspace with incremental mode with e.g. --max-len=4 and then start a longer session for the rest with --min-length=5, or use one core for lengths up to 8 and other cores for exact lengths of 9, 10 and so on.
Note: With UTF-8 encoding and no internal codepage, non-ASCII characters will use more than one byte.
Gracefully exit after N seconds. If you resume it, it will run for another N seconds and exit again.
If a negative value is specified, John will run for N seconds after the last crack, ie. each cracked password will reset the timer.
Gracefully exit after N candidates were tried. If you resume it, it will run for another set of N candidates and exit again. Note that some formats will process candidates in "batches" of a few, or many, candidates so the number may well be overshot by some amount.
If a negative value is specified, John will process N candidates after the last crack, ie. each cracked password will reset the counter.
search for alternative plaintexts
Some formats has plaintext collisions. That means some (or many) different plaintexts will result in the same hash, so are equally valid. It may be due to a design flaw as in BFEgg, or due to limited hash size as in CRC-32 – or artificially limited keyspace as in Office formats before 2007 (a good sized key is truncated to 40-bit on purpose - thank you Microsoft). When this option is used a successful crack will not result in that hash being removed from further cracking, so you can use it to find alternative plaintexts.
reject printable binaries
This esoteric option can be used to filter out many bogus hashes. It only works well with not too small binary sizes. Rejected hashes are printed (as text) to stderr. It may fail to work with some formats that e.g. reverse steps. A good example of that is it does not work with raw-md5 format, but works fine with dynamic_0 (which is also raw MD5 but less optimized). An example of hash that would be rejected is 6d61676e756d474747476d61676e756d which is hex of the ASCII string "magnumGGGGmagnum" and not very likely a real hash. You'd be surprised what you can find in some dumps.
Make John more verbose, or less verbose. Default level is 3. For example, level 2 will mute the extra messages (device, work sizes etc) printed by OpenCL formats and level 1 will mute printing of cracked passwords to screen.
This option can be used to gain information about what rules, modes etc are available. Use --list=help for a list of valid arguments.
If information about formats is requested, a --format=[NAME|CLASS] option can be used in addition to --list=WHAT.
If an additional option --config=FILE
List all external modes/filters
List external modes [has a generate()]
List external filters, including modes with a filter
List external filters [lacks a generate()]
List external hybrid modes [has a new()]
List all the supported formats in the sequence they are registered (this is also the sequence that will be used to identify the first format which detects a valid ciphertext (password hash) in the input file if John is started without the --format=NAME option)
List all the supported formats in the same sequence as with --list=formats, but with additional details (which might be more interesting for developers than for regular users), machine-parsable. Fields:
This is to be used as NAME in --format=NAME -maximum supported password length in bytes
For performance reasons, the maximum length supported by John the Ripper can be shorter than the maximum length supported by the application which uses this format
-minimum keys per crypt
-maximum keys per crypt
-number of hard coded test cases for --test
(the individual columns are separated by [tab])
List all the supported formats and their attributes in the same sequence as with --list=format-details, but in a more descriptive form readable by humans
List all methods which are NOT default for each format. If 'WHICH' is set, then this listing will ONLY be formats which have the 'WHICH' format overridden.
List all format specific tests (format name, number, hash, password)
If a format uses encoding specific tests, you can use --encoding=NAME as an additional option to see these encoding specific tests.
If a ciphertext contains line feeds or the separator character (horizontal tab), just the format name and the test number are written. If the password has
line feeds, it will not be written.
(A warning message is written to stderr in this case)
List all the built-in dynamic formats
Finds passwords AND salts in a set of raw hashes.
This function has been changed, and now is 'generic'.
See the file Regen-Lost-Salts.txt for information.
John the Ripper Usage Example
How to crack ZIP archive password
To extract the hash, run a command like this:
zip2john FILE > zip.hash
For example, the path to the file /mnt/disk_d/Share/test/file.zip, then the command is as follows:
zip2john /mnt/disk_d/Share/test/file.zip > zip.hash
Brute force on a central processor
Now, to launch a dictionary attack using the CPU, run a command like this:
john --wordlist=/PATH/TO/DICTIONARY --fork=CORES /PATH/TO/zip.hash
For example, my dictionary is located in the same folder as the executable file john and has the name rockyou.txt, and on my computer there are 12 cores, and zip.hash is in the user's home folder, then the command is as follows:
./john --wordlist=rockyou.txt --fork=12 ~/zip.hash
To iterate over all passwords consisting only of numbers and length from 1 to 10 characters and perform calculations on the CPU, run a command like this:
john --fork=CORES --mask='?d' --min-length=1 --max-length=10 /PATH/TO/zip.hash
To iterate over all passwords consisting of numbers, as well as uppercase and lowercase letters, from 1 to 8 characters long and perform calculations on the CPU, run a command like this:
john --fork=CORES -1=?l?u?d --mask='?1' --min-length=1 --max-length=8 /PATH/TO/zip.hash
How to crack passwords of ZIP archives on a video card
John the Ripper supports two algorithms for cracking ZIP archives on the CPU:
And only one archive for cracking on video cards:
In the previous commands, we did not specify the hash type, since it is uniquely indicated in the hash itself. To use a video card, you must use the --format=HASH option. But it will only work for ZIP format. Therefore, you need to open the file where the hash is saved and look at the beginning of the hash.
If you see something like this there:
This means that this hash can be cracked with commands like:
john --format=ZIP-opencl --wordlist=/PATH/TO/DICTIONARY /PATH/TO/zip.hash john --format=ZIP-opencl -mask='?d' --min-length=1 --max-length=10 /PATH/TO/zip.hash john --format=ZIP-opencl -1=?l?u?d --mask='?1' --min-length=1 --max-length=8 /PATH/TO/zip.hash
If there is a hash with the “pkzip” string:
This means that cracking of this format on the video card is currently not supported.
How to install John the Ripper
Drivers to support OpenCL
On any operating system, start by Installing Graphics Card Drivers for John the Ripper.
Installation on Kali Linux
The program is pre-installed on Kali Linux.
sudo apt install john
Installing John the Ripper on Kali Linux from source
sudo apt install build-essential libssl-dev yasm libgmp-dev libpcap-dev libnss3-dev libkrb5-dev pkg-config wget https://github.com/openwall/john/archive/bleeding-jumbo.zip unzip bleeding-jumbo.zip rm bleeding-jumbo.zip cd john-bleeding-jumbo/src/ ./configure && make
Please note that in the last command you can use the -j option after which specify the number of (logical) cores of your processor, for example, I have 12 logical cores, then I use:
./configure && make -j12
Now go to the run folder:
And run the test:
You don't need to install John the Ripper at the system level - move the run folder to a location convenient to you and run John from there.
Remember that if you type in the terminal
then the version preinstalled on the system will run, not the one you compiled.
Installation on Debian, Linux Mint, Ubuntu
The installation should be done exactly the same as in Kali Linux. Therefore, refer to Installing John the Ripper on Kali Linux from source.
Installation on BlackArch
The program is pre-installed on BlackArch.
sudo pacman -S john
Installing John the Ripper on BlackArch, Arch Linux from source
sudo pacman -S openssl yasm gmp libpcap nss krb5 pkg-config wget https://github.com/openwall/john/archive/bleeding-jumbo.zip unzip bleeding-jumbo.zip rm bleeding-jumbo.zip cd john-bleeding-jumbo/src/ ./configure && make
Please note that in the last command you can use the -j option after which specify the number of (logical) cores of your processor, for example, I have 12 logical cores, then I use:
./configure && make -j12
Now go to the run folder:
And run the test:
Installing John the Ripper on Windows
We'll look at compiling John the Ripper from source on Windows sometime later. Let's use the official binary file.
Install Cygwin first – just go to the official website https://www.cygwin.com/, download the setup-x86_64.exe file and install.
Download the winX64_1_JtR.7z file from https://github.com/openwall/john-packages/releases/tag/jumbo-dev.
Unzip the contents of this archive into the C:\cygwin64\home\<USERNAME> folder, for example, my username is MiAl, so I unpack it to C:\cygwin64\home\MiAl\. Please note that you need to create a folder and copy files into it on behalf of a regular user, because during its work John the Ripper will try to write data to a .pot file in the same folder where the program is running. If you copied the JtR folder in the file manager with elevated rights, then this folder will belong to the Administrator and it is impossible to write anything into it or change the rights to it.
It is actually possible to run John the Ripper on Windows even without Cygwin, but in this case it will not be able to use OpenCL (video cores) for brute-force.
Now in the folder C:\cygwin64\home\<USERNAME>\JtR\run\ find cygOpenCL-1.dll file and rename it to cygOpenCL-1.dll.bac.
Then in the c:\Windows\System32 folder find the OpenCL.dll file and copy it to the C:\cygwin64\home\<USERNAME>\JtR\run\ folder.
Then, in the C:\cygwin64\home\<USERNAME>\JtR\run\ folder, rename the OpenCL.dll file to cygOpenCL-1.dll.
Then the same procedure must be repeated for the file in the C:\cygwin64\bin\ folder. That is, in the C:\cygwin64\bin\ folder, find cygOpenCL-1.dll and rename it to cygOpenCL-1.dll.bac. Then find the OpenCL.dll file in the c:\Windows\System32 folder and copy it to the C:\cygwin64\bin\ folder. Finally, in the C:\cygwin64\bin\ folder, rename the OpenCL.dll file to cygOpenCL-1.dll.
The file swap trick may not work for all systems – but either way, you can use the CPU or integrated graphics to hack.
Open Cygwin console to execute commands.
Run your system benchmark:
Still, JtR is one of those programs that primarily targets Linux. Further you will see that we will run scripts to generate (extract) hashes from files and, for example, some of the auxiliary programs/scripts need, for example, an installed Python environment, which is present in Linux by default.
John the Ripper Screenshots
John the Ripper Tutorials
- Comprehensive Guide to John the Ripper. Part 1: Introducing and Installing John the Ripper
- Comprehensive Guide to John the Ripper. Part 2: Utilities for extracting hashes
- Comprehensive Guide to John the Ripper. Part 3: How to start cracking passwords in John the Ripper (how to specify masks, dictionaries, hashes, formats, modes)
- Comprehensive Guide to John the Ripper. Part 4: Practical examples of John the Ripper usage
- Comprehensive Guide to John the Ripper. Part 5: Rule-based attack
- Comprehensive Guide to John the Ripper. Part 6: How to brute force non-standard hashes
- Comprehensive Guide to John the Ripper. Part 7: Johnny – GUI for John the Ripper
- Programs for generating wordlists
- Hacking WPA/WPA2 passwords with Aircrack-ng: dictionary attack, cooperation with Hashcat, maskprocessor, statsprocessor, John the Ripper, Crunch, hacking in Windows
- How to use rainbow tables to crack Wi-Fi passwords in Hashcat and John the Ripper
- How to identify hash types
- How to create dictionaries that comply with specific password strength policies (using Rule-based attack)
- Advanced wordlist generating techniques