Cryptohaze.com

Alright, I give up for now. The 32-bit Windows version has issues with the FAST[hash] options. They don't work. Don't use them. Use 0.61 if you have a small number of hashes or want something that plays nice with the GUI (0.7 likes longer execution periods to be efficient).

I'll attach the various binaries to this thread. I'm not feeling like repackaging things completely right now, so install instructions are as follows:

Windows:
Download the 0.61 release from the website. Download the 0.7 binary. Put it in the same folder. Call it as appropriate.

Linux: Same deal, pull the 0.61 release, put the 0.7 binary in it. Rename to the -64 name in the bin directory.


The hash types (MD4, MD5, NTLM, SHA1) are the "new" version. They work with unlimited hashes. They are a LOT faster with multiple hashes. They don't work well with a 50ms kernel execution, and really prefer 100-500ms (so they screw with the display significantly more), as there's a lot more constant per-invocation work they need to do.

The --maxthreads, --maxblocks, --autotune calls do not work. Sorry. They'll probably crash the program.

For best performance, you'll probably want to pass something like '--threads 256 --blocks 256 -m 500'

If you have a GT200 core (GTX260, 280, 295, etc), try '--threads 512 --blocks 512 -m 500'

I've added the following:
-l (lowercase L) - when using very large hashlists (500k+), this should improve performance. It uses 512MB of GPU RAM as a lookup table, so it's only for cards with a LOT of video RAM (768MB minimum, probably 1GB).
-c - this is the single characterset support.
-u - per-position character set support. To do this, put one character set on each line of the file. -v will show you what's loaded. It's pretty slick.

SHA1 support now exists. Please try it out!

Ehm... beyond that, ask questions & play around. If you find bugs, please report them and I'll try to fix them. This is a beta release, I'd like people to test the pants off it for a while and then I'll fix any bugs, hopefully fix the FAST[hash] options, and get the full release out.

Thanks!

Windows binary (32-bit):

http://www.cryptohaze.com/releases/CUDA ... er-0.7.exe

Linux binary (64-bit) - chmod 755 after downloading to run.

http://www.cryptohaze.com/releases/CUDA ... 64-0.7.bin

giving this a shot right now.

Wow is it me or did the NON Fast routines get a speedup too?

blazer wrote:giving this a shot right now.

Wow is it me or did the NON Fast routines get a speedup too?

The "FAST" routines are sort of misnamed. They're basically the 0.61 routines. They're faster for a very small number of hashes, and work better with short kernel invocation times (if you're running 50ms kernels so you don't affect screen refreshes, the FAST[hash] kernels will probably be quicker).

The "standard" routines should be much, much faster than in 0.61 for large numbers of hashes. I've run 200k+ hashes through them at once, and while the stepping speed eventually settles at 60M passwords per second (with the -l flag on a GTX260), the effective search rate is Very Large.

0.61 searches through the unsorted hash list linearly for each hash. This gets slow for large numbers of hashes, and relies on constant memory, which is limited in size, hence the 4k hash limit (and, really, beyond a few hundred it starts getting really slow).

0.7 sorts the hash list first (this may take a while with a few hundred thousand hashes), then creates an 8kb bitmap that gets stored in shared memory to pre-filter (if a bitmap item is present, there may or may not be a hash, but if it's not present, there is no hash), then does a binary search through the sorted hash list in global memory to look for the hash. It's a much more efficient system.

The -l switch creates a 512MB bitmap in global memory. This is effective with very large numbers of hashes - the big bitmap is slow, but searching through 500k+ hashes is a lot slower even with a binary search. It appears that with the -l switch, you get a constant speed regardless of how many hashes you add (up to really, really big numbers in the millions).

Other questions?

if you use -u and your charset file looks somewhat like this:

Code: Select all

ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz0123456789
abcdefghijklmnopqrstuvwxyz0123456789
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
0123456789
0123456789


--min / --max should no longer be required should they ?

the_drag0n wrote:if you use -u and your charset file looks somewhat like this:

...

--min / --max should no longer be required should they ?

Yes, they are still required - you can search anything up to the charsetfile length.

You could search for anything length 0-8 with that, and may want to - so --min and --max are still needed. If you try to search for a length beyond what the charset file has, it will throw an error and exit when trying to launch that kernel length.

Has anyone tested with the latest nVidia drivers?

196.21_desktop_win7_winvista_64bit_english_whql.exe

http://www.nvidia.com/object/win7_winvista_64bit_196.21_whql.html

After I installed them, the app started fast, then quickly slowed down to 0.0M/sec (After about 5 - 10 seconds)

Anyone else found the same symptoms?

Log:

C:\1\CM>CUDA-Multiforcer-0.7.exe --hashtype=MD5 --charsetfile=charsets\charsetfull --hashfile=c:\1\hashes.txt --min=4 --max=4 -o c:\1\CM\done.txt
Cryptohaze.com CUDA Multiforcer (multiple hash brute forcer)
by Bitweasil
Version 0.70, length 0-14
Currently supported hash types: MD5 FASTMD5 MD4 FASTMD4 NTLM FASTNTLM SHA1 FASTS
HA1
Hash type: MD5
CUDA Device Information:
Device 0: "GeForce 8500 GT"
Number of cores: 16
Clock rate: 0.92 GHz
Single charset loaded.
Loading & sorting hashes. This may take a while.
Returning from sort.
Hashes loaded (92859 hashes)
Done with copy to constant
Launching kernel for password length 4
Done: 25.75% Step rate: 0.7M/s Search rate: 68506.8M/sec
MD5 : 9B90BC032A6BEF2BA1A06B7087A9E0C6: 'naJ.' 0x6E614A2E
^Cne: 27.76% Step rate: 0.0M/s Search rate: 0.0M/sec sec
C:\1\CM>

It starts at 278457.2M/s, drops to 146740.7M/sec, then 96kM/sec, then rapidly declines to 0.

Try passing in -m 100 or -m 500

Vista has VERY long kernel launch times compared to Linux/XP, and so it can end up cutting the work to zero trying to match a 50ms kernel time.

This is something the code should probably look for - null kernel launch times, and adapt accordingly.

I'll put it on the list...

Bitweasil wrote:If you have a GT200 core (GTX260, 280, 295, etc), try '--threads 512 --blocks 512...

I would not suggest that.The best way is to set threads and block in such a way so they will be divisible by the number of stream processors your gfx card has.
As one man suggested, I tried --blocks=30 --threads=512 -m 1000 and it was the best config.I am using GTX 285 btw.