Most routers allow to save and restore configuration from files. This is cool because you can edit the configuration file and upload to the router again enabling some "hidden" configuration options. For example on my D-Link DSL-2640B I managed to get higher download speed disabling DSL QoS (it was broken) by setting X_BROADCOM_COM_ATMEnbQos to FALSE! So, I get a TP-Link wireless access point and, sadly, I found that they encrypted the configuration file, so I decided to reverse engineer it. First of all I needed a dump of the filesystem to get the binaries, so I soldered a serial port on the router to get a serial console. The bootloader didn't allow to interrupt the boot process but fortunately I knew that you can get a prompt by typing the secret word tpltpltpl
AP93 (ar7240) U-boot DRAM: sri #### TAP VALUE 1 = 9, 2 = 9 32 MB id read 0x100000ff flash size 4194304, sector count = 64 Flash: 4 MB Using default environment In: serial Out: serial Err: serial Net: ag7240_enet_initialize... No valid address in Flash. Using fixed address : cfg1 0xf cfg2 0x7014 eth0: 00:03:7f:09:0b:ad eth0 up No valid address in Flash. Using fixed address : cfg1 0xf cfg2 0x7214 eth1: 00:03:7f:09:0b:ad ATHRS26: resetting s26 ATHRS26: s26 reset done eth1 up eth0, eth1 Autobooting in 1 seconds ar7240>
I've compiled an OpenWrt (you know OpenWrt, right??) firmware with initramfs, and I loaded it from RAM without flashing the firmware:
ar7240> tftp 0x81000000 openwrt-ar71xx-generic-tl-wr841n-v8-initramfs-uImage.bin ar7240> bootm
After that making the dump was easy, just "dd" the mtdblock device with the firmware and copy to the computer via scp.
# dd if=/dev/block/mtd2 of=/tmp/rootfs # scp /tmp/rootfs [email protected]:
I needed to compile an old version of squashfs tools to extract the files, and finally I extracted the whole filesystem.
$ unsquashfs rootfs
I looked at the web page which handled the configuration load/save and I noticed that there were many references to some sort of embedded functions which most likely are handled by the webserver itself. The webserver is a single blob which handled many system utilities, indeed there were many executables symlinked to the httpd binary. This is a common practice in embedded firmwares, like OpenWrt's Busybox and Android's toolbox I started IDA to look at this binary, clearly httpConfUpload was the function to start hacking from. Due to a reference to des_min_do and some string starting with DES_ I suspected that DES was used as cypher. des_min_do was a galore of bitwise operators and nasty loops, clearly it was an inlined cryptographic function, and before calling it a pointer to a fixed null terminated string was pushed to the stack. It could be some salt or key passed to the encryption function so I'll note this string which was 478DA50BF9E3D2CF. I tried to decrypt it with mdecrypt using that string as key but without success:
$ mdecrypt -b -a des -f key <config.bin
I looked again at the binary and I searching for the _des string I found md5_des which suggested me to use the md5 hash function:
$ mdecrypt -b -a des -f key -o mcrypt-md5 <config.bin
again with no luck, so I tried all the block modes available until I found the correct one:
$ mdecrypt -b -a des -m ecb -f key -o mcrypt-md5 <config.bin ????????????????lan_ip 192.168.1.254 lan_msk 255.255.255.0 lan_gateway 0.0.0.0
The file is decrypted! Note that the trailing 16 bytes are the md5 sum of the files without trailing zeroes: the same can be done with openssl:
$ openssl enc -d -des-ecb -nopad -K 478DA50BF9E3D2CF -in config.bin
Have fun! for info mail me: [email protected] Matteo Croce OpenWrt Developer