[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 5 Jun 2011 21:37:28 -0500
From: "JFoug" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: Re: Issues with gen_md5 new linking method
It may be easier in the end to do that, but at this time, the way things
link in, is the linked format actually 'uses' the main format structure for
the specific format. Thus, I have to make some structual changes.
What I plan on doing, is for the linked formats, they no longer actually use
an existing format, but copy the format structure (and all associated
entries) to a newly allocated format structure. In that way, I can change
things like the flags for loading, etc. Or set a 'fixed' salt size, etc.
Right now, if you did that in a thin format, it would change the underlying
format also, and thus, may fail a self test. The thin formats are actually
truely tied to the underlying md5_gen format. I believe it will work better
to replicate a starting place format, and then make changes to it as need be
for a thin format. Most of the time, there will be no changes needed.
However, in this case, setting a fixed salt of 3 bytes, and setting a yet to
be created salt_as_base16 into the loader flags would have worked around the
problems.
I will use pass_gen to make up some $$x salted values, and see if I can
again work past these for now, and spend a little more time addressing the
salt issue and the 'linked' format issue in the next jumbo.
Jim.
----- Original Message -----
From: "Jean-Michel" <jtr@...izoku.org>
To: <john-users@...ts.openwall.com>
Sent: Sunday, June 05, 2011 8:51 PM
Subject: Re: [john-users] Issues with gen_md5 new linking method
> Well, I really have a silly database....
>
> Your patch nearly solved the problem. Except that I have entries with salt
> beginning with "$$" too !
> So the error still is "unknown salt string $$7".
>
> Isn't it "easier" to add a loader flag, like "MGF_SALT_BASE16", that
> simply
> tells the md5_gen loader to unhex the salt(s)/fields after parsing ?
> That was how the previous PHPS module was written (I mean with an
> hexencoded
> salt). Maybe it will be also useful to further formats and it may
> uncomplexify your salts/fields parser.
>
> But if you want to try other things, feel free to send me patches and I'll
> try them against my database ASAP. It's quite uge so I can't easily spot
> problematic entries to give them to you.
>
>
> --
> Jean-Michel
>
>
> 2011/6/6 JFoug <jfoug@....net>
>
>> I have gotten your .pot file.
>>
>> The problem stems from having the first character of the salt be a '$'
>> char. There is some 'magic' logic within the salt function, since md5_gen
>> has to handle a totally 'unknown' salt condition. There can be a salt, a
>> 2nd
>> salt, the user name, and up to 10 fields. The salt starts with a $s.
>> The
>> 2nd salt starts with $$2 the user id starts with $$U, then the fields
>> start with $$Fx where x is 0 to 9
>>
>> So, what I 'believe' the code does, is if the first char of the salt is a
>> '$', then the salt function, grabs the entire salt (including the leading
>> $). The logic behind this, was I was assuming that seeing the salt start
>> with $$ meant that there was a complex salt (which is broken apart
>> later),
>> such as $$Uuser$$F2field2 So, the pointer that a 'normal' salt would
>> copy
>> from is $Uuser$$F2field2, but the code is detecting the first $$ and
>> backing
>> up and getting the whole thing, in preparation to later rip out the user
>> ID,
>> and Field2 data.
>>
>> However, in this case, we have a simple salt, and the salt starts with a
>> '$' char. Thus, the code is returning $$xy for the salt value, instead
>> of
>> the proper $xy.
>>
>> I can make a simple fix to get this operating properly, and then put this
>> on my todo list.
>>
>> I have attached the patch here, since it is such a trivial patch. Please
>> let the list know if this resolves the problems you have seen. Also, if
>> there still are additional problems, then if you can get me a file
>> (offline
>> again) that demonstrates this, I will continue getting it fixed. I have
>> not
>> placed this patch on the wiki, and will wait to hear if this corrects
>> Jean-Michel's problem before I place it there.
>>
>> Jim.
>>
>> ----- Original Message ----- From: "Jean-Michel" <jtr@...izoku.org>
>> To: <john-users@...ts.openwall.com>
>>
>> Sent: Sunday, June 05, 2011 5:25 PM
>> Subject: [john-users] Issues with gen_md5 new linking method
>>
>>
>>
>> Hello,
>>>
>>> with the version 1.7.7 and the new jumbo patches, the method to link a
>>> format to a gen_md5() one has changed.
>>> For example, the old PHPS format now links to gen_md5(6) as a "thin"
>>> format.
>>> But with that, I can't load my database anymore because the salt used in
>>> this format as to be in "raw" format instead of base16.
>>> I have entries were the salt begins with "$" for example (or contains
>>> specials chars such as "\r"), and that totally messes the md5_gen
>>> parser.
>>>
>>> Is it already on the TODO-list to add a flag to allow the salt to be
>>> hex-encoded ?
>>> I haven't seen a simple way to do so just by modifing the thin module...
>>>
>>> Thanks.
>>>
>>>
>
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.
