Feature to [b]ypass if not worthwhile attack

[PenguinKeeper7]

Add feature to [b]ypass an attack if the attack isn't sufficiently fruitful, so for --bypass-threshold 10 --bypass-delay 5, it would expect at least 10 cracks per 5 seconds, if less than 10 cracks are successful, bypass. This would likely be helpful especially for masks, either to ignore bad masks or to simply skip before the markov candidates get too inefficient. Could also be helpful if someone's running many wordlists in series and one wordlist isn't performing too well etc. I'm happy to rename the flags. s/delay/timeframe/g maybe?

Inspired by: https://github.com/justpretending/avgdrop

[roycewilliams]

Interesting! Since some attacks can ebb and flow, this "power user" feature might also be accompanied by an advice-level warning/note to that effect, and to only use it if you know what you're doing? (Not sure on phrasing though.)

[ghost]

I notice you're using digests_done. Doesn't that include cracked hashes that are already in the potfile and in the outfile directory?

There's digests_done_new if you only want new cracks.

[PenguinKeeper7]

I notice you're using digests_done. Doesn't that include cracked hashes that are already in the potfile and in the outfile directory?

There's digests_done_new if you only want new cracks.

Doesn't matter, it's working from a delta between two points in time so it doesn't matter where the start point is. digests_done_new would work the same way because it doesn't reset between Guess.Queue elements

[ghost]

If, between these two points in time, some founds were added to the outfile directory (--outfile-check-dir) and processed by hashcat, wouldn't it increase your delta erroneously?

[magnumripper]

This is Good Stuff™. JtR has had this for years as a (nowadays documented) easter egg with --max-run-time=n (seconds). If you set it to a negative number, it will quit n seconds after last crack. And here the thing: It will keep the session file. So if you later want to resume that one attack, you can.

This would be hard to implement if you just bypassed a poorly performing mask in a mask file and keep running in the same session though. Perhaps you could just log (or output) enough detail that you could resume the bypassed attack(s) later by starting new session(s) with --skip? Anyway that would be a feature request and obviously not a blocker for this PR.

[PenguinKeeper7]

Perhaps you could just log (or output) enough detail that you could resume the bypassed attack(s) later by starting new session(s) with --skip? Anyway that would be a feature request and obviously not a blocker for this PR.

Nice! I agree that it'd be cool to do that but I'm not sure how it'd be possible in a very "Hashcat" way, it'd require a very large redesign of the current restore file to get working with --restore. Do you have a suggestion for how it'd be most elegant to do this? Only thing I can think of is a new logfile that says bypassed attack:restore_value, i.e bypassed ?a?a?a?a:123456 or bypassed wordlist.txt:7890 but it's not very confirmative with the rest of the logging system

[magnumripper]

Well you do get status info (such as ETA) for the current mask line (or wordlist), don't you? So the needed information should be somewhere in there.

[PenguinKeeper7]

Yeah, it's definitely possible, I'm just not sure how it'd be logged/presented the best for UX, especially if we're potentially bypassing thousands of masks/wordlists

[magnumripper]

It could just say bypassed -a3 ?a?a?a?a at <skip position> meaning you could mount that attack separately and use --skip=skip position to continue it. For the "thousands" case you'd just grep the log for "bypassed" and process with some ninja perl-fu.

[ghost]

Then there's the minor matter of formatting: the lack of a space after the new ifs is at odds with the rest of the code in monitor.c.

+ if(user_options->bypass_delay_chgd == true)

I don't know if the owners are okay with a bit of inconsistency, but I would fix that.

[PenguinKeeper7]

Then there's the minor matter of formatting: the lack of space after the new ifs is at odds with the rest of the code in monitor.c.

+ if(user_options->bypass_delay_chgd == true)

I don't know if the owners are okay with a bit of inconsistency, but I would fix that.

I don't see any inconsistency. If you can show 2 blocks of code that are the same in essence but are formatted differently, I'm happy to update it but I don't see any problem with the line you pointed out. Make sure you're viewing the file directly

[ghost]

[jsteube]

Same as https://github.com/hashcat/hashcat/pull/3724 there's a larger patch coming in and the changes in types.h complicate things too much. We'll maybe merge this afterwards, I've not yet decided.

[ghost]

It shouldn't start counting until the first candidate has arrived from stdin. Currently, if the external password generator is slow to start up, you get a premature bypass with Candidates.#1: [Copying].

[PenguinKeeper7]

It shouldn't start counting until the first candidate has arrived from stdin. Currently, if the external password generator is slow to start up, you get a premature bypass with Candidates.#1: [Copying].

Yeah. Other Hashcat features have this problem like --runtime will kill a run before ever hashing a single candidate so while I'm happy to patch this, it may require a bit more than just me fixing --bypass