Troubleshoot John the Ripper: Fix Common Errors

Introduction

John the Ripper (JtR) is a powerful and widely-used open-source password cracking tool. While it's incredibly effective, users, especially beginners, can run into common issues that halt their progress. These problems can range from cryptic error messages to performance slowdowns.

In this lab, you will learn how to troubleshoot some of the most frequent problems encountered when using John the Ripper. We will cover errors like "No hashes loaded," deal with invalid hash formats, address performance bottlenecks, handle corrupted session files, and learn where to find help when you're stuck. By the end of this lab, you'll be better equipped to diagnose and solve JtR issues efficiently.

Resolve "No hashes loaded" Error

In this step, we will investigate one of the most common errors in John the Ripper: No password hashes loaded. This error typically occurs for two main reasons: John has already cracked all the hashes in the provided file, or the file is not in a format that John can understand.

First, let's run John on a valid hash file. The setup script has already created a file named shadow.txt in your current directory (~/project) which contains a user's password hash in a format John recognizes.

Let's try to crack it using a simple wordlist.

john --wordlist=pass.list shadow.txt

You should see output indicating that John has loaded one hash and is attempting to crack it. It should find the password quickly.

Using default input encoding: UTF-8
Loaded 1 password hash (descrypt, traditional crypt(3) [DES 128/128 SSE2-16])
Cost 1 (algorithm [1:descrypt]...
Press 'q' or Ctrl-C to abort, almost any other key for status
password123      (dummyuser)
1g 0:00:00:00 DONE (2023-10-27 10:30) 100.0g/s 100.0p/s 100.0c/s 100.0C/s password123
Use the "--show" option to display all of the cracked passwords reliably
Session completed

Now that the password has been cracked, John stores it in a file called john.pot. Let's try running the exact same command again.

john --wordlist=pass.list shadow.txt

This time, you will see the error.

Using default input encoding: UTF-8
No password hashes loaded (see FAQ)

This is because John checks the john.pot file before starting and ignores any hashes that have already been cracked. You can view the contents of the john.pot file to confirm.

cat ~/.john/john.pot

The output will show the hash and the cracked password.

$1$notarealhash$b5gQ1P2kPiyP2t.OqI0kS1:password123

Another reason for this error is an invalid file format. Let's create a file that doesn't contain any hashes.

echo "this is just a text file" > plain.txt

Now, try to run John on it.

john plain.txt

You will see the same "No password hashes loaded" error because John could not find any data in the file that looked like a password hash. Always ensure your target file contains hashes in a supported format.

Debug "Invalid hash type" Error

In this step, we'll address issues related to hash types. Sometimes John cannot automatically detect the hash type, or a user might specify the wrong one using the --format flag, leading to errors or failed cracking attempts.

First, let's see what happens when John encounters a file with a malformed hash string. We have a file named invalid_hashes.txt for this purpose.

john invalid_hashes.txt

John will analyze the file and report that it couldn't load any valid hashes, similar to the error in the previous step.

Using default input encoding: UTF-8
No password hashes loaded (see FAQ)

Now, let's use a file with a valid hash but specify the wrong format. Our file hashes_md5.txt contains a standard raw-MD5 hash, but we will tell John it's an NT hash.

john --wordlist=pass.list --format=nt hashes_md5.txt

John will produce a warning or error because the hash data does not match the specified format.

Warning: invalid ciphertext ignored: user1:5d41402abc4b2a76b9719d911017c592
No password hashes loaded (see FAQ)

To fix this, you must provide the correct hash format. If you know the format is raw-MD5, you can specify it directly. This is often faster than letting John auto-detect it.

Let's run the command with the correct format.

john --wordlist=pass.list --format=raw-md5 hashes_md5.txt

This time, the command succeeds and cracks the password.

Using default input encoding: UTF-8
Loaded 1 password hash (raw-MD5 [MD5 128/128 SSE2-16])
Cost 1 (iteration count) is 1 for all loaded hashes
Press 'q' or Ctrl-C to abort, almost any other key for status
labex            (user1)
1g 0:00:00:00 DONE (2023-10-27 10:35) 100.0g/s 1234Kp/s 1234Kc/s 1234KC/s 123..labex
Use the "--show" option to display all of the cracked passwords reliably
Session completed

If you are unsure of the hash type, you can omit the --format flag and let John try to auto-detect it. However, for ambiguous or non-standard hashes, specifying the format is the best way to ensure success.

Address Performance Bottlenecks

In this step, we will explore how to identify and address performance issues. Password cracking can be a very resource-intensive task, and slow performance can make it impractical.

A key metric for performance in John the Ripper is "candidates per second" (c/s). You can run a benchmark to see how well your system performs with different hashing algorithms.

john --test

This command will run a series of benchmarks. Look at the output for the c/s rates for various algorithms.

Benchmarking: descrypt, traditional crypt(3) [DES 128/128 SSE2-16]... DONE
Many salts:	1234K c/s real, 1234K c/s virtual
Only one salt:	1111K c/s real, 1111K c/s virtual

... (many other algorithms) ...

Benchmarking: raw-MD5 [MD5 128/128 SSE2-16]... DONE
Raw:	45678K c/s real, 45678K c/s virtual

One of the most effective ways to improve performance on a multi-core system is to use parallel processing. John can do this with the --fork=N option, where N is the number of processes to spawn.

Before we test this, let's clear the john.pot file so we can re-crack the hash from Step 1.

rm ~/.john/john.pot

Now, let's run a single-core cracking session on shadow.txt. While it's running, press any key (like Enter) to see the status. Note the c/s rate.

john --wordlist=pass.list shadow.txt

After a moment, press Enter. You'll see a status line. Then press Ctrl+C to stop it.

Now, let's try again with two parallel processes.

john --fork=2 --wordlist=pass.list shadow.txt

This time, John will use two CPU cores to work on the task. If you check the status, the overall c/s rate should be significantly higher, nearly double the single-core rate. This can dramatically reduce the time required for a cracking session.

Other performance tips include:

Using targeted wordlists: A smaller, more relevant wordlist is faster than a massive, generic one.
Specifying the format: As seen in Step 2, using --format avoids the overhead of auto-detection.

Handle Corrupted Session Files

In this step, we'll learn how to handle a corrupted session file. John the Ripper automatically saves its progress in a session file (with a .rec extension) located in the ~/.john/ directory. This allows you to pause and resume long-running cracking sessions. However, if this file becomes corrupted, you won't be able to restore your session.

Let's start a new session. We'll name it my_session.

john --session=my_session --wordlist=pass.list corrupt_me.txt

Let the command run for a few seconds, then press Ctrl+C to gracefully stop it. John will save its progress.

Session aborted

You can see the session file that was created.

ls ~/.john/

john.log  john.pot  my_session.rec

Now, let's simulate a corrupted file by appending some garbage data to it.

echo "THIS IS CORRUPTED DATA" >> ~/.john/my_session.rec

With the session file corrupted, let's try to resume our work.

john --restore=my_session

John will fail to parse the recovery file and will likely exit with an error message. The exact error can vary, but it will indicate a problem with the .rec file.

Error in recovery file: ~/.john/my_session.rec

When this happens, the only solution is to remove the corrupted session file. This means you will lose the progress for that specific session and will have to start it over. However, any passwords that were already successfully cracked are safe in the john.pot file.

Let's remove the bad file.

rm ~/.john/my_session.rec

Now you can start the session again from the beginning. This is a crucial troubleshooting step for recovering from unexpected crashes or system shutdowns during a cracking attempt.

Seek Help from John the Ripper Community

In this step, we'll cover what to do when you've tried everything and are still stuck. The John the Ripper community is an excellent resource, but to get effective help, you need to provide the right information.

The primary place for community support is the john-users mailing list. Before posting, it's a good practice to search the archives to see if your question has already been answered.

When you need to ask for help, providing clear and complete information is key. Here is what you should always include in your request:

John the Ripper Version: Different versions have different features and bugs.
The Exact Command: The full command you used to run John.
The Full Output: All output from the command, including any error messages.
Operating System: The OS you are using (e.g., Ubuntu 22.04, Windows 10).
Hash Sample: An example of the hash you are trying to crack (if it's not sensitive).

You can get your John the Ripper version with the --version flag. Let's run it now.

john --version

The output will look something like this:

John the Ripper 1.9.0-jumbo-1 [linux-gnu 64-bit x86_64 AVX2 AC]

Knowing how to gather this information will make it much easier for community members to understand your problem and provide a helpful solution. Remember to be polite and patient when asking for help from open-source communities.

Summary

In this lab, you gained hands-on experience troubleshooting some of the most common issues with John the Ripper.

You learned how to:

Diagnose the No hashes loaded error by checking the john.pot file for already-cracked passwords and verifying the input file format.
Resolve hash type issues by using the --format flag to specify the correct algorithm.
Address performance bottlenecks by running benchmarks and using the --fork option for parallel processing.
Recover from a failed cracking attempt by removing a corrupted session (.rec) file.
Gather the necessary information, such as the JtR version and command output, to effectively seek help from the community.

With these skills, you are now better prepared to use John the Ripper more effectively and solve problems as they arise.

Troubleshoot Common John the Ripper Issues