|
Message-ID: <2bf148efb090e9b7597e31b7466b7ee5@smtp.hushmail.com> 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.