Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Apr 2012 14:40:38 -0500
From: "jfoug" <>
To: <>
Subject: RE: MSCash2 formats reliability & usability

>From: Solar Designer []
>Jim, magnum, Lukas, Sayantan -
>We have three JtR formats for MSCash2: CPU, CUDA, OpenCL.
>The CPU one supports many different representations of MSCash2 hashes
>and has many test vectors of different form ($DCC2$ prefix present vs.
>not, iteration count included vs. not, username included vs. separate).
>This is great, although the format's support for variable iteration
>counts is probably unneeded (there are no non-10240 MSCash2 hashes in
>the wild, as far as I'm aware).  However, I think with all this
>complexity the format is also more prone to bugs than it has to be.
>For example, with this combination of hashes in the input file:
>John does not recognize the different salts (should be 3 different):

I have tightened up prepare in mscash1 and mscash2.

>user@...l:~/john/magnum-jumbo/run$ ./john pw-bug -fo=mscash2 Loaded 7
>password hashes with no different salts (M$ Cache Hash 2 (DCC2) [SSE2i

They were being loaded totally wrong.  The string being loaded for the
first one, was:


Thus, in that form, ALL were getting the salt of ? as the salt.

>I guess there's a bug in prepare(), get_salt() or/and SALT_SIZE.  By the
>way, it is weird how SALT_SIZE is defined as 11*4, but is actually put
>into the struct as SALT_SIZE+4.  

Because I 'stole' the first 4 bytes (array of 2 2 byte values), to store the

iteration count, and the salt len, so they would be 'ready' to be used and 
not have to be computed over and over again.  I simply left the salt 'junk' 
alone, and bumped up the size in bytes of the salt in the format structure
by 4.
Looking at it now, the SALT_LEN #define is only used within setting the
struct, so I have simply modified the #define.

>Assuming that this is the correct value
>to use, we should specify SALT_SIZE as (11*4+4) right away.
>Another issue is that strings of the above form are somehow also
>recognized as "mscash".  I guess this has to do with
>mscash1_fmt_plug.c's prepare() being too willing to turn anything into
>what its valid() would recognize.  It should probably perform some
>validation first.

Fixed in patch.  It 'only' appends the M$ (or $DCC2$1024# for cash2),
IF the field 1 is 32 byte hex number (i.e. raw).  So yes, it did get
some added validation.

Download attachment "jumbo_unstable_mscash_1_2_perpare_fixes-01.diff" of type "application/octet-stream" (2956 bytes)

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.