Keyspace List for WPA on Default Routers
(12-28-2024, 05:24 AM)Have Blue Wrote: One thing that struck me was the prevalence of the 'b' character versus 'a' which made me wonder if zeroes are for whatever reason much less likely to be generated from whatever the 'seed' is (my assumption being that 'a' equates to '0' and 'b' equates to '1').  I had done a statistical analysis on the data, and 'b' was indeed among the most common characters.

Yeah the 640L algo would produce the same amount of 'a' vs 'b' but almost twice 'abcdef' vs 'ghij' so I blamed it on the small sampling size, but it could be a completely a different algo that treats 0 differently. There's definitely something fishy going on. If you overlay the letters and numbers they show a similar tendency for 1/b and slightly lower for 2/c.
The other chars could even be about the same likelihood. Won't know how any of this works until we find the algo in a random firmware somewhere. 


[Image: V4nGnigB_o.png]
Reply
I think I got something to at least explain the above graphs.
Take all values 0,1,2,3, .... 255 and look at the probabilities of each number occurring. Doesn't that look exactly like the probabilities of the characters in the password? (See graph below)

What does that mean for the algo? Well, my guess it's just three bytes, perhaps the last three of the MAC followed may be with a checksum char like WPS pins. 
3 bytes, may be some math, with probably some XORs, directly translated into the password.

Say the MAC is e46f136876c4 --> 0x68 0x76 0xc4 --> 104 118 196 C
convert half to a-j and you have a password that matches the above probability distribution.

[Image: N24mZF6.png]
Reply
Hacked together some c-code. Catches 17 out of the 19 dir605l passwords I've collected. It generates a 50G dictionary in about 20 minutes. There are quite a few identical passwords in the rainbow table, so sort -u will help cut it in half.

It misses when the length of combined four bytes is less than what is need to fill the password.
e.g.  febii86601 --> 5418886601 cannot be split in 4 bytes , you'd need 5 bytes.
54 188 86 60 1
(although in this case you could flip left to right and get there, but then you'd miss on a different password in my collection)
Instead of the padding "000000" you'd need to do something a bit more clever to fill the remainder to get to 10 chars, some sort of recursive loop. I'm sure an actual programmer can figure that out!

Of course I'd rather have the real algorithm, but this can work until that is discovered. 
Working backwards from the password may work: password --> bytes --> ?math? <-- mac  
May be I'll give that a whirl tomorrow.

Code:
#include <stdio.h>

int main() {

    int byte1, byte2, byte3, byte4;
    char buffer[20];
    int pos;

    for (byte1 = 0; byte1 < 256; byte1++) {
        for (byte2 = 0; byte2 < 256; byte2++) {
            for (byte3 = 0; byte3 < 256; byte3++) {
                for (byte4 = 0; byte4 < 256; byte4++) {
                    sprintf(buffer, "%d%d%d%d%s", byte1, byte2, byte3, byte4,"000000"); // add padding
                          for (pos=0;pos<5;pos++)
                              buffer[pos]=buffer[pos]+49;
                         buffer[10]=0; // trim to first 10 chars
                         printf("%s\n",buffer);
}
}
}
}
}
Reply