Hash cracking is often paused or stopped for various reasons. Hashcat has a Pause button to temporarily pause the attack, but what if you need to stop for an extended period, shut down your computer, and then resume the cracking process? In that case, it would be impractical to lose all progress and start the attack from scratch.
Luckily, Hashcat provides a mechanism to address this issue. The purpose of this tutorial is to explain this mechanism, provide practical examples, and delve into the inner workings of how it operates.
1. Hashcat Restore
Let's start a dictionary attack against hash type 22000 that is located in the output_file-01.hc22000 (Figure 1).
$ /usr/local/bin/hashcat -a 0 -m 22000 output_file-01.hc22000 rockyou.txt
-a 0 The dictionary attack, or “straight mode,”. hashcat reads lne by line from a dictionary rockyou.txt and try each line as a password candidate.
-m 22000 -Hash type is WPA-PBKDF2-PMKID+EAPOL - Pre-Shared-Key (PSK). Length of a PSK can be 8 up to 63 characters.
Figure 1 - Dictionary Attack Against the 22000 Hash Type
When launching the attack, two files, hashcat.log and hashcat.restore, are created in the hidden directory .hashcat/sessions, which is located in the home directory. The complete file path for hashcat.restore is ~/.hashcat/sessions/hashcat.restore.
The "hashcat.restore" file plays a crucial role in the cracking process within Hashcat. It serves as a storage mechanism for the current position, specifically the line number, within the dictionary file (such as "rockyou.txt") where the password being processed is located.
As mentioned earlier, the file "hashcat.restore" is a snapshot in which Hashcat continuously stores the progress of the cracking operation. However, to maintain efficiency and speed, the file is not updated with every password attempted. Updating it for every password would be impractical and slow. Instead, the file is automatically updated at regular time intervals.
This is where the concept of "Restore Points" or "Checkpoints" becomes crucial. Hashcat automatically creates checkpoints during the cracking process at checkpoint intervals. If the cracking process is interrupted for any reason, like a power failure, system crash, or manual interruption, you can utilize the saved checkpoint to restore the cracking process from the precise point where it was halted. This way, you can resume cracking without starting from the beginning, saving time and resources.
1.1 Structure of Hashcat.restore File
Please refer to the highlighted line "392950/301232043 (0.13%)" enclosed within the red rectangle in Figure 1. This line indicates the current position in the cracking process, where the password "ricecake1" is located. The corresponding information is stored in the file "hashcat.restore," along with other relevant attributes. At this stage, the overall cracking progress stands at 0.13%.
The Figure 2 depicts structure of binary file hashcat.restore which contains the following attributes [1]:
- The version of hashcat that was used to create the file
- The current working directory. Hashcat will change to this directory
- The current position within the dictionary list
- The current position within the list of masks
- The position within the dictionary/mask
- The number of command line arguments
- The command line argument list
Note the hexadecimal numbers "F6 FE 05" highlighted in the red rectangle. When we reverse the order of these hexadecimal numbers and convert "05 FE F6" to decimal form, we get the number 392 950. This number is the line number 392,950 in our dictionary "rockyou.txt"
When we resume cracking, Hashcat will continue from line 392,950, ensuring that progress continues seamlessly from where it left off.
Figure 2 - Structure of Binary hashcat.restore File
The utility "analyze_hc_restore" written in Perl can help us understand the meaning of individual hex digits and their location in the Hashcat restore binary (Figure 3).
$ git clone https://github.com/philsmd/analyze_hc_restore.git
$ ./analyze_hc_restore.pl ~/.hashcat/sessions/hashcat.restorehashcat.restore
Figure 3 - Analyzing Hashcat Default Restore file hashcat.restore
1.2 Restoring Hashcat Job
In section 1, we terminated Hashcat by pressing the "q" key. As previously mentioned, Hashcat automatically generates and updates checkpoints throughout the cracking process. However, by opting for 'q' instead of 'c', there is a risk of losing progress if the restore file has not been recently updated.
Hence, the developers of Hashcat advise utilizing the Checkpoint feature to exit the program. This can be achieved by pressing 'c'. By employing this approach, Hashcat will pause its operation until the restore file is appropriately updated before closing.
Figure 4 - Creating Hashcat Checkpoint with "c" Key
We can use the command to resume the cracking job:
$ /usr/local/bin/hashcat --restore
Remember not to leave out the "--restore" keyword, as failing to include it will result in the cracking process restarting from the beginning.
2. Hashcat Sessions
When running Hashcat without specifying a session name, the restore file can be found at ~/.hashcat/sessions/hashcat.restore. However, if you include a session name in the Hashcat syntax, the "hashcat" prefix within hashcat.restore will be replaced by the designated session name.
Let's illustrate this by starting a dictionary attack using Hashcat and specifying the session as "aaa":
$ /usr/local/bin/hashcat -a 0 -m 22000 --session aaa output_file-01.hc22000 rockyou.txt
In this scenario, the Hashcat restore file will be located at ~/.hashcat/sessions/aaa.restore.
To create a checkpoint, press the 'c' key. Now, to resume the attack that was launched with the above command, use the following command:
$ /usr/local/bin/hashcat --session aaa --restore
By executing this command, the session named "aaa" will be restored, and the cracking operation will resume from the point where it was last paused.
Note: A session in Hashcat offers several advantages for managing cracking operations efficiently. It allows for:
- Clear organization and categorization of different cracking tasks within Hashcat.
- Easy tracking and management of progress and results for each session.
- Seamless resumption of cracking tasks from where they were left off.
- Simultaneous execution of multiple cracking operations with distinct sessions.
- Enhanced flexibility and control over specific cracking configurations for each session.
End.