[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Jan 2013 09:31:10 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Speeding up WPAPSK, by leveraging salt shortcomings
On 30 Jan, 2013, at 6:04 , jfoug <jfoug@....net> wrote:
> 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!).
>
> Great point(s). I will add ssid to user field. I am not quite sure where to
> put the bssid.
It should go to the uid field (IIRC this is not a numeric-only field as one might think) because then you could also use the --user option to pick a certain BSSID to attack from a larger file.
> Also, is there some field that would show up on a -show or
> other way.
For this, the BSSID would be better put in the login field but that would seriously hurt Single mode so this is out of question. We could add a john.conf option ShowUIDinCracks = Bool, that when set will add the uid to the crack output. So instead of the normal real-time crack output:
password123 (Administrator)
sesame (root)
Induction (netgear)
We'll get this:
password123 (Administrator:500)
sesame (root:0)
Induction (netgear:31-33-7b-ab-e5-00)
...or something like that (for this output, using dashes is better than not when storing BSSID). Something similar could be done to --show using the same config option.
> 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.
Probably. RAR salt is exactly like this one, although I have only seen same-salts when batch-creating test files so it is probably not happening IRL. I presume the salt is derived from timestamp. That code is not public.
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.
