hashcat Forum

Since the last groups of rules in best64.rule might not change the input work, I wrapped them in the "M" and "Q" memorize and reject commands, but they wouldn't work on my Device #1: GeForce GTX 970, 1024/4096 MB allocatable, 13MCU:

hashcat64.exe
--attack-mode=0
--hash-type=2100
--rules-file=best64-MQ.rule

hashcat (v3.10-628-gf3626fa) starting...

Cannot convert rule for use on OpenCL device in file best64-MQ.rule on line 57: M o0d Q
.....

Is there an obvious reason why this doesn't work?

Hey, you couldn't know, the rules.txt wasn't updated. I've fixed that now. Take a look here:

https://github.com/hashcat/hashcat/blob/.../rules.txt

It shows you which rules you can use with -r and which ones are limited to -j and -k.

Is there some major hurdle to having "M" and "Q" be usable with -r?
And will the memory rules ever be usable with -r?

Edited: E.g., if I want to avoid having something like the 34 thousand rules in d3ad0ne.rule create candidates that waste time in slow algorithms, how am I supposed to do it?

> Is there some major hurdle to having "M" and "Q" be usable with -r?
> And will the memory rules ever be usable with -r?

Maybe, if it turns out to be important

> Edited: E.g., if I want to avoid having something like the 34 thousand rules in d3ad0ne.rule created waste candidates that waste time in slow algorithms, how am I supposed to do it?

Can you please make an example what you mean and how M and Q rules can help here?

The best64.rule set is small enough to examine by eye.

"Append" rules like $0 will always change the input word.

But "overwrite" rules like the o0d above won't change the input word if it already begins with "d".
Why have the unchanged word waste the time going throught ten thousand spins when it could be rejected and move on to the next input word?

Similarly "replace" rules like se3 will leave input words with "e" in them unchanged.

For "slow" algorithms there is a time payoff in rejecting unchanged words.

> Why have the unchanged word waste the time going throught ten thousand spins when it could be rejected and move on to the next input word?

Because there's no benefit in skipping it. The time it takes to process all threads in the kernel wouldn't change just because one (or more) of them isn't executed. That's the problem with parallel execution systems.

Also, that's why there's no support for reject rules for the in-kernel rule engine at all. It would only make the process slower because the switch() would need to test for a reject rule and that test would require additional time.