Free Rainbow Tables | Forum

Home of the Distributed Generator and Cracker
It is currently 18 Apr 2014, 10:02

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: 12 May 2012, 23:51 
Offline
Shoulder Surfer

Joined: 12 May 2012, 23:20
Posts: 8
I am fascinated by puzzles and problem solving. I especialy like mechanical and electronic puzzles. I have recently discoverd crytpoanalysis. I thinks it's fascinating. I have been playing around with my router for weeks.

I wish to make sure I understand the concept correctly.
A rainbow table is basicaly a list of every possible character combination which was run through the appropriate hash algorithm and stored in a file with the result.
This way instead of having to brute force a key, you can do a hash dump and then look up the hash in your table to see what char string was used to generate that hash?


I am also to understand in regards to WIFI the SSID is part of the key so you would be better off generating your own rainbow table for that paticular network?

I was wondering what hash algorithm wifi typicaly uses.
Also what program can be used to generate a rainbow table?
GUI's are nice because I'm just a newb.
Thanks for any help you can give me.
For what it is worth, I promise not to use anything I learn here to hurt people. This is mostly just for my own curiosity.


Top
 Profile  
 
 Post subject:
Posted: 13 May 2012, 17:03 


Top
  
 
PostPosted: 13 May 2012, 17:03 
Offline
Site Admin

Joined: 11 Oct 2007, 21:17
Posts: 1618
Location: Copenhagen, Denmark
jarrod0987 wrote:
I wish to make sure I understand the concept correctly.
A rainbow table is basicaly a list of every possible character combination which was run through the appropriate hash algorithm and stored in a file with the result.
This way instead of having to brute force a key, you can do a hash dump and then look up the hash in your table to see what char string was used to generate that hash?


No. Looks like you have to read it all over again. :)
I know it can be hard and confusing to understand the concept. It takes time.
A rainbow chain consists of a starting point and a ending point. In rainbowcrack, these are 64 bit integers for a total of 16 bytes for a rainbow chain (we pack in the RTI2 file format so it only takes up 8 bytes/chain of space on the disk). Each rainbow chain "contains" chainlength number of hashes. Using a mathematical function you can determine if the hash in the found in the given rainbow chain.
In the case of md5_mixalpha-numeric#1-9_16_755000 (which we are currently generating), each rainbow chain (8 bytes of diskspace) will contain 755000 plaintexts (passwords) that are linked together in the chain and the entire rainbow table will contain millions of rainbow chains. Trying to do the same when storing the raw hashes and the corresponding plaintext on the disk will consume multiple terabytes of space. This table will only take up a couple of 100 GBs


Top
 Profile  
 
PostPosted: 13 May 2012, 17:45 
Offline
Shoulder Surfer

Joined: 12 May 2012, 23:20
Posts: 8
Ok so it's not brute forcing the PW in realtime, I got that. And it's not a massive look up tabe, I got that. It's some where in the middle? I guess I have to go do more reading. Don't get how it could not be one or the other.


Update.
Ok so I'm getting closer. What I originaly stated is a look up table and it's massive. So the purpose of a rainbow table is to make it smaller. To sort of "compress" it if you will. This means you have to use CPU to use it, but it fits on your drive easier.

Right so far?

Still reading on how it works. This is fun :)

Update. I'm reading this article
http://stichintime.wordpress.com/2009/04/09/rainbow-tables-part-5-chains-and-rainbow-tables/
I was doing great until page 5. I get the concept of what a reduction function is for but I'm getting lost trying to follow along with the example.

In the example are 5 columns.

I understand that 3 (1st column)would be the a magic number given to us by our rainbow table.
What is it's proper name and how is it derived from the hash please?
Either way, it gets hashed into a result which is 3955 (2nd column).
the 3rd column says 55 which I believe is the hash 3955 fed through the reduction function R1? Is this right?
Which then gets hashed again resulting in 4532 which is column 4. That gets reduced by a second reduction function R2 and the result is 45 which is stored in column 5?

