[<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.
