Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Nov 2014 08:25:31 -0600
From: "jfoug" <>
To: <>
Subject: RE: Re: phpass and $dynamic_17$

This is by design.  I am not 100% sure how to proceed.  The thin formats
were generated to convert specific hashes into a dynamic type, for the real
workhorse of dynamic to do the work.  That being the case, they handle and
know about their native types, and the dynamic types.    Now, the inverse is
NOT the case.  If it was, then there would be no need to have these thin
formats, BUT there would need to be huge changes made in dyna for most of
the core exposed format functions (valid, prepare, split, salt, binary,
etc).   Each time there is an existing hash that 'could' be done by dynamic,
we would have to make many ugly changes to these functions, so that dyna
would be able to handle this prior unhandled format.

Now, about the only way I could see to handle situations like this, is to
disable the dyna format, IF there is a thin format.  But this in of itself
is likely to be hugely fraught with problems.  Dyna/thin is NOT the only
case of problems like this. ANY time there are multiple possible formats
that can handle hashes (and there are MANY instances of this in JtR), we run
into this situation.

From: Aleksey Cherepanov [] On Behalf Of
Aleksey Cherepanov

On Tue, Nov 04, 2014 at 04:43:00PM +0300, Aleksey Cherepanov wrote:
> When I don't specify --format= , john loads $P$ as phpass and 
> $dynamic_17$ as dynamic_17 but for dynamic_17, it shows that it is 
> possible to load the hashes as phpass while it does not show similar 
> option for phpass.
> With --format=phpass, both $P$ and $dynamic_17$ files are loaded the 
> same way.
> With --format=dynamic_17, only $dynamic_17$ is loaded, $P$ could not 
> be loaded this way. It explains why john does not propose options for 
> $P$.

There is a minor inconvenience with it: when file has both $P$ and
$dynamic_17$, order of the hashes affects john's automatic decision about
format of hashes.

When $dynamic_17$ is before $P$ (2 $dynamic_17$ then $H$ and $P$):

Warning: detected hash type "dynamic_17", but the string is also recognized
as "phpass"
Use the "--format=phpass" option to force loading these as that type instead
Warning: only loading hashes of type "dynamic_17", but also saw type
Use the "--format=phpass" option to force loading hashes of that type
instead Loaded 2 password hashes with 2 different salts (dynamic_17 [phpass
($P$ or $H$) 32/64 1x2  (MD5_body)])

In this case, --format=phpass is needed to load all hashes.

When $P$ goes first ($H$, $P$, 2 $dynamic_17$):

Loaded 4 password hashes with 2 different salts (phpass [phpass ($P$ or $H$)
32/64 1x2  (MD5_body)])

Also I'd expect for this case
Warning: detected hash type "phpass", but the string is also recognized as

I guess it would be much slower to check everything. So a separate option
may be used. There may be a whole mode when john does not perform cracking
at all but shows detailed information about hashes with possibilities for
each hash separately.

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.