Crunch password list with exact length and number of letters and numbers known

Yes, that math is correct.

Your 56gb file is only about 3% of the size of the eventual output. :)

There's honestly no point in generating on-disk files like these - your particular password criteria is so extremely simple to generate procedurally that any good password cracker should either have a brute force capability built in that would meet your needs, or it should be able to read wordlists from off a pipe rather than off disk.

Actually, any good password cracker should be able to do both of these things. :)

also, here's the math on that other guy's problem:

The password contains one digit - that's 10^1 = 10 possible combinations.
The password contains 19 lowercase alpha characters - that's 26^19 = 766467265200361890474622976 possible combinations.

If the digit was in a fixed location, then you could multiply these two numbers together and have the total number of combinations, but the digit can be anywhere in the password, so we have the following set of possibilities:

19 alphas, 1 digit
18 alphas, 1 digit, 1 alpha
17 alphas, 1 digit, 2 alphas
...
1 digit, 19 alphas

That's 20 possible character alignments.

The total number of password combinations is therefore 26^19 * 10^1 * 20 = 153293453040072378094924595200

Assuming that we're creating a wordlist for some program that expects each password to be delimited with a newline then that means each password is 20 bytes in size + 1 for the newline (let's ignore MSDOS/Win32 and it's CR/LF combinations).

The total storage space is therefore 26^19 * 10 * 20 * 21 = 3219162513841519939993416499200 bytes.

There's no filesystem that I know of capable of storing 2.6 million yottabytes of data, so you might be out of luck if you plan to output this data to storage.

Of course you can generate large wordlists and run into storage problems however there is a bigger problem. Most applications in BT4 can only handle 2GB or less sized files. 2GB is the maximum filesize for 32-bit OSs. Yes there are workarounds (crunch uses them) but john the ripper and aircrack can't use a wordlist greater than 2GB in size. Then there is performance impact. To maximize performance you should have enough free RAM to store the wordlist in RAM. If you have a 2GB wordlist with 1GB of RAM performance will be horrible.

I'm pretty sure BT4 is using a 64-bit kernel. As to the specifics of the word size you're using in this app or that (size_t vs size64_t), I don't know.

There's also no reason to store the passwords in memory or anywhere else after you have tried them and proven they don't work - this is what I was trying to say earlier. Depending on the level of parallelism in the particular app, I'd be surprised if you needed any more than a hundred passwords stored in memory at any given moment; just generate candidate passwords procedurally.

firstly i would like to say thanks for replying to my question, so thank you...

however i am clearly not grasping something still, maybe you could help me clear this up as well.

we have confirmed that my wordlist should come out @ 1.70934398 terabytes (according to the math posted earlier in the thread)

this is what i don't understand, a collegue of mine has a LM hash rainbow table set which i believe contains all the keyboard characters (excluding the UK pound sign, £ ). he isn't around at the moment but i believe it weighs in at around 40gb or so

how come this is substantially less in filesize than my only 8 character wordlist if in theory it should contain more combinations...i know LM takes a password splits it into 2 smaller words and makes it into UPPERCASE (something like that ;) but surely there is still many more combinations and therefore should equal a bigger filesize

the theory which jumps out at me straight away is that rainbow tables are in someway compressed hence his lower filesize, i can ask him later but can anyone shed any light on this for me please

regards

BT4 is 32-bit. It can support some 64 things using some gcc hacks (please don't quote me on this I really don't fully understand how it works). The old forums had a thread on 64-bit BT. I think it is at 64 bit version - Remote Exploit Forums

Oh hey, looks like you're right:

Code:

---

root@bt:~# gunzip -c /proc/config.gz | egrep CONFIG_64BIT
# CONFIG_64BIT is not set
root@bt:~#

---

In any case, I was being facetious in my earlier post - whether you're using a 32-bit kernel or a 64-bit kernel makes no difference, it's too much data to store, and since we're talking about an exhaustive brute force scenario, there's absolutely no reason to want to try to store it in the first place.

The point I was trying to make is that with a password of this length, brute force just isn't feasible - forget about storage, even if you totally luck out and the password just happens to begin with 'aaaa' (meaning it'll be right up near the beginning of the list of passwords you try), and even if you've got some kind of supercomputer that can do a billion password tests per second, you're still going to have to wait for up to 8 million years to recover the password.

Anyway, on to the OP and his rainbow tables question:

You're comparing apples and oranges - on the one hand, you want an exhaustive list of every possible password that meets certain criteria so that you can try each one until you find the right one.

On the other hand, your friend has a list of password strings organized in such a manner that - if you know a hashed password string - then you can lookup a string that will produce the same password hash very quickly.

In this scenario, your friend has better information than you do - he knows what the a hashed password is, and he knows the algorithm that was used to produce the hash (LM). With these two pieces of information, he can get the answer much quicker.

Note that this isn't a hard and fast kind of a relationship - in this particular case, your friend has the advantage.

If, on the other hand, your friend knew that the hash algorithm was MD5 or SHA, then he might very well be screwed because it's not yet feasible to create a complete rainbow table containing password strings for every possible hash value for these algorithms yet, but you might be OK because you happen to know that the password is only 5 mixed alpha characters and it's not infeasible to brute force that.

Hi guys just wondering if any off you know how to tell crunch to make a alphanumeric wordlist 8 characters long but to exclude ALL combos with repeat letters/numbers and word that are not letter/num/letter/num/letter/.... or num/letter/letter/....etc ???

as i believe this is more realisable format and would cut down size by quite some way although i'm sure still massive!

Thanks

B.

Quote:

---

Originally Posted by purehate

Sure you would do it like this:

crunch 20 20 abcdefghijklmnopqrs9 > passwordlist.txt

---

I am sorry. I am new to BT4. When I type above commond in in BT4. It returned command not found. I booted up using a CD. How do I get above command to work?