I think this is related: https://github.com/hashcat/hashcat/issues/1644
it's probably much more complicated than just storing 1 additional value... I think the problem has mainly to do with statistics and making sure the file didn't change etc.
what I mean by statistics is that in the status we have a lot of values... e.g. rejected count, progress, restore points etc... if we just seek to a position all those values could be computed totally wrong.
I think we discussed a while back if we should add even a further file to improve seeking... because the current architecture is that dictstat has nothing to do with restore and the .restore file has kind of nothing to do with stats about the dict etc... therefore storing this restore/skip/seek values in one of them, is actually quite misleading and wrong.
That said, I think there is still room for improvement, we just need to come up with a clever strategy that doesn't impact the user that doesn't intent to restore/seek/--skip (performance-wise) and that is also correct with all the stats/values etc (for instance, we won't want to risk to somehow get progress > 100%, just because we didn't want to risk waiting a few extra minutes to get the values correct etc).
Any volunteer that has enough insides and knowledge about the general architecture of hashcat and has a good strategy is of course very welcome... and of course also Pull Requests that try to improve speed or fix the "problem" in a very clever and most importanty correct way. Thx
it's probably much more complicated than just storing 1 additional value... I think the problem has mainly to do with statistics and making sure the file didn't change etc.
what I mean by statistics is that in the status we have a lot of values... e.g. rejected count, progress, restore points etc... if we just seek to a position all those values could be computed totally wrong.
I think we discussed a while back if we should add even a further file to improve seeking... because the current architecture is that dictstat has nothing to do with restore and the .restore file has kind of nothing to do with stats about the dict etc... therefore storing this restore/skip/seek values in one of them, is actually quite misleading and wrong.
That said, I think there is still room for improvement, we just need to come up with a clever strategy that doesn't impact the user that doesn't intent to restore/seek/--skip (performance-wise) and that is also correct with all the stats/values etc (for instance, we won't want to risk to somehow get progress > 100%, just because we didn't want to risk waiting a few extra minutes to get the values correct etc).
Any volunteer that has enough insides and knowledge about the general architecture of hashcat and has a good strategy is of course very welcome... and of course also Pull Requests that try to improve speed or fix the "problem" in a very clever and most importanty correct way. Thx