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.