[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 Jul 2015 14:37:30 +0200
From: Marek Wrzosek <marek.wrzosek@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Why does john display some cracked passwords twice?
W dniu 29.07.2015 o 10:20, Marek Wrzosek pisze:
> W dniu 28.07.2015 o 22:39, magnum pisze:
>> On 2015-07-28 18:49, Marek Wrzosek wrote:
>>> W dniu 28.07.2015 o 18:40, Marek Wrzosek pisze:
>>>> Here is some examples:
>>>> br4v0br4v0 (?)
>>>> br4v0br4v0 (?)
>>
>>>>
>>>> This happens very frequently with different modes (incremental,
>>>> wordlist, prince, markov, ...) while cracking raw-md5 with --fork
>>>> option. Sometimes it happens even three times:
>>>> Emmanuelf12 (?)
>>>> Teddyg17 (?)
>>>> Teddyg17 (?)
>>
>>> PS. Apparently they are cracked multiple times, because this occurs in a
>>> .pot file too.
>>> $dynamic_0$077a62e15d63c5a10ec58866c2b5202e:passopasso83
>>> $dynamic_0$077a62e15d63c5a10ec58866c2b5202e:passopasso83
>>>
>>> Maybe this would be helpful too:
>>> $ ./john --list=build-info
>>> Version: 1.8.0.6-jumbo-1-521-gb58aa25
>>> (...)
>>
>> You need to state what command you ran. It could be a bug (should be
>> fairly new bug if so), but it's likely due to eg. running -fork in some
>> non-efficient way.
>>
>> For example, if you ran wordlist + rules with fork, no two processes
>> will apply the same rule to the same word. But if one process read the
>> word "teddyg" and used a rule that applied "17", and another process
>> read the word "teddy" and a rule that applied "g17", they would both
>> crack the same "teddyg17" hash. If they do this within minutes the "pot
>> sync" feature will not have a chance to mitigate it. OTOH it can be
>> ignored (and it was much much worse before pot sync) as long as we know
>> this is the actual issue here.
>>
>> magnum
>>
> For now, I stuck, so I'll probably go back in time (remove some lines
> from pot file) and calmly I'll try to reproduce the problem.
> Most likely this is because of wordlist/loopback with rules and fork, an
> unfortunate coincidence that two or more threads are using two or more
> different but similar words and different rules that together cause the
> same output in the exact same moment that "pot sync" was unable to deal
> with them. That is a lot of coincidence for me ;-)
> It should happens from time to time. Isn't it too frequent then?
> I can easily remove duplicates by using uniq command, no harm done.
> BTW, I was using fork with wordlist+rules mainly because of this statement:
> "Warning: no OpenMP support for this hash type, consider --fork=4".
> Maybe it should be disabled for certain cases like above.
> Most probably it's EOT. Thanks for help, magnum.
>
> Best Regards
>
One more thing. How are the passwords from wordlist divided between
threads with fork? If wordlist is:
a
b
c
d
e
f
g
h
i
j
k
l
and there are 4 threads, then it'll be
a d g j
b e h k
c f i l
right? And then rules are applied and/or mask or regen or something else
in the future.
But there are other ways of dividing wordlist among threads, e.g.:
a b c d
e f g h
i j k l
Or even by shuffling them in rows (for 4 threads there are 24
permutations) because wordlist could be sorted by probability of
occurence. There is factorial of number of threads (or the value of fork
parameter) ways how to divide them between processes. Choosing a way for
current row could be done by using a simple PRNG (initialized by random
seed that could be easily saved in rec file). Even simple PRNG should
remove accidental periodicity of wordlist (Or am I missing something,
again?). For debugging purposes the seed could be chosen using command
line parameter.
--
Marek Wrzosek
marek.wrzosek@...il.com
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.
