OPTIONS

	John the Ripper's command line syntax.
	(Updated in/for the Jumbo patch by JimF and magnum)

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[=(SECTION[,SECTION2,....,SECTIONn]|:rule)] "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.

--single-seed=WORD[,WORD][,...]

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).

--single-wordlist=FILE

Same as --single-seed except words are read from a wordlist file.

--single-user-seed=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.

--[no-]single-retest-guess

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.

--no-loader-dupe-check

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[=FILE]		wordlist mode, read words from FILE,
--stdin				or from stdin
--pipe				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.

--force-tty

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.

--dupe-suppression[=SIZE]	suppress some duplicates from wordlist+rules

Opportunistic duplicate candidate password suppression for wordlist+rules.
This creates a buffer in memory, which is then used to detect and suppress
some (hopefully, most) duplicates resulting from application of wordlist
rules (or otherwise, but rules are the most common source of duplicates).

When you use wordlist rules (explicitly or as part of batch mode), this is
enabled by default, but it also gets automatically disabled if efficiency
isn't high enough (ratio of candidate passwords suppressed does not look
high enough to justify the overhead given the current attack's p/s rate).

When in batch mode, the suppression can continue into its incremental mode
pass - to suppress incremental mode's passwords that happen to match those
previously generated in wordlist mode.

When enabled along with --rules-stack, the suppression is applied before the
stacked rules (but after the main --rules, which would be the reason to have
it enabled).

You can use this option to override the default behavior, such as to enable
suppression for a wordlist without rules, keep it enabled regardless of
current efficiency (e.g., in case you expect more duplicates later in the
run), disable suppression despite of use of rules (--dupe-suppression=0
does that), or request a specific allocation size (in MiB).  See also
[Options:Suppressor] in john.conf.

--loopback[=FILE]		use (a) pot file as a wordlist

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, and duplicate
passwords suppressed.  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.

--encoding=NAME
--input-encoding=NAME
--target-encoding=NAME
--internal-codepage=NAME

Expect/use a character encoding other than the default.  See doc/ENCODINGS.
Use --list=encodings for a list of supported encodings.

--rules[=(SECTION[,..]|:rule[;..])]

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.

--rules-skip-nop

Option for --rules that makes it skip any no-op rules.  This is intended for
when you already ran some attack on some slow format without rules and now
want to run it with rules.

--rules-stack=(SECTION[,..]|:rule[;..])

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]		"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.
If no definition is found for MODE but it ends with ".chr", it will be
taken as a charset file name, eg. for temporary use.


--external=MODE			external mode or word filter

Enables an external mode, using external functions defined in section
[List.External:MODE].

--stdout[=LENGTH]		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[=NAME]		restore an interrupted session

Continues an interrupted cracking session, reading state information
from the specified session file or from $JOHN/john.rec by default.

--session=NAME			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.

--status[=NAME]			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.

--catch-up=NAME			catch up with paused session

Limit the session to running only until it reaches the candidates tried
count of a different, existing and paused session NAME.  This can be
used for adding more hashes to an existing job:  After the new session
finishes, just concatenate the new hashes to the older session's hash
file and resume the old session.  This will end up more or less as if
both sets of hashes were in the original session to start with.

--make-charset=FILE		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[=left]			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.

--show=formats			parse hashes and show meta-information in JSON
--show=types				or in old custom format

Shows the formats/types of input hashes contained in the input file.
See doc/SHOW_FORMATS.md

--show=invalid			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.

--test[=TIME]			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.

--stress-test[=TIME]		continuous self-test

Perform self-tests just like with --test except it loops until failure or
until aborted by user.  This is mostly for debugging.

--no-mask			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		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.

--users=[-]LOGIN|UID[,..]	[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).

--groups=[-]GID[,..]		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.

--shells=[-]SHELL[,..]		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.

--salts=[-]N[:MAX]		load salts with[out] at least N passwords
--salts=#M[-N]			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.

--costs=[-]Cn[:Mn][,...]	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=NAME			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).

--save-memory=LEVEL		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.

--node=MIN[-MAX]/TOTAL		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.  In case you actually share the
pot file (such as when different sessions run on one same physical
machine, or when the working directory is on NFS), a feature called
"pot sync" will mitigate this: Each process will detect when some other
process wrote to the pot file, and read/process that data.  This syncing
is delayed by buffering but mitigates any need for interrupting/
restoring.  The feature is always active as long as you run with the
same pot file: Sessions using neither node nor fork but working with the
same set of hashes will still benefit from it.

--fork=N			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", but the "pot sync" feature (described under that
option) will promptly exclude hashes cracked by other processes.

--format=NAME[,NAME...]		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 format classes 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,
classes "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 if neither 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.


