hashcat Forum

Full Version: speed reduce in using rules to generate keys
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

In the Rule-based attack, i want to store the generated keys, so i use the "--stdout" switch, for example,
"./hashcat64.bin -r ./rules/rockyou-30000.rule --stdout dictionary.txt".

My dictionary is large enough, but i find the speed is much lower than expected, both cpu (with "-D 1") and gpu (with "-D 2"). 

Even if i use "./hashcat64.bin -r ./rules/rockyou-30000.rule --stdout dictionary.txt >/dev/null" to reduce the time used in printing screen, the speed is still very low.

What's the reason for the slow down? and how can i reach the expected speed?
what do you mean by "very low speed"? how do you measure it?
(03-16-2018, 11:02 AM)undeath Wrote: [ -> ]what do you mean by "very low speed"? how do you measure it?

I record the run time of the command " ./hashcat64.bin -r ./rules/rockyou-30000.rule --stdout dictionary.txt  >/dev/null"

and i calculated the total number of generated keys(num of rules multiply by num of dictionaries), so i calculated how many keys it can produce in one second. The rate is about 10M/s on my cpu.

In this "--stdout" mode, hashcat only produces new keys, it's rate is  even slower than normal rule-based crack mode, in which it does both key producing and hash cracking. 

The rate in normal rule-based crack mode is about 30MH/s on my cpu.
but what does this tell us? I think kind of no news here.
It just means that I/O should be avoided and could always be a bottleneck (even if you use /dev/null and the /dev/null is highly optimized by the operating systems... the binary still needs to form the output and call the syscalls for the input/output). If you do not need to print each and every password candidate (but just hold it in memory for a few nanoseconds and manipuate/use it), you save a lot of other resources (no need to format the output, no I/O syscalls and no disk IO if not using /dev/null etc).

I'm not saying that there is absolutely no way to optimize --stdout a little bit, but it probably won't be more than a very small constant factor, in the best case. Feel free to make a pull request on https://github.com/hashcat/hashcat if you find some code improvements.

btw: I think the argument "-o /dev/null" could even be a little bit faster compared to the redirect with > /dev/null (but I didn't test it)