John the Ripper Password Cracker

John the Ripper – Cracking Passwords

Table of contents about Jhon the Ripper


Cracking Passwords

Incremental Mode Cracking

Markov Mode Cracking

Using Feedback for Efficient Cracking

Managing Multiple Cracking Sessions


Cracking Passwords

John is compiled and awaits our command. Let’s crack a password. John automatically recognizes common password formats extracted from operating system files like /etc/ shadow or dumped by tools like pwdump (we’ll get to that tool in a moment). In practice, John supports close to 150 different hashing algorithms; you’ll find them listed by running the benchmark with the -test option.

John the Ripper - Cracking Passwords
John the Ripper – Cracking Passwords

The following example shows John’s ability to guess the correct format for password entries. First, create a text file named windows.txt with the following two lines containing an entry for “Ged” and “Arha.” They represent passwords taken from a Windows system.

Ged:1006:NO PASSWORD*********************:FB9C381BD729E7A93C14EBAFBA9B78DE::: Arha:1007:NO PASSWORD*********************:2C5F5597333BD214B5BEA2C01C591BC9:::

Next, run John against the windows.txt file:

$ ./john windows.txt

Warning: detected hash type “nt”, but the string is also recognized as “nt2”

Use the “–format=nt2” option to force loading these as that type inste

Loaded 2 password hashes with no different salts (NT MD4 [128/128 X2 SSE2-
16]) Tenar            (Arha)

The brute-force attack should very quickly discover that “Tenar” is the password for the Arha account. It will take much longer to guess the Ged account’s password unless we try some refinements to the brute-force approach. (Or, if you’ve been a patient enough reader to slog through this book chapter by chapter, you might remember a hint for this account from Chapter 13.) In the previous example, John recommended that we use the –format=nt2 option to explicitly define which hash algorithm to target with the cracker. If the format isn’t evident, or John misinterprets the format of the target file, use that option to correct it. You can obtain all formats supported by John with the –list option, as follows:

$ ./john –list=formats

$ ./john –list=format-all-details

Let’s take a look at a Unix-based format before we continue on to other options. Create a unix.txt file with the following two lines (which start with “ged” and “arha”; they wrap here due to the page-width constraints):

ged:$6$c9XZawuR$SDS4m/akj1MRJoSv.RFIul.6CIxwL5EuppP3gVYZjsl02obQvf2NolH64TEjHd/O.0P 4rUN7ffH1XWgMPQhA8/:15833:0:99999:7::: arha:$6$8Q42v47a$TAcEW1FGm5qCU3tdJX0FMZMRGvEBpEM99hSAc65b0a6rX1JmY3ovFFGi0tLhvKQlB4 95f3Ps68lile4CuLG/A1:15834:0:99999:7:::

Next, unleash John against the hashes. We’ll cross our fingers that John divines the correct format:

$ ./john unix.txt

Loaded 2 password hashes with 2 different salts (sha512crypt [64/64])

Don’t be upset if John doesn’t immediately spit out matches for the two hashes. This particular format takes a few orders of magnitude longer to crack than the previous Windows example. In other words, our work factor has seriously increased. As a consequence, we’ll have to try to be smarter in our approach to password cracking.

To be smarter requires deciding how to expend our resources. We can try to improve the power of the brute-force attack (by optimizing the implementation of algorithms, using faster CPUs, using customized processors, distributing the work, etc.) to attain higher cracks per second, or we can try to improve the efficiency of the attack by guiding the sequence of guesses or choosing dictionaries that are statistically more likely to match the kinds of passwords humans create. A security researcher (and PhD) with the University of Cambridge, Joseph Bonneau, has written extensively about methods to protect and defeat passwords. You’ll find a particularly illuminating two-part “Password Cracking” article at password-cracking-part-i-how-much-has-cracking-improved/. (Sorry for the long URL!) I recommend adding the Light Blue Touchpaper blog to your regular reading list.

So, you’ve toiled through these paragraphs and visited the aforementioned blog. But John has yet to finish cracking all the passwords you’ve given it. Keep the concepts of power and efficiency in mind as we continue through this section. I’ll show you how to tweak John so that it performs with more bias toward one approach or the other. And eventually we’ll get those passwords cracked.

