Bug - words get rejected
Hi all,

 I think I found a bug.
 I'm trying the WPA/WPA2 cracking, but unfortunately all the words that are less than 8 characters are getting rejected, since the minimum length of WPA passwords are 8 characters.
 The problem is that I'm trying with a rule based attack which adds characters to the original word, so the end result is 8 characteres long, but hashcat only checkes the original word.

word + rule: ^0^0^0^0 results in: "0000word" but still gets rejected.

Any idea?
I guess the only workaround is to pregenerate the wordlist with the extra characters, but it's not really a flexible way.

Not a bug, it's a feature! Really, you can use hashcat in --stdout mode and pipe it to another hashcat session in stdin mode. Then it will work. Something like this:

Quote:$ ./hashcat wordlist.txt -r rule.txt | ./hashcat -m 2500 mywpa.hccap -w 3
You are right. It works with pipe Smile Thank you.

Also the -w 3 option is very important: it gave +40% hash speed.
-w 4 gives +50%, but the PC gets a bit laggy. No problem if you want speed.
Just ran into the same issue and posted it on irc today. atom came up with a great solution for this:

1) echo [[[[[ > pre.rule  
2) hashcat <as usual> -j ^X^X^X^X^X -r pre.rule -r yournormalrule.rule 

the -j ^X^X^X^X^X will prepend every password candidate from the dictionary with "XXXXX" making it long enough to pass the limit of 8 as the minimum length, the first "pre.rule" will then remove the "XXXXX" again. Finally your "normal" rules will be applied.

Worked for me.
(08-17-2016, 05:42 PM)jodler303 Wrote: hashcat <as usual> -j ^X^X^X^X^X -r pre.rule -r yournormalrule.rule

Doesn't seem to work on Windows.

Pipe does, after you install a gigabyte worth of CL drivers. But estimation doesn't work with piped input.

EDIT: you need to escape this on Windows. -j ^^X^^X^^X^^X^^X