Custom restore points

[sdt]

Is there a way I can set a custom restore point to my sessions ? 

eg: Iam running this dictionary combination on a large hash file of around 1.6M hashes

Code:

hashcat -m 124 -a 1 -O -w 3  -o all.found hashes.txt example.dict suffix.dict  --session ex1

And these are my running stats -

Code:

Progress.........: 1058334043200/5655470689344 (18.71%)                                                      
Rejected.........: 0/1058334043200 (0.00%)                                                                  
Restore.Point....: 0/128416 (0.00%)                                                                          
Restore.Sub.#1...: Salt:196224 Amplifier:0-42 Iteration:0-42 

Though it has gone around 19%, the restore points have not moved . Iam not sure about when the restore points get updated , but when I stop and start the session, it starts the iterations all over again . ( essentially wasting the runs  that were already done . )

The checkpoints option also does not work since they are never reached??? even the first checkpoint ?

1) Is there a way I can set a custom / manually create a checkpoint / restore point ? ( I checked the -s option - but that seems to be for skipping the number of words in the dictionary - might be suitable when Iam using only 1 dictionary ) 

Any clues on how to interpret the restore / checkpoints ? 
Thanks

[Snoopy]

Is there a way I can set a custom restore point to my sessions ? 

eg: Iam running this dictionary combination on a large hash file of around 1.6M hashes

Code:

hashcat -m 124 -a 1 -O -w 3  -o all.found hashes.txt example.dict suffix.dict  --session ex1

And these are my running stats -

Code:

Progress.........: 1058334043200/5655470689344 (18.71%)                                                      
Rejected.........: 0/1058334043200 (0.00%)                                                                  
Restore.Point....: 0/128416 (0.00%)                                                                          
Restore.Sub.#1...: Salt:196224 Amplifier:0-42 Iteration:0-42 

Though it has gone around 19%, the restore points have not moved . Iam not sure about when the restore points get updated , but when I stop and start the session, it starts the iterations all over again . ( essentially wasting the runs  that were already done . )

The checkpoints option also does not work since they are never reached??? even the first checkpoint ?

1) Is there a way I can set a custom / manually create a checkpoint / restore point ? ( I checked the -s option - but that seems to be for skipping the number of words in the dictionary - might be suitable when Iam using only 1 dictionary ) 

Any clues on how to interpret the restore / checkpoints ? 
Thanks

try to use [c] when hahscat is running to tell hashcat, to stop after next checkpoint (dont mind the output shown),if it stops after a while, good, anyway, to restart the session i hope u just used

hashcat --session yoursessionname --restore

if you used your first command from above again, your session file is overwriten

[sdt]

@Snoopy  Thanks for the response .
I did try with the [c]  - But it never stops at a checkpoint - indefinitely waits for a checkpoint and continues to run.
It happens when there are no restore points - like the case posted above .

Code:

Progress.........: 1269994620940/67047134308813 (1.89%)
Rejected.........: 2160068620/1269994620940 (0.17%)
Restore.Point....: 983899/63941069 (1.54%)
Restore.Sub.#1...: Salt:241131 Amplifier:0-1 Iteration:0-1
Candidates.#1....: 0874058840 -> 170991Z

( But on occasions where there are restore points , eg : like the one above , The [c] works . ( Since I know that restore points are created )

2) yes. I do use the same command . But since there is no valid check points / restore points , the session, when trying to "restore", starts from the very beginning.

Hence was wondering if I could try using a custom restore point - maybe on a percentage completion level or something like that ?

[Snoopy]

are you sure that no restorefile was written?

even when im using CTRL+C to kill hashcat i can see the file (mysession.restore) in the hashcat folder (can check tomorrow)

[atom]

The problem is that you have too many salts. The more salts, the longer it takes to reach the checkpoint. To verify, try a single (or a few hundret salted hashes), it will reach the checkpoint pretty soon as long as your amplifier (typically rules) are not too many. Also for the large hashlist you have - it will work, it will just take a very very long time. There's no way to change this.

[sdt]

Thanks @atom @Snoopy for the responses.


Yes, there are a lot of salts - and hashes. 
These are my approx hash stats from the hash files.
approx 2.1M digests , 1.67M unique digests, 1M unique salts

Iam using the same input files ( hashfile) with different modes ( for experiementation )

This is what I observed -
1) when using masked mode ( -a 3 ) ,
- The Restore.points DONOT get incremented . stays at 0 till the end  ( NO restore files are created for the session )

jumps from

Code:

Rejected.........: 0/93317300000 (0.00%)
Restore.Point....: 0/10000 (0.00%)
Restore.Sub.#1...: Salt:933173 Amplifier:0-10 Iteration:0-10
Candidates.#1....: 12345 -> 67646     

                     

to

Code:

Restore.Point....: 10000/10000 (100.00%)

2)  With a dictionary mode ( -a 0 ) with a large dict,
- Restore.points DO get updated  ( but slow )
eg:

Code:

Restore.Point....: 3938534/63941069 (6.16%)

....

Code:

Restore.Point....: 5919896/63941069 (9.26%)

( And the .restore files ARE created )

Am yet to do other experiments .. 
Am not sure if Iam reading too much between the lines when the answer is quite a straight forward 'No - donot expect it '
Just some observations and my effort to save some reruns.

The problem is that you  have too many salts. The more salts, the longer it takes to reach the checkpoint. To verify, try a single (or a few hundret salted hashes), it will reach the checkpoint pretty soon as long as your amplifier (typically rules) are not too many. Also for the large hashlist you have - it will work, it will just take a very very long time. There's no way to change this.

[atom]

Yeah what I say is true even if it means that the first possible checkpoint is at 100%.

[sdt]

Cool. Thanks for the explanation . 
I guess I will have to live with it then .

Yeah what I say is true even if it means that the first possible checkpoint is at 100%.