One password should have been cracked so far. We use the –show option to list it:

$ ./john –show windows.txt

Arha:Tenar:NO PASSWORD*********************:2C5F5597333BD214B5BEA2C01C591BC9:::

1 password hash cracked, 1 left

John keeps track of all passwords it has ever cracked in a john.pot file by default. For example, here’s what ours currently looks like:

$ cat john.pot


Make sure not to lose this file, because otherwise you’ll have to rerun all your brute-force tests from the beginning. Use the –pot option to specify alternate files to store (or read) cracked passwords from.

From an efficiency perspective, we can try different wordlists (aka dictionaries) of common passwords against our unknown hashes. The measure of “common” may be based on past successful cracks, actual dictionaries, or popular terms from media. Use the –wordlist option to try a (relatively) quick pass against the hashes. John provides a single dictionary, password.lst, with its distribution. You can find more, larger dictionaries on the John the Ripper web site.

$ ./john –format=nt2 –wordlist=password.lst windows.txt

Loaded 2 password hashes with no different salts (NT MD4 [128/128 X2 SSE2-16])

Remaining 1 password hash

guesses: 0  time: 0:00:00:00 DONE (Tue May  7 21:44:00 2013)  c/s: 354600  trying: paagal – sss

$ ./john –wordlist=password.lst unix.txt

Loaded 2 password hashes with 2 different salts (sha512crypt [64/64]) guesses: 0  time: 0:00:00:30 DONE

(Tue May  7 21:44:36 2013)  c/s: 236  trying: sss

Still no luck, but we’ve tried an efficient attack. Next, we’ll try some permutations on each of the dictionary entries. We do this with the –rules option. John’s rulesbased cracking is its most powerful feature. The following example show it applied against the wordlist (i.e., dictionary). Expect this to take longer than the previous run through the same wordlist; after all, it’s generating far more guesses due to permutation rules.

$ ./john –format=nt2 –wordlist=password.lst –rules windows.txt

Loaded 2 password hashes with no different salts (NT MD4 [128/128 X2 SSE2-16])

Remaining 1 password hash

guesses: 0  time: 0:00:00:00 DONE (Tue May  7 21:52:46 2013)  c/s: 7842K  trying: Slipping – Sssing

$ ./john –wordlist=password.lst –rules unix.txt

Loaded 2 password hashes with 2 different salts (sha512crypt [64/64])

To understand what the –rules option did, we must turn to the john.conf file. This is the configuration file used to influence John’s behavior. The john.conf file contains several useful settings worth reviewing. But first we’ll look at how rules are defined and perform.

John provides lots of documentation in its doc directory. The doc/RULES file is especially relevant for this section.

John the Ripper - Cracking Passwords
John the Ripper – Cracking Passwords

The following example lists a portion of the john.conf file that applies permutations to a wordlist. The rules will seem inscrutable for the moment; we’ll break out a Rosetta stone in a moment to help decipher them. Lines that begin with the # symbol are comments that explain the purpose of a rule (even through the syntax of the rule may seem unclear right now). The rule syntax is derived from the old Unix crack utility written by Alec Muffet.


# Wordlist file name, to be used in batch mode

Wordlist = $JOHN/password.lst


# Try words as they are


# Lowercase every pure alphanumeric word

-c 3!?XlQ

# Capitalize every pure alphanumeric word

