Posts: 2
Threads: 1
Joined: Mar 2018
03-16-2018, 04:25 AM
(This post was last modified: 03-16-2018, 05:51 AM by frankcynthia.)
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?
Posts: 2,301
Threads: 11
Joined: Jul 2010
what do you mean by "very low speed"? how do you measure it?
Posts: 2
Threads: 1
Joined: Mar 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.
Posts: 2,267
Threads: 16
Joined: Feb 2013
03-19-2018, 09:22 AM
(This post was last modified: 03-19-2018, 09:26 AM by philsmd.)
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)
