Revert "raw-md5-opencl bugfix: You can't release buffers that are not allocated."

This reverts commit d043fbec0fde43169361ab935e963920c187edd2.
Revert "Raw-MD5-opencl: status check bug fix"

This reverts commit d6cd0fea8575354079de3d50476cf7a96d811baa.
Revert "Update opencl_rawmd5_fmt.c"

This reverts commit 70b114878bcf867755aef59d637d27994f0fe4c7.
Revert "Raw-MD5-opencl: fixed memory cleanup"

This reverts commit 8e2043ec270a78aa1ab2509a920564ed96fc03be.
Revert "Raw-MD5-opencl: compare on gpu"

This reverts commit 6c0d209d9161a146e28571b6a53b1fe8e5bd41e0.

Conflicts:
	src/opencl_rawmd5_fmt.c
Mask mode for GPU

On Thu, Jun 13, 2013 at 07:37:17PM +0400, Solar Designer wrote:
> [...]  Our rules preprocessor implements something very similar -
> in fact, I think we might want to support its syntax as well.  For a
> trivial implementation, we could simply be calling rpp_*() from the mask
> mode implementation - and it'd just work for rpp's variation of the
> syntax.  However, rpp is mostly unoptimized (it wasn't meant to be used
> from a performance-critical place) and it implements its syntax only
> (not the PasswordsPro/hashcat "mask attack" syntax).

I've attached a proof-of-concept patch (against core) that illustrates
this similarity.  Moreover, it introduces PasswordsPro/hashcat "mask
attack" syntax into rpp (only enabled when invoked from our mask mode).
Mixed syntax works, too:

$ ./john --mask='?u?l[ab]?d??' --stdout | head -3
Press 'q' or Ctrl-C to abort, almost any other key for status
Aaa0?
Aaa1?
Aaa2?

$ ./john --mask='?u?l[ab]?d??' --stdout | tail -3
Press 'q' or Ctrl-C to abort, almost any other key for status
13520p 0:00:00:00 1352Kp/s Zzb9?
Zzb7?
Zzb8?
Zzb9?

Speed on one core in FX-8120 when run against one LM hash:

$ ./john --mask='?u?u?u?u?u?u' --format=lm pw
Loaded 1 password hash (LM [DES 128/128 XOP-16])
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:13 0g/s 23157Kp/s 23157Kc/s 23157KC/s ZZZZXO..ZZZZZZ
Session completed

For comparison, incremental mode locked to the same charset and length:

$ ./john -i=upper6 --format=lm pw
Loaded 1 password hash (LM [DES 128/128 XOP-16])
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:06 0g/s 44448Kp/s 44448Kc/s 44448KC/s UXHZQN..UXHQFQ
Session completed

So, yes, in its present form rpp is slower than our mask mode should be
(it should be faster than incremental, not slower, unless we somehow
make it use incremental's *.chr files).  It's not slow to the point of
being unusable, though.

Not implemented in this PoC are support for: --restore, --node & --fork,
progress indicator.  These are trivial to add (good efficiency and
scalability at --node & --fork is not as trivial, though - would require
changes to rpp.c).  Also not implemented yet are many of the pre-defined
"mask attack" charsets, but these are even more obviously trivial to add.

As to introducing support for format's set_mask() into this - now that's
possibly more difficult than it would be with a specialized implementation.
Yet I think we should not give up on this approach.  Perhaps we'd have
to untie mask mode from rpp, but we may nevertheless start by duplicating
much of rpp's structure and initially even code - and only then proceed
to customize it for optional use of set_mask().

Alexander

Conflicts:
	src/Makefile
	src/john.c
	src/options.c
	src/options.h
Fix after reverts.