cudaHashcat-plus64 on Debian fails when using a known password

[clamore2]

I wanted to try how well cudaHashcat plus did against aircrack, so I captured the WPA2-CCMP handshake of my own network and tried to crack it both with aircrack and cudaHashcat using the example.dict that comes with hashcat and adding my network password inside it.

Long story short, aircrack cracked it, but hashcat failed: it "Exhausted" the dictionary without recognizing the password.

My steps were:
airodump-ed a 4-way handshake between my phone and the router, wpaclean-ed it, used "aircrack <capfile> -J <hccapfile>" to generate the hccap file and launched

$ aircrack-ng -w /tmp/dic /tmp/hashcat.hccap

and

$ ./cudaHashcat-plus64.bin -m 2500 /tmp/hashcat.hccap /tmp/dic2

while the first succeded, the second resulted in:

Code:

cudaHashcat-plus v0.09 by atom starting...

Hashes: 1 total, 1 unique salts, 1 unique digests
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Rules: 1
Workload: 16 loops, 8 accel
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: GeForce GT 540M, 2047MB, 1344Mhz, 2MCU
Device #1: Kernel ./kernels/4318/m2500.sm_21.ptx

Scanned dictionary /tmp/dic2: 1210252 bytes, 129989 words, 129989 keyspace, starting attack...

                                            
Status.......: Exhausted
Input.Mode...: File (/tmp/dic2)
Hash.Target..: MyNetworkName (00:11:22:33:44:55 <-> 66:77:88:99:aa:bb)
Hash.Type....: WPA/WPA2
Time.Running.: 15 secs
Time.Left....: 0 secs
Time.Util....: 15995.6ms/21.7ms Real/CPU, 0.1% idle
Speed........:     4029 c/s Real,        0 c/s GPU
Recovered....: 0/1 Digests, 0/1 Salts
Progress.....: 129989/129989 (100.00%)
Rejected.....: 65543/129989 (50.42%)
HWMon.GPU.#1.: -1% Util, 53c Temp, -1% Fan

Started: Fri Sep 21 16:03:46 2012
Stopped: Fri Sep 21 16:04:03 2012

Any ideas about why this happened?

Thanks!

[M@LIK]

Your password must be 8 min 15 max in length.

[yiurunk]

I'm having the same exact issue as OP.

How is the key length the issue since it has an allowable key length up to 64 characters?

It's obviously working with different applications to find keys larger than 15 chars. So is it something else or am I missing something? Thanks for your help!

[undeath]

oclhashcat-plus does this for performance reasons. It is implemented that way and you can't change anything about it.

[yiurunk]

oclhashcat-plus does this for performance reasons. It is implemented that way and you can't change anything about it.

Ah well that explains it! ... and that sucks. So if I were to recompile with a longer space what are the drawbacks besides a perceived incredibly long calculation time?

Thanks for the quick reply undeath.

[atom]

Well not for WPA/WPA2 but for other algorithms. There has been a lot of talks on the max. length 15 restriction but still none of them convinced me to overcome with this limit and rewrite the base classes. Also it would require a lot more memory. My main argument is still that the chances to crack 15+ passwords is VERY unusual for whatever algorithm. Only if the passwords is really really bad and in this case you have it in your dictionary and can crack it with aircrack-ng.

[qweasd]

I would like to point out that there is a CUDA version of aircrack-ng: https://trac.aircrack-ng.org/svn/branch/a...k-ng-cuda/

i really doubt it's as fast as hashcat though.