Solar Designer | 1 Mar 2010 02:01
Favicon

Re: Special character (like TAB) in rules

On Fri, Feb 26, 2010 at 09:12:16AM +0100, Magnum, P.I. wrote:
> Is there a way to specify specific non-printables in rules? Say I want 
> to prepend a TAB, or match a TAB and replace with a BEL, just as 
> examples. The documentation does not mention any way to do this.

There's no JtR-specific way to do it.  You may embed those characters in
the config file literally if your text editor permits you to do so - e.g.,
in VIM to enter a TAB you simply press the Tab key, and to enter a BEL
you may press Ctrl-V Ctrl-G.  I understand that this is not pretty.
Also, it won't work for CR, LF, and NUL, because they will affect the
config file parsing (and more).

> In external modes, I can use 0x09 of course.
> 
> A generic way to specify *any* non-printable, like \x09 or something to 
> that effect, would be very usable.

OK, I've added your request to my ever-growing to-do list.  I think
people might also find this useful to specify 8-bit and utf-8 characters
when their native character set is different - e.g., I might have my
terminal and keyboard layout configured for koi8-r, yet have some of the
rules append iso-8859-1 characters.

> I thought of placing this 
> functionality in the preprocessor but keep in mind you may want to use 
> it in a PP list (like [0-9\x09] for digits + TAB) too.

That's precisely the reason to have it in the preprocessor and not
somewhere else.

(Continue reading)

Magnum, P.I. | 1 Mar 2010 22:36

Markov mode ignores external filters

I just discovered that the Markov mode doesn't seem to cooperate with 
any filter. It silently ignores them. I can't find any mentioning of 
this in archives nor anywhere else.

I assume it's appropriate to post this here, as a combination of 
heads-up to users and "bug report" to Simon, or whoever is willing to 
give it a look. Maybe it's a trivial fix?

MPI

Simon Marechal | 1 Mar 2010 23:37

Re: Markov mode ignores external filters

Le 01/03/2010 22:36, Magnum, P.I. a écrit :
> I just discovered that the Markov mode doesn't seem to cooperate with
> any filter. It silently ignores them. I can't find any mentioning of
> this in archives nor anywhere else.

I never thought about them, so it is no wonder it ignores them. I'll fix 
this tomorrow.

bartavelle | 2 Mar 2010 13:55

Re: Markov mode ignores external filters

Magnum, P.I. a écrit :
> I just discovered that the Markov mode doesn't seem to cooperate with 
> any filter. It silently ignores them. I can't find any mentioning of 
> this in archives nor anywhere else.
> 
> I assume it's appropriate to post this here, as a combination of 
> heads-up to users and "bug report" to Simon, or whoever is willing to 
> give it a look. Maybe it's a trivial fix?
> 
> MPI

Should do the trick :

http://openwall.info/wiki/john/patches
http://openwall.info/wiki/_media/john/filter_for_mkv.diff?id=john%3Apatches&cache=cache

(i didn't check for password sizes, but PLAINTEXT_BUFFER_SIZE is 0x80 so 
it should be ok)

Solar Designer | 2 Mar 2010 18:01
Favicon

Re: Markov mode ignores external filters

> Magnum, P.I. a ?crit :
> >I just discovered that the Markov mode doesn't seem to cooperate with 
> >any filter. It silently ignores them. I can't find any mentioning of 
> >this in archives nor anywhere else.
[...]

On Tue, Mar 02, 2010 at 01:55:47PM +0100, bartavelle@... wrote:
> Should do the trick :
> 
> http://openwall.info/wiki/john/patches
> http://openwall.info/wiki/_media/john/filter_for_mkv.diff?id=john%3Apatches&cache=cache

Thanks!  This appeared to have a minor bug in that most calls to
crk_process_key() continued to use pwd->password instead of the newly
introduced "pass" pointer.  I've fixed this and included the patch into
1.7.5-jumbo-2, which I've just released.  I've also dropped the extra
call to crk_done() at the end of mkv.c.

While at it, I've also included the missed rules.c commit that was
meant to be part of 1.7.5 into this jumbo patch update.

http://www.openwall.com/john/#contrib

Alexander

Solar Designer | 2 Mar 2010 18:42
Favicon

1.7.5-jumbo-1 builds for Win32 and Mac OS X

Hi,

