Cryptohaze.com

I would like to suggest an option to specify the charset to be used for every character position. In essence: i would like to use only uppercase characters for the first password character, and then only lowercase for the rest of the password to be tested.

There's a rather large percentage of users/accounts using first character uppercase and rest lowercase when they are forced to use both upper and lowercase in their passwords. This way there'll be a improved chance of recovering NTLM alpha-numeric passwords with lenghts 8 and higher.

Regards,
mrCracker

as you might have noticed by reading the right threat, this is a work in progress (already quite far afaik )

mrCracker wrote:I would like to suggest an option to specify the charset to be used for every character position. In essence: i would like to use only uppercase characters for the first password character, and then only lowercase for the rest of the password to be tested.

There's a rather large percentage of users/accounts using first character uppercase and rest lowercase when they are forced to use both upper and lowercase in their passwords. This way there'll be a improved chance of recovering NTLM alpha-numeric passwords with lenghts 8 and higher.

Regards,
mrCracker

Already implemented in the next version.

v0.7 will allow using charsets like this, specifying for each position.

Code: Select all

!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~


Highly effective, and allows for some unique use cases.

does this new charset ability impede performance by any chance.

blazer wrote:does this new charset ability impede performance by any chance.

The "full" set of improvements (per-position charset, better performance on large lists) does hurt performance somewhat significantly on shorter kernel execution lengths - 30% or more is common with "don't interfere with the GUI" execution lengths (<50ms).

To work around this, and deal more effectively with short hash lists, I'm planning on adding "FAST[hash]" functions that are significantly quicker on a single charset & a short list (under 50-60) hashes. These will also not degrade nearly as badly with GUI settings.

For the multiple charset support and the "Doesn't degrade in performance as quickly with large numbers of hashes," the way this is done involves a good amount of additional setup time per kernel execution, so "short" executions spend more time setting things up than actually working. They're really best suited to very long executions on either a non-utilized system (where GUI degradation doesn't matter) or a headless server. They're pretty sweet, though...

Excellent, sorry for not seeing existing posts about per-position charsets.

Currently running 0.61 CUDA here, testing charsetlowernumeric length 8-10 on 3829 NTLM hashes, using a 9800GTX. For some reason Cain didn't succeed on cracking the LM hash (see my post here. http://oxid.netsons.org/phpBB2/viewtopic.php?t=3116), so i'm kinda "stuck" with attacking the NTLM hashes for now... (i'm gonna run rcracki and rcrack on the LM hashes as well, to see if they can give me something Cain can't at the moment.)

Again: looking forward to the 0.7 release!

Regards,
mrCracker

Heh. Good luck on that. It's probably a foreign character - they break pretty much everything right now.

The new release will be a lot faster on multiple hashes. Unfortunately, I don't have Windows binaries for it yet.