[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Jul 2012 06:18:29 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: XSHA_fmt_plug.c should support hashes in lower-case
Dhiru -
On Thu, Jul 05, 2012 at 03:57:27PM +0530, Dhiru Kholia wrote:
> I tried running john on hash
> "3e8ed8fc0c6ac6c17cb6efcbe43bf31e765f8f456b2a6500" but it wouldn't
> accept the hash. After doing echo
> 3e8ed8fc0c6ac6c17cb6efcbe43bf31e765f8f456b2a6500 | tr "a-z" "A-Z" >
> newhash, john happily cracks the newhash.
>
> Is this by design or is it a bug / limitation?
It is by design, for two reasons:
1. To have fewer false positives on this format's valid(). IIRC, these
hashes are stored as all-uppercase on OS X. Why is yours all-lowercase?
Where did you get it from and how?
2. Out of laziness, since we'd have to implement split() converting to
all-uppercase and set FMT_SPLIT_UNIFIES_CASE to support
non-all-uppercase hash encodings correctly.
Similarly, for XSHA512 we accept only all-lowercase, although in that
case the first reason above does not apply (the system does not store
these hashes as hex). Perhaps we actually need to do the split() and
FMT_SPLIT_UNIFIES_CASE thing for XSHA512. As to XSHA, I am not sure -
I'd like to hear your story first.
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.
Alexander
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.
