08-31-2018, 06:55 PM
I already mentioned in my previous post that you can easily workaround this limitation with either pipes (stdin mode) or -j/-k single rules.
There are some considerations to develop/implement/allow a non-GPU (slow) rule engine in future releases of hashcat, but this was just an idea until now and it's not sure if devs are convinced by the speed/effectiveness of this type of rule-engine-on-CPU-but-attack-on-GPU design.
However, if something like this will be implemented in future releases of hashcat, it will for sure be an opt-in command line switch whereby the user will be forced to enable this specific slow attack mode.
I think pipes, pre-generated small dicts, -j/-k rules etc are a very good compromise for now (as I already mentioned)... of course all of them have some disadvantages (but as we saw also a on-CPU rule engine has disadvantages, namely the speed drop !).
There are some considerations to develop/implement/allow a non-GPU (slow) rule engine in future releases of hashcat, but this was just an idea until now and it's not sure if devs are convinced by the speed/effectiveness of this type of rule-engine-on-CPU-but-attack-on-GPU design.
However, if something like this will be implemented in future releases of hashcat, it will for sure be an opt-in command line switch whereby the user will be forced to enable this specific slow attack mode.
I think pipes, pre-generated small dicts, -j/-k rules etc are a very good compromise for now (as I already mentioned)... of course all of them have some disadvantages (but as we saw also a on-CPU rule engine has disadvantages, namely the speed drop !).