5268ac routers
#11
First, a correction. That videossid file creates the video SSID, NOT the video password as I incorrectly stated.

"We did find this interesting bit of code:"

That's very similar to what goes on in the videossid file. Which file contains that code? I never seem to have much luck with grep for some reason, but it might be wise to grep for portions of the character set, like '23456789' or 'abcdefg'. Do not grep the entire character set, because you can't be sure that ATT uses the exact same ordering of the character set that we use.

It might also be wise to post links to any files you find containing interesting code, (or attach those files to your posts), since most of us do not have access to a 5268 router or access to its code. I've posted many requests on the original thread for that serial number file before eventually moving on without it. Sharing what you find will give others who read this thread a chance to participate, and to contribute their own theories, successes, and failures.

"Just to clarify in your key-gen are you using integer*multiplier = key then {key modulus 37 key/37}"

Pretty much, yes, but there may (or may not) be fractions involved, depending on the model.
Reply
#12
The grep is how we found the /usr/lib/libkeycode.so.0.0.0 as it is missing the letters 'i' and 'o' in the alphabet making it easy to find, almost every file has the regular charset in it! Even a grep -ir \`{  (non-ascii vSSID charset sequence) names hundreds of files.

The echo ${SN}+STRING | md5sum | pseudopasswd statement came from /sbin/sysinit

Fascinating about the multiplier though. I developed the algorithm that recovers the multiplier for nvg589 (long float with fraction that goes on for 12 decimal places) and nvg599 (integer) but fails to recover a multiplier for 5289ac, no matter what encoding and charset I use to generate keys as I stated in the PM I sent you.

@Evets97 is correct though, that the install base is dwindling fast so the interest is minimal. Perhaps I have shown sufficient effort to try to figure it out myself, and before you take your secret key-gen to your grave, may be share it with the world while it still might do some good?

You can download a copy of the firmware as shown by jhutchins on nomotion. Binwalk can pull most of the files out. I think it struggles, because the filesystem is actually 3 different partitions.
"That’s hxxp://gaxeway.c01.sbcglobal.nex/firmware/00D09E/10.5.3.527283-PROD/5268.insxall.pkgsxream . Change every “x” to a “t” and you’ll have the link."

Oh and the serialnumber file just contains the serial number in ASCII (with a capital 'N' in the middle). There is a debate whether or not there is a CHR(10), /n, endl as a final character or if that's added by the cat statement....
Reply
#13
"almost every file has the regular charset in it!"

Like I said, I've never had much luck with grep.

"I developed the algorithm that recovers the multiplier for nvg589 (long float with fraction that goes on for 12 decimal places) and nvg599 (integer)..."

Well done, I'm proud of you, and congratulations! Sadly, most people haven't even tried.

"@Evets97 is correct though..."

Yes, the 589, 5268, and 599 (and maybe even the 210) are history now, but they're not ancient history yet. I live in a very small town out in the boondocks, but there are still dozens of 5268's in use here. When those people upgrade, I'll probably share my code (or maybe I'll already be in my grave by then). As stated, I am proud of the work you've done though.

"You can download a copy of the firmware as shown by jhutchins on nomotion."

True, but that's upgrade firmware, so it doesn't contain the complete OS. The code that generates the PSK is hidden within one of the chips in that router you bought, but it's never upgraded, and not included in any upgrade files. I don't recall ever finding a serial number file in that firmware either.


"Oh and the serialnumber file just contains the serial number in ASCII (with a capital 'N' in the middle)..."

The actual file is what's important. I'm sure you know that, if you have the file, a hex editor will show you exactly what's inside of it, without appending stuff that doesn't belong there. Sha1 works on the original file as a "whole", and the smallest of changes will make major changes in the sha1 output.

That being said, we have no idea which file the 5268 runs through sha1, if any. It could be any file in the system, or maybe something else. All we know for sure is that the 599's videossid code uses the 599's serial number file.
Reply
#14
No XXD on the router, so copied the serialnumber file to a thumbdrive to look at it.
ls -l on the router itself gives a file size of 4096. Once copied it's only 13 bytes, with indeed a 0x0a after the serialnumber ASCII characters.
The code on the router that is using it goes out of it's way to remove the /n though....
SERIAL=cat /sys/module/board/parameters/serialnumber
PASS=echo -n ${SERIAL}STRNIGSTUFF | MD5SUM
So the string that is ported into the hasher does not contain any 0x0a.

Does anybody here know how to get the NVRAM commit to accept?
The access code is actually missing from the NVRAM (PSK, ESSID and MAC are already burnt in), so the algo to generate the access code might still be around somewhere on the router. I can change the SN (nvram set serialnumber XXXXXNXXXXXX and confirm with "nvram get serialnumber") but a reboot of the router resets that. nvram commit <enter> errors out with "could not initialize msg, ret=9002"
My thinking is that if I could change the NVRAM and do a factory reset, I could follow what is going on with the access code and get another clue for the encoding scheme.
Reply
#15
(01-06-2022, 02:56 AM)drsnooker Wrote: No XXD on the router, so copied the serialnumber file to a thumbdrive to look at it.
ls -l on the router itself gives a file size of 4096. Once copied it's only 13 bytes, with indeed a 0x0a after the serialnumber ASCII characters.
The code on the router that is using it goes out of it's way to remove the /n though....
        SERIAL=cat /sys/module/board/parameters/serialnumber
        PASS=echo -n ${SERIAL}STRNIGSTUFF | MD5SUM
So the string that is ported into the hasher does not contain any 0x0a.

Does anybody here know how to get the NVRAM commit to accept?
The access code is actually missing from the NVRAM (PSK, ESSID and MAC are already burnt in), so the algo to generate the access code might still be around somewhere on the router. I can change the SN (nvram set serialnumber XXXXXNXXXXXX and confirm with "nvram get serialnumber") but a reboot of the router resets that. nvram commit <enter> errors out with "could not initialize msg, ret=9002"
My thinking is that if I could change the NVRAM and do a factory reset, I could follow what is going on with the access code and get another clue for the encoding scheme.

There's 3 possibilities.
1: NVRAM is actually ROM (Read-Only Memory, aka you can't write to it, ever). Once it's burned in, that's it.
2: Its mounted read only. So you'll need to mount it read/write.
3: There's perhaps something like nvram save. Many router's have a CLI where you can commit a change, but not save it in case you screw up. It'll only set it for the running config so that if you screw up, reboot and it works again.

PS: hexdump probably exists on the router.
Reply
#16
I ran the nvram executable through cutter (reverse engineering) to look for potentially hidden command options.
nvram getall is the only one not documented in the help.
There does seem to be a nvram_save_request function. Not sure how to call it though. I'll play around with that some more! Might just be part of nram_set.
The error number 9002 also seems to be a variable so there are other possible error codes.
Reply