MaddGamer wrote:Alright final report back on MD5 len 6 from table generation to cracking hashes.
Awesome! Thanks for the detailed testing - I don't have any test cases built yet, but plan to for automated testing. They'll probably be based on what you did at this point.
MaddGamer wrote:GRTIndex on windows does not work
Looks like an issue with not linking in the "advanced command line expansion" library on Windows - an oversight in the make process. Should be trivial to fix.
MaddGamer wrote:GRTCrack does not exit on q, but pause does work
Thought I'd fixed that... I'll take a look. The two use the same general signaling system...
MaddGamer wrote:GRTCrack dies if there are no .idx files for the .grt tables
That's definitely a bug. It should just search without using the index files (which is slow on spindle disks, but leads to the same results). I'll look into this.
MaddGamer wrote:On an earlier post it was mentioned that each part of a table that has the same index should have a different seed, when running GRTGen with --numtables > 1 all the parts will have the same seed number. I may have been reading into the earlier statement incorrectly... The number of chains after perfecting both of the following table spaces had close to the same number of chains.
Yes, that's a subtle misunderstanding of what I'd meant to say (I make no claims to having said it clearly). It's probably easiest to explain with the backend process:
The seed value simply seeds a mersanne twister random number generator used to generate the initial passwords.
The "-0, -1, -2, -3" postfixes just indicate subsequent table parts generated with the same seed, but they are not the same, as the rng has continued through.If you generated another set of tables, same parms, seed 1262..., you'd end up with an identical set. This is by design to allow verification of code - generating a set with the same seed on all platforms should generate absolutely identical tables.
But, yes, what you're doing is correct. In normal use, just don't set a seed, and don't worry about it. It works properly.
The seed is really there for debugging and separating out table parts.MaddGamer wrote:I wasn't sure on what size to run things so for a first run I left GRTMerge with 128 bits, and GRTIndex with 32 bits. I made a hash list of 10 values and put it against my 4 perfect grt tables.
There will be a wiki article soon talking about this. It basically involves using GRTAnalyze & figuring out how to trim the table size. What you did works fine, it's just not as space efficient.
MaddGamer wrote:7 hashes were cracked by table 1 in 6 minutes
2 more hashes were cracked by table 2 in a total of 7 minutes 45 seconds
the last hash was cracked by table 3 at about 8 minutes 30 seconds
Awesome.
That's how it's supposed to work. Glad to hear it does.MaddGamer wrote:I also ran GRTCrack against a hashlist of 100 values to test the percentage of passwords the tables would find. The CH gen time was slow with that many hashes but I was able to crack 100/100 in 60 minutes again only using 3 of 4 tables, compared with 40 minutes for Multiforcer.
Conversely using GRTCrack for what rainbow tables are good for, 1 hash was found in 26 seconds with the first table, while Multiforcer took 26 minutes for the same random hash.
Yes, 100 hashes for len6 is probably well beyond the brute force point. But it's definitely a good test, and I'm glad you had the 100% crack rate - that's a good test. I need to do stuff like this for my larger tables to verify hit rates as well.
And, yes, RTs rock for small lists of hashes in long hash spaces.
Again, I really appreciate you doing the work to test this out. I'll look into the bugs you reported & get them fixed. Any chance you'd be willing to write up some scripts for a formal test case?
