Code:
hashcat64.exe -a 3 -m 0 [xx.hash.xx] masks\my_mask.hcmask -w 4 --status
Quote:Session..........: hashcat
Status...........: Exhausted
Hash.Type........: MD5
Hash.Target......: [xx.hash.xx]
Time.Started.....: Sat Jun 01 13:45:10 2019 (1 sec)
Time.Estimated...: Sat Jun 01 13:45:11 2019 (0 secs)
Guess.Mask.......: ?l?l?l?l?s?l?l [7]
Guess.Queue......: 1592/91133 (1.75%)
Speed.#3.........: 10657.3 MH/s (49.76ms) @ Accel:64 Loops:1024 Thr:1024 Vec:1
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 10194220608/10194220608 (100.00%)
Rejected.........: 0/10194220608 (0.00%)
Restore.Point....: 580008/580008 (100.00%)
Restore.Sub.#3...: Salt:0 Amplifier:17408-17576 Iteration:0-1024
Candidates.#3....: fkxe_ma -> xqxq~xq
Hardware.Mon.#3..: Temp: 81c Fan: 78% Util: 95% Core:1847MHz Mem:4513MHz Bus:16
Restore value is greater than keyspace.
Started: Sat Jun 01 13:26:50 2019
Stopped: Sat Jun 01 13:45:13 2019
Can anyone advise on this issue? I didn't pause or attempt to resume anything, it just happened. However I get the same error when trying to restore.
This is indeed an interesting problem, but very difficult to reproduce.
I *think* this is a glitch and hashcat while changing from one mask to another (in your case to or from mask number 1592 of 91133) it's not in sync somehow and thinks that the val > max because the mask before the current/new mask had a different max restore value etc... This is just an educated guess, because I saw a similar problem reported on the forum before and it also didn't make much sense and wasn't really reproducible easily.
If somebody could somehow generate a reproducible test mask file which always leads to this error, that would be great and much easier for the devs to troubleshoot and hopefully fix.
good news, I was able to reproduce this problem with a very dedicated mask file (masks with small keyspace after masks with large keyspace, repeated thousands of times).
The problem seems to be located here:
https://github.com/hashcat/hashcat/blob/...c#L87-L102
(and also present in the latest git master version)
Especially this seems to be dangerous doing on every mask change:
https://github.com/hashcat/hashcat/blob/...hcat.c#L93 , if we can't guarantee that the restore data is in sync with the current loop.
I've asked atom about it and we will try to find a resolution (maybe doing this assignment only maximum once per launch or only one time at startup, because the restore file value isn't that much important to read after the first mask run is completed).
Thanks again for reporting... I think I nailed it, because without this code (commented out) it doesn't seem to error out for me anymore (but of course without the code at all we have a problem with the .restore file, therefore we should do it one time and only one time)
Good catch! You're theory also works with the example I gave above, from keyspace 67,600,000 to 10,194,220,608. I hope you guys don't have too much headache with a fix.
no, that's the wrong value.
the values should be from 580008 to the next keyspace (from the "large" 580008 value to something smaller, that is why it's a "greater than" problem, new mask is smaller, but value of last one is larger, but the comparison is wrong because it should compare val_new > max_new instead of val_old > max_new, this happens only rarely, something like a race condition) for the next mask (after the ?l?l?l?l?s?l?l mask)
you can use --keyspace to show that value, it's also in the max value in the "Restore.Point" line
Sorry, I was using the 'actual' keyspace, and also the mask before instead of mask after, when using the --keyspace flag:
Mask 1592: 580,008
Mask 1593: 67,600