Erik Winkler has contributed Win32 and Mac OS X builds of John the
Ripper 1.7.5 with revision 1 of the jumbo patch.  I've placed these into
the contrib/ directory and updated the links at:

http://www.openwall.com/john/#contrib

You may also find the files on Erik's website at:

http://www.macunix.net/JTR/

The Mac OS X build is usable on a wide range of Mac hardware and
versions of Mac OS X - it is a universal binary with four architectures
and it is statically-linked against Erik's special build of OpenSSL.
Additionally, it uses faster bitslice DES S-box code for PowerPC with
AltiVec by Dumplinger Boy (Dango-Chu).

For some hash types, it may be preferable to run the "32-bit" version of
the code when you're on a 64-bit Intel-based Mac.  This is primarily
because some contributed "formats" (included in the jumbo patch) have
MMX or SSE2 optimized code for 32-bit mode only.  To invoke this version
of the code, you may run the universal binary through "arch -i386", e.g.:

arch -i386 ./john --test --format=pix-md5

For many other hash types, the above will actually hurt performance, so
only use it when you know what you're doing.

Erik - thank you!
(Continue reading)

Solar Designer | 2 Mar 2010 23:04
Favicon

gcc version, Core i7

Hi,

I thought that some of you could want to be building JtR with a newer
version of gcc (GNU C compiler) than whatever version your system has
installed globally.

gcc version makes almost no difference for 32-bit x86 builds of the
official JtR since almost all performance-critical code is written in
assembly anyway, but on other architectures (especially x86-64) and for
other hash types (those added with the jumbo patch) it could make a
difference (speedups of 10% to 20% when going from gcc 3.x to 4.4.x are
sometimes seen).

I created a wiki page with instructions on building and using gcc 4.4.3
(the latest stable release as of this writing) under a non-root account
on a Unix-like system (tested on a 64-bit Linux install on a Core i7
machine, which had gcc 3.4.5 installed globally):

http://openwall.info/wiki/internal/gcc-local-build

I and others also made some benchmarks of JtR that show the differences
between gcc 3.4.x and 4.x on x86-64:

http://openwall.info/wiki/john/benchmarks

Of the hashes supported by the official JtR, these differences on x86-64
are mostly limited to MD5-based and Blowfish-based crypt(3) hashes,
because DES is mostly implemented in assembly anyway.  Similar
differences are also seen for some of the hash types added with the
jumbo patch (but this is not seen on the benchmarks page).
(Continue reading)

Lee Hambley | 2 Mar 2010 23:06
Picon
Gravatar

Re: gcc version, Core i7

Thanks Alex, useful stuff.

-- Lee Hambley
Picon

cracked passwords up to 10 characters with 1.7.5

Hi 

 Some months ago, I requested help about cracking passwords up to 10 
letters/digits (was with JTR 1.6.x if I remember right).

 With latest 1.7.5, and all changes in the .conf, old advices do not 
works. Could you tell me how to do, what must be changed in the .conf.

 I tried with dumbforce , I changed :

	minlength = 1;	// Initial password length to try, must be at least 1
	maxlength = 10;	// Must be at least same as minlength   <------  8 to 
10

 but, JTR try letters/digits up to 8 only.

 Why is it so hard to change something about length password in JTR, 
it's so easy in passwordspro :-/

 Thanks,

 W.A.

Rich Rumble | 3 Mar 2010 14:33
Picon

Re: cracked passwords up to 10 characters with 1.7.5

http://openwall.info/wiki/john/mailing-list-excerpts
More specifically: http://www.openwall.com/lists/john-users/2007/07/04/6
-rich

On Wed, Mar 3, 2010 at 5:07 AM, websiteaccess@...
<websiteaccess@...> wrote:
> Hi
>
>  Some months ago, I requested help about cracking passwords up to 10
> letters/digits (was with JTR 1.6.x if I remember right).
>
>  With latest 1.7.5, and all changes in the .conf, old advices do not
> works. Could you tell me how to do, what must be changed in the .conf.
>
>  I tried with dumbforce , I changed :
>
>        minlength = 1;  // Initial password length to try, must be at least 1
>        maxlength = 10; // Must be at least same as minlength   <------  8 to
> 10
>
>  but, JTR try letters/digits up to 8 only.
>
>  Why is it so hard to change something about length password in JTR,
> it's so easy in passwordspro :-/
>
>  Thanks,
>
>  W.A.
>

(Continue reading)


Gmane