Hashcat 3.30 problems

[r9290xocl]

Hi, 

I have a WPA2 handshake (hccap file) which I am doing tests on and I know the passphrase in advance, as I set it myself

There is clearly something wrong, and I am trying to figure out where the problem is. 

System: GTX 970M with an i7 6700HQ, Hashcat 3.30

Let's assume the passphrase for that handshake is simply: Goldfreak123

When put that same passphrase in a custom.txt dictionary file, hashcat cracks it without issues.   

However my goal is testing the rules functionality of hashcat. So I changed the passphrase in the custom.txt dictionary file to Goldfreak, and created a rule file (temprule.txt) with one entry as follow: $1 $2 $3 

which will append 123 at the end of every passphrase. 

I know the rule works because this command works: 
hashcat64.exe -r temprule.txt --stdout custom.txt 

The output is Goldfreak123 as expected. 

However, the problem is that the rule-based attack itself does not work: 

hashcat64.exe -m 2500 handshake.hccap -r D:\rules\temprule.txt D:\custom.txt

The wordlist or mask you are using is too small.
Therefore, hashcat is unable to utilize the full parallelization power of your device(s).
The cracking speed will drop.
Workaround: https://hashcat.net/wiki/doku.php?id=fre...full_speed

INFO: approaching final keyspace, workload adjusted

Session..........: hashcat
Status...........: Exhausted
Hash.Type........: WPA/WPA2
Hash.Target......: TestSSID (MAC_hidden <-> MAC_hiden)
Time.Started.....: Wed Feb 22 13:39:21 2017 (0 secs)
Time.Estimated...: Wed Feb 22 13:39:21 2017 (0 secs)
Input.Base.......: File (D:\custom.txt)
Input.Mod........: Rules (D:\rules\temprule.txt)
Input.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:        0 H/s (0.00ms)
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 1/1 (100.00%)
Rejected.........: 1/1 (100.00%)
Restore.Point....: 1/1 (100.00%)
Candidates.#1....: [Copying]
HWMon.Dev.#1.....: Temp: 47c Util: 99% Core:1037Mhz Mem:2505Mhz Lanes:16

Started: Wed Feb 22 13:39:18 2017
Stopped: Wed Feb 22 13:39:22 2017


Any ideas why the Rule attack is not working? I did delete the previous potfile.

[r9290xocl]

My issue is similar to this thread, but with hashcat and CUDA in my case:

https://hashcat.net/forum/thread-4468.html

[rico]

I don't know if this is the same issue as reported in that 2015 link but I do know that hashcat v3.30 uses a new format .hccapx file now instead: https://hashcat.net/forum/thread-6273.html

You should run hashcat-utils new cap2hccapx tool on your .cap file and try cracking that .hccapx file instead.

[atom]

It's none of the above cases. The problem is that the user has an rejected input:

Rejected.........: 1/1 (100.00%)

Which means that the wordlist contains a word < length 8. So everything works as designed I think.

[r9290xocl]

atom: ahhh. I think I know what is the issue, and I really think there is a logical flaw. Let me explain.

The "real" password in the .hccap file is 10 char long. The "real" password in the dic file is only 4 chars, and the rule in my rule file appends the remaining 6 chars. So the word in the wordlist is getting rejected (having only 4 chars) without even considering the additional extra characters that would eventually be appended (either at the beginning or at the end of the passphrase)!

What hashcat should really do is base this decision on the final output of the rule file result, not on the passphrase in the dictionary file alone.

Here is an example: I know your SSID password has the word "loving" in it, but I am creating some special rule file to append 3 more numbers (or characters) to that dictionary word... At the end, I will satisfy the over 8 chars for WPA, but right now hashcat is prematurely rejecting the entry in the dictionary file. Do you agree?

[atom]

There's a solution for that. Just run hashcat in --stdout mode and pipe it to hashcat doing the cracking. Like this:

hashcat64.exe -r D:\rules\temprule.txt D:\custom.txt | hashcat64.exe -m 2500 handshake.hccap --status --status-timer 1

That works fine on windows, too.

[r9290xocl]

Thanks for your reply.

I think most people would agree that this is clearly a "workaround" rather than a solution. 99% of users would not know about this workaround, and would expect hashcat to work differently.

I strongly suggest to have hashcat reject passwords *only* after it goes through the rule file. This is the expected behavior, even if it means that hashcat would run slightly slower, at least it wont reject 50% of a password list and many rules when it does not have to just yet (as far as WPA or other hash functions)

It is scary to think that a hash can be cracked but hashcat is not finding it within its own password list and rule file.

[miccee]

Goldfreak has 9 characters, doesn't it?

[r9290xocl]

Goldfreak has 9 characters, doesn't it?

That was just an example. In reality, it was 4 chars in the dic file and the rule file will add the other 6 chars. However, hashcat right now would outright reject the 4 without even considering that there might be more chars added via the rule file. IMO it is not a sound approach.

[atom]

In the past, hashcat worked like you suggested. The problem is that such an on-cpu rule engine would be to slow to feed password candidates on the faster ones of the slow hash family (like md5crypt). I think the way it works is the most flexible one, so this behavior is intentional. Also, hashcat tells the user about it (rejected passwords).