Today we will be looking at the firmware that we extracted from the last post (https://dfresh.ninja/index.php/2021/01/16/exploring-uart-protocol-and-dumping-firmware-on-the-tenda-300-wireless-router/). Last time we were able to extract files called BSS, CFEMenu, Data, Heap, Stack, and Text. Let’s see what kinds of files these are.
I downloaded these files into a Linux virtual machine, because I am more used to do analysis from here. First I will run the file command against all the files to see what they are.
file *
Looks like they are all data files. I created a backup of all these file just in case. In order to move them over to my virtual machine I used a python3 server on Windows.
python3.exe -m http.server 7777
Then on my Linux machine
wget WINDOWSIP:7777/FILENAME
I was in the same directory of the firmware when I ran the python3 server. Depending on your confirmation it may be easier to drag and drop files, or use ftp to move them over.
Let’s try to cat out these files. NOTE: Sometimes doing this on files, such as binaries, can cause issues with your terminal. A better method to do this is to use the strings command.
Here is what happens with the cat command.
There’s some interesting stuff in here including the Mac address, the IP address, and the WPS pin. Now let’s try the strings command, which will attempt to pull out all the readable strings in this file.
We get the same information just in a better format. There are additional screens that I did not capture. Something interesting is that it appears we are running some sort of Linux operating system.
Looks like we can identify the version of Linux running as well!
Maybe if we can get the device to use this tftp boot, we can feed it custom firmware. A lot of this looks like the data we were seeing last time, because I believe this file is the current settings file.
Now let’s look at the CFEMenu, CFE is for the Common Firmware Environment. This is the environment that we booted into when we held CTRL + C, while the router was booting up.
strings CFEMenu
At first the top just looks like random data, but when we get into some readable strings. The first thing that stands out to me is the version for CFE. The specific version of CFE doesn’t necessarily have vulnerabilities, but it’s good for reconnaissance to note it down.
Looks like if this device’s firmware gets corrupted for whatever reason, it will enter a recovery mode to receive new firmware. This is pretty standard, because you don’t want the router to be fried from something going wrong during a firmware update.
So this is interesting, it appears there’s some sort of user called Zhuzeji, could this be a backdoor account?
Here it looks like the device will check for a CRC code before flashing an image. The cyclic redundance check, CRC, is code to check for errors and changes to the raw binary. If you tried to upload a different firmware image, you would have to ensure that it passes the CRC check. Hopefully we can find out how that check is performed when we open this firmware in a reverse engineering tool.
I believe if we can set this value and reupload the firmware, we could enable http over the internet, possibly without anyone knowing.
Looks like the device keeps a backup of the original SSID, I suspect this is used in case you have to restore the firmware, so it knows to broadcast the Tenda wireless network, just like when it’s out of the box.
We can see some of the commands that are offered once you get into the CFEMenu. This would be useful if you didn’t have access to the device you were trying to hack. That way you could plan your attack for when you do gain physical access, but may only have a short time to interact with the device.
Here we have the WiFi password, this is great info. If I were an attacker and only had physical access for a short time, I can now come back later and connect to the Wi-Fi from farther away.
When I ran strings on the file Text I found the compiled time, this could help you find additional vulnerabilities knowing that the target hasn’t updated firmware.
Next time we will open up these files in a de-compiler, I will be using Ghidra because it is free. There we can take a better look at the files. Ghidra will take the assembly code and attempt to create C code from it. This is not accurate, but usually it’s good enough for us to understand some of the functions and maybe find an exploit.