[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Jun 2011 11:19:32 +0200
From: Jean-Michel <jtr@...izoku.org>
To: john-users@...ts.openwall.com
Subject: Re: Issues with gen_md5 new linking method
I applied the patch and everything is working properly with md5_gen(6). The
database loads properly without any error.
Counterpart is that md5_gen(15) and md5_gen(16) are failing now (as well as
a custom algorithm I put in my john.conf file).
Seems to be linked to the "username" functionnality.
--
Jean-Michel
2011/6/6 JFoug <jfoug@....net>
> The problem here, is in load salt (the part where I actually process OUT
> $$2, $$U, $$Fx, which is the salt2, the user id, and the field items). The
> logic was being triggering on ANY $$ pair. It would not have mattered if it
> was first, or last. A 2 byte $$ was enough to trigger the logic. If the
> following value was not a 2, an U a Fx (with x from 0 to 9), then the
> program would exit.
>
> I have made changes, so that the code will ONLY perform this logic if the
> $$ matches one of the patterns ($$2, $$U, $$Fx). So, with the included
> patch (made against jumbo-5, so you will have to roll back the prior patch),
> it shoudl work through the problems you see.
>
> NOTE that if you have any found hashes that have the salt of $$2 or $$U,
> then those simply will not work any more, sorry. I 'may' be able to work
> around that issue also, but it may be a larger change, than this simple
> patch here. However, hopefully, this will get you by until 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.
