Free Rainbow Tables | Forum

index :

1.What is the max length of the password that freerainbowtables is able to crack?
Which combination of alphabet, char, symbol did covered in that hash?
How many types of encryption your table are able to crack? what are their success rate/ each type?
http://freerainbowtables.com/phpBB3/vie ... &f=8#p6839

2.Upload of Parts is being aborted

3.Cracking RAR protected archives

4.Is it possible to crack 16 char long NTLM password?

5.Why 12 characters, LowerAlpha, UpperAlpha, Numbers and Symbol-14 is infeasible.

6.How to use rcracki

7.The difference between DES and DES Crypt

8.Is it possible to generate rainbow tables for zip archives?

9.Time required to create a rainbow table ?

10.Is there a description of how indexed rainbow tables works?

11.Upper "limit" of chainLength ?

12.keySpace upper "limit" of FreeRainbowTables.com ?

_________________
a2480f25 blog.

_________________
a2480f25 blog.

---------
viewtopic.php?p=6826#p6826

_________________
a2480f25 blog.

_________________
a2480f25 blog.

Cracking RAR protected archives



----------
viewtopic.php?f=2&t=563&p=4038#p4038

_________________
a2480f25 blog.

Is it possible to crack 16 char long NTLM password?
quick answer : NO
long answer :

--------
viewtopic.php?p=2800#p2800

_________________
a2480f25 blog.

Why 12 characters, LowerAlpha, UpperAlpha, Numbers and Symbol-14 is infeasible.

----------------
viewtopic.php?p=1665#p1665

_________________
a2480f25 blog.

How to use rcracki:

in general you use these commands :

rcracki.exe [table_dir]\*.rti -h [hash (one)]
or
rcracki.exe [table_dir]\*.rti -l [hash list]

what is important ?! :

the dir of the tables must not contain spaces! or you have to put it into quotes ( "C:\Documents and Settings\...." )

LM hashes have to be split into parts! : as you should already know from a bit above lm hashes are actualy 2 hashes (16 byte each). You HAVE to split them so rcracki can use them. otherwise it will give an error : "this table contains hashes with length 8 only"

rcracki requires this to be installed !!!

_________________

The difference between DES and DES Crypt

-----
viewtopic.php?p=7569#p7569

-------
viewtopic.php?p=7576#p7576

_________________
a2480f25 blog.

Is it possible to generate rainbow tables for zip archives?
short answer NO.



viewtopic.php?p=8897#p8897

_________________
a2480f25 blog.

Time required to create a rainbow table ?

hours_required = key_space * work_factor / step_speed / 3600
where:
character_set_length = 69
min_password_length = 1
max_password_length = 7
key_space = (character_set_length ^ (max_password_length + 1) - character_set_length ^ min_password_length) / (character_set_length - 1) = 7,555,858,447,479
step_speed in links per second, a quad core probably gets like 3 million per second on winrtgen.
work_factor = chain_length * chains / key_space
work_factor is chosen depending on table accuracy wanted. These work factors are found by guess and check and work for most key spaces and chain lengths (small chain lengths like 100 will be off by a little).

non-perfect table sets:
9.4 (2.35 per table, 4 tables) for a 99.80% (miss 1 in 500) non-perfect table set.
11 (2.75 per table, 4 tables) for a 99.90% (miss 1 in 1000) non-perfect table set.

perfect table sets:
10.86 (2.715 per table, 4 tables) for a 99.00% (miss 1 in 100) perfect table set.
17.84 (4.46 per table, 4 tables) for a 99.60% (miss 1 in 250) perfect table set.
28 (7 per table, 4 tables) for a 99.80% (miss 1 in 500) perfect table set.
52 (13 per table, 4 tables) for a 99.90% (miss 1 in 1000) perfect table set.

-Sc00bz-
--------
viewtopic.php?p=10909#p10909

_________________
a2480f25 blog.

Optimum number of tables for minimizing the space-time needed to crack a hash with a success rate of 99.9% is 4 tables.
"Optimum success rate" doesn't exist this is something you just pick. This depends on how long you want to spend creating rainbow tables and disk space.
"Optimum time for computing" is basically the same as "optimum success rate" as they are directly related. The only thing you can change that only effects one of them is number of tables and perfect vs non-perfect.