Now we hash that to get column 6 which is 3708.
For the "Rainbow Table" we only store the 1st and Last column so that would be 3 from column 1 and 3708 from column 6.
If we need the numbers in the middle later, and I suspect we will, then we have to recalculate them on demand. Is that right?

The Idea being if we have a hash of 3708 we can take the value of 3, run it through the math and get 3 possibilities for our decoded data. it must be either 3, 55, or 45.
We then try hashing each of those 3 and see which one gives us 3708. The one that does is our decoded data?? is this right?
If more then one does then we have a collision and that is bad yes??

Thanks for your help on this issue. It's hard but it's fun.


Top
 Profile  
 
PostPosted: 14 May 2012, 03:13 
Offline
MΩth √G∑∏∫∪≤

Joined: 03 Dec 2007, 11:37
Posts: 1059
Actually since you are looking at WPA-PSK those are just lists of passwords and their hashes. These are neither lookup tables nor rainbow tables. The hard part of cracking WPA-PSK is converting the password into the PSK (Pre-Shared Key) which costs 16,388 SHA1 rounds. Then given the captured handshake packets you can verify if the PSK is correct with only a couple extra SHA1s and MD5s.

So you would precompute the PSKs from the passwords for the SSID and store it in a file. Then use the PSKs in the file instead of generating them on the fly.

-----

jarrod0987 wrote:
I understand that 3 (1st column)would be the a magic number given to us by our rainbow table.
What is it's proper name and how is it derived from the hash please?

The first column is picked at random or sequentially.

jarrod0987 wrote:
the 3rd column says 55 which I believe is the hash 3955 fed through the reduction function R1? Is this right?

yes

jarrod0987 wrote:
Which then gets hashed again resulting in 4532 which is column 4. That gets reduced by a second reduction function R2 and the result is 45 which is stored in column 5?

yes

jarrod0987 wrote:
If we need the numbers in the middle later, and I suspect we will, then we have to recalculate them on demand. Is that right?

yes

jarrod0987 wrote:
The Idea being if we have a hash of 3708 we can take the value of 3, run it through the math and get 3 possibilities for our decoded data. it must be either 3, 55, or 45.
We then try hashing each of those 3 and see which one gives us 3708. The one that does is our decoded data?? is this right?

Not exactly given a hash of 4532 you would lookup 4532 on all the end points then lookup H(R2(4532)) = H(45) = 3708 which you would find that chain and calculate H(R1(H(3))) = H(55) = 4532 and verify it matches your hash which it does so 55 is the password.

_________________
http://www.tobtu.com/


Top
 Profile  
 
PostPosted: 14 May 2012, 03:25 
Offline
Shoulder Surfer

Joined: 12 May 2012, 23:20
Posts: 8
Sc00bz wrote:
Actually since you are looking at WPA-PSK those are just lists of passwords and their hashes. These are neither lookup tables nor rainbow tables.


Isn't a "look up table" a list of passwords and there hashes by definition??
Or would that termanology only refer to rainbow tables?
Would that make such a list only be called a dictionary file?
Perhaps I don't understand what PSK realy is. I know it stands for pre shared key. Doesn't that mean it is a hash of your PW for the purpose of authentication when you enter in the real password and it creates the same identical hash??


Top
 Profile  
 
PostPosted: 14 May 2012, 03:34 
Offline
Shoulder Surfer

Joined: 12 May 2012, 23:20
Posts: 8
"Not exactly given a hash of 4532 you would lookup 4532 on all the end points then lookup H(R2(4532)) = H(45) = 3708 which you would find that chain and calculate H(R1(H(3))) = H(55) = 4532 and verify it matches your hash which it does so 55 is the password."

Ummm...But I said you were given a hash of 3708 not 4532 LOL What are you trying to do to me??

Also I'm not sure what you mean by "endpoint".
Is only the 6th colmn considered an endpoint or is column 2,4, and 6 all considered endpoints?

I'm to understand that colums 2,3,4, and 5 are not saved in the table. Therefore how could I look up 4532 in a column that is not there?


