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: http://trac.aircrack-ng.org/svn/branch/a...k-ng-cuda/

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