• John The Ripper Pkzip2
• John The Ripper 0 Password Hashes Cracked 1 Left Hands
• John The Ripper 0 Password Hashes Cracked 1 Left Handed

After seeing how to compile John the Ripper to use all your computer's processors now we can use it for some tasks that may be useful to digital forensic investigators: getting around passwords. Today we will focus on cracking passwords for ZIP and RAR archive files. Luckily, the JtR community has done most of the hard work for us. For this to work you need to have built the community version of John the Ripper since it has extra utilities for ZIP and RAR files.

• Using passwords recovered from LM hashes to crack NTLM hashes is easier with John the Ripper, because it comes with a rule (NT) to toggle all letter combinations: John-the-Ripper-v1.8.0-jumbo-1-Win-32 run john.exe -wordlist=lm-passwords.txt -rules=NT -pot=john-lm-ntlm.pot nt.john.out Warning: detected hash type 'NT', but the string is also recognized as 'nt2' Use the '-format=nt2' option.
• Actually I have done the following commands: root@localhost #unshadow /etc/passwd /etc/shadow mypasswd. root@localhost # john -show mypasswd. 0 password hashes cracked, 0 left. I'm not sure if the program is installed in my machine or not but when I checks it gives me: root@localhost # rpm -ivh john.

Hackers use multiple methods to crack those seemingly fool-proof passwords. John the Ripper and pwdump3 can be used to crack passwords for Windows and Linux/Unix. Follow the easy steps below. How to crack Windows passwords The following steps use two utilities to test the security of current passwords on Windows systems: pwdump3 (to extract password. Hackers use multiple methods to crack those seemingly fool-proof passwords. John the Ripper and pwdump3 can be used to crack passwords for Windows and Linux/Unix. Follow the easy steps below. How to crack Windows passwords The following steps use two utilities to test the security of current passwords on Windows systems: pwdump3 (to extract password.

For this exercise I have created password protected RAR and ZIP files, that each contain two files.
The password for the rar file is 'test1234' and the password for the zip file is 'test4321'.
In the 'run' folder of John the Ripper community version (I am using John-1.7.9-jumbo-7), there are two programs called 'zip2john' and 'rar2john'. Run them against their respective file types to extract the password hashes:
This will give you files that contain the password hashes to be cracked... something like this:
After, that you can run John the Ripper directly on the password hash files:
You should get a message like: Loaded 1 password hash (PKZIP [32/64]). By using John with no options it will use its default order of cracking modes. See the examples page for more information on modes.
Notice, in this case we are not using explicit dictionaries. You could potentially speed the cracking process up if you have an idea what the password may be. If you look at your processor usage, if only one is maxed out, then you did not enable OpenMP when building. If you have a multi-processor system, it will greatly speed up the cracking process.
Now sit back and wait for the cracking to finish. On a 64bit quad-core i7 system, without using GPU, and while doing some other CPU-intensive tasks, the password was cracked in 6.5 hours.
Now if you want to see the cracked passwords give john the following arguments:
It should output something like:
Note: the hash file should have the same type of hashes. For example, we cannot put the rar AND zip hashes in the same file. But this means you could try to crack more than one zip/rar file at a time.
For the rar file it did not take nearly as long since the password was relatively common. If you take a look at john.conf in the run directory, it has a list of the patterns it checks (in order). The pattern 12345 is much more likely than 54321, so it is checked first resulting in a quick crack.

Table of contents about Jhon the Ripper

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.

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 www.lightbluetouchpaper.org/2012/09/03/ 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

$NT$2c5f5597333bd214b5bea2c01c591bc9:Tenar

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.

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.

[Options]

# Wordlist file name, to be used in batch mode

John The Ripper Pkzip2

Wordlist = $JOHN/password.lst

…

[List.Rules:Wordlist]

# 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’

*2!?Al$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

12345

password

password1

123456789

12345678

1234567890

abc123

…

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.

[List.Rules:AHT4Number]

^[0-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

0123456

012345

John The Ripper 0 Password Hashes Cracked 1 Left Hands

0password

0password1

0123456789

012345678

01234567890

0abc123

…

9sss

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:

[List.Rules:AHT4Number2]

A0″[0-9][0-9]”

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:

John The Ripper 0 Password Hashes Cracked 1 Left Handed

[List.Rules:AHT4Number3]

A1″[0-9][0-9]”

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.

[List.Rules:AHT4Logan]

A[0-9]”19[89][0-9]”

A[0-9]”200[0-9]”

A[0-9]”201[0-3]”

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 “letm3in@facebook.com” or “letm3in@ gmail.com” 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.

[List.Rules:AHT4Email]

Az”@email.domain”

# version with “l33t” substitutions

Az”@[eE3]mail.d[oO0]m[aA4][iI1]n”

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:

[List.Rules:AHT442]

A[0-9A-Zz]”42″

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.

[List.Rules:AHT4Disemvowel]

# change vowels to dot (.)

s?v.

# substitute 0 for o

so0

# two “l33t” substitutions

so0 sa4

Rule	Description	Example
^/	Prepends the character.	^[01]
1letmein
0letmein
$	Appends the character.	$[!.]
letmein!
letmein.
i[n]	Inserts a character at the n position.	i[4][XZ]
letXmein
letZmein
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:

[List.Rules:AHT4ChangeCase]

# force uppercase

u

# force lowercase

l

# toggle case of character in a specific position

T[1-9]

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

[List.Rules:AHT4Remove]

D[0-9A-Z]

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.

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:

[List.Rules:AHT4]

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