Date: Thu, 15 Mar 2012 08:51:40 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: Adding a new format On 03/14/2012 10:53 PM, Claudio Broglia wrote: > For now, I'm trying to improve it taking advantage of the issues it has, > that I mentioned before. In particular: > - it supports only uppercase passwords > So far, I toupper()-ize every key given by john, which is working just fine. If you develop for Jumbo, please note that there are Unicode and codepage-aware alternatives for uppercasing, that should be used. Here is a subset: // This is needed for all of the below #include "unicode.h" // Encoding-aware in-place uppercase of string extern char *enc_strupper(char *s); // Uppercase UTF-8 or codepage string extern int enc_uc(UTF8 *dst, unsigned dst_len, const UTF8 *src, unsigned src_len); For upper-casing a char at a time, there are arrays that can be used inside a key setup loop: // Used by various formats uc/lc extern UTF8 CP_up[0x100]; extern UTF8 CP_down[0x100]; CP_up is used in DES_bs.c for LM format, and it does not introduce much of a performance hit when used (besides it's only used when you say so). > To improve incremental mode speed, I was thinking of building a > dedicated charset. So, I read the posts linked in the wiki, which advise > to generate a fake john.pot and generate a new charset from it, > filtering out unwanted chars using external mode. I was going to do > this, but then I thought: what if, in the, say, 100000 passwords in the > fake john.pot I generate with john --incremental=all --stdout, some char > is missing? I mean, I want in my charset all the possible chars, just > excluding the lowercase ones. Use CharCount for detecting that (emitting a warning), and Extra for filling in the blanks: http://www.openwall.com/lists/john-users/2009/07/26/7 See also doc/EXAMPLES > To improve wordlist mode speed, the external mode filter is the best way? I do not understand the question but in general, a rule is faster than an external filter. But some things just can't be done with rules. > - I know in advance password length (!) > Because password's length is used as one of the salt parameters (yes, > it's true. no, I didn't design this format.) I know it in advance. What > would be a smart way to take advantage of this? Wow. Well you should be able to just skip hash calculation in crypt_all() for any key with the wrong length, then. > - I've understood correctly the meaning of CHARSET_LENGTH in params.h? > Being set to 8 by default, john will not generate password longer than > that without modifying john sources and, after, rebuilding the charset? Yes but this only affects Incremental mode. The other cracking modes are only limited by your format's PLAINTEXT_LENGTH. 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.