Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