Table of contents about Jhon the Ripper
Managing Multiple Cracking Sessions
Whether you encounter groups of passwords hashed by different algorithms or are targeting a group with a multiple-month cracking effort, you’ll need to know how to manage the state of sessions so your work isn’t lost. John stores all cracked passwords in the john.pot file. It represents the successful work done by your wordlists, rules, and CPU cycles. You should keep this file backed up, and use the –pot option to specify alternatives.
John keeps track of its state information in john.log and john.rec files. The log file contains output related to the processing of rules and successes. The rec file maintains a periodic snapshot of the cracking session. This way, if the John binary is stopped or killed, a session can be restarted without having to restart from the beginning. You don’t need to do anything to have John take care of this for you. If you stop a John process (e.g., press ctrl-c within the shell), then use the –restore option as shown next, the process will pick up from its last save point:
$ ./john –restore
When you work with multiple password sources, it’s a good idea to use the –session and –restore options to keep track of individual workloads. The following example shows how to use these options:
$ ./john –session=alpha_brute_windows –incremental=Alpha windows.txt
$ ./john –session=alpha_brute_unix –incremental=Alpha unix.txt
$ ./john –restore=alpha_brute_windows
$ ls alpha_brute* alpha_brute_unix.log alpha_brute_unix.rec alpha_brute_windows.log alpha_brute_windows.rec
The session files keep track of command-line options and information necessary to regenerate the point in time at which the last iteration of a guess was performed. Hence, a killed session resumes without losing days or months of effort.
NOTE: The session files are a snapshot of John’s command line and configuration. If you modify a wordlist, change a rule, or update a charset referenced by the session file, John will restore execution incorrectly—it won’t be aware of what the changes were.
Since the wordlists, john.conf, and session files are all text based, you might consider tracking them in a source control manager like Git, which would enable you to ensure that configurations and rules remain tied to the sessions that rely on them.
The ultimate reason for managing cracking sessions is that brute-force guessing requires days, weeks, months, or centuries (and more!) depending on the character sets and length of guesses. Hit the spacebar during a cracking session to have John report its progress. Once it has had a chance to run through about 0.10% (a tenth of a percent) of its guesses, it will print an estimate for when the cracking session will finish.
It’s easy to calculate the number of guesses required to complete a brute-force attack. Take the number of potential characters from which the password might be composed and raise it to a power equal to the length of the expected password. For example, a four-digit PIN commonly used to access an ATM comes from a pool of 104 numbers (10,000 equals ten digits to the fourth power). All lowercase and uppercase letters plus the ten digits equals 62 characters. A 12-character password composed from that pool produces a target space of 6212 guesses, or about 3.2E21 or 271 depending on whether you like a frame of reference in base 10 or base 2. In either case, that’s a lot.
NOTE: This section has focused on passwords composed from ASCII characters. Not all systems are limited to accepting, storing, or using passwords with alternate character sets. John supports UTF-8. However, you will not be able to effectively target other character-encoding schemes.
So, increasing the pool of characters from which you choose a password increases the work factor required to attack it. And, as mentioned at the beginning of this section, so does the hashing algorithm. A “fast” algorithm for which John can calculate a million cracks/second is weaker in this sense than a “slow” algorithm whose cracks/ second is around 200. In the fast case, John could generate all guesses for a six-digit number in about one second. In the second case, it would take John over an hour.