[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140426003906.GA18755@openwall.com>
Date: Sat, 26 Apr 2014 04:39:06 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Many Problem's + Many Try's and no Soultion
On Mon, Apr 21, 2014 at 09:19:15PM +0000, wyss-adrian@...onet.ch wrote:
> i have still truble with my very long password. (mail from Dezember 2013)
> i tried a lot.
I've read your message, and frankly it looks like you're doing some
pretty ridiculous stuff. No wonder you're having no luck. Specifically:
> i tried to make a combo with incremental and external
This is a viable approach and one I could recommend, but what you're
actually doing looks weird:
> [List.External:bla]
> void filter()
> {
> word[8] = 'Z';
> word[9] = 'B';
> word[10] = ':';
> word[11] = 'n';
> word[12] = 'G';
> word[14] = '4';
> word[15] = '#';
> word[16] = '5';
> word[17] = '3';
> word[18] = 'V';
> word[19] = '8';
> word[20] = 0;
> }
This overwrites characters in positions 9 to 20, skipping the character
in position 14 (leaving it as-is). It also sets the total length to 20
(that's OK).
> [Incremental:bla]
> File = SJOHN/all.chr (or ascii.chr)
> MinLen = 14
> MaxLen = 14
> CharCount = 95
This makes JtR try different 14-character strings. When you combine it
with the external mode above, you have the external mode replace
characters in positions 9 to 13 with its own constants. You're wasting
most of your performance right there, on testing duplicate candidate
passwords. First, incremental mode puts _different_ characters in those
5 positions, but then you replace them with constant characters with
your external mode. Why?! You're slowing things down by some orders of
magnitude here.
If you know the characters in those positions reliably, then you must
exclude them from incremental mode's range. Keep it at MinLen = 8 and
MaxLen = 8. If you nevertheless need to alter the character in position
14 (you don't know that one reliably, despite of knowing reliably the
characters in positions 9 to 13, and 15 to 20), then I'm afraid it'd be
best for you to run multiple instances of JtR, each one configured to
try a different likely character for that position. If there are more
than a handful of likely possible characters per position, then you're
probably out of luck anyway - although this depends on hash type (you
had probably mentioned which it was, but I don't recall).
> i tried to work together with crunch.
> i tried ./crunch 20 20 -f mycharset.lst -u | john mypasswordfile
>
> both programms run, but crunch does everything in /dev/null
> and john tries normaly all 3 modes
Of course, since you never told John to make use of whatever you're
piping to it on stdin. You'd want to use the --stdin option. But this
whole approach is no good for what you're doing. Your keyspace is too
large, so you need interrupt/restore.
> my last problem, and i think this is my bigest
>
> i have an
> HP ProLiant 380 G5 Server with
> 2x Intel Xeon Quad Core @ 2.3 GHz and 20 GB RAM
>
> and only 143.8 crack's per second
What hash type? Are you using --fork? Please show an excerpt of output
from JtR (at least the "Loaded ..." line and a status line).
You mention you had posted about this in December 2013 - can you please
find your posting in the list archives and include its URL?
Alexander
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.
