Cracked hashes during hashcat --restore not written to potfile
(09-20-2020, 09:08 AM)philsmd Wrote: did you copy the hashcat.restore file from another directory ?

The .restore file contains a path from which hashcat was originally launched (cwd, see and hashcat will use that directory and move to this folder at start.

You could either try to open the restore file with a hex editor, with a modern text editor that is able to display the bytes evn through most of them are binary or analyze_hc_restore  from to see which cwd is used within the restore file).

Thanks for your assistance philsmd. I have not touched the hashcat.restore file by any means. The cwd is as it should be.

I have found a way to reproduce this issue:

If a session is started and stopped by hitting 'c', and then again started by hashcat --restore, then hashcat seems to write to my correct hashcat.potfile. When I say the correct hashcat.potfile, then I mean the potfile from within the directory where the hashcat.bin are placed. Just to clarify, I have this located within my ~/Documents folder.

However, if a session is started and stopped by hitting 'c', and the pc is rebooted, and then the session is started again by hashcat --restore, then hashcat read and writes to the potfile which is located in ~/.hashcat/hashcat.potfile and not to the potfile placed within the same folder as the hashcat.bin are placed.

I assume I have the ~/.hashcat folder because the first time I installed hashcat it was through pacman, which I then uninstalled again. It then seems like the ~/.hashcat folder didn't got removed completely and is causing this issue?

The ~/.hashcat folder only contains a hashcat.potfile, hashcat.dictstat2, kernels folder and a sessions folder. Nothing else.

I think removing the ~/.hashcat folder could solve this problem, although I'm not sure and haven't tried so as I don't know if my assumptions are true or not.


Tried moving the ~/.hashcat folder after a reboot, and then restore a session. Turns out hashcat just creates a new folder instead of using the one where the binary is... Any suggestions?

Looking into the .log file of the restored session, it seems like these settings are changed from the original sessions .log file:


In the original sessions .log file, these above settings are correct. In the restored sessions .log file after a reboot, they are incorrect.