hashcat Forum

Full Version: Hashcat never creates restore point
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I started hashcat and at 16 seconds and asked it to create a checkpoint. I ran it for 10 minutes and it still didn't create a checkpoint. Restores seem to be broken too because it starts over even after running for 40mins...
This can happen when the attack you've setup has very few minimum work divisions and/or you've got relatively large amplifier values for a small base value(e.g. many rules, small dict). It can also be exacerbated by increasing the workload (-w 4), as well as attacking slower hashes (bcrypt, scrypt, etc.). Without more information, this just sounds like things are running as expected.
(09-18-2023, 06:43 PM)Chick3nman Wrote: [ -> ]This can happen when the attack you've setup has very few minimum work divisions and/or you've got relatively large amplifier values for a small base value(e.g. many rules, small dict). It can also be exacerbated by increasing the workload (-w 4), as well as attacking slower hashes (bcrypt, scrypt, etc.). Without more information, this just sounds like things are running as expected.

The list has 10M entries and the rule is not small either. 
I tried without -w 4 and the issue is the same. No restore point with checkpoint requested since start at 17 mins...
Code:
Session..........: name
Status...........: Running (Checkpoint Quit requested)
Hash.Mode........: 2100 (Domain Cached Credentials 2 (DCC2), MS Cache 2)
Hash.Target......: hash.txt
Time.Started.....: Mon Sep 18 18:48:53 2023 (17 mins, 34 secs)
Time.Estimated...: Wed Sep 20 08:51:29 2023 (1 day, 13 hours)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (lists/ignis-10M.txt)
Guess.Mod........: Rules (rules/clem9669_small.rule)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  168.7 kH/s (10.83ms) @ Accel:8 Loops:256 Thr:512 Vec:1
Recovered........: 3/9 (33.33%) Digests (total), 0/9 (0.00%) Digests (new), 3/9 (33.33%) Salts
Progress.........: 272302080/34650000000 (0.79%)
Rejected.........: 0/272302080 (0.00%)
Restore.Point....: 0/10000000 (0.00%)
Restore.Sub.#1...: Salt:8 Amplifier:244-245 Iteration:3584-3840
Candidate.Engine.: Device Generator
Candidates.#1....: V123456 -> V08031982
Hardware.Mon.#1..: Temp: 66c Fan: 77% Util: 99% Core:1875MHz Mem:5750MHz Bus:4
Just as I post the reply, it somehow managed to checkpoint at 18 mins…
Still, I'm unsure if that's because -w 4?
Also, the progress % is different after restore but restore point is the same. Is that expected?
(09-18-2023, 07:13 PM)Darksoul1 Wrote: [ -> ]Just as I post the reply, it somehow managed to checkpoint at 18 mins…
Still, I'm unsure if that's because -w 4?
Also, the progress % is different after restore but restore point is the same. Is that expected?

when restoring you restart from that restore point, loosing work already done until not reaching the next restore point
it's still not saving restore after 2 hours... Why can't it just instantly save, why does it need to wait for progress?

Code:
hashcat -O -m 2100 hashes.txt lists/ignis-10M.txt -r rules/top_1500.rule --restore-file-path restore.restore --session sessionname -w 3
....
Session..........: sessionname
Status...........: Running
Hash.Mode........: 2100 (Domain Cached Credentials 2 (DCC2), MS Cache 2)
Hash.Target......: hashes.txt
Time.Started.....: ... (59 mins, 35 secs)
Time.Estimated...: Mon Oct 16 20:51:32 2023 (25 days, 2 hours)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (lists/ignis-10M.txt)
Guess.Mod........: Rules (rules/top_1500.rule)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  124.1 kH/s (106.10ms) @ Accel:256 Loops:1024 Thr:32 Vec:1
Recovered........: 16/35 (45.71%) Digests (total), 0/35 (0.00%) Digests (new), 16/34 (47.06%) Salts
Progress.........: 4374528000/510000000000 (0.86%)
Rejected.........: 0/4374528000 (0.00%)
Restore.Point....: 0/10000000 (0.00%)
Restore.Sub.#1...: Salt:17 Amplifier:1200-1201 Iteration:5120-6144
Candidate.Engine.: Device Generator
Candidates.#1....: 1234553 -> Sakura113
Hardware.Mon.#1..: Temp: 60c Fan: 68% Util:100% Core:1890MHz Mem:5750MHz Bus:4
[s]tatus [p]ause [b]ypass [c]heckpoint [f]inish [q]uit => c
Checkpoint enabled. Will quit at next restore-point update.
[s]tatus [p]ause [b]ypass [c]heckpoint [f]inish [q]uit => s
Session..........: sessionname
Status...........: Running (Checkpoint Quit requested)
Hash.Mode........: 2100 (Domain Cached Credentials 2 (DCC2), MS Cache 2)
Hash.Target......: hashes.txt
Time.Started.....: ... (1 hour, 5 mins)
Time.Estimated...: Sat Oct 14 13:54:05 2023 (22 days, 19 hours)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (lists/ignis-10M.txt)
Guess.Mod........: Rules (rules/top_1500.rule)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  136.6 kH/s (106.81ms) @ Accel:256 Loops:1024 Thr:32 Vec:1
Recovered........: 16/35 (45.71%) Digests (total), 0/35 (0.00%) Digests (new), 16/34 (47.06%) Salts
Progress.........: 4424990720/510000000000 (0.87%)
Rejected.........: 0/4424990720 (0.00%)
Restore.Point....: 0/10000000 (0.00%)
Restore.Sub.#1...: Salt:18 Amplifier:8-9 Iteration:7168-8192
Candidate.Engine.: Device Generator
Candidates.#1....: 1234561 -> Sakura121
Hardware.Mon.#1..: Temp: 61c Fan: 70% Util:100% Core:1890MHz Mem:5750MHz Bus:4
...
[s]tatus [p]ause [b]ypass [c]heckpoint [f]inish [q]uit => s
Session..........: sessionname
Status...........: Running (Checkpoint Quit requested)
Hash.Mode........: 2100 (Domain Cached Credentials 2 (DCC2), MS Cache 2)
Hash.Target......: hashes.txt
Time.Started.....: ... (3 hours, 14 mins)
Time.Estimated...: Mon Oct 16 22:56:14 2023 (25 days, 2 hours)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (lists/ignis-10M.txt)
Guess.Mod........: Rules (rules/top_1500.rule)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  116.8 kH/s (112.43ms) @ Accel:256 Loops:1024 Thr:32 Vec:1
Recovered........: 17/35 (48.57%) Digests (total), 1/35 (2.86%) Digests (new), 17/34 (50.00%) Salts
Progress.........: 5933465600/510000000000 (1.16%)
Rejected.........: 0/5933465600 (0.00%)
Restore.Point....: 0/10000000 (0.00%)
Restore.Sub.#1...: Salt:24 Amplifier:215-216 Iteration:0-1024
Candidate.Engine.: Device Generator
Candidates.#1....: 2345633 -> akura1233
Hardware.Mon.#1..: Temp: 58c Fan: 67% Util:100% Core:1890MHz Mem:5750MHz Bus:4
Restore points do not work the way you think they do. Restore points happen at specific positions in the keyspace, and the positions that can trigger restore points depend on the attack base/mod, computing device size/speed/count, workload and chunksize tuning values, etc. A list of 10 million words, with rules, and -w 3, and against a slower algorithm will be VERY bad for restore points, per my post earlier in the thread. Increased workload/tuning values(-w 3), small wordlists(10M), and slow algorithms(2100) ALL exacerbate this issue, meaning you have setup almost a perfect storm for long times between restore points.