[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101127012422.GC4903@openwall.com>
Date: Sat, 27 Nov 2010 04:24:22 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Cracking a known password shape
Brad,
On Tue, Nov 16, 2010 at 09:37:20PM -0500, Brad Tilley wrote:
> You can code an "enumeration program" to produce all possibilities of
> those sets writing every possibility to stdout. I placed an example with
> a test password file here: http://16s.us/16crack/examples/
>
> Next, use your enumeration program with JTR's --stdin feature:
>
> ./enumerate | john --stdin passwords.txt
>
> I tested this on a Debian Linux 5 machine and my test case did indeed
> find the password so I'm sure this works, but it may be less efficient
> than Alexander's method.
>
> Alexander, please correct me where I'm wrong.
You're correct, but I am puzzled as to why you would prefer to write a
separate program such as your eric.cpp (2 KB, 85 lines, requires a C++
compiler) as opposed to using JtR's external mode. The KnownEric mode I
had posted is 1.8 KB source, 82 lines, and it does not require anything
except for JtR itself. Only 29 lines (in the init() function) are
specific to Eric's requirements; the rest is unmodified KnownForce code.
(Both have some comments in the source code, which I included in the
sizes and line counts.)
Maybe your eric.cpp is easier for a non-programmer to modify. (I think
this should be better addressed by including a "mask mode" into JtR.)
JtR's KnownForce mode variations support interrupt and recovery (this
actually costs 15 lines of code in the mode definition itself, which you
have no equivalent of). This is not trivial to implement with two
programs where your external program does not know how many of the
passwords that it has output might not be fully processed yet (there are
several buffers involved). (There's a way around this, though.)
As to speed, neither is the fastest way to do it, but JtR's external
mode should be faster than having candidate passwords travel between
programs through the operating system. Either is fast enough when the
target hash or cipher is slow (such as with your test run). In this
case, any overhead is negligible anyway.
That said, I appreciate you posting this. Thanks!
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.
