PDA

View Full Version : Is it possible to reverse engineer a WPA key if you have the hex code?


NamelessNom4d
03-30-2009, 05:05 PM
I'm sure it is, you would just have to reverse the algorithm that generates the hex code from the SSID and the WPA key.

This is a hex code generator: http://www.xs4all.nl/~rjoris/wpapsk.html

Except, what I need is something that can take the hex code and SSID and give me the ASCII version. I'm sure I could take the javascript from that page and rewrite the code to do this, but why rewrite code if it already exists? Does anyone know of anything that does this?

I especially don't want to go crazy trying to figure out how to rewrite that code... my coding skills are a bit basic, high school level. :rolleyes:

NamelessNom4d
03-30-2009, 05:27 PM
After looking into this further, it seems a bit more complicated than just reversing the algorithm, which I now know is called PBKDF2. I'll have to look into this further once I get home, but something tells me it's a bit more complicated than just rewriting code.

But my original question still holds, is it possible to derive the WPA passphrase from the hexadecimal number?

Axiom
03-31-2009, 07:40 AM
If the acronym stands for Password-Based Key Derivation Function 2 you can almost be certain it's a one way hash, plus salt...

NamelessNom4d
04-01-2009, 04:59 PM
Okay... it looks like it's impossible to reverse engineer something like this, probably why it's so widely used.

BUT, is there a program out there that can crack it? How long would it take to brute force something like that? I would need a program to generate hex codes from the SSID and a random password, and check it against the correct code.

Something tells me that would take a while... I know it's 8 characters at least, or at least I'm 95% sure it is 8 characters.

Animal Farm Pig
04-01-2009, 10:55 PM
You could use a word list to generate a table in the form of: "plaintext, hash". Then, just grep the file for the hash.

Implemented in pseudo-code, it would look like this:

MyWordList = open('somewordlist', 'read binary')
MyTable = open('somefilename', 'write binary')
for Word in MyWordList:
HashedWord = HashFunction(Word)
MyTable.writeline(Word, HashedWord)


Edit:

Hmm... okay... I just actually read a bit about the algorithm and "salting". Well, I suppose you could wrap everything above in a loop and change salt values at each iteration...

There's a nice equation here: http://en.wikipedia.org/wiki/Salt_(cryptography)

If you know a little bit about the password, you could reduce by a great amount the amount of computation. For example, don't bother to compute plaintexts shorter than 8 chars; use only dictionary words; use only lower case, or initial capitalization, etc.

Because of the amount of iterations necessary, it's probably not practical to write to file. Probably more appropriate to have something like "do {GenerateHash} while(GeneratedHash != TargetHash)".

The wikipedia page on PBKDF2 (http://en.wikipedia.org/wiki/PBKDF2) has links to implementations in a couple different languages.

I should also add that I don't really know anything about cryptography, but this seems like an interesting problem to me, which is why I'm responding.

Axiom
04-01-2009, 10:58 PM
You could use a word list to generate a table in the form of: "plaintext, hash". Then, just grep the file for the hash.

Implemented in pseudo-code, it would look like this:

MyWordList = open('somewordlist', 'read binary')
MyTable = open('somefilename', 'write binary')
for Word in MyWordList:
HashedWord = HashFunction(Word)
MyTable.writeline(Word, HashedWord)


Hmm... okay... I just actually read a bit about the algorithm and "salting". Well, I suppose you could wrap everything above in a loop and change salt values at each iteration...

In theory, but what will your salting algorithm be?

My understanding is that by the time you can afford a computer to give you a reasonable chance of doing it, security policy would have changed the password many times over...

Animal Farm Pig
04-01-2009, 11:25 PM
In theory, but what will your salting algorithm be?

My understanding is that by the time you can afford a computer to give you a reasonable chance of doing it, security policy would have changed the password many times over...

Depends how long the salt is and how it's typically generated. I suppose that could be found out by reading documentation, but right now I don't have the time to dive into it.

If I find myself with enough free time and it turns out to be mathematically feasible, I might be willing to collaborate with someone on this. I've written a small Python module for clustering / distributed computing that would be useful for this kind of number crunching.

NamelessNom4d
04-02-2009, 04:49 AM
I should also add that I don't really know anything about cryptography, but this seems like an interesting problem to me, which is why I'm responding.

Neither do I, that's why I asked the question in the first place! :D

I also haven't coded much of anything in like a year... so I might find it a bit difficult at first to create a program that works, since I am rusty.

Prometheum
04-05-2009, 04:16 AM
aircrack-ng.