Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 May 2007 15:16:35 +0000 (UTC)
From:  -.-PhanTom-.- <phantom_otw@...oo.com>
To: john-users@...ts.openwall.com
Subject:  Re: Potfile size limitation?

Solar Designer <solar@...> writes:

> On Thu, May 10, 2007 at 07:02:55AM +0000, -. -PhanTom-. - wrote:
> > (gdb) bt
> > #0  0x61016525 in stack_info::walk ()
> >    from /home/-.-PhanTom-.-/john-1.7.2/run/cygwin1.dll
> > #1  0x7c859f4c in OutputDebugStringA ()
> >    from /cygdrive/c/WINDOWS/system32/kernel32.dll
> > #2  0x40010006 in ?? ()
> > #3  0x00000000 in ?? ()
> 
> Well, this is not useful.  It appears that gdb traps the fault that
> occurs during Cygwin's backtrace dump rather than the one in John
> itself.  Additionally, it appears that this fault occurs in a callback
> from Windows APIs, which were compiled without frame pointers, so we do
> not get a complete backtrace back into John.

Ok, so is there any more I can do in this regard?

> > $ wc -l john.pot
> > 21100879 john.pot
> 
> OK, I went ahead and created a fake 688 MB john.pot with 33.5 million
> entries (mostly duplicates, which could have affected the results).
> Then I ran "john --show passwd" on a tiny password file for which there
> were entries in john.pot.  I've noticed the "john" process take up to
> 1.5 GB of memory (watching it in "top"), then it produced the expected
> output and terminated normally.  As expected, no crash.  This is on
> Linux/x86-64 (Owl-current).  I might try with a 32-bit build and with a
> large john.pot with no duplicate entries later, but I don't expect to be
> able to reproduce the problem in this way.

So this issue seems to be related to windows/cygwin only. 
Atleast that narrows it down a bit :)

Similar to what I experienced on my Ubuntu machine.
I copied the john.pot over, and did a show. 
JTR used up 96-98% of RAM during the show (machine has 1 Gb)
So maybe there is room for improving the memory usage during the show
procedure? Or is it as good as it can be? 


> > > > Tried to compile 1.7.2 under ubuntu-7.04-desktop-amd64 - ...
> ...
> > However, when I compile "linux-x86-64" and test it, I don't get SSE2 - 
> > Only [64/64 BS] and a rather poor performance compared to [128/128 BS SSE2]
> > 
> > If I try to compile "linux-x86-sse2" I get errors:
> > "make: *** No rule to make target 'linux-x86-sse2'. Stop"
> > 
> > libc6-dev is already installed. Trying to install libc6-amd64 I get an error
> > about wrong architecture i386 ....
> 
> This tells me several things:
> 
> 1. You're using a version of John older than 1.7.2 - why?  SSE2 was
> added to the "linux-x86-64" target in 1.7.2.

No, I am using ver 1.7.2 - hence my confusion about the reported "make"
being used when compiling "linux-x86-64" - [64/64 BS] instead of 
[128/128 BS SSE2]....

"me@...desktop:~/john-1.7.2/run$ ./john
John the Ripper password cracker, version 1.7.2
Copyright (c) 1996-2006 by Solar Designer and others
Homepage: http://www.openwall.com/john/"

 
> 2. The "linux-x86-sse2" target would be wrong for x86-64 (it shouldn't
> work, unless your distribution is for 32-bit x86, which it might be).
> The reason it's missing, though, is that you're using an older version
> of John.

Ah yeah, I got do focused on the SSE2 thing, because I did not get that with
"linux-x86-64" - so was blind to the apcence of "64" in this make type...
 
> 3. Your Linux distribution might be for 32-bit x86, not x86-64.  What
> does "uname -m" say?  What kind of addresses does "ldd /bin/ls" print?
> 

"uname -m" -> x86_64
""ldd /bin/ls":
me@...desktop:~/john-1.7.2/run$ ldd /bin/ls
        librt.so.1 => /lib/librt.so.1 (0x00002b3b689a9000)
        libacl.so.1 => /lib/libacl.so.1 (0x00002b3b68bb2000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x00002b3b68db8000)
        libc.so.6 => /lib/libc.so.6 (0x00002b3b68fd0000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00002b3b69322000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b3b6878c000)
        libattr.so.1 => /lib/libattr.so.1 (0x00002b3b6953d000)
        libdl.so.2 => /lib/libdl.so.2 (0x00002b3b69741000)
        libsepol.so.1 => /lib/libsepol.so.1 (0x00002b3b69946000)
        
Regards


-- 
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