Problems with WPA rejection of candidates

[henpemaz]

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
1234567
12345671
1234567123
12345672
123456712

C:\me\hackhim>echo 1234567| hashcat -r .\rules\append.rule -m 2500 .\captures\catAll.hccap
hashcat (v3.10) starting...

OpenCL Platform #1: Intel(R) Corporation
========================================
- Device #1: Intel(R) HD Graphics 4600, 407/1629 MB allocatable, 20MCU
- Device #2: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz, skipped

OpenCL Platform #2: NVIDIA Corporation
======================================
- Device #3: GeForce GTX 960M, 512/2048 MB allocatable, 5MCU
- Device #3: WARNING! Kernel exec timeout is not disabled, it might cause you errors of code 702
             See the wiki on how to disable it: https://hashcat.net/wiki/doku.php?id=timeout_patch

WARN: nvmlDeviceGetFanSpeed() 3 Not Supported

Hashes: 5 hashes; 5 unique digests, 5 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 5
Applicable Optimizers:
* Zero-Byte
* Slow-Hash-SIMD
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 75c

Starting attack in stdin mode...


Session.Name...: hashcat
Status.........: Exhausted
Rules.Type.....: File (.\rules\append.rule)
Input.Mode.....: Pipe
Hash.Target....: File (.\captures\catAll.hccap)
Hash.Type......: WPA/WPA2
Time.Started...: 0 secs
Speed.Dev.#1...:        0 H/s (0.00ms)
Speed.Dev.#3...:        0 H/s (0.00ms)
Speed.Dev.#*...:        0 H/s
Recovered......: 0/5 (0.00%) Digests, 0/5 (0.00%) Salts
Progress.......: 25
Rejected.......: 25

Started: Wed Sep 07 06:01:00 2016
Stopped: Wed Sep 07 06:01:07 2016

C:\me\hackhim>

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

C:\me\hackhim>type small.rule
<C

C:\me\hackhim>echo 12345678| hashcat -r .\small.rule -m 2500 .\captures\catAll.hccap
hashcat (v3.10) starting...

WARNING: Cannot convert rule for use on OpenCL device in file .\small.rule on line 1: <C


ERROR: No valid rules left


C:\me\hackhim>

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


ERROR: C:\Program Files\hashcat-3.10/stdout.induct: Permission denied

hashcat (v3.10) starting...

And then it exhausts without processing a single word...


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 :/

[d2]

In my opinion ....... 

• 2nd error block, according to docs '<N' expects decimal number, not 'C'. Try '<5' for your small.rule file
  
• 3rd error block:
  

Code:

ERROR: C:\Program Files\hashcat-3.10/stdout.induct: Permission denied

Just remove that file and start over.

[henpemaz]

• 2nd error block, according to docs '<N' expects decimal number, not 'C'. Try '<5' for your small.rule file
  

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.

• 3rd error block:
  

Code:

ERROR: C:\Program Files\hashcat-3.10/stdout.induct: Permission denied

Just remove that file and start over.

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

[jodler303]

https://hashcat.net/forum/thread-5744.ht...t=pre.rule

[henpemaz]

https://hashcat.net/forum/thread-5744.ht...t=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...

• As stated above, why the heck do inline rule takes precedence over length check, but normal rules do not ?
  
• Why, just WHY are > and < the ONLY rules that take a two-digit numeric input (10, 11, 12) for stuff above 9 ??? ALL other rules expect you to use A, B, C for, the doc would say, 11, 12, 13, but I presume it's wrong since how the fuck do you put in the 10 like that ? I know it's nicer this way but can't you just also accept the other way for CONSISTENCY ?
  
• Why do Combination attacks take no rules, forcing you to pipe it to another hashcat command and therefore not giving any information about completion percentage and stuff ? I know I can do these by hand, and I do already, but just why ?
  
• Piping 2 hashcats to --stdout to make a 3-hashcat workline gives me that weird error. Why, and how to avoid it, since some of the methods I want to use (say, combination) REQUIRE me to pipe ?! ?
  

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 :^)

[henpemaz]

(Sorry for the double post, I can merge if that's an issue)

Decided to test what drummachina suggested :



So, a few points here:

• I was right
  
• drummachina was wrong in correcting me
  
• the doc was also wrong, there is just one '*' missing there
  
• I take back  what I said about consistency, atom
  

With this, part of the issue comes back: Hashcat is not accepting rejection rules if those rules are given on -r rule files



...

(╯°□°）╯︵ ┻━┻

[jodler303]

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.