Hello,
I would like to reboot my PC, but I have a 100GB wordlist running that is at 25%. (So I don't want to do something wrong). I didn't name the session, so I'm not sure what command I have to type in. The sessions name is "hashcat". Is this always the LAST session I did, saved under "hashcat", or are they numbered(other aborted sessions)?. Do I only have to make a [c]heckpoint and restore later with "--restore hashcat"?
* Session:
--runtime=NUM Abort session after NUM seconds of runtime
--session=STR Define specific session name
--restore Restore session from --session
--restore-timer=NUM Save restore file each NUM seconds
Thank You
(Sorry if this is stupid question but I couldn't find the answer I need. Maybe this thread helps other newbees.)
plan A:
if you haven't specified a session name, the default would be "hashcat". therefore, you only need to call
./hashcat64.bin --restore
not even need to specify the session name if it was default. - just did the same a few minutes ago.
plan B:
doesn't make much sense after having plan A, but just to mention it: even if you have lost a session or restore wouldn't work, if you remember the percentage before rebooting, then use --keyspace with the same hashcat parameters to show the total keyspace, and by multiplying the percentage with keyspace you can calculate the offset for --skip .... so it will start at that position. also works, also did it. obviously "plan A" is way better/more nice ...
(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).
Typing --restore worked. I will name every session now.
(08-12-2016, 08:42 AM)philsmd Wrote: [ -> ]You should never use the progress or percentage directly with --skip (or calculate the skip value from the progress line).
How can I read the status output?
Would it be okay to use the percentage if the PC freezes and I know the progress is at ~75% and I --skip 70% (to be sure)?
Quote:How can I read the status output?
When you know you're at 75% it's because you saw it on the status screen. There's also a column named Restore Point
Quote:Would it be okay to use the percentage if the PC freezes and I know the progress is at ~75% and I --skip 70% (to be sure)?
There's no general yes here, so it means no.
(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.
(08-13-2016, 05:07 PM)jodler303 Wrote: [ -> ]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.
Nope, that's the wrong way of doing it.
You still need to stick to the Restore point value and not the percentage of that specific mask.
So instead of using "the percentage from the last mask", you need to use the restore point value of the last mask.
That's the only way that is guaranteed to work everything else might just be totally wrong.
(You can't just use some value a little bit lower than the percentage and hope that it will work nevertheless because it won't in most of the cases - because it is the wrong way of doing it - ... you risk of not cracking/skipping a lot of hashes that otherwise would crack using the only acceptable approach)
OMG. That was a real hard one.
OK, I think i can FINALLY
understand your point. - The root for irritation remains though, that is ... when using the restore value for --skip in combination with a .hcmask file, hashcat will print this error:
"ERROR: Restore value greater keyspace"
and this is VERY irritating. (possibly only if skip is higher than the keyspace of the first mask in the .hcmask file, haven't checked sources for that yet)
Assuming what you're saying, and the general solution besides --restore is manually running the last mask with --skip and the restore point value, hashcat should maybe not accept --skip at all in combination with a .hcmask containing multiple masks then, or is there a use for that?
I also think an error or at least a warning should be displayed whenever someone tries to use --skip with a mask file.
Since warnings are often ignored by the users, I think hashcat should show an error message and exit.
Would be nice if someone can open a github issue for this.