01-27-2021, 01:38 PM
other alternatives or things you could still test are using the multi-rule file feature (see https://hashcat.net/wiki/doku.php?id=rul...ulti-rules) where each rule from one rule file is combined with the other (can be even more than 2) rule files (hashcat -r first.rule -r second.rule ...)
or try the nice (and often underestimated and rarely used) generate rule feature with the -g option (can't be combined with -r , but you could already generate a mangled/modified/pre-computed password list with -r and --stdout or similar and afterwards combine it with -g 49999 or similar)
or completely different attacks (see https://hashcat.net/wiki/#core_attack_modes and https://hashcat.net/wiki/#other_attacks ) ; for instance adding some "common chars" (like in ?a charset) at the end or front of the password candidates (hybrid attack) etc.
I still think it makes sense to not just test only one single password (at the end there could still be the chance that the correct password is "quite different" from what you think it is) with many rules, but a lot of possible password candidates (could and probably should even contain many mangled/derived forms of the passwords you think are likely the right ones, or similar to the correct password) and mangle them further.... (similar approach that x34cha suggests above, just make sure that the original password is also within the list that will be mangled with "random" or a lot of rules and don't forget to use the ":" rules if you use the multi-rules feature).
or try the nice (and often underestimated and rarely used) generate rule feature with the -g option (can't be combined with -r , but you could already generate a mangled/modified/pre-computed password list with -r and --stdout or similar and afterwards combine it with -g 49999 or similar)
or completely different attacks (see https://hashcat.net/wiki/#core_attack_modes and https://hashcat.net/wiki/#other_attacks ) ; for instance adding some "common chars" (like in ?a charset) at the end or front of the password candidates (hybrid attack) etc.
I still think it makes sense to not just test only one single password (at the end there could still be the chance that the correct password is "quite different" from what you think it is) with many rules, but a lot of possible password candidates (could and probably should even contain many mangled/derived forms of the passwords you think are likely the right ones, or similar to the correct password) and mangle them further.... (similar approach that x34cha suggests above, just make sure that the original password is also within the list that will be mangled with "random" or a lot of rules and don't forget to use the ":" rules if you use the multi-rules feature).