* How do you determine the best number of tables?
As you can see from the data for a 99.9% success rate the best space-time for cracking is 4 tables for either perfect or non-perfect rainbow tables. For perfect rainbow tables you might want to do 5 tables as it takes less than half the time to generate 4 tables.
Perfect Rainbow Tables "99.9%"

Non-Perfect Rainbow Tables "99.9%"

* How do you determine the best indexes?
It appears that if you bit pack all the data the best index is such that there are about 15 to 30 chains per index, but all you do is increase or decrease the index until you find the smallest total table size. You may want to do a smaller index if you want to load the whole index in memory. Having an index smaller than the optimal by one or two bits indexed will only make the total size a few percent bigger.

* How do you determine the best chain length vs chain count?
What ever feels right. One way to measure how good a table is, is to do "key space / (chain length * (chain length + 1) / 2 * number of tables)" this number should be at least 10000. This number is roughly the point where you should do brute forcing if you have that many hashes. Chain count is found by calculating "work factor * key space / chain length."

Please note that rainbow crack's "chain length" is one higher than the "real chain length."
One last thing perfect rainbow tables are faster since they don't need to check for as many false alarms as non-perfect rainbow tables.

Perfect:

* (bits indexed,bits per start point+bits per end point=bits per chain)

Non-Perfect:


I just picked a number that isn't really low. The higher the number the better as long as the size of the tables are manageable. It's basically so that someone doesn't pick a chain length of 100 or 10,000,000. You should also look at the time it takes to generate the end points when cracking a hash and make sure it is not too high. Also a nice little trick for indexing is to make the number of chains just under 2^n (where n is an integer). This way the tables are slightly more space efficient.


- Sc00bz -

viewtopic.php?p=10958#p10958

update 19.08.2010
-------------------
1 : 0.8646462849 Max (rainbow table)
2 : 1-(1-0.8646462849)^2 = 0.98167937181 (miss 1 in 54.58)
3 : 1-(1-0.8646462849)^3 = 0.9975202349 (miss 1 in 403.26)
4 : 1-(1-0.8646462849)^4 = 0.99966435458 (miss 1 in 2979.33)
5 : 1-(1-0.8646462849)^5 = 0.9999545691458 (miss 1 in 22011.62)
6 : 1-(1-0.8646462849)^6 = 0.99999385076511 (miss 1 in 162624.34)
7 : 1-(1-0.8646462849)^7 = 0.99999916767821 (miss 1 in 1201486.78)
8 : 1-(1-0.8646462849)^8 = 0.999999887342154 (miss 1 in 8876718.86)
9 : 1-(1-0.8646462849)^9 = 0.999999984751342 (miss 1 in 65582192.15)
10 : 1-(1-0.8646462849)^10 = 0.99999999793603749 (miss 1 in 484528573.5)
...
n : 1-(1-0.8646462849)^n


Pick pretty much any keySpace
Set chainCount = keySpace
I picked a chainLen of 50000 for that, but it doesn't change much as the chain length goes up.
expectedUniqueChains = euc(chainLen)
euc(1) = chainCount
euc(i) = keySpace * (1 - e ^ (-euc(i - 1) / keySpace))
perfectTableSuccessRate = 1 - (1 - uniqueChains / keySpace) ^ chainLen <--- that's about equal for some reason I'm getting a memory allocation error with that character.

10k: 86.4587076220994%
20k: 86.4622770147352%
50k: 86.4646284852614%
100k: 86.4654875417649%
150k: 86.4657912004252%
200k: 86.4659483369251%
500k: 86.4662457462117%

http://cryptohaze.com/forum/viewtopic.php?p=738#p738

_________________
a2480f25 blog.

Is there a description of how indexed rainbow tables works?

Since rainbow tables can be really big they are split into several files usually 1 GiB in size. N and M are the totals for all the files in the rainbow table. All the rainbow table sets currently generated at FRT have 4 tables: "_0_" "_1_" "_2_" and "_3_" Except the really old ones that basically got thrown out. So if you see a rainbow table set with 40 *.rti or *.rt files it means that each rainbow table is split into 10 parts each.

