reject bug when using wordlist + rule attack on WPA/WPA2 hash

[hworm4]

the rule is :T0 $2 $0 $0 $0
the word is :kadem
the hccapx file: https://www.sendspace.com/file/diu7ll

NOTE: this WPA hash is my own network hash.

the password of the hash in the hccapx file is (Kadem2000) so hashcat should be able to recover it with provided rule + word attack but hashcat reject the word even so the password is longer than 8 chars (obviously)



when I re-write the rule to be only (T0) and the word (kadem2000) then it works and it recovers the password

so the problem obviously that hashcat checks the length of the word in the file and not the result password after applying the rules

this behavour happens even with older versions of hashcat like 5.0, 4.2.1, 3.6 where all have the same problem.


is this behavour normal? or is it a bug?
I'm comfused because this behavour seems to be exists in all hashcat versions.

[philsmd]

rules are applied on GPU for performance reasons (after the fact, after the rejection routine) and we can't really filter each and every combination correctly on GPU (syncing this would be very complex and make everything very slow).

there are 2 known workarounds (might be much slower than without them):
1. use -S
2. use a pipe: hashcat --stdout -r a.rule dict.txt | hashcat -a 0 -w 3 -m 2500 my.hccapx

[hworm4]

rules are applied on GPU for performance reasons (after the fact, after the rejection routine) and we can't really filter each and every combination correctly on GPU (syncing this would be very complex and make everything very slow).

there are 2 known workarounds (might be much slower than without them):
1. use -S
2. use a pipe: hashcat --stdout -r a.rule dict.txt | hashcat -a 0 -w 3 -m 2500 my.hccapx

Worked Thanx .