hashcat Forum

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

In my opinion .......
[Image: FNn87RO.jpg]

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.

Quote:
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.

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

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

(09-07-2016, 09:37 PM)jodler303 Wrote: [ -> ]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 :^)

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

Decided to test what drummachina suggested :

[Image: AkyOrzr.png]

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

[Image: c7syl6p.png]

...

(╯°□°）╯︵ ┻━┻

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.

henpemaz

d2

henpemaz

jodler303

henpemaz

henpemaz

jodler303