In our initial post we opened up the Tenda Wireless N300 router. We were able to successfully connect to the UART protocol using a USB to TTY serial cable. We brute forced the baud rate and then used putty to gain access to the device. This time around we are going to look at what commands we can run from the UART shell and attempt to dump the firmware from the device. Let’s dive in!
Remember last time we had connected up our device to the cable, so let’s do that again. If you haven’t read the first post check it out here.
For reference here’s the section talking about connecting to the device via UART.
For the next step we will solder the wires and connect to the USB to serial cable. You can get one off Amazon for around $15. Here is a diagram of what pins would go where. I reference this non-stop at work, so it’s handy to print one off and keep close. Mine is a little simpler and had GND (Ground), TRX (Transmit), RTX(Receive) and VCC (power).
Solder your wires on. For this one I put a ball of solder into the holes and let it dry. Then I melted it with the soldering iron, and while it was melted stuck the wire into the melted solder and took the iron off letting solder dry. Test the wire to make sure it is not going to come off by lightly pulling it.
So on our board we will connect the RXD to Pin2 and the TXD to Pin3. Pin 1 is our ground pin. Don’t connect to Pin 4 that’s the power and we are supplying power via the power source. Connect the USB to the computer, verify your COM port and use putty to establish a serial connection with 115200 set as the baud rate.
Once we click open we will just have a blank screen, but once you plug in the router you can see all the text appearing.
Looking above we have some memory addresses for CFF mem, Data, BSS, Heap, Stack, and Text. Let’s explore what commands we have. Entering a ? will give you a help menu.
You can use the question mark after a command to try and get more information. reboot ? will still just reboot the device.
reboot – reboot the device
debug – sets the debug level for the process httpd or wl_restart. debug <http | wl_restart> <level>
fw – used to set firewall rules. fw rule/mac/url/add/flush
wlconf – bring up, down, and restart the wlan interface
restart – restarts the device, my guess is this is more of a soft restart
splx – Unsure
route – Add/dev/flush routes on the device
et – configure the various ethernet interfaces.
thread – Get information about the various threads running on the device.
mbuf – Get information about Network stack stats
envram – Gives you information about the environment non-volatile ram. This is ram that stores values even when power is lost.
time – shows us up time and current time
ifconfig – shows us the network configuration
arp – Probably shows us the arp table, mine has nothing when I ran it.
nvram – Gives you information stored in the non-volatile ram (the data that persists upon reboot)
ping – Allows you to use the ping command to test for connectivity
tenda_arp – Probably shows information about arp, mine displays nothing.
syslog – Shows logs from the system
ipnat – Unsure
wl – Appears to allow us to see information about device like associated mac addresses, hardware revision information, scan for other SSIDs
There’s actually a lot of things we can do now that we are connected to the device. Let’s look at the ram data and environment data to see if there’s anything interesting.
envram
There’s some pretty good info with the output of this command. Towards the bottom we see the wps_device_pin. We could use this to possible connect to the Wi-Fi.
The WPS setting is turned off by default. Therefore, someone would need to enable it before we could do this attack. Then you would just need to hit the reset button and enter this pin to connect. It does not look like there is a variable in envram that we can overwrite for this setting.
There’s other useful information such as the MAC address, LAN IP address, various vlan ports and more. One interesting note is the tftp_boot_cmd=192.168.0.100:vmlinuz. This appears to be where the device may look if it’s having issues booting. It’s possible we could maybe serve up malicious firmware and sneak a backdoor onto the device.
envram show
Now let’s take a look at the nvram command.
nvram show
Something interesting here is that we could pull out all the reservations for IP addresses. These addresses could be an important system such as a server, or even better a domain controller.
The wan_pppoe_passwd may be interesting because maybe you could use this to get the same internet as the company.
We can see what the default http password is as well, it’s YWRtaW4=. Items that end with an equals is usually a good sign it is base64 encoded. Since this is encoded, NOT ENCRYPTED, we can easily google for a base64 decode or you can do it within a Linux terminal echo “YWRtaW4= | base64 -d
Unfortunately that only shows us the default password and it does not reflect the current password to get into the router. So I thought what if we overwrite that value and then do a hard reset.
nvram set http_defaultpwd=SGFja2VK
That is the value of Hacked but based64 encoded. Sadly after the reset the value reverted back to admin. We can still get in, but can’t have backdoor persistence on the device.
Even the value of http_passwd which I thought would be the current password, is actually just the default of admin, base64 encoded.
This value is really interesting and I’m not really sure what it is.
Do these routers always have hacker in them? Seems odd, maybe a backdoor of some sort?
I think at this point since we are already in the router after boot we need to try and interrupt the boot to get into a special shell like Uboot or CFE. U-Boot is also known as the Universal Boot Loader. This is the package that contains the instructions to boot a device’s operating system. Uboot would run first and then say alright we need to enter the firmware at this memory address. CFE stands for Common Firmware Environment and it is a firmware interface developed by Broadcom. We can see that we should have a CFE bootloader by the picture of the device as it boots, while we are connected to UART.
Taking a look at the chip will confirm what bootloader we are using.
Looking at the docs from Broadcom it says it uses the Common Firmware Environment (CFE). I don’t want to link to the site because it auto downloads a text file and I don’t want people to have to directly download files.
Let’s see if we can enter the CFE menu. Looking online it looks like maybe we can hold CTRL + C to enter the menu. Unplug the router, select your Putty window, hold CTRL + C and finally give the device power.
Great we have now interrupted the process to load the firmware and can interact with the device through its bootloader! Running help will give us information about commands we can run.
It looks like we can just save a copy of the firmware right off the device using the save command. We can also use the batch command to load a specific file onto the device and execute it. For now let’s try to get the firmware off the device.
For the save command we will give it a host:filename startaddr and the length. We have our memory addresses above and then the length of those spaces. Let’s try to save all of these files off. First we need to connect our device to our computer through an ethernet cable to communicate with the TFTP server we will set up. From the envram command earlier I know that router’s IP address is 192.168.0.1. We will need to assign our ethernet port an address within range, so I will use 192.168.0.7.
I found this program useful to quickly spin up a TFTP server for windows (https://tftpd32.jounin.net/tftpd32_download.html) I just used the portable version and unzipped the contents. When you open it click on Settings and under TFTP Security choose none.
Now run this command on your putty session to download the firmware to your machine, remember to replace with your IP of your ethernet port.
save 192.168.0.7:CFEMenu 0x80700000 628640
Checking back in our directory we can see the file is saved in our TFTP Server folder! Let’s do the rest of the files as well.
save 192.168.0.7:Data 0x8072F580 12896
save 192.168.0.7:BSS 0x807327E0 4032
save 192.168.0.7:Heap 0x807337A0 409600
save 192.168.0.7:Stack 0x807977A0 8192
save 192.168.0.7:Text 0x80700000 193912
We have successfully dumped out the firmware! Next time we will take a look at these files and see if we can find any useful information in them! This is why if you have sensitive firmware on your devices you want to encrypt it, as well as disable protocols like UART and JTAG. You can either destroy the interaction within the software of your device, or you can physically not create traces from the processor to the pins. Thanks for checking out my journey hacking this Tenda Router!