From 26C3 Public Wiki
Freerainbowtables
FRT was "represented" at congress by a lightning talk and two people actually bringing the tables on a bunch of large disks. We were able to make a bunch of direct copies and copy most of them on the congress network. Thanks for everyone who helped out.
"Official" torrents are on GARR. This also the "official" mirror. Tables generated last year will also turn up there.
Contents |
How to get the rainbowtables
Thanks to our Dating-request we could make some direct copies overnight. Now you need to check the GARR-Mirror (see above)
Basic Info
freerainbowtables.com generates ... free rainbowtables with BOINC (http://boinc.berkeley.edu/). That's the same thing used for folding@home and many, many other projects. This project is called distrrtgen, and (at this time) the client runs on Linux/Windows 32/64 bit. Decent computers (such as a cheap quadcore) will upload a few megabytes every half an hour minutes or so; slower ones, including atoms (=netbooks) will take a few hours to complete a single work unit. So, unless you have a big rig and a terrible connection, you won't really notice it. However, the BOINC client allows you to customize the upload and computing settings to your liking.
The tables from frt.com are indexed and perfected, that means they're small (one table element is about 600 MBs) and rather fast. However, you'll need rcracki_mt to use them: http://sourceforge.net/projects/rcracki/
This baby runs on most unixes and windows. It should compile on backtrack. It has some nifty features such as pause and resume, can benefit from multicore systems and so on.
- More info about the math is here
FAQ: Something is wrong!
At the moment you might notice three things:
- You can't join the project
- You get SQL-Errors
- You don't find all tables on the mirror garr.it
A harddisk failed while one administrator was on holiday and another failure meant the mirror is not up to date. Highly scientific analysis shows the god of unsalted hashes is angry at the moment. So that's why we carry the tables right to congress. Project activity will/might resume after the holiday season in early 2010.
If you want to help out, you can either give tips where to find nice mirrors (for the future) or somehow appease the god of unsalted hashes. Ideas are appreciated - we didn't even know unsalted hashes had a god.
Types of Tables
- A detailed overview about all the tables generated can be found here
- If you'd like tables for other hash-types, create an account on the forum of freerainbowtables.com and post here
LM
The biggest table generated by frt.com (so far) is a titanic LM-set. LM is a "broken" hash used up to XP/Windows 2003. Tools like cain and pwdump/fgdump will create files with LM-NTLM-pairs, rcracki_mt can read those, and use the LM-result to find the correct NTLM plaintext. This is the actual password used for authentication.
As this table includes a bunch of characters from codepages 850 and 437 (german umlauts, french accents) strange things sometimes used in passwords can be uncovered. This is really cool and called "unicode correction" by its inventor, the incomparable neinbrucke.
MD5 and NTLM
MD5 is still used in many, many applications including forums software, CMSes ... and way, way too many security applications. NTLM is still used in Windows 7 and Windows Servers 2008. So, there's a bunch of tables for them both.
For MD5 and NTLM there are some "hybrid" tables following some pattern people like to use with their passwords, such as 1-6 alpha characters and 1-4 numeric characters. This uncovers pretty common passwords which'd take some time to bruteforce due to their length.
Difference to other tables
- they're free!
- their success rate is around ~99.9% whilst being rather fast.
- and small.
That's basically it. Of course, the latter also means that with few exceptions, the FRT-tables do not fit on traditional removable media as the 0phcrack tables do. You'll need an external disk of some sort. USB disks will do, just consider that you need to load the tables from them, so you might like a known-not-slow-device.
Using those rainbowtables
Once the project has generated a table-set, no powerful machine is required. Even a netbook will do, although it won't be that fast. (Turning of memory-hungry things should help when you just have one GB of RAM)
However, rainbow tables will be slow if you have a lot of hashes - say several hundred/thousand. It really depends on the system, just test your own with 10 hashes against a table of your choice to get a feeling of what is doable.
Keep in mind those tables only work against the hash-type they were created for. For MD5, this is plain MD5, no salts, no iterations. For LM/NTLM, this is only the hashes stored for local accounts on clients or servers (domain controllers) not the stuff windows transfers over the wire when authenticating.
After you got rcracki_mt to work, you'll need to put your hashes into a list (one per line, no usernames). For LM, cain *.lst files and pwdump/fgdump output is ok. Afterwards, call rcracki_mt like this:
rcracki_mt -t 2 -l hashlist.md5 /mnt/usb/md5
It will use two cores and check /mnt/usb/md5 for rainbow-table sets. It will keep running until it has found all plaintexts or you run out of tables. If you have a lot of hashes, precalculation will take some time and CPU-power. If you have common passwords, the first tables will unvover the most passwords. As more and more hashes are uncovered, the faster the remaining tables will be searched through. For a single hash, even searching lm_frt takes less than 2 hours on a quadcore.
Some benchmarks
This might give you an idea about the speed of the tables. The table used is the lm_all-one (A-Z,0-9,32 symbols, length 1-7) which is about 45 GB altogether (4 sets). Bruteforcing LM is slower than either NTLM (MD4) or MD5, so it makes a nice example.
Running rcracki_mt on a 64 bit linux against 27-hashes, were one is (deliberatly) not in the table yields the following results:
- Q9300 (2.5 Ghz, HDD) : 16:08 min.
- i7 965 (3.2 Ghz, HDD) : 10:32 min.
- Q9300 (2.6 Ghz, SSD) : 09:13 min.
Since one hash is not in the table, rcracki_mt has to load the whole set. 4 threads were used on the Q9300 and 8 threads on the i7.
Running the same table against a single hash not in the table-set:
- i7 965 (3.2 Ghz, HDD) : 08:07 min.
- Q9300 (2.5 Ghz, HDD) : 07:10 min.
- Q9300 (2.6 Ghz, SSD) : 05:02 min.
Bruteforcing the same keyspace on the i7 using john (MPI-Patch, utilizing all cores) would take 18 hours and roughly 2 days on the Q9300. However, the single-crack mode of john is rather clever and you can use it to reduce the number of hashes you want to check against the table - this is true for all hashtypes, not just LM.
The speed gain caused by the SSD (OCZ Vertex II) is fixed and unrelated to the number of hashes checked. It's just that you have to load the tables from a medium, where the faster is the better of course. In this case, it's loading 45 GB to RAM.
Using a SSD only makes sense if you have one or two tables you need to run a lot - the price of the SSD will buy you at least two 1.5 TB HDDs, were you can put all the tables on and even speed up things by creating a RAID.
In our tests, we were able to read about 200 MB/s from an SSD (no optimisations) and 100 MB/s from a RAID-1 from two 1 TB HDDs (also no optimisations).
Who is responsible
- Powerblade created the project, wrote the first distrrtgen and converted everything to boinc. At the moment he and Sorcier_FXK (Kalkulators Knights) administer the whole thing.
- Quel and neinbrucke created and maintain rcracki_mt.
- note that this sourceforge-only
- Sc00bz and haxxxor are freerainbowtables.com resident mathematicians, whose post you should check if would like to know more.
Your contact at congress
This dude
Dragon? Which dragon ?
Actually, freerainbowtables.com has a dragon, which can be found in the IRC channel:
irc.freenode.net #freerainbowtables
You can ask it questions when it is online.
