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


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 []
>> 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 []
>>> I can reproduce this with 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
>>> (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