Top
 Profile  
 
PostPosted: 14 May 2012, 21:12 
Offline
MΩth √G∑∏∫∪≤

Joined: 03 Dec 2007, 11:37
Posts: 1059
jarrod0987 wrote:
Isn't a "look up table" a list of passwords and there hashes by definition??

Yes but they are sorted or indexed on the hash so you can search for the hash. With WPA-PSK order doesn't matter because you have to test each entry. Although you would want the most likely password first.

jarrod0987 wrote:
Perhaps I don't understand what PSK realy is. I know it stands for pre shared key. Doesn't that mean it is a hash of your PW for the purpose of authentication when you enter in the real password and it creates the same identical hash??

It takes a password and turns it into a 256 bit PSK using PBKDF2-SHA1. It uses that PSK along with the AP's and client's MACs and nonces to generate a session key to encrypt the connection. I forget the exact way it's done but you can just look at the source for Pyrit or coWPAtty for more details.

jarrod0987 wrote:
"Not exactly given a hash of 4532 you would lookup 4532 on all the end points then lookup H(R2(4532)) = H(45) = 3708 which you would find that chain and calculate H(R1(H(3))) = H(55) = 4532 and verify it matches your hash which it does so 55 is the password."

Ummm...But I said you were given a hash of 3708 not 4532 LOL What are you trying to do to me??

jarrod0987 wrote:
I'm to understand that colums 2,3,4, and 5 are not saved in the table. Therefore how could I look up 4532 in a column that is not there?

3708 didn't really illustrate the way it's searched for since you lookup 3708 and then you find that chain "3 - 3708". Then you do H(R2(H(R1(H(3))))) = H(45) = 3708. You have to search for hash, H(R2(hash)), and H(R2(H(R1(hash)))) which you will need to do H(R2(H(R1(H(start point))))), H(R2(H(start point))), and H(start point) respectively.

jarrod0987 wrote:
Also I'm not sure what you mean by "endpoint".
Is only the 6th colmn considered an endpoint or is column 2,4, and 6 all considered endpoints?

Start point is the first column and the endpoint is the last column. Also the endpoint is usually not a hash it's a password or a truncated hash. The reason behind that is a password is smaller than a hash and if you really wanted to you could increase the chain length at a later time. With a truncated hash it's just for space savings and usually you can't increase the chain length at a later time.

In that article they had this:
Code:
Start point | Endpoint
------------+----------
          3 |     3708
         10 |     5850
         25 |     4202
         68 |     5520
         89 |     5109

_________________
http://www.tobtu.com/


Top
 Profile  
 
PostPosted: 14 May 2012, 23:08 
Offline
Shoulder Surfer

Joined: 12 May 2012, 23:20
Posts: 8
"Yes but they are sorted or indexed on the hash so you can search for the hash. With WPA-PSK order doesn't matter because you have to test each entry. Although you would want the most likely password first."

So what your saying is, Rainbow tables are for when you have a hash to look up. With WPA-PSK you have no hash to look up so you have to try every possible combination? Sorting just increases your likelyhood of finding it faster?

I thought you would use monitor mode to capture a hash of the PSK or perhaps just some random comunication and then use the rainbow table on your recorded sample? Is that not correct?


Ok, I'm trying to follow along with the way these things are written. I kinda get it but it's easier for me just to say hash or R1 or R2 etc. Please let me make sure I am correct.

"You lookup 3708 and then you find that chain "3 - 3708".
3708 is the endpoint, I found it in the table and it gave me the magic number of 3. Yes?

" Then you do H(R2(H(R1(H(3))))) = H(45) = 3708."
So we run it through R1 and R2 and we get 3708 which is what we should get if our table is working right. Yes?

" You have to search for hash, H(R2(hash)), and H(R2(H(R1(hash)))) which you will need to do H(R2(H(R1(H(start point))))), H(R2(H(start point))), and H(start point) respectively."
This is where I'm loosing it. What am i still searching for? I already figured out 45 is my Plain text of the hash 3708? Isn't that what I wanted to know?

