06-03-2013, 06:00 AM
(06-03-2013, 02:42 AM)Kgx Pnqvhm Wrote: What was more fresh in my mind that that the same dictionary and ruleset took a few seconds to run as an attack, but several hours to output the mangles to a file.
Well yes, that's absolutely to be expected.
(06-03-2013, 02:42 AM)Kgx Pnqvhm Wrote: As pointed out, stdout isn't really made for high speed I/O.
You misinterpreted what philsmd said. There's nothing special about stdout, it's just a file. It's not that writing to stdout is slow, it's that writing in general is slow. What slows down stdout specifically depends on what is reading from stdout, or where you are redirecting stdout. But this, as philsmd said, is unavoidable, since this is the task at hand.
(06-03-2013, 02:42 AM)Kgx Pnqvhm Wrote: And atom hasn't optimized hashcat for outputting mangles, but for doing actual attacks.
This is not true, atom actually has greatly optimized --stdout. It's as optimized as it's ever going to be.
(06-03-2013, 02:42 AM)Kgx Pnqvhm Wrote: The hashcat utilities mp and sp have a formal specified output file, and are very fast.
This is not why mp and sp are faster. Again, stdout is just a file. All three programs write to files in the same way, regardless of what the file is.
The reason mp and sp are faster is because they generate candidates internally, using a static, compiled algorithm. The rule engine generates candidates using a dynamic, interpreted scripting language. It also has to do simultaneous reads and writes. So this will of course be much slower.
(06-03-2013, 02:42 AM)Kgx Pnqvhm Wrote: What might be needed is, rather than fiddle with hashcat itself, have just the rule engine in a separate mp or sp style program, for the express purpose of generating the mangles.
The speed would be the same regardless.