(08-12-2016, 08:42 AM)philsmd Wrote:(08-11-2016, 06:50 PM)jodler303 Wrote: and by multiplying the percentage with keyspace you can calculate the offset for --skip
Sorry, but this statement is bullshit. There is a specific line on the status output (not the progress line, but the Restore.Point line) that exactly gives you the value for skip. You should never use the progress or percentage directly with --skip (or calculate the skip value from the progress line).
Sorry phil, but why do you comment on something like this in such an insulting way? - Is this necessary, really?
Especially after i had posted the preferred solution (plan A). And, in fact, your suggestion is NOT working for some cases, even if it - in theory - indeed sounds good.
But let me elaborate ...
So ... while there is no doubt that plan A is the desired solution (that makes it plan A) and your suggestion is ALSO good for many situations for sure, in fact there are scenarios for plan B and where your suggestion simply won't work.
Simple example:
-a 3 attack with a multi-line .hcmask file. Hashcat is running the n-th line of maskfile, got interrupted and lost session, therefore --restore is not an option (otherwise we would be using plan A right away)
Now, try using --skip as you've suggested to restore this job with the value from Restore Point.
Guess what happens?
"ERROR: Restore value greater keyspace"
So what you will do (or maybe just me ;-)) is, taking the percentage from the last mask hashcat was working on, letting it finish off that mask the way i have described in plan B, and then run the rest of the masks. (Preferably with a small overlap to make sure you're not skipping candidates, as 'Zwei' suggested). - Exactly that happened to me, and it worked, while your suggestion unfortunately didn't (that was the first thing i've tried after being mad that i accidentally crippled the session and --restore was no option).
So pleeeeease be nice and don't insult me for a working solution, there was a reason for doing so. ^^ - Yes this is ugly, and yes we are really willing to use --restore instead (self explaining).
Cheers.