To make sure I understand how your refwering to things.. H(R2)hash)) = Hash of R2 which was the first 2 numbers of the hash we did just before it?
"H(R2(H(R1(H(start point)))))" Isn't this just a mathamatical way of saying we take the 6 and recreate the chain using our hash and reduction functions?

Perhaps you could run me through an example so I can see what is happening.

1 So I have 3708 as a hash from something I am trying to get the plaintext for.
2 I look up 3708 in my rainbow table and I find it. = 3 3708
3 I hash the 3. = 3955
4 I check to see if 3955 is 3708. Nope.
5 I take the R1 of 3955. = 55.
6 I hash55. = 4532
7 I check to see if 4532 is 3708. Nope.
8 I take the R2 of 1977. = 45
9 I hash 45. = 3708
10 I cehck to see if 3708 is 3708. Yes.
11 45 is the plain text of 3708. This is the "Decoded" hash I was looking for.
Is anything here not proper?

Thank You


Top
 Profile  
 
PostPosted: 15 May 2012, 00:42 
Offline
MΩth √G∑∏∫∪≤

Joined: 03 Dec 2007, 11:37
Posts: 1059
jarrod0987 wrote:
"Yes but they are sorted or indexed on the hash so you can search for the hash. With WPA-PSK order doesn't matter because you have to test each entry. Although you would want the most likely password first."

So what your saying is, Rainbow tables are for when you have a hash to look up. With WPA-PSK you have no hash to look up so you have to try every possible combination? Sorting just increases your likelyhood of finding it faster?

Yes and yes.

jarrod0987 wrote:
I thought you would use monitor mode to capture a hash of the PSK or perhaps just some random comunication and then use the rainbow table on your recorded sample? Is that not correct?

You can't because it is "salted" per every connect. Basically you capture encrypted data of with a key that is a hash of the two MACs, two nonces (number used once), and the PSK. Given the 256 bit PSK you have access to the network so there is nothing to crack.

jarrod0987 wrote:
"You lookup 3708 and then you find that chain "3 - 3708".
3708 is the endpoint, I found it in the table and it gave me the magic number of 3. Yes?

yes

jarrod0987 wrote:
" Then you do H(R2(H(R1(H(3))))) = H(45) = 3708."
So we run it through R1 and R2 and we get 3708 which is what we should get if our table is working right. Yes?

3 is a password so you hash it then run it through R1 then hash it again and then R2 and then hash it again.

jarrod0987 wrote:
" You have to search for hash, H(R2(hash)), and H(R2(H(R1(hash)))) which you will need to do H(R2(H(R1(H(start point))))), H(R2(H(start point))), and H(start point) respectively."
This is where I'm loosing it. What am i still searching for? I already figured out 45 is my Plain text of the hash 3708? Isn't that what I wanted to know?

"hash" is what ever hash you are looking for. This is the general case for when you don't find it or haven't found it yet. Once it's found you stop.

jarrod0987 wrote:
To make sure I understand how your refwering to things.. H(R2)hash)) = Hash of R2 which was the first 2 numbers of the hash we did just before it?

It's H(R2(hash)) which is do R2 of "hash" (ie 3708) then hash that.

jarrod0987 wrote:
"H(R2(H(R1(H(start point)))))" Isn't this just a mathamatical way of saying we take the 6 and recreate the chain using our hash and reduction functions?

In this case yes, but usually chains end in a reduction function like "R3(H(R2(H(R1(H(start point))))))" and then you would need to run through "H(R2(H(R1(H(start point)))))".

jarrod0987 wrote:
Perhaps you could run me through an example so I can see what is happening.

1 So I have 3708 as a hash from something I am trying to get the plaintext for.
2 I look up 3708 in my rainbow table and I find it. = 3 3708
3 I hash the 3. = 3955
4 I check to see if 3955 is 3708. Nope.
5 I take the R1 of 3955. = 55.
6 I hash55. = 4532
7 I check to see if 4532 is 3708. Nope.
8 I take the R2 of 1977. = 45
9 I hash 45. = 3708
10 I cehck to see if 3708 is 3708. Yes.
11 45 is the plain text of 3708. This is the "Decoded" hash I was looking for.
Is anything here not proper?

