it's not directly supported, mainly because the combination of 2 dicts can turn out to be huge (combining hundred of thousands words with each other - or more - gives a huge and sometimes too huge combined list, it grows exponentially with the size of the dictionaries) and combining this even with rules makes the size even huger, e.g. k * n * m (where k is the number of rules, n the number of words in the left dict and m the number of rules in the right dict).
So it's important to note these facts:
1. the hash type is important to determine if it is feasible
2. the size of the dictionaries is important to determine if it is feasible (also the number of rules shouldn't be too huge, as "k" in the formula above is also a determining factor)
3. the type of rules determine if workarounds to this limitation are possible:
4. you could pre-compute one new dict and combine it with the second one
for #4 you could do:
Code:
hashcat --stdout -r my.rules dict1.txt > dict1_mod.txt
hashcat -m 0 -a 1 -w 3 hash.txt dict1_mod.txt dict2.txt
it depends of course on the rules you want to run if this is possible and which dictionary needs to be modified (e.g. if you only want to append, prepend or put in the middle of the "2 words" some numbers etc)
an alternative to this (for instance if you need to use rules that effect the whole combined password, not just append/prepend at one side etc):
Code:
combinator dict1.txt dict2.txt | hashcat -m 0 -a 0 -w 3 -r my.rules hash.txt
instead of combinator or combinator.bin from hashcat-utils (see
https://hashcat.net/wiki/doku.php?id=has...combinator) you could also use --stdout:
Code:
hashcat --stdout -a 1 dict1.txt dict2.txt | hashcat -m 0 -a 0 -w 3 -r my.rules hash.txt
in general, combinator would load up and run faster, but with huge amount of rules etc there won't be much difference (disk I/O hopefully shouldn't be the bottleneck)