Date: Thu, 12 Apr 2012 14:40:38 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: RE: MSCash2 formats reliability & usability >From: Solar Designer [mailto:solar@...nwall.com] > >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: > >$DCC2$Joe#e09b38f84ab0be586b730baf61781e30 >$DCC2$test#a86012faf7d88d1fc037a69764a92cac >$DCC2$administrator#a150f71752b5d605ef0b2a1e98945611 >$DCC2$administrator#c14eb8279e4233ec14e9d393637b65e2 >$DCC2$administrator#8ce9c0279b4e6f226f52d559f9c2c5f3 >$DCC2$administrator#2fc788d09fad7e26a92d12356fa44bdf >$DCC2$administrator#6aa19842ffea11f0f0c89f8ca8d245bd > >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 >8x]) They were being loaded totally wrong. The string being loaded for the first one, was: $DCC2$10240#?#$dcc2$joe#e09b38f84ab0be586b730baf61781e30 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 format 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.