5268ac routers

[drsnooker]

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.

[soxrok2212]

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.

[drsnooker]

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.

[drsnooker]

With the latest ebay offering, and the help of @red1337, @mrfancypants, @bitwise bill, @soxrok2212, I have collected 600 wifi passwords for the 5268AC and most serial numbers, SSIDs and MACs. Some users have dropped of the radar so I'm sure they won't mind that I share them with the world. PM me if you want a copy!

[drsnooker]

Not all firmware versions allow root access and not all firmware have the videossid binary. But we found one that had both. 

# cat /sys/module/board/parameters/wifi5gssid1
vATT5$Hni18
# /usr/bin/videossid
vATT&dap1e;
#


So the found algorithm to generate the videoSSID does not generate the actual videoSSID and is likely vestigial from perhaps another router.

In the mean time, we found a lot of similarities between the wifi password as well as the ESSIDs, access codes, vSSIDs and its password. They all share the same characteristics hence we feel they must have a very similar algorithm. 

[drsnooker]

I figured I'd clarify, although it is a small data set, (from root access to physical routers) the pattern holds for the video SSID and its passwords. Starts with a number, end in anything but a symbol. No more than 3 letters in a row and never back to back symbols. Probably the same algorithm at work, just a different charset, and perhaps a different seed.

[soxrok2212]

I've been digging into a copy of the dumped firmware and looking at the u-boot logs. The MTD storage is basically as follows:

First 512KB: u-boot
Next 1024KB: unknown, perhaps some Broadcom second stage boot loader?
Remaining 131MB: General storage (dump has total 132MB, but the flash chip is only 128MB, don't understand this).

Mount info:

Code:

# mount
rootfs on / type rootfs (rw)
proc on /proc type proc (rw,relatime)
sys on /sys type sysfs (rw,relatime)
/dev on /dev type tmpfs (rw,relatime)
/tmp on /tmp type tmpfs (rw,relatime)
/dev/opentla4 on /rwdata type ext2 (rw,relatime)
/dev/loop0 on / type squashfs (ro,relatime)
etc on /etc type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
/dev/loop1 on /mnt/web type squashfs (ro,relatime)

df:

Code:

# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/opentla4          119.0M    37.2M    80.6M  32% /rwdata
/dev/loop0              29.6M    29.6M        0 100% /
/dev/loop1                1.4M      1.4M        0 100% /mnt/web

Bootlogs are here: https://deviwiki.com/wiki/Pace_5268AC and you can very clearly see how the partitions should be on the NAND flash:

Code:

[    2.282000] MTD partition(0) offset=0 size=524288 num=3
[    2.287000] MTD partition(1) offset=524288 size=1048576 num=3
[    2.293000] MTD partition(2) offset=1572864 size=132644864 num=3

So again, clearly mtd0 is 512KB, mtd1 is 1MB and mtd2 is 126.5MB, totally 128MB as the chip specs say. Part I dont understand is why there's not separated partitions for one or two software images to be loaded into ram on each boot and then a couple r/w partitions for persistent storage or certs or something. Why is it all piled into one partition?

[drsnooker]

Thanks for digging around. Hope you find something useful!

[drsnooker]

Fart-box asked to describe the algorithm so I figured I'd take a few minutes and outline the algo to determine the multiplier (like for nvg589 and nvg599)

First things first, the key at least as those for nvg589 and nvg599 is base 37 (heptatrigesimal), with a charset of abcdefghijkmnpqrstuvwxyz23456789#%+=?  This is all described by MrFancyPants and implemented in PSKracker by Soxrok2212, see the default router keyspace thread here on hashcat.

key = integer * multiplier

The password converts into the key (long integer). This key is the product of an integer and the multiplier. If the multiplier is an integer then you can use the Euclidean method to determine the greatest common denominator. So far so good, but what if the multiplier is a real number (with a fraction)? The response surface is jagged so you cannot fit it, it needs at least 7 decimal places to get the last character of the password correct, so brute forcing the multiplier is out. I always ended up with one more unknown than equations to go the linear algebra route.


My happy thought was I should drop my fascination with the multiplier and instead brute force the integer. You can use the first key and a guessed integer to determine a multiplier. Then use a second key, divide by that same multiplier to recover the integer belonging to the 2nd key. If that value is in fact an integer you have discovered a multiplier! If it isn't an integer than the first integer was wrong and thus the multiplier was wrong.

for integer1 = 1 to Very_Large_Number 
     multiplier = key1/integer1;
     integer2 = key2/multiplier;
     if is_integer(integer2) then print "BINGO"
endfor

Obviously you have to define integer2 as a float. The critical function here is is_integer. It needs to flag x.9999 as well as x.0001 as close enough to an integer with a defined precision. I'll leave that to the reader to implement.

Of course using multiple keys vs each other makes it robust against typos. Lastly, you will also recover more than the greatest common denominator, because key = (integer1 * 6) * (multiplier/6) and a host of other small integers (that cancel each other out). So it requires a bit of sorting out, but you'll quickly spot the ones that belong together.


Let's do an example for the 5268AC.
password 9yw9mx6sj3wt turns into key1=1353921430411399943 (assuming the first digit is base8 not base37)
password 9u7ke7kz7r9w turns into key2=1335782341279950921

So you are merrily scanning integers until you hit integer1=1940033061 (in C++ you can scan billions in minutes single threaded)
multiplier = key1/integer1;  = 1353921430411399943/1940033061 = 697885751.345657064037
then you do
integer2 = key2/multiplier;  = 1335782341279950921/697885751.345657064037 = 1914041573.000032
1914041573.000032 is pretty close to an actually integer so perhaps 697885751.345657064037 is the multiplier.

Might as well verify say against password 39bh23v3qpf6 (key3=234888871301781004)
key3/multiplier= 336572097.72354 *sad trombone* that's not an integer at all!


There many more ways to turn a password into a key including changing the charset around, so I'll let the reader experiment with those! May be they are more creative than I and strike gold!

[drsnooker]

New listings of this router have really dropped off, been stuck at 628 for weeks. I'll keep an eye out for new ones, but until then let me post the passwords I've been using more.
 

Note that these are the lowest entropy passwords in the collection (no shenanigans with three letters in a row, or what is allowed next to a symbol) There are no symbols at all in these! This might be important for the degrees of freedom of the used charset. 

The NVG589 and NVG599 charset is abcdefghijkmnpqrstuvwxyz23456789#%+=?
It is likely the 5268AC uses the same one, however because I have had no luck with it, it's safe to question this assumption. The order of the symbols could be flipped around. Hence this set of passwords is independent of the order of the symbols.

/usr/lib/libkeycode.so.0.0.0 has a charset that has number before letters: 
23456789ABCDEFGHJKLMNPQRSTUVWXYZ

/usr/bin/pseudopwd does a pseudo base64 using a charset with letters first, then numbers and a symbol last:
aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ0123456789.

/usr/bin/videossid has a charset similar to the NVG589/599 with letters first, then numbers and all the symbols last:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!"#$%&'()*+,-./:;<=>?@[]_`{|}~\


However alternate charsets for the password are possible and perhaps only slightly less likely e.g.
23456789abcdefghijkmnpqrstuvwxyz#%+=?