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-.- <>
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

> 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 => /lib/ (0x00002b3b689a9000) => /lib/ (0x00002b3b68bb2000) => /lib/ (0x00002b3b68db8000) => /lib/ (0x00002b3b68fd0000) => /lib/ (0x00002b3b69322000)
        /lib64/ (0x00002b3b6878c000) => /lib/ (0x00002b3b6953d000) => /lib/ (0x00002b3b69741000) => /lib/ (0x00002b3b69946000)

To unsubscribe, e-mail 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