Date: Sun, 27 Feb 2011 14:37:40 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Password file hash type analysis in JtR On Tue, Jan 25, 2011 at 10:56:16AM +0100, Frank Dittrich wrote: > e10adc3949ba59abbe56e057f20f883e appears twice, > because it is valid for lotus5 and raw-MD5. > (Additionally, it has been stored in cracked_hashes_mscash as > 9:M$9#e10adc3949ba59abbe56e057f20f883e.) 1.7.7 will try to detect these things and print helpful messages: #ifdef LDR_WARN_AMBIGUOUS fprintf(stderr, "Warning: detected hash type \"%s\", but the string is " "also recognized as \"%s\"\n" "Use the \"--format=%s\" option to force loading these " "as that type instead\n", (*format)->params.label, alt->params.label, alt->params.label); #endif My intent is to keep this detection code in the official JtR, but only enable it in jumbo for now. (No such ambiguities are possible in the official JtR yet, except for "crypt", which is treated specially anyway.) > And crypt recognizes all hash types supported by your system, see > man 3 crypt > > > That means you could exclude crypt from the list of "hash formats", > unless you used john --format=crypt to crack hashes not currently > supported by an individual implementation (SHA-256 or SHA-512). Actually, there's some magic in loader.c to have those SHA-crypt hashes detected (if supported by the underlying system) even without explicit "--format=crypt". > Unless I misunderstood your requirement, I think there's no need > to develop a new tool. > (On the other side, a tool could remove some of the ambiguity I > mentioned. But this could also be done with some more thought put > into some scripting.) Indeed, a script around JtR could work, but I think it's best to have some of this built in, which is why I am enhancing the loader's reporting for 1.7.7. Thanks, Alexander
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.