03-18-2022, 01:23 AM
Since this is a hashcat forum let me bring the discussion back to hashcat.
We have two examples of a string appended to the serial number (/usr/lib/librgw_compat.so.0.0.0 and /sbin/sysinit) and one without adding anything at all (/usr/bin/videossid).
There is also one example of using the access code instead. (http://en.techinfodepot.shoutwiki.com/wi...26T_Uverse)
We have two examples of AT&T using MD5 to generate a router unique code (/sbin/sysinit and the techinfodepot link) and one using SHA1 (/usr/bin/videossid)
The AT&T programmer could potentially use the same starting string (e.g. the serial number), add a different suffix string to generate each of the eSSID, videoSSID, video password, access code and wifi password all using the same algorithm. So what I'm trying here is to reverse engineer the AT&T programmers' thinking and determine the suffix string. (if *big IF* this is how it was originally generated)
There are three router dependent data as a starting point to generate a string to feed a hashing algorithm and that can potentially be brute-forced into rainbow tables of passwords (<1e11 possibilities): Serial number, access code and MAC (drunk looking under the street lights for his keys). From there, as exemplified by the videoSSID algo, one can take the modulus of each byte of the digest to the length of the charset. For the WIFI password this would be 37 (with the exception for the first character of the password, which is modulus 8)
So let's presume the charset is the default choice:
abcdefghijkmnpqrstuvwxyz23456789#%+=?
And we'll use the first entry in the table above:
password 2u47nk96b58m with serial number 32161N114933
Hascat has a half MD5 mode 5100, so you could take the first 8 characters of the password and turn those into hashes:
2 u 4 7 n k 9 6 (letters of the password)
0 18 26 29 12 10 31 28 (position in charset)
00 12 1a 1a 0c 0a 1f 1c (converted to hexadecimal)
00121a1d0c0a1f1c (without spaces: first half of the MD5 hash)
So that's the minimum hash to would produce the password, however, all other hashes that also result in the password after each byte modulus 37 will need to be included. You'd just need to keep adding 37 to each byte until it is bigger than 255, than add 37 to the byte prior. Here's a sampling
00121a1d0c0a1f1c
00121a1d0c0a1f41
00121a1d0c0a1f66
00121a1d0c0a1f8b
00121a1d0c0a1fb0
00121a1d0c0a1fd5
00121a1d0c0a1ffa
00121a1d0c0a441c
00121a1d0c0a4441
00121a1d0c0a4466
00121a1d0c0a448b
00121a1d0c0a44b0
00121a1d0c0a44d5
00121a1d0c0a44fa
00121a1d0c0a691c
00121a1d0c0a6941
...
f8f0f8fbeae8fdd5
f8f0f8fbeae8fdfa
Again each of these half-hashes after taking modulus 37 and projecting those results onto the charset will result in the first 8 chars of the password. For this example there will be 26 million hash entries per charset that would all turn into the password. But hashcat is only about a 1% slower looking for millions hashes versus a single hash when they are unsalted. So then we can use hashcat's power to try to determine the string appended to the serial number.
hashcat -m 5100 -w 4 -O sorted_half_hashes.hash -a 3 -1 ?u?l?d-_ 32161N114993?1?1?1?1?1?1?1?1
There will be quite a few results so you will have to sort through those. e.g.
32161N114993DaoNBdVa MD5 hash will result in 78F0AE67A0541F1C010FDE275A608A11
Then a mod 8 on the first byte and mod 37 on the rest will give
0 18 26 29 12 10 31 28 1 15 0 2 16 22 27 17
Projecting the first 12 bytes onto the charset will give you
2u47nk96brac while it should be 2u47nk96b58m, so close but no cigar!
So this is how hashcat can potentially help trying to get at the password generating algorithm. If only it had a truncated SHA1 mode....
We have two examples of a string appended to the serial number (/usr/lib/librgw_compat.so.0.0.0 and /sbin/sysinit) and one without adding anything at all (/usr/bin/videossid).
There is also one example of using the access code instead. (http://en.techinfodepot.shoutwiki.com/wi...26T_Uverse)
We have two examples of AT&T using MD5 to generate a router unique code (/sbin/sysinit and the techinfodepot link) and one using SHA1 (/usr/bin/videossid)
The AT&T programmer could potentially use the same starting string (e.g. the serial number), add a different suffix string to generate each of the eSSID, videoSSID, video password, access code and wifi password all using the same algorithm. So what I'm trying here is to reverse engineer the AT&T programmers' thinking and determine the suffix string. (if *big IF* this is how it was originally generated)
There are three router dependent data as a starting point to generate a string to feed a hashing algorithm and that can potentially be brute-forced into rainbow tables of passwords (<1e11 possibilities): Serial number, access code and MAC (drunk looking under the street lights for his keys). From there, as exemplified by the videoSSID algo, one can take the modulus of each byte of the digest to the length of the charset. For the WIFI password this would be 37 (with the exception for the first character of the password, which is modulus 8)
So let's presume the charset is the default choice:
abcdefghijkmnpqrstuvwxyz23456789#%+=?
And we'll use the first entry in the table above:
password 2u47nk96b58m with serial number 32161N114933
Hascat has a half MD5 mode 5100, so you could take the first 8 characters of the password and turn those into hashes:
2 u 4 7 n k 9 6 (letters of the password)
0 18 26 29 12 10 31 28 (position in charset)
00 12 1a 1a 0c 0a 1f 1c (converted to hexadecimal)
00121a1d0c0a1f1c (without spaces: first half of the MD5 hash)
So that's the minimum hash to would produce the password, however, all other hashes that also result in the password after each byte modulus 37 will need to be included. You'd just need to keep adding 37 to each byte until it is bigger than 255, than add 37 to the byte prior. Here's a sampling
00121a1d0c0a1f1c
00121a1d0c0a1f41
00121a1d0c0a1f66
00121a1d0c0a1f8b
00121a1d0c0a1fb0
00121a1d0c0a1fd5
00121a1d0c0a1ffa
00121a1d0c0a441c
00121a1d0c0a4441
00121a1d0c0a4466
00121a1d0c0a448b
00121a1d0c0a44b0
00121a1d0c0a44d5
00121a1d0c0a44fa
00121a1d0c0a691c
00121a1d0c0a6941
...
f8f0f8fbeae8fdd5
f8f0f8fbeae8fdfa
Again each of these half-hashes after taking modulus 37 and projecting those results onto the charset will result in the first 8 chars of the password. For this example there will be 26 million hash entries per charset that would all turn into the password. But hashcat is only about a 1% slower looking for millions hashes versus a single hash when they are unsalted. So then we can use hashcat's power to try to determine the string appended to the serial number.
hashcat -m 5100 -w 4 -O sorted_half_hashes.hash -a 3 -1 ?u?l?d-_ 32161N114993?1?1?1?1?1?1?1?1
There will be quite a few results so you will have to sort through those. e.g.
32161N114993DaoNBdVa MD5 hash will result in 78F0AE67A0541F1C010FDE275A608A11
Then a mod 8 on the first byte and mod 37 on the rest will give
0 18 26 29 12 10 31 28 1 15 0 2 16 22 27 17
Projecting the first 12 bytes onto the charset will give you
2u47nk96brac while it should be 2u47nk96b58m, so close but no cigar!
So this is how hashcat can potentially help trying to get at the password generating algorithm. If only it had a truncated SHA1 mode....