+- 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: Hashcat 3.30 problems (/thread-6324.html)
Pages:
1
2
Hashcat 3.30 problems - r9290xocl - 02-22-2017
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=frequently_asked_questions#how_to_create_more_work_for_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.
RE: Hashcat 3.30 problems - r9290xocl - 02-22-2017
My issue is similar to this thread, but with hashcat and CUDA in my case:
https://hashcat.net/forum/thread-4468.html
RE: Hashcat 3.30 problems - rico - 02-22-2017
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.
RE: Hashcat 3.30 problems - atom - 02-23-2017
It's none of the above cases. The problem is that the user has an rejected input:
Quote:Rejected.........: 1/1 (100.00%)
Which means that the wordlist contains a word < length 8. So everything works as designed I think.
RE: Hashcat 3.30 problems - r9290xocl - 02-23-2017
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?
RE: Hashcat 3.30 problems - atom - 02-23-2017
There's a solution for that. Just run hashcat in --stdout mode and pipe it to hashcat doing the cracking. Like this:
Quote: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.
RE: Hashcat 3.30 problems - r9290xocl - 02-23-2017
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.
RE: Hashcat 3.30 problems - miccee - 02-23-2017
Goldfreak has 9 characters, doesn't it?
RE: Hashcat 3.30 problems - r9290xocl - 02-23-2017
(02-23-2017, 09:01 PM)miccee Wrote: 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.
RE: Hashcat 3.30 problems - atom - 02-24-2017
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).