Keyspace List for WPA on Default Routers
Maybe you're interested in this (not only ATT):

You can reduce the key space, if you assume "N0" within every serial number:
That makes life easier (and faster) to run first tests against some well selected hashes.
Not knowing C or C++ but pretty good at matlab, I've managed to take the code shown earlier and created a matlab version so I can create the dictionaries for GVN589 and 599. It was a struggle dealing with some of the 128 bit operations and deciphering all the weird C code, but it now matches the outputs upto intmax.

PM if you want a copy of the code. Here's a teaser:

function psk=genpass589(x)

CHARSET = 'abcdefghijkmnpqrstuvwxyz23456789#%+=?';


y=int128_product_shift(y); %128 bit integers

y=psk_rounding(y); %back to 64 bits


for i=0:5
Well silly me. It just takes to dang long. So I thought I'd learn python and do it in there. It's the exact same speed!!!! Alright, I guess I gotta go dig into C++ get a compiler going so it might be 10x faster then what I got now.
Fart-box if you can tell me the errors at least I won't have to generate those giant files multiple times. (was actually doing 10M chunks each on 8 cores to speed things along)
I may get flak for going a bit off-topic, but...
From what i have researched from research papers(and stuff), routers mostly use part of sha1(and derivatives), md5 or base64 hashes for passkey generation(like doing sha1 hash and taking 10 first chars from that hash). I have been tinkering with those hashes and found out that they *may* follow some kind of rules. Maybe not, so here i am asking from professionals.
Example problem(let's say sha1): Is it possible to know the least possible character on 3rd position after knowing first two characters on sha1 hash? Or the least possible character on 4th position after knowing first three characters?
(06-10-2020, 10:57 PM)hashserious Wrote: Is it possible to know the least possible character on 3rd position after knowing first two characters on sha1 hash? Or the least possible character on 4th position after knowing first three characters?

Thanks Far-box. Let me digest that. First I'm learning to program C++ to speed up the creation of the dictionaries. Matlab is useful for exploring data sets and visualization, but it's not build for speed! (turns out python isn't either). At one point actually want to learn more about CUDA as well!
Getting closer. Got the c-code running in Got a copy of visual studio 2015, so now I'm just trying to figure out how to clear all the error codes and which .h modules I'm missing to make it go!

Okay I'm beginning to understand what fart-box is saying that the password is really just a heptatrigesimal representation. But your example key '2a4w8c3c7#8x' isn't an actual key is it? The keygen for nvg589 with a seed of 710684 is pretty close but not exact. So far both examples are seed (upto intmax) * XXXXXX then convert to heptatrigesimal presentation. However the multiplier (XXXXXX) for 589 and 599 are very different. And I don't know what it is for 5286. But you gave me clue and that's I'll have to work backwards from actual keys, convert to a int64 and work from there. Alright back to matlab to do some digging....

hmmmm. so I'm getting different keys...
2a4w8c3c7#8x 330178273358843
2c7p482e7w3= 10053172903997416
2e3c76393722 19891432910040544

If you feed those back into the algorithm after all the bitshifting manipulation (by MrFancypants) of the seed, you get the right password out. Perhaps I still don't understand what you mean by key. Seed*multiplier=key --> password?
Okay, so I completely follow Mr. Fancypants! (in matlab)
>> genpass589c(double(501073112)*465661287.5245797)
ans =
but then your key:
ans =
so a few decimals in the middle are different, are you using a (mod 37) or a (mod 8) for the odd characters in the pw? That (mod 8) ripples through the whole password (well all the numbers, the letters stay the same), but I managed to reproduce it. Mod 37 isolates each character in the password. I need to test it to see if that makes your key match that.

It indeed that falls apart with the other keys. Man what time wasted on a dead-end LOL. I need more thinking time....
That's what I thought and that was the obvious solution. However, that's not the SoxRok code.... I got this running in (still working on learning C++) That Mod 8 is causing the wrong answer (3m5p5s349p3m). So everybody who used SoxRoks version has the wrong dictionary for 589! I had to rewrite all my code to make the results match SoxRok. Oh well, back to return to the original code! That also means it's the same as 5268!

#include <iostream>
using namespace std;
#define ATT_NVG5XX_PSK_LEN 13

void genpass589(uint64_t key, unsigned char *psk) {
static const char CHARSET[] = "abcdefghijkmnpqrstuvwxyz23456789#%+=?";
int i;

uint64_t two = key;
psk[ATT_NVG5XX_PSK_LEN - 1] = 0;

for (i = 0; i < 6; i++) { // select character from the charset at given position
int key1 = CHARSET[two % 37];
two /= 37;
int key2 = 50 + (two % 8);
two /= 37;
psk[(10 - (i * 2)) + 1] = key1;
psk[(10 - (i * 2))] = key2;

int main(void){
    uint64_t key=234369665153722384;
    unsigned char psk[ATT_NVG5XX_PSK_LEN];
    genpass589(key, psk);
    cout << psk;
Well I finally understand the appeal of C++! I got the Soxrok code compiled and generated (the wrong) dictionaries. Took about 7 minutes! (instead of 10 days in matlab) And only takes about an hour to run through hashcat6.
Alright now for going back to understanding all the hints Fart-box dropped, to convert indexes to keys to passwords...
A book can't possibly be 37^11 (times 13 characters), that's probably more storage than atoms in the universe!