The .restore file format is a custom format, specifically developed for hashcat.

hashcat supports resuming cracking jobs for each and every hash type, attack mode, input type (even stdin) etc. It doesn't even matter why the job was stopped as long as you have a .restore file with all the information needed for hashcat to continue cracking (and the directories/dictionaries/masks/rules/hashes/hash files etc used within the original cracking job). No matter if you had a power failure or you just stopped the cracking job because you wanted to sleep near your hardware, with --restore you should be able to resume the cracking job.

It's important to know that the .restore file will be updated whenever this line in the status screen changes:

Restore.Point....:

… and not whenever this line changes (hashcat needs to reach the next restore checkpoint):

Progress.........:

The second most important thing to note is that quitting hashcat via the Checkpoint stop feature, by hitting 'c', will wait until the restore file has updated to quit, whereas forcing hashcat to quit by hitting 'q' will not. By using 'q' instead of 'c' you run the risk of losing progress due to the restore file having not been recently updated.

The .restore file will be automatically deleted whenever the full cracking job was finished (exhausted) or whenever every hash within the hash list was cracked.

To disable the restore support you can use --restore-disable. If you want to specify a different path to the restore file you can use --restore-file-path.

Consider that you used this command line to start a cracking job:

hashcat -m 0 -a 3 --session session_name example0.hash masks/rockyou-7-2592000.hcmask

and you hit 'c' (or 'q' for quit) while it was running (or it was stopped/killed for some other reasons).

This command resumes the above cracking job:

hashcat --session session_name --restore

The --restore command does not need nor allow any further arguments except from --session (and --restore itself). You can't simply add or change some arguments when you restore the job. If you really insist to change any arguments, you might be able to use some external tools (like analyze_hc_restore) at your own risk.

Also have a look at the FAQ section about the restoring feature.

.restore files are binary files. You might need to use a hex editor or use some external tools which are able to display the content of a restore-file in a human-readable format (like https://github.com/philsmd/analyze_hc_restore ).

struct restore_data
{
  int  version;
  char cwd[256];

  u32  dicts_pos;
  u32  masks_pos;

  u64  words_cur;

  u32  argc;
  char **argv;

} restore_data_t;

Note: the .restore file has no fixed length. The total number of arguments and the length of each argument determine the total length of the .restore file. The number of arguments (argc) should not exceed 250.

Note 2: There are some gaps within the restore structure since the format does not use packed alignment (__attribute__((packed))). Therefore, you should make sure that you use the offsets exactly like listed within the table above.