just look it up here: https://hashcat.net/wiki/doku.php?id=rule_based_attack
every rule that shortens the password, especially the "Truncate" rules "[" and "]" are able to generate passwords with "too short" length.
i.e. every rule that removes more than it adds for instance
btw: you could also use stdin/pipe (hashcat --stdout -r rule dict.txt | hashcat -a 0 -m 2500 a.hccapx) or the -S (upper-case S) to get rid of every password candidate that doesn't fit the min. password length. The reason that this is not done when using other/normal commands (without pipe/-S) is for performance reasons, i.e. the kernel doesn't know the length before it is actually computed and (due to performance reasons) there is no further interaction between host and GPU/kernel when the GPU-based rule engine generates "too short" password candidates. Applying the rules is performed within the fast kernels too (except if you use -S) and therefore you can't easily reject them afterwards and pre-computing everything at the start could also be really slow depending on your dict/ruleset.
every rule that shortens the password, especially the "Truncate" rules "[" and "]" are able to generate passwords with "too short" length.
Code:
] ] $s
] ] $a
] ] ] $o
] ] ] $y
]
] ]
] ] ]
] ] ] d
] ] D1 ]
'5 D3
'5 $1
+5 ] } } } } '4
} } } } '4
} } } } } '5
*04 +0 '4
*05 O03 d '3 p1
O14 d p2 '6
Z4 '8 O42
Z5 *75 '5 { O02
f *A5 '8 O14
p2 '7 p1 O58
# .... (etc etc)i.e. every rule that removes more than it adds for instance
btw: you could also use stdin/pipe (hashcat --stdout -r rule dict.txt | hashcat -a 0 -m 2500 a.hccapx) or the -S (upper-case S) to get rid of every password candidate that doesn't fit the min. password length. The reason that this is not done when using other/normal commands (without pipe/-S) is for performance reasons, i.e. the kernel doesn't know the length before it is actually computed and (due to performance reasons) there is no further interaction between host and GPU/kernel when the GPU-based rule engine generates "too short" password candidates. Applying the rules is performed within the fast kernels too (except if you use -S) and therefore you can't easily reject them afterwards and pre-computing everything at the start could also be really slow depending on your dict/ruleset.