Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <A0E4F460-C466-4044-8E42-1D342831D324@gmail.com>
Date: Mon, 21 Sep 2015 08:54:08 -0700
From: Fred Wang <waffle.contest@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Judy array


On Sep 21, 2015, at 6:38 AM, Solar Designer <solar@...nwall.com> wrote:

> On Mon, Sep 21, 2015 at 06:18:34AM -0700, Fred Wang wrote:
>> Here go (you know you can run mdxfind too - I won't be offended :-)
>> 
>> https://www.sendspace.com/file/v04opu
> 
> Thanks.  I am still looking into the crack count discrepancy, but it's
> immediately apparent that MDXfind misreports many cracked passwords, in
> one of two ways: some are truncated, and some are unnecessarily reported
> in $HEX[] form with a NUL byte in them and garbage (leftover from
> another candidate password?) after the NUL.
> 
> For example:
> 
> -000d76a73aba493c5bcc5c7c8528b568:1justice
> +000d76a73aba493c5bcc5c7c8528b568:1just
> 
> -00010a8932c665aa7cb49aa5899adbd4:klarence
> +00010a8932c665aa7cb49aa5899adbd4:$HEX[6b6c6172656e6365006265656b5f726f6e]
> 
> I've verified JtR's cracks (the "-" lines here) with "echo -n ... |
> md5sum", and they are correct.


Yes.  I have a bug.  For only MD5, I was not setting the length correctly for passwords which did not have rules applied.  I had special-cased the rule application for ^md5$, and during that, neglected to set up the "default" case (no rules).  This caused MDXfind to output the solved hash, but not the solved plaintext correctly, if the input word was found in the hashes without rules.

MD5x01 000d76a73aba493c5bcc5c7c8528b568:1justice

Thank you for finding that!



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.