[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120713002342.L0G6M.544369.imail@eastrmwml302>
Date: Fri, 13 Jul 2012 0:23:42 -0400
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>
Subject: Re: XSHA_fmt_plug.c should support hashes in lower-case
---- Solar Designer <solar@...nwall.com> wrote:
> If in some other formats you support hex-encoded hashes without the
> all-lowercase or all-uppercase restriction and you don't have split()
> unify the case or/and you don't have the flag set, that's a bug, which
> may result in misbehavior of the loader and especially of --show when
> differently-looking instances of the same hash are present.
With the above description of the how/why of the FMT_SPLIT_UNIFIES_CASE flag (and processing within split), it becomes obvious that the dynamic format (and likely all of the 'thin' formats) suffer from this bug.
However, (and this is WHY the prepare function was created), there is no way within the existing JtR structure to fix this problem. That is due to the dynamic format behaving like an object oriented polymorphic class, however, the split method does not pass in a this pointer. The few initial functions that are called before init, do not know WHAT the format will look like, unless they get the format pointer given to them. I changed valid, and init a while back, and added the prepare function. At that time, I was not aware the split function also behaved this way.
However, i do think I can 'work' around this issue. When I set the FMT_SPLIT_UNIFIES_CASE, which can only be set if none of these bits are used in the setup flags of the format: MGF_INPBASE64|MGF_INPBASE64_4x6|MGF_INPBASE64a. I will simply make 2 split functions, one is split_UC and the other is split. Then when I setup the format, and set the FMT_SPLIT_UNIFIES_CASE flag, I can check the split method pointer, and if it pointing to dynamic.split, I will change that to dynamic.split_UC. This will allow JtR to call the proper case preserving split for base-64 formats, and will also allow a 'thin' format to overload the split method if it requires it (several do). However, these thin formats will need to handle case unification if they are base-16 formats.
Again, I probably should have fixed split when I added the format pointer to the other 'static' functions (i.e. functions called before the init() constructor). But I do think this work around will get things working properly.
Can the split function modify the buffer that is passed in, or should it copy to it's own static buffer?
Jim.
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.
