[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 May 2012 20:53:21 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Additions to JtR rules, arbitrary characters
On 05/20/2012 08:16 PM, Frank Dittrich wrote:
> I also noticed that appending a newline character cracked several
> raw-md5 hashes from
> https://www.korelogic.com/InfoSecSouthwest2012_Ripe_Hashes.html
> (...)
> Cracking these hashes with such an external mode or with a rule $\x10
> and your patched rpp.c works.
> However, john.pot will also contain these newline characters.
> This results in john --show reporting wrong cracked passwords, unique
> removing "duplicate" empty lines, and so on.
>
> I'm not sure how much effort should be spent supporting such faked hashes.
> Can/should we try to add new options/values to john --show and/or unique?
> Or is this just not worth the effort, because these passwords will never
> be needed to crack real password hashes?
We could use literal '\n' and '\r' for a couple of such offenders. But
then we'd have to use '\\' for an actual '\' and this could break things.
FWIW, I have sometimes wanted another field in john.pot, a hex of the
plaintext like this:
$NT$3dbde697d71690a769204beb12283678:123:313233
I think some other crackers has this. If we had this in place, we could
print '?' (or something else) for linefeeds or otherwise unprintable
characters. But this would break lots of things so it would have to be
optional.
magnum
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.
