[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <op.x3ah7ofz3qx92w@mom-laptop>
Date: Wed, 12 Aug 2015 23:46:26 -0500
From: "jfoug@....net" <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: Lei's weekly report #15
On Wed, 12 Aug 2015 23:05:14 -0500, Lei Zhang <zhanglei.april@...il.com>
wrote:
> On Aug 13, 2015, at 11:05 AM, jfoug@....net wrote:
>>
>> On Wed, 12 Aug 2015 21:38:24 -0500, Lei Zhang
>> <zhanglei.april@...il.com> wrote:
>>
>>
>>> I got this error message:
>>>
>>> form=episerver_sha1 guesses: 1476 -show=1476 0:00:00:00
>>> DONE : Expected count(s) (1500) [!!!FAILED1!!!]
>>> .pot CHK:episerver_sha1 guesses: 1476 0:00:00:00 DONE
>>> [PASSED] (1476 val-pwd)
>>>
>>> form=episerver_sha256 guesses: 1476 -show=1476 0:00:00:00
>>> DONE : Expected count(s) (1500) [!!!FAILED1!!!]
>>> .pot CHK:episerver_sha256 guesses: 1476 0:00:00:00 DONE
>>> [PASSED] (1476 val-pwd)
>>>
>>> What does that mean?
>>
>> It 'may' be expected. There are some tests which we will have to add
>> specific multiple 'valid' number of passing tests. These are due to
>> some data within the test being longer passwords than certain builds
>> can handle.
>>
>> This also may mean that there are BUGS. If the code blindly inserts
>> data, and you do not have proper length settings, then you will get
>> longer passwords sent to your format, which can overwrite internal
>> buffers of the candidates around the one you are writing data to.
>>
>> So either way, we need to find out. If you run the ts with these
>> command switches:
>>
>> -v -v -v --stop it will print out a whole lot of stuff to screen, but
>> it will stop on the first error. It shows you the command used that
>> failed. So now, you can run that command by hand, then use the -show
>> and -show=left to find out what was found, and what was 'missed'. If
>> all of the missed data is long passwords, then we will need to adjust
>> the jtrts.dat file saying that 1476 is a 'correct' possibility for this
>> format. If the missed words vary, then again, it is likely that you
>> have not set the plaintext length properly, which would allow the very
>> long passwords (120's, 125's, 128's) scattered in the input dictionary
>> to smash your buffers. That is exactly why those longer passwords were
>> put in there, to help force problems like this, when a format is too
>> promiscuous allowing data that are longer than it can handle.
>
> Thanks for the tips.
>
> I found those 24 uncracked passwords are indeed the longest passwords,
> with a length of 25, while the SIMD build of episerver only support
> plaintext length of up to 19.
>
> So I guess the number 1476 will need to be put in jtrts.dat.
>
>
> Lei
$ ./count_finder.pl 25 19 1500 pw.dic
Found 1500 of length 25 (required 1556 total lines to do)
Found 1476 of length 19
I had to change the script to allow it to also look into pw.dic, but once
done, my counter script validates that if you can only handle 19 byte
words, but the file was originally built with 25 byte words, that your run
will only find 1476 of them. I can easily change the TS to fix this for
your update to the format.
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.