Step 4 and 7 are not done because you know that a possible password is going to be the 3rd password in the chain.

When searching a rainbow table you assume that the hash you are looking for is in each of the columns then you finish the chain and then look up that endpoint in the rainbow table. If you find the endpoint in the table then you need to reconstruct the beginning of the chain up until the password before the column the hash was assumed to be in. Then you hash the password and see if it matches the hash. If it matches then you found the password otherwise it was a false alarm.

Also note that each column is a password and it's hash. It's so that chain length is the same as number of columns although this gets messed up a little when chains end in a reduction function. Some formulas use chain length as the number of hashes in the chain and in other formulas chain length is number of passwords in the chain.

_________________
http://www.tobtu.com/


Top
 Profile  
 
PostPosted: 15 May 2012, 03:41 
Offline
Shoulder Surfer

Joined: 12 May 2012, 23:20
Posts: 8
OK, so 4 and 7 have never produced the proper number for me in my tests. I was starting to suspect I should just go right for the R2 hash. So this is normal.
the purpose is just that the number you are refering to as the password (The starting point) is shorter then the true password. Is that right?

Also I am wondering now what would happen if you cannot find your hash in the table?
Are you just out of luck? Or is there some way to extrapolate it from other values that are in the table?

On the subject of salt, thats next on my researh list.

To make sure I understand correctly...
"Encryption" is 2 ways. You can encode and later decode the data.
"Hash" is one way. Once you encode it, there is no decodeing it. The best you can do is keep guessing until you find a plain text that results in the identical hash.

These 2 statements are correct??

Thank you.


Top
 Profile  
 
PostPosted: 15 May 2012, 07:28 
Offline
MΩth √G∑∏∫∪≤

Joined: 03 Dec 2007, 11:37
Posts: 1059
jarrod0987 wrote:
the purpose is just that the number you are refering to as the password (The starting point) is shorter then the true password. Is that right?

Are you talking about "password1234" verse 0x0a35d82 then yes, if you are talking about how chains normally end in a reduction function.

jarrod0987 wrote:
Also I am wondering now what would happen if you cannot find your hash in the table?
Are you just out of luck? Or is there some way to extrapolate it from other values that are in the table?

Yes you are out of luck unless you have another table. There is a way to find all the passwords in the key space that are not in the rainbow table but this is really only feasible for small key spaces 2^46-ish (is really hard like several hard drive-months or is it a few hard drive-years somewhere around there).

jarrod0987 wrote:
On the subject of salt, thats next on my researh list.

If the salt is large enough like 32 bits then it makes rainbow tables worthless but normally you want a salt that is at least 64 bits to avoid collisions.

jarrod0987 wrote:
To make sure I understand correctly...
"Encryption" is 2 ways. You can encode and later decode the data.
"Hash" is one way. Once you encode it, there is no decodeing it. The best you can do is keep guessing until you find a plain text that results in the identical hash.

These 2 statements are correct??

Kind of and yes. Encryption can be turned into a hash like LM where the plain text is known and the password is the encryption key. Also hash functions are usually an encryption algorithm in output feedback (OFB) mode with a key change for every block that only outputs the last block of the keystream as the hash which is why you can "back clock"/reverse/"decrypt" them.

_________________
http://www.tobtu.com/


Top
 Profile  
 
PostPosted: 15 May 2012, 09:12 
Offline
Shoulder Surfer

Joined: 12 May 2012, 23:20
Posts: 8
I think I'm getting a decent handle on this now.

Lets say for example your target is using a password that you know is not going to be in english but is going to be a word , probably all lowercase letters and probably less then 10 characters.

There is probably a program that could generate every possible combination of those characters between say 4 and 10 character lengths.