-c 2(?a!?XcQ

# Lowercase and pluralize pure alphabetic words *2!?Alp # Lowercase pure alphabetic words and append ‘1’


We’ll use the –stdout option to help explain how rules work. Note that in the previous example the default Wordlist setting was defined to point to the password .lst file we’ve been using. The following example shows how to list the guesses that John will make based on its configuration file and command-line options. In this case, it would just use each entry from the password.lst file.

$  ./john –wordlist –stdout








We’ll start with simple rules. Complex rules, like the ones we saw for the wordlist in the previous example, are composed from clever combinations of simpler rules.

Imagine a password policy that requires every password to begin with a number. Obviously, we don’t need to bother trying to guess “letmein” since the word doesn’t match the policy; it wouldn’t be efficient to spend time on guesses we know would fail. The following example creates a new rule that prepends a digit to every guess. The caret (^) indicates the beginning of the word (much like its meaning in regular expressions). The [0-9] indicates the range of numbers from 0 through 9.



Now, we check how the rule mutates the dictionary. We’ll end up with ten times the number of guesses—one for each word prepended by 0, then 1, then 2, all the way through 9.

$ ./john –wordlist –stdout –rule=AHT4Number










Want to prepend two numbers? We’ll use a different rule syntax that inserts arbitrary characters (only numbers for now) in any position of the word. The first position is 0. Create the following rule:



Confirm the rule works as expected by checking for two leading digits for all our guesses. We’ve just increased the dictionary size by a hundredfold. This rule is more flexible because you can insert the digits anywhere within the word by changing the ordinal for the A from 0 to another number. For example, the following rule inserts two digits after the first character:



We can try to be more clever by assuming that users like to include their birth year as part of a password. If we lived in the world of Logan’s Run, then we’d only worry about birthdays from the past 30 years. (We’d have more important worries past 30.) Assuming this book actually met its deadline and was published in 2013, then we want to create a range of years from 1983 through 2013. The following rule would suffice. Take your time deciphering how it works. Note that the [0-9] after the A indicates a range of positions as opposed to the range of digits when [0-9] appears inside the quotes.





John the Ripper - Cracking Passwords
John the Ripper – Cracking Passwords

Now that we’ve spent some time on efficiency, let’s take a look at another trick for mutating words. The following example takes advantage of the assumption that users might append the domain name of the web site to their password. For example, a user might like to reuse “letm3in” but alter it to “” or “letm3in@” under the mistaken expectation that doing so significantly increases the password’s entropy (i.e., decreases its “guessability”). The following rule shows how to target such an assumption. The z after the A rule indicates that the string should be appended to the word.



# version with “l33t” substitutions


So far we’ve defined positions for the A rule for the beginning (0), the end (z), and the first through tenth ([0-9]) place in a word. You can also use the [A-Z] range to indicate positions from 10 through 35. For example, the following rule targets Douglas Adams fans with a mutation that will insert “42” in every position in words up to 35 characters long, and at the beginning and end of words of any length:



Table 1 summarizes the position indicators we’ve covered so far. These are most useful when you wish to insert new characters into a word.

John also supports conversion rules that change the case (lowercase to uppercase or vice versa) or type (such as e to 3) of characters or remove certain types of characters. For example, the following rule makes different substitutions for vowels within a word. The ?v represents a character class placeholder. John has predefined ?v to represent all vowels. Look for the “[UserClasses]” section in the john.conf file for other ideas.


# change vowels to dot (.)


# substitute 0 for o


# two “l33t” substitutions

so0 sa4

Rule Description Example
^/ Prepends the character. ^[01]
$ Appends the character. $[!.]
i[n] Inserts a character at the n position. i[4][XZ]
An”…” Inserts a string at the n position, or from A1″19″
A[n-m]”…” n to m positions. Positions may be 0–9, l19etmein
A–Z (for positions 10 through 35), or z (for append).

Table 1 Position Indicators for john.conf Rules

The following rules show how to change the case of words or letters within words:


# force uppercase


# force lowercase


# toggle case of character in a specific position


Or, you can delete characters with the D rule, as in the following example:



Wordlist rules can help us create efficient cracks, but that’s no guarantee they’ll succeed against every hash we encounter. We’ll still need to apply brute-force guesses that iterate through all possible permutations of characters for a given word length. We accomplish this with the –incremental option.

John the Ripper - Cracking Passwords

Finally, you can combine different rules for more comprehensive guessing. The following example shows how to put several of the previous examples together into a single rule:


.include [List.Rules:AHT4Email]

.include [List.Rules:AHT4Logan]

.include [List.Rules:AHT4Number]

.include [List.Rules:AHT4Number2]

.include [List.Rules:AHT4Number3]

John should be able to avoid duplicate guesses that might occur from any overlapping rules.

John the Ripper - Cracking Passwords

Dejar una contestacion

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.