08-15-2017, 02:26 AM
(This post was last modified: 08-15-2017, 02:27 AM by mrfancypants.)
I am not sure I even understand your difficulty.
Let's take NVG589 specifically. We have an algorithm that takes in a 64-bit integer 'x' and spits out a 12-letter password:
for n in range(0,6):
pw=pw_charset[x%37] + pw
x/=37
pw=chr(50+(x%8)) + pw
x/=37
For whatever reason, AT&T people don't just pull an 'x' out of a RNG or something, instead they pull a 31-bit int and multiply it by a magic number that is approximately 465661287.5245797. (Or possibly do some slightly longer sequence of multiplications and additions which amounts to the same thing, because simply multiplying by that number does not always yield the exact result. But ignore that for now.)
Now, where did they get 465661287.5245797? Beats me. All I know is: (1) if they are starting with a 31-bit number, they had to multiply by _something_ (to span the whole range of passwords), since feeding a 31-bit value direct into code above would always result in passwords that start with 2a2a2a..; (2) that exact value reproduces many of the passwords I see in the wild and that can't be a coincidence. (To calculate it, I basically had the computer run through all possible values until it found one that gave lots of hits.)
for NVG599, they tweak the number->password conversion algorithm and replace the 465... value with 2^32+2. Again why 2^32+2? Not a clue.
Let's take NVG589 specifically. We have an algorithm that takes in a 64-bit integer 'x' and spits out a 12-letter password:
for n in range(0,6):
pw=pw_charset[x%37] + pw
x/=37
pw=chr(50+(x%8)) + pw
x/=37
For whatever reason, AT&T people don't just pull an 'x' out of a RNG or something, instead they pull a 31-bit int and multiply it by a magic number that is approximately 465661287.5245797. (Or possibly do some slightly longer sequence of multiplications and additions which amounts to the same thing, because simply multiplying by that number does not always yield the exact result. But ignore that for now.)
Now, where did they get 465661287.5245797? Beats me. All I know is: (1) if they are starting with a 31-bit number, they had to multiply by _something_ (to span the whole range of passwords), since feeding a 31-bit value direct into code above would always result in passwords that start with 2a2a2a..; (2) that exact value reproduces many of the passwords I see in the wild and that can't be a coincidence. (To calculate it, I basically had the computer run through all possible values until it found one that gave lots of hits.)
for NVG599, they tweak the number->password conversion algorithm and replace the 465... value with 2^32+2. Again why 2^32+2? Not a clue.