I gues this is a form of brute force and i am to understand it becomes impracticle at a certain point.

Is there a way to calculate how big of a file would be created if you generated such a list?
EDIT Nevermind, I just found L517. Seems very impractical very quickly.
Is there some kind of way brute force passwords could just be generated in real time and not saved in a word list?
I realize it would still take forever but would not require all the storage space.

Also regarding salt...
I get what it is.
In the case of WPA, I read the Salt is the SSID. If you know the SSID and had already captured the handshake, could that not narrow down the possibilities and perhaps generate a rainbow table of some sort based on that specific SSID? If you did that would making a brute force attack become more practicle due to a smaller sized amount of possibilities?
It seems some people are posting WPA Rainbow tables (They admit it is really a lookup table) for specific SSID's. It seems like this sort of thing is related to the work here with rainbow crack.

Could you explain exactly what it is that is being worked on here and how it differs from what they are doing, pregenerating tables for specific common SSID's?

I used dictionary attacks on my own network already and have that working. Of course I had to use a crappy password so that it would be in the dictionary. I like this Pyrit Cuda thing but I am not smart enough to make it work right yet.
I did just upgrade my GTX 280 to 2x GTX 480's. I hope to eventualy try it out with this cracking stuff.

At some point I might have to buy some math books and then a crypto book. What kind of math is recommended to be able to study cryptogrophy?
As always, Thanks for your help.


Top
 Profile  
 
PostPosted: 16 May 2012, 22:41 
Offline
MΩth √G∑∏∫∪≤

Joined: 03 Dec 2007, 11:37
Posts: 1059
jarrod0987 wrote:
Is there some kind of way brute force passwords could just be generated in real time and not saved in a word list?
I realize it would still take forever but would not require all the storage space.

http://sourceforge.net/projects/crunch- ... -wordlist/ and you can pipe the output straight into Pyrit or coWPAtty.

jarrod0987 wrote:
Also regarding salt...
I get what it is.
In the case of WPA, I read the Salt is the SSID. If you know the SSID and had already captured the handshake, could that not narrow down the possibilities and perhaps generate a rainbow table of some sort based on that specific SSID? If you did that would making a brute force attack become more practicle due to a smaller sized amount of possibilities?

The only thing you can do is generate a list of PSKs from a list of passwords and the SSID. Then use the PSKs to see if any of them are valid for the handshake. In the handshake there are salts that are only used once so you could only generate a RT for the specific handshake. This would be pointless since the work factor to generate a 99.9% rainbow table is 11x (51x for perfect). This means it takes 11x more time to generate the RT than to brute force the key space.

jarrod0987 wrote:
It seems some people are posting WPA Rainbow tables (They admit it is really a lookup table) for specific SSID's. It seems like this sort of thing is related to the work here with rainbow crack.
Could you explain exactly what it is that is being worked on here and how it differs from what they are doing, pregenerating tables for specific common SSID's?

Lookup tables (or in this case hash lists) take up a large amount of disk space O(N) vs O(N^(2/3)) for rainbow tables. So if a lookup table takes 2^51 bytes (2 PiB) then the equivalent rainbow table would take 2^34 bytes (16 GiB).

Lookup tables - O(N) space and O(1) time. Costs about 3 bytes/password* and recover "instantly" (<100ms usually).
Rainbow tables - O(N^(2/3)) space and O(N^(2/3)) time. Costs about log2(N)+2 bits/chain* (another method gets log2(originalChainCount)+5.3 bits/chain*) and usually takes minutes to hours.
Hash lists - O(N) space and O(N) time. Costs about 32 bytes/password* (in this case with WPA) and speeds up recovery by 2,000x-ish.
* Does not include the cost of describing the key space. Brute force style key spaces take a negligible amount of data to describe and can be assumed to be free, but word lists may add a non-negligible amount of space.

jarrod0987 wrote:
At some point I might have to buy some math books and then a crypto book. What kind of math is recommended to be able to study cryptogrophy?

I guess discrete probability and number theory. Well there's always this https://www.coursera.org/course/crypto

