[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 18 Sep 2015 04:01:56 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: "struct db_password" allocation
On Fri, Sep 18, 2015 at 12:13:42AM +0200, magnum wrote:
> On 2015-09-17 23:59, Solar Designer wrote:
> >On Thu, Sep 17, 2015 at 11:04:54PM +0200, magnum wrote:
> >>It's main use (or at least the reason Jim implemented it) is to get
> >>BSSID printed/logged when cracking WPA-PSK. In that case, the ESSID is
> >>the "login" and sometimes there are many same ESSID so we need to see
> >>the BSSID as well (but we do not want it used by Single mode so it can't
> >>be included in login). There might be other uses too. I'll look into
> >>that double string idea!
> >
> >Oh, I didn't realize this is controlled with ShowUIDinCracks, and is
> >disabled by default. If so, we should simply make the allocation for
> >the uid pointer conditional upon that setting. And no need for the
> >double string then.
>
> I don't quite get those allocs, could you fix that please?
Patch attached.
This also avoids allocating the "source" pointer when possible, which it
is when running with --save-memory=1 (or higher) and the format provides
source(). In that case, the binary ends up being allocated with the
very next call to mem_alloc_tiny(), which most likely places it right
into where the "source" pointer would have been. Previously, we already
tried to put the binary into the unused "source" pointer, but only if
it'd fit in the pointer size - now we do an equivalent of this for
larger binaries as well (but only at --save-memory=1 or higher). When
this "source" reuse happens, the binary pointer ends up pointing to
right after itself, so chances are very good that the actual binary is
in the same cache line with the binary pointer.
I've also adjusted the documentation to advertise --save-memory=1 as
potentially speeding things up.
I'll get these changes into core (except for the "uid" stuff) after some
more testing in jumbo.
--save-memory=1 on the 29M testcase:
real 0m41.366s
user 2m54.951s
sys 0m13.279s
Alexander
View attachment "john-loader-pw_size.diff" of type "text/plain" (7235 bytes)
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.
