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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