_________________
http://www.tobtu.com/


Top
 Profile  
 
PostPosted: 17 May 2012, 01:27 
Offline
Shoulder Surfer

Joined: 12 May 2012, 23:20
Posts: 8
"Lookup tables (or in this case hash lists) take up a large amount of disk space O(N) vs O(N^(2/3)) for rainbow tables. So if a lookup table takes 2^51 bytes (2 PiB) then the equivalent rainbow table would take 2^34 bytes (16 GiB).

Lookup tables - O(N) space and O(1) time. Costs about 3 bytes/password* and recover "instantly" (<100ms usually).
Rainbow tables - O(N^(2/3)) space and O(N^(2/3)) time. Costs about log2(N)+2 bits/chain* (another method gets log2(originalChainCount)+5.3 bits/chain*) and usually takes minutes to hours.
Hash lists - O(N) space and O(N) time. Costs about 32 bytes/password* (in this case with WPA) and speeds up recovery by 2,000x-ish.
* Does not include the cost of describing the key space. Brute force style key spaces take a negligible amount of data to describe and can be assumed to be free, but word lists may add a non-negligible amount of space."

I'm sorry but all this code is just way over my head.

I have been watching video's on people doing "Precomputed" WPA PSK lists before running the dictionary attack. They are only providing a SSID and a word list.
Then when they run the attack later, they get the handhsake first then run the precomputed list for that specific SSID. At least I think that is what is happening. I have tried a few diffrent ways to make this precomputed list but it isn't working out. What am is seeing exactly?

Also, I still stuggle alot just with point my code at files and such. I can see a directory when I type ls. use CD to go Into it. LS again and see the next part of the tree. Try to CD and it tells me theres no such directory even though it is right there. I made sure the spelling and capitalization was correct. It's really frustrated. I've been forced to move my files around to directories that respond instead of the ones I would prefer to use. Any Idea what is happening here?

I also downloaded what I believe is some kind of dictionary that is about 33 gigs. it says it is a .tar.lzma which i understand is some kind of compression. Still trying to figure out how to unzip it to a removable USB HD.

Also, I realy want to learn how to do this feeding one program into another in real time trick. It looks cool but It's a little beyond me right now. Maybe when I get this precomputed stuff to work I can move on tot he real time stuff. I know brute force isn't good anymore but I just want to learn it for understandings sake.

I'm starting to think I need a real time convo with someone instead of posting. It's holding back my learning curve. Can you recomend a voip or IRC (Yuk) where I can get some good linux help?

Thank you for your help.


Top
 Profile  
 
PostPosted: 17 May 2012, 02:36 
Offline
MΩth √G∑∏∫∪≤

Joined: 03 Dec 2007, 11:37
Posts: 1059
jarrod0987 wrote:
I have been watching video's on people doing "Precomputed" WPA PSK lists before running the dictionary attack. They are only providing a SSID and a word list.
Then when they run the attack later, they get the handhsake first then run the precomputed list for that specific SSID. At least I think that is what is happening. I have tried a few diffrent ways to make this precomputed list but it isn't working out. What am is seeing exactly?

People generating lists of passwords and their 256 bit keys. Then using them against a handshake.

jarrod0987 wrote:
Also, I realy want to learn how to do this feeding one program into another in real time trick. It looks cool but It's a little beyond me right now. Maybe when I get this precomputed stuff to work I can move on tot he real time stuff. I know brute force isn't good anymore but I just want to learn it for understandings sake.

http://code.google.com/p/pyrit/wiki/ReferenceManual
Option "-i infile" "Specifies a filename to read from; the special filename '-' can be used for stdin."
./crunch 8 8 abcdefghijklmnopqrstuvwxyz | ./pyrit -i - [everything else you need]

jarrod0987 wrote:
I'm starting to think I need a real time convo with someone instead of posting. It's holding back my learning curve. Can you recomend a voip or IRC (Yuk) where I can get some good linux help?

No clue

_________________
http://www.tobtu.com/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group