[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7470db2bd4cc01fd01c89eef3dee3d77@smtp.hushmail.com>
Date: Thu, 09 Aug 2012 22:27:47 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: bleeding-jumbo and contest edition fail to recognize
cracked dynamic_21 hashes
Just do a patch for -fixes. I'm pretty sure git will sort it out. If
not, I'll give you a holler.
magnum
On 2012-08-09 22:23, jfoug wrote:
> I have found the issue here (I hope). Recently added, was writing hashes
> out in a salt-safe manner, within dynamic. This was done to work around some
> known issues, such as \n : $ NULL, or other naughty characters being
> contained within the salt field, causing JtR's string handling and field
> splitting functions to fail.
>
> Well, there were 2 places within loader which required changes. One was in
> load_pot_line() the other (which was not done), as in show_pot_line(). I am
> not sure why the 2 functions, but I had only added code to the
> load_pot_line.
>
> This also affects the j7 release candidate I have made some changes here
> also.
>
> I may need to talk to magnum offline a little, to figure out just how to
> push this out. It may be best if I make a patch for j7-rc, for jumbo, and
> for bleeding. Unfortunately, I think that all of these may have some
> collision issues, especially within the loader code, which is different
> between the versions.
>
> Jim.
>
>> From: jfoug [mailto:jfoug@....net]
>>
>> This was the $HEX$ fix (un-hex) which people reverted out, because it
>> was causing some problem with -show=left, or something like that. I
>> have not gotten back on this.
>>
>> Jim.
>>
>>> From: Frank Dittrich [mailto:frank_dittrich@...mail.com]
>>>
>>> I can reproduce this with 1.7.9.6-c5 and with bleeding-jumbo, but not
>>> with magnum-jumbo or john-1.7.9-jumbo-6-fixes.
>>>
>>> When I just run
>>>
>>> ./john hashes-4.dynamic_21.txt
>>>
>>> john starts cracking and soon cracks the first hash for ed.fox
>>> (password: edFox) in single mode.
>>>
>>> When I interrupt, and repeat the same command, john should find at
>>> least the last hash being cracked, but it doesn't.
>>> john --show also shows 0 cracked.
>>>
>>> But the hash is correctly stored in john.pot.
>>> After repeating this experiment several times, I have exactly the same
>>> line in john.pot for each new test.
>
>
>
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.
