Cryptohaze.com

*grins*

Same as the Linux betas: GRTCrack -f [hashfile] -h [hash type] [list of GRT files]

I need to write up extensive docs for the gen process, but if you know what you're doing, it should work.

The cracker tool: It crashes on occasion on startup. I'm working on tracking down the race condition, but:

It should work! If it crashes, relaunch it. It should be fine.

Let me know if it works, and let me know any feedback you have.

The UI on the crack tool is still very bad - I need to update this...

Enjoy!

//EDIT: This is 64-bit only - 32-bit OSes make handling large files a true pain, so I'm not caring to do that. If you don't have a 64-bit Windows, you're out of luck on the rainbow table tools. Sorry.

First!!! and excited.

Can't wait to get home and give this a spin.

Thanks

Looks fine from here

What can i say... Bitweasil you are awesome!!!!

BTW For those with the DLL error.

<<< This may help.


Here is an output during a run looking good.

Code: Select all

C:\CryptohazeGRT>GRTCrack -f hash.txt -h MD5 E:\GRT\Len7\MD5-idx1-chr95-cl200000
-perfect.grt
Loaded 1 hashes!
Processing GRT file E:\GRT\Len7\MD5-idx1-chr95-cl200000-perfect.grt

Table version:   1
Hash:            MD5
Password length: 7
Table index:     1
Chain length:    200000
Num chains:      374655386
Perfect table:   Yes
Charset length:  95
Charset:          !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQR
                 STUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~


Running group 1 of 2
Kernel Time: 36.090 ms  Done: 97.82%
Running group 2 of 2
Kernel Time: 0.235 ms  Done: 44.33%

Total time: 24.65 seconds
Average rate: 811.46 M h/s
Thread 0 completed workunit ID 1 / 1
Thread 0 out of workunits
GPU memory freed... SHOULD be returning...
Threads joined
Total candidate hashes before unique removal: 200000
Total candidate hashes after unique removal: 199969
Using index file E:\GRT\Len7\MD5-idx1-chr95-cl200000-perfect.grt.idx, 16777216 i
ndexes
Index file bits to index: 24


Step 120000 / 199969 (60.01%) 61485 chains found

Awesome

I've got a few tweaks to make, then I should be able to get a full set of release quality code out. The UI still needs help... it's a confused mess with multiple GPUs.

it looks great but i have the problem that the maximum chain number is 25,000,000 because then my GPU RAM is full. Is there no way to get a higher chain number like blazer? with 25,000,000 the success rate of a table with password length 8 is too low even with 4 tables.. but the computation time with 2,000,000 chainlength would take about 12 hours which is ok.

you are suppose to generate the tables in parts eg like 10 million chains per time then merge them tables together. Same index of course.

kevinkk5 wrote:it looks great but i have the problem that the maximum chain number is 25,000,000 because then my GPU RAM is full. Is there no way to get a higher chain number like blazer? with 25,000,000 the success rate of a table with password length 8 is too low even with 4 tables.. but the computation time with 2,000,000 chainlength would take about 12 hours which is ok.

The "--numtables" argument is how many tables of the same index/etc to make.

It lets you build a ton of tables then merge them together.

Out of curiosity, what password space are you looking to build? NTLM len8 full? I'm working on those as I type

oh nice! ntlm len8 is what i wanted to generate.
well i would have generated 4 tables for it but because of the small chainnumber the success rate would still be low.

what blazer told: i understand it not completely but i´ll try it. but it would be nice if the programe could manage this itself and does not start if the chainnum is too high...

2,000,000 chain length

Err I think that is too overkill. You will have really inefficient tables and brute forcing will probably be faster.

yes that´s right. it was just to get a higher success rate but it was stupid...