hashcat Forum
speed reduce in using rules to generate keys - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: speed reduce in using rules to generate keys (/thread-7368.html)



speed reduce in using rules to generate keys - frankcynthia - 03-16-2018

Hello! 

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?


RE: speed reduce in using rules to generate keys - undeath - 03-16-2018

what do you mean by "very low speed"? how do you measure it?


RE: speed reduce in using rules to generate keys - frankcynthia - 03-19-2018

(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.


RE: speed reduce in using rules to generate keys - philsmd - 03-19-2018

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)