Partial success with Archer C2

[AXKuhta]

tpconf_bin_xml.py can successfully decode and re-encode Archer C2's conf.bin file, but the re-encoded file is significantly different from the original and will give error 4051 on restore.

Something is off with compression, as far as I can tell. I added some code to dump the compressed but not yet encrypted data into a file after this line: https://github.com/sta-c0000/tpconf_bin_xml/blob/767fd84479fa636ad0e49704284e216f2a38c7fa/tpconf_bin_xml.py#L239

Then I compared it with the output of openssl enc -d -des-ecb -nopad -K 478DA50BF9E3D2CF -in conf.bin > conf.bin.dec.

The files are similar for sure, there are 16 bytes of checksum and 4 bytes of length, followed by the compressed data, which starts to diverge after about 100 bytes.

Anyway, I decided to try the StatPOSTer-20160306.jar tool mentioned in #11, and it actually produced a working .bin on the VR900 preset! I added <Description val="Archer C2 Router`telnetd -p 1023 -l login`" /> line into the XML. It worked. It's funny how it made its way into the WebUI:

[AXKuhta]

This is a little-endian device, notably. I did get a little-endian warning when decoding conf.bin and did try using the -l option when re-encoding, but that didn't fix the 4051 error.

It will need busybox-mipsel instead of busybox-mips. The binary can be delivered using the vsftp server that's running on there:

• Telnet into the box (admin:1234), run mkdir /var/vsftp/root/admin/123
• FTP into the box (admin:admin), drop the binary into the 123 folder
• cd /var/vsftp/root/admin/123
• chmod +x busybox-mipsel
• ./busybox-mipsel

[sta-c0000]

Yes, the Archer C2 uses little-endian (also MIPS CPU). Don't know why it doesn't work for you, I don't have access to one. (Apparently works with Archer C20, which is very similar?) TP-Link could always change their compression for recent devices/firmware?… But then it would be strange that it decompresses correctly… So you are saying that if you decode and immediately recode (without modifying the XML file!):

python3 tpconf_bin_xml.py -l conf.bin conf.xml
python3 tpconf_bin_xml.py -l conf.xml conf_new.bin
diff -s conf.bin conf_new.bin

That the resulting conf_new.bin is not the same as the original conf.bin?! That would be very weird!

StatPOSTer does not actually compress the bin file; the VR900 uses an ARM CPU, but apparently the only difference for conf.bin would also be the endianness.

Sorry, I can't reproduce.

[AXKuhta]

That the resulting conf_new.bin is not the same as the original conf.bin?! That would be very weird!

Indeed, that's exactly what's happening.

$ python3 tpconf_bin_xml.py -l conf.bin conf.xml
OK: BIN file decrypted, MD5 hash verified, uncompressing…
Done.
$ python3 tpconf_bin_xml.py -l conf.xml conf_new.bin
OK: XML file - compressing, hashing and encrypting…
Done.
$ diff -s conf.bin conf_new.bin
Binary files conf.bin and conf_new.bin differ

Here's my conf.bin file, scrubbed of any passwords, if you want to take a look: conf.bin.zip

It may very well be that something is wrong with my setup...

[sta-c0000]

Ah! Thanks for the bin to help diagnose! It's not your setup... :) It seems that your Archer C2 is using a different hash key/table when compressing. But it's strange to me that it actually cares about that when uncompressing (after upload). Because the W9970 doesn't appear to care, like my python script (because we can uncompress without caring what hash key/table was used).

I'm not sure I can fix it without reverse engineering the Archer C2's binaries. It's normally the cen_compressBuff and cen_uncompressBuff functions located in /lib/libcutil.so on the router.

I searched for more recent related projects, and came across archer-c3200-tools, which is partly based on mine, but also on a blog post by Pwn2Learn. Interestingly they use the Python angr library to actually simulate cen_compressBuff using the router's own libcutil.so, very neat!

So that's another option to consider. But at least you had success with StatPOSTer without needing to compress. Thanks!

[AXKuhta]

That's a cool article, and damn, that's a cool library! archer-c3200-tools looks like it might work with just about anything that uses libcutil.so.

Thank you for investigating, suppose I'll close the issue now.

[sta-c0000]

Hi @AXKuhta. Had time to look at this closer. Looks like the Archer C2 actually uses the exact same hash key/table but it simply doesn't re-hash hits (ends up slightly less compressed). I'm still not sure why it cares when uncompressing (it shouldn't!), but that doesn't matter... I modified the code to support the Archer C2. Let me know if it works. Thanks again, I couldn't know this without your file.

[AXKuhta]

@sta-c0000 Definitely working now: unmodified .xml produces identical .bin, and modified .xml now produces a working, restorable file.

Thank you!

[AXKuhta]

Oh man, this is amazing (In a bad way). I found this vulnerability report that tells how the diagnostics page can be used to run arbitrary commands. Bricking the router is as easy as running cat /dev/random > /dev/mtd0.

[sta-c0000]

Appears that specific CVE vuln is fixed (with latest firmware). Of course, once you have admin/root access you can brick most devices ;) I'm of the opinion that if you have valid credentials (and they are reasonably protected), you should be able to do what you want with your device. But yeah, unauthorized vulns are bad; safest not to expose router services to the Internet, run those in a container on a separate device.