Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 15 Mar 2012 08:51:40 +0100
From: magnum <>
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

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:

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.


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.