Well i guess the idea about rejecting password candidates that are too short was improving performance. As long as you are not using rules this makes perfectly sense.
When i initially ran into the same problem, the first workaround was to apply a rule which adds XXXXX to all passwords and use --stdout to pipe the longer candidates into another hashcat, where XXXXX is removed again and other rules being applied. To achieve this i initially wanted to alter all rules for the second part by using a short bashscript that would add the [[[[[ to every line. Since that was not a very clean approach, atom came up with the -j rule together with the "pre.rule" and that perfectly works!
So this is how this solution came up. And yeah maybe it would be an idea to have a command line flag to turn off the "early password length rejection" thing. On the other hand, -j works well, too *IF* you know about it.
When i initially ran into the same problem, the first workaround was to apply a rule which adds XXXXX to all passwords and use --stdout to pipe the longer candidates into another hashcat, where XXXXX is removed again and other rules being applied. To achieve this i initially wanted to alter all rules for the second part by using a short bashscript that would add the [[[[[ to every line. Since that was not a very clean approach, atom came up with the -j rule together with the "pre.rule" and that perfectly works!
So this is how this solution came up. And yeah maybe it would be an idea to have a command line flag to turn off the "early password length rejection" thing. On the other hand, -j works well, too *IF* you know about it.