Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Jun 2011 03:51:56 +0200
From: Jean-Michel <>
Subject: Re: 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.


2011/6/6 JFoug <>

> 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" <>
> To: <>
> 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.