------------------------------------------

rt tables (*.rt) (16 bytes / row):
Start point 1 (64 bits), end point 1 (64 bits)
Start point 2 (64 bits), end point 2 (64 bits)
...
Start point N (64 bits), end point N (64 bits)
The start point and end point pairs are sorted on the end point. So to do a search for "my end point" you can do a binary search for it since the table is sorted by the end points.

------------------------------------------

rti tables (*.rti) (8 bytes / row and N is number of chains):
Start point 1 (48 bits), end point 1 (16 bits)
Start point 2 (48 bits), end point 2 (16 bits)
...
Start point N (48 bits), end point N (16 bits)

rti tables (*.rti.index) (11 bytes / row and M is int((key space + 65535) / 65536)):
end point prefix 1 (40 bits), first chain 1 (32 bits), chain count 1 (16 bits)
end point prefix 2 (40 bits), first chain 2 (32 bits), chain count 2 (16 bits)
...
end point prefix M (40 bits), first chain M (32 bits), chain count M (16 bits)

To get the full end point you do "(end point prefix X << 16) + end point Y" where Y is between "first chain X" and "first chain X + chain count X - 1"
So to do a search for "my end point" you do "my end point prefix = my end point >> 16" and search for "my end point prefix" in a *.rti.index file lets say it's row Z (my end point prefix == end point prefix Z). Now you read "chain count Z" rows from the *.rti file starting with row "first chain Z" then you see if "my end point" is one of them.

---Sc00bz---

Thank you for the post, but I am still not sure I understand. Could you seperate the parts where the table is generated, and the parts where the table is searched? Also, it doesnt see that the bits add up right (to 64). Could you explain?

---shifter1---

For rti tables the chains are generated with incremental start points instead of random start points. Since we don't generate more than 2^48 chains per table the start point can fit in a 48 bit field. Also since tables have a key space of less than 2^56 the end point can be store with 56 bits (16 bits in the end point field and 40 bits in the end point prefix field).

Let's say we have a key space of 0x5ffff and we generate these 8 chains:

This is how it would look like in a finished rt file:

That is a non-perfect table FRT creates perfect tables this just means that merged chains (duplicate end points) are removed.

Then it is indexed:
The .rti file:

The .rti.index file:

* Note that all fields are stored in little endian so the bytes are flipped in each of the fields:

------------------------------------------------------------

Searching for end point "00 00 00 00 00 02 d2 f2" (I'm just going to do linear search instead of binary search to make this easier)
.rt file:

-------
Searching for end point "00 *00 00 00 00 02* **d2 f2**" in rti file format
Searching for "*00 00 00 00 02*" in the end point prefixes column (I'm just going to do linear search instead of binary search to make this easier).
.rti.index file:

.rti file:


---Sc00bz---

viewtopic.php?f=2&t=1223

_________________
a2480f25 blog.

Upper "limit" of chainLength ?

65537 you can go higher but the table index needs to be weird.





So nPos can be 0 to 65535 (2^16-1) when calling HashToIndex() without interfering with the table index. For nPos to be 65535, nRainbowChainLen needs to be 65537 (2^16+1). Once nRainbowChainLen is more than 65537 you need to the table index to have it's lowest bit zero. So 0, 2, 4, 6, ... in binary it's 000, 010, 100, 110, ...

When nPos reaches 2^17 (nRainbowChainLen > 2^17+1) it will interfere with the table index so you need the lowest two bit to be zero. So 0, 4, 8, 12, ... in binary it's 0000, 0100, 1000, 1100, ...

-Sc00bz
----------
viewtopic.php?f=2&t=1449

_________________
a2480f25 blog.

keySpace upper "limit" of FreeRainbowTables.com ?

Short answer : ~ 2^51
Sc00bz's explanation :

The limit is something higher than 2^51.38 and that's being limited by 20 mbps bandwidth and it will take 66 days for 99.9%. Only problem is it's 2TB so not many people will be able to download it if the server had enough bandwidth to upload it. For some reason no one knows (99% of people) how to set up their router to forward ports to their computer or sets maximum upload to near zero. So torrents don't work to well.

_________________
a2480f25 blog.