![]() |
Problems with WPA rejection of candidates - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Support (https://hashcat.net/forum/forum-3.html) +--- Forum: hashcat (https://hashcat.net/forum/forum-45.html) +--- Thread: Problems with WPA rejection of candidates (/thread-5846.html) |
Problems with WPA rejection of candidates - henpemaz - 09-07-2016 Hello, first time here. I'm having some issues with the WPA algorithm rejecting all my candidate passwords before applying any rules (that would make them valid >len8 candidates) I'm competing with my roommate, and we decided to start with 5 short passwords (8 characters), and so far he's ahead with python scripts to generate dictionaries + aircrack... Here is some code + output to demonstrate what is happening. You can see that the append rule produces 4 valid results out of 5. Yet hashcat seems to evaluate the candidates based on the lenght of the base word... I would expect it to reject 5 out of the 25 candidates, but it just goes ham. Code: C:\me\hackhim>echo 1234567| hashcat -r .\rules\append.rule --stdout Works like a charm for len>=8 base words, and I've tested it on my own handshakes, so I know it's working. Also, on the same bucket of problems, here is another error that I've found: (at least) On hashcat v3.10, rejection rules are not working on the 'slow algorithm' which is WPA, contrary to what is stated on the rule-based attack page... Proof : Code: C:\me\hackhim>echo ^<C > small.rule I managed to get a dirty workaround for these problems by piping hashcat into itself, which fells pretty dumb. And then I tried something more complex, a combination attack (which doesnt accept rules for god knows what reason), piped into my rule set, piped into the actual hash cracking. It didn't work, and I got presented with a pretty... well, see for yourself: Code: C:\me\hackhim>hashcat -a 1 --stdout -j c -k c guesses.dic guesses.dic | hashcat --stdout -r small.rule -r .\rules\append.rule | hashcat -m 2500 .\captures\catAll.hccap Sorry for the huge dump of complaints, it's just that all this is giving me a hard time in something that is already challenging... Thanks a bunch for any help :/ RE: Problems with WPA rejection of candidates - d2 - 09-07-2016 In my opinion ....... ![]()
Code: ERROR: C:\Program Files\hashcat-3.10/stdout.induct: Permission denied Just remove that file and start over. RE: Problems with WPA rejection of candidates - henpemaz - 09-07-2016 Quote:Oh, you're right ! Confusing, since according to the docs ALL the other rules that take a number expect it as 0-9 or A-Z. I'll try that in a moment. Quote: This file is nowhere to be found. Looks to me like a temporary sort of pipe/buffer used by hashcat and that thus limits it to one instance being piped to stdout. Thanks for the answer anyways RE: Problems with WPA rejection of candidates - jodler303 - 09-07-2016 https://hashcat.net/forum/thread-5744.html?highlight=pre.rule RE: Problems with WPA rejection of candidates - henpemaz - 09-08-2016 (09-07-2016, 09:37 PM)jodler303 Wrote: https://hashcat.net/forum/thread-5744.html?highlight=pre.rule It works ! Thanks a bunch ! Now it raises the weird question that is why the heck does this work... So, the inline rule takes precedence over length check, but normal rules don't... I don't care what atom says for this matter, it's not a feature if you have to take an extra step to fill your input with garbage just to get past a test that is in the wrong place. I think I can get around the problem I've found by now. There are only some minor questions left open, but these are more like suggestions for improvements...
Code: [/rant] Well, @jodler303, thanks again for your working workaround, and thanks @atom for that, and for hashcat, it's a great tool, even if there are still some points to improve :^) RE: Problems with WPA rejection of candidates - henpemaz - 09-08-2016 (Sorry for the double post, I can merge if that's an issue) Decided to test what drummachina suggested : ![]() So, a few points here:
With this, part of the issue comes back: Hashcat is not accepting rejection rules if those rules are given on -r rule files ![]() ... (╯°□°)╯︵ ┻━┻ RE: Problems with WPA rejection of candidates - jodler303 - 09-09-2016 Well i guess the idea about rejecting password candidates that are too short was improving performance. As long as you are not using rules this makes perfectly sense. When i initially ran into the same problem, the first workaround was to apply a rule which adds XXXXX to all passwords and use --stdout to pipe the longer candidates into another hashcat, where XXXXX is removed again and other rules being applied. To achieve this i initially wanted to alter all rules for the second part by using a short bashscript that would add the [[[[[ to every line. Since that was not a very clean approach, atom came up with the -j rule together with the "pre.rule" and that perfectly works! So this is how this solution came up. And yeah maybe it would be an idea to have a command line flag to turn off the "early password length rejection" thing. On the other hand, -j works well, too *IF* you know about it. |