hashcat Forum
Cracked hashes during hashcat --restore not written to potfile - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: Cracked hashes during hashcat --restore not written to potfile (/thread-9514.html)

Pages: 1 2


Cracked hashes during hashcat --restore not written to potfile - username - 09-18-2020

Hi all.

If I've been running a session and stopped the session by hitting 'c' and then later want to restore the session by using:

Code:
hashcat --restore

Then if a hash is cracked during the session started by the above command, then hashcat does not write the cracked hash to the hashcat.potfile?

I'm not providing any session name to begin with, but if I'm providing an output file to begin with, hashcat writes the cracked hashes to the output file, but as already mentioned, not to the hashcat.potfile. 

It does not seem to matter which mode are being used as I've experienced it with different modes.

Is this an issue or am I doing something wrong? Can't really seem to find anything on this subject.


RE: Cracked hashes during hashcat --restore not written to potfile - 102980175isi - 09-18-2020

it should be:
hashcat --session (sessionname) --restore

i.e. hashcat --session test --restore

you need to input this into your initial cracking session command ie

sudo hashcat -m 22000 shit.22000 -a 3 w 3 --session shit -1 abcdefghijklmnqu ?1?1?1?1?1?1?d?d?d


RE: Cracked hashes during hashcat --restore not written to potfile - username - 09-18-2020

(09-18-2020, 11:33 PM)102980175isi Wrote: it should be:
hashcat --session (sessionname) --restore

i.e. hashcat --session test --restore

you need to input this into your initial cracking session command ie

sudo hashcat -m 22000 shit.22000 -a 3 w 3 --session shit -1 abcdefghijklmnqu ?1?1?1?1?1?1?d?d?d

As mentioned I'm not providing any session name to begin with, hence I only just use 'hashcat --restore' as the standard session is named hashcat. 

Is it required for the session to have a name different from the default for hashcat to write to the hashcat.potfile when a hash is cracked during the restored session?


RE: Cracked hashes during hashcat --restore not written to potfile - 102980175isi - 09-19-2020

Not sure mate, that is all I know. It is how I restore every session I start.

Apologies if it wasn't what you were looking for, hopefully someone will be able to go into more depth


RE: Cracked hashes during hashcat --restore not written to potfile - username - 09-19-2020

(09-19-2020, 12:02 AM)102980175isi Wrote: Not sure mate, that is all I know. It is how I restore every session I start.

Apologies if it wasn't what you were looking for, hopefully someone will be able to go into more depth

Thanks anyway tho!

If a hash is cracked during the restored session, does hashcat then write the cracked hash to the hashcat.potfile?


RE: Cracked hashes during hashcat --restore not written to potfile - 102980175isi - 09-19-2020

(09-19-2020, 12:21 AM)username Wrote: If a hash is cracked during the restored session, does hashcat then write the cracked hash to the hashcat.potfile?

it does, mine showed up fine in mousepad ~/.hashcat/hashcat.potfile

Edit: Just realised....using mouse pad....with a hashcat...hah


RE: Cracked hashes during hashcat --restore not written to potfile - username - 09-19-2020

(09-19-2020, 12:33 AM)102980175isi Wrote:
(09-19-2020, 12:21 AM)username Wrote: If a hash is cracked during the restored session, does hashcat then write the cracked hash to the hashcat.potfile?

it does, mine showed up fine in mousepad ~/.hashcat/hashcat.potfile

Edit: Just realised....using mouse pad....with a hashcat...hah

Just tried with a name specified for the session to begin with, didn't write to the potfile either once the restored session cracked the hash. Weird.

Edit: Hmm this is a little weird, I didn't knew I had a folder ~/.hashcat/, as I'm just running hashcat straight out of its folder from where I've located it when I downloaded it (although first time I downloaded it, it was through pacman, which I then uninstalled and then got the one from the official website instead). The folder from my download also contain a hashcat.potfile? Usually it writes to the one within the folder I've downloaded and not the one in ~/.hashcat/ ...


RE: Cracked hashes during hashcat --restore not written to potfile - philsmd - 09-19-2020

Code:
./hashcat
is different from
Code:
hashcat

if installed, the $HOME/.hashcat/ directory is used:
https://github.com/hashcat/hashcat/commit/0c65bc6ba3fd5c9068f751346d0533c9099ae83b#diff-05ce98cb03d150c05f7863b8b945a9aaR32


RE: Cracked hashes during hashcat --restore not written to potfile - username - 09-19-2020

(09-19-2020, 10:56 PM)philsmd Wrote:
Code:
./hashcat
is different from
Code:
hashcat

if installed, the $HOME/.hashcat/ directory is used:
https://github.com/hashcat/hashcat/commit/0c65bc6ba3fd5c9068f751346d0533c9099ae83b#diff-05ce98cb03d150c05f7863b8b945a9aaR32

I've created a symlink to the binary in the folder so that I just need to write hashcat instead of ./hashcat. 

Although, as I just edited in my command above, first time I installed hashcat it was through pacman, but I uninstalled it and just downloaded it from the website instead to get the latest version. Could this be what is causing the issue?

Normally hashcat is just writing to the hashcat.potfile from within the folder where the binary is. I've only experienced this when a hash is cracked in a restored session.


RE: Cracked hashes during hashcat --restore not written to potfile - philsmd - 09-20-2020

did you copy the hashcat.restore file from another directory ?

The .restore file contains a path from which hashcat was originally launched (cwd, see https://hashcat.net/wiki/doku.php?id=restore#screenshot) 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 https://github.com/philsmd/analyze_hc_restore to see which cwd is used within the restore file).