[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 29 Jan 2013 23:04:07 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Speeding up WPAPSK, by leveraging salt shortcomings
Great point(s). I will add ssid to user field. I am not quite sure where to
put the bssid. Also, is there some field that would show up on a -show or
other way.
I have made changes to wpask_fmt.c (very very simple). Added an int
(new_keys), and char buffer, last_ssid. Then there is an if in crypt_all,
which simply avoids calling the pbkdf2 code.
then at the bottom of crypt_all, new_keys is set to 0, and we memcpy into
last_ssid. Then I added a clear_keys that sets new_keys to 1.
To test, I grabbed 3 distinct hashes from my router, and made 5 extra
copies, changing 1 byte in each of these new 15, so that they can never be
cracked. I added my password to the input file, and out popped all three
'real' hashes. I ran it again using password.lst + rules and here are the
timings.
$ ./john jfoug.in -w=password.lst -rules -ses=xxx
Loaded 18 password hashes with 18 different salts (WPA-PSK PBKDF2-HMAC-SHA-1
[128/128 SSE2 4x])
Remaining 15 password hashes with 15 different salts
Note: minimum length forced to 8
guesses: 0 time: 0:00:01:16 72.34% (ETA: Tue Jan 29 22:45:01 2013) c/s:
8040 trying: Eclipse. - Excalibur.
guesses: 0 time: 0:00:01:54 DONE (Tue Jan 29 22:45:10 2013) c/s: 8068
trying: Xanthing - Notuseding
$ head -1 jfoug.in > jfoug1.in
$ ./john jfoug1.in -w=password.lst -rules -ses=xxx
Loaded 1 password hash (WPA-PSK PBKDF2-HMAC-SHA-1 [128/128 SSE2 4x])
Note: minimum length forced to 8
guesses: 0 time: 0:00:00:41 44.43% (ETA: Tue Jan 29 22:47:11 2013) c/s:
571 trying: AlohaAloha - AmourAmour
guesses: 0 time: 0:00:01:47 DONE (Tue Jan 29 22:47:26 2013) c/s: 573
trying: Xanthing - Notuseding
So in this test, we processed a single hash in 107s. We processed 15 hashes
with same SSID in 114s. So, the extra 14 hashes only cost 7s. Not bad ;)
Now, with this proof of concept, we need to figure out the easiest/best way
to properly load salts in SSID order for this format.
Also, I wonder if there are other formats that can be greatly reduced in
runtime by changing how the salts are being handled within JtR.
Jim.
From: magnum [mailto:john.magnum@...hmail.com]
>
>BTW, the *cap2john utility should put the essid in a login field. This way,
with just this one-line patch, you can take advantage of the same-essid
optimization by just attacking one essid at a time, using
>
>./john wpapsk.in -user:netgear
>
>Another really great advantage is that Single mode will permute essids into
candidates. That might prove very rewarding.
>
>Also, the utility should definitely fill in the bssid (mac address) in some
field. How else would you know *which* of the 110 "netgear" you cracked? As
we can't use colons, this must be in dash form (de-ad-ba-be-ca-fe) or
compressed (deadbabecafe) and could be put in the uid field or whatever (but
NOT a fields read by Single!).
>
>magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
