Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 07 Nov 2014 00:17:40 +0100
From: magnum <>
Subject: Re: Re: phpass and $dynamic_17$

You did not mention your work in the "alias" experimental branch (stale 
right now but could be updated easy I think). I'm not sure how hard it 
would be to solve the last issues and finish it, but that would solve a 
bunch of problem like this.


On 2014-11-06 15:25, jfoug wrote:
> 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
> "phpass"
> 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
> "dynamic_17"
> 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.