--mem-file-size=SIZE		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.

--field-separator-char=c	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.

--no-log			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-stderr

Log to screen (stderr) as well as (unless you also use --no-log) to file.

--bare-always-valid=C

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".

--crack-status			show status line on every crack

This will automagically emit a status line at every cracked password.  This is
mostly for testing.

--progress-every=N		emit a status line every N seconds

This will automagically emit a status line every N seconds.  This is mostly
for testing.

--mkpc=N			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.

--min-length=N			request a minimum candidate length in bytes
--max-length=N			request a maximum candidate length in bytes
   or
--length=N			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.

--max-run-time=[-]N

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.

--max-candidates=[-]N

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.

--keep-guessing			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		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.

--verbosity=N			change verbosity

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.

--list=WHAT			list capabilities

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=externals          List all external modes/filters
--list=ext-modes          List external modes [has a generate()]
--list=ext-filters        List external filters, including modes with a filter
--list=ext-filters-only   List external filters [lacks a generate()]
--list=ext-hybrids        List external hybrid modes [has a new()]
--list=formats            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=format-details     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:
                          -format label
                           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
                          -format flags
                          -number of hard coded test cases for --test
                          -algorithm name
                          -format name
                          -benchmark comment
                          -benchmark length
                          -binary size
                          -salt size
                          -example ciphertext
                          (the individual columns are separated by [tab])
--list=format-all-details 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=format-methods[:WHICH]
                          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=format-tests       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=subformats	  List all the built-in dynamic formats

--regen-lost-salts=type:hash_sz:mask
                          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.


	Additional utilities (compiled/installed along with John).

There are some related utilities in John's run directory.  (Depending on
platform, these may be symlinks to the main John program binary.)

	unshadow PASSWORD-FILE SHADOW-FILE

Combines the "passwd" and "shadow" files (when you already have access
to both) for use with John.  You might need this since if you only
used your shadow file, the "Full Name" or "GECOS" information wouldn't
be used by the "single crack" mode (thus reducing its efficiency) and
you wouldn't be able to use the "--groups" and "--shells" options and
to select by UID with "--users".  You probably also want to see all of
the passwd file fields with "--show".

You'll usually want to redirect the output of "unshadow" to a file
which you then pass to John.

	unafs DATABASE-FILE CELL-NAME

Gets password hashes out of the binary AFS database and produces
output usable by John (you should redirect the output to a file).

	unique OUTPUT-FILE

Removes duplicates from a wordlist (read from stdin) without changing
the order of entries.  You might want to use this with John's
"--stdout" option if you've got a lot of disk space to trade for the
reduced cracking time (on possibly trying some duplicates as they
might be produced with word mangling rules).  Note that this program
will silently truncate any lines longer than 1023 bytes.


	Scripts.

There are also some related scripts supplied in John's run directory.
(Binary packages of John may choose to install these along with the
documentation instead.)

	relbench BENCHMARK-FILE-1 BENCHMARK-FILE-2

relbench is a Perl script to compare two "john --test" benchmark runs,
such as for different machines, "make" targets, C compilers,
optimization options, or/and versions of John the Ripper.  To use it,
redirect the output of each "john --test" run to a file, then run the
script on the two files.  Most values output by the script indicate
relative performance seen on the second benchmark run as compared to the
first one, with the value of 1.0 indicating no change, values higher
than 1.0 indicating speedup, and values lower than 1.0 indicating
slowdown.  Specifically, the script outputs the minimum, maximum,
median, and geometric mean for the speedup (or slowdown) seen across the
many individual benchmarks that "john --test" performs.  It also outputs
the median absolute deviation (relative to the median) and geometric
standard deviation (relative to the geometric mean).  Of these two, a
median absolute deviation of 0.0 would indicate that no deviation from
the median is prevalent, whereas a geometric standard deviation of 1.0
would indicate that all benchmarks were sped up or slowed down by the
exact same ratio or their speed remained unchanged.  In practice, these
values will tend to deviate from 0.0 and 1.0, respectively.

	mailer PASSWORD-FILE

A shell script to send mail to all users whose passwords got cracked.
This is not always a good idea, though, since lots of people do not
check their e-mail or ignore such messages, and the messages can be a
hint for crackers.

You should probably deploy proactive password strength checking, such as
with passwdqc, before you ask users to change their passwords - whether
using this script or otherwise.  And you should edit the message inside
the script before possibly using it.

	makechr

This is a script to (re-)generate the .chr files using passwords in
john.pot and applying all of the defined external mode filters.  To
speed it up on a sufficiently large computer (RAM and CPUs), "&" may be
added after the John invocation inside the script (to run all of them in
parallel).