Router Firmware Reverse Engineering
Hello there. Welcome to my first blog for Firmware Reverse Engineering. In this post we will reverse the firmware of TP-Link’s Archer AX 21 V4.6 modem. You can check TP-Link’s original page to download the firmware.
Warning
The information shared in this blog is provided for security research and technical training purposes. It is not intended to cause any harm or malicious behavior towards the relevant company or its product.
First, let’s take a look at the information of the firmware we downloaded:
As you can see, it was released on November 14, 2024. So it’s a firmware released almost 1 month ago. We can see that a few bugs have been fixed, optimizations have been made and new things have been added.
Since I don’t physically own this router, I will only analyze the firmware in this blog.
Finding Linux Version
We will use a tool called binwalk, which is often used especially in firmware reverse engineering. This tool can provide us with various information about the firmware.
First, let’s give binwalk the firmware we are going to analyze:
Yeaap, we have some complicated outputs…
These outputs contain the offsets of the related firmware. However, this binwalk tool does not only give offset values, it also gives explanations for these fields. Let’s take a look at the Decimal and Hexdecimal values in this output:
These are the offset values. binwalk tool shows them to us in both decimal and hexdecimal. Now let’s first focus on the Bootloader (U-Boot) and take a look at its architecture.
At this stage we can use the dd tool. Let’s run the following command:
Let’s pay attention to the values we give. with ‘if’, we give the target firmware. with ‘of’, we specify how to save the replicated data. with ‘skip’, we skip a certain amount of bytes and start the copying process. Notice that we gave a value of 8212. This means that dd will copy data up to 8212 bytes after the tool. This value is the offset of the uImage we found from binwalk.
This copy will result in a file called uImage:
Analyzing the copied file we can verify that it is u-boot Legacy uImage. We can also see that arch is MIPS.
To look for the Linux version, let’s take a look at our binwalk output again:
If we look at the offsets again, we can go to the compressed partition with LZMA. Let’s take the file with the .lzma extension and extract the file:
After these steps we should have a file as files. Our goal will be to browse the Linux version with strings only:
The Linux version used is 3.10.108 and 4.6.3 for GCC. Both of these are old versions.
Linux version 3.10.108 was released on November 5, 2017:
Version 4.6.3 of GCC was released on March 1, 2012:
To be honest, even though I am new to Firmware Reverse Engineering, I didn’t find it logical that a firmware released in 2024 would use an old Linux and GCC version. This could be a security risk.
When I saw this, I asked myself: “Do other companies do this and is it normal?”. Although I didn’t think it was normal, I wanted to analyze a different company’s router firmware and compare it with the Linux version. After a short research, I decided to analyze ASUS’s RT-AX58U Router Firmware.
The information for this firmware is as follows:
Likewise, this Firmware was released almost 1 month ago. I will share the result I found quickly so that we don’t get distracted. But if you want to practice more, I recommend you to analyze this Firmware of ASUS Router like me after reading this blog:
As a result, Linux version 4.19.183 and GCC version 9.2.0 are used for this firmware.
Linux version 4.19.183 was released on March 24, 2021:
Version 9.2.0 of GCC was released on August 12, 2019
In this Firmware of the ASUS RT-AX58U we can see that it uses more recent versions compared to the TP-LINK Firmware we analyzed.
Finding Linux Files
Let’s take a look again at the offset outputs we obtained with binwalk:
Here we can navigate to Squashfs to find Linux files. This is where most Linux files are located.
Let’s copy them in the same way with the .sqfs extension:
Analyzing the file we can verify that it is already compressed with Squashfs. Now we will need to extract it, but the Squashfs-tools package needs to be downloaded if it is not installed. On Debian systems you can download it with the following command:
sudo apt install squashfs-tools -yAfter downloading, extract it with unsquashfs: command:
After extraction we get a file named squashfs-root. Let’s take a look inside
As you can see, we have accessed the Linux files. There are many things we can do in this section. You can search for a bug, hashes or passwords, whatever your analysis is based on. For example, we can take a look at the passwords in /etc/shadow:
If you are new like me you can search for these Linux files and copy and browse other offset sections.
Simulating
Finally, let’s emulate (simulate) the firmware. We can use chroot and qemu for this. But before that we need to know the architecture of the firmware.
When we browsed uImage looking for the Linux version, we already saw that the architecture is MIPS. But let’s check the output one more time:
We can see that it’s MIPS. It is also Little Endian.
Since we are going to use Qemu, let’s copy /usr/bin/qemu-mipsel-static to squashfs-root and then run chroot:
When we take a look at the version of Busybox, we see that 1.19.4 is used. This is an old version released in 2012.
Conclusion
In this blog, we discussed the fundamental steps of analyzing a router’s firmware, using a recently released TP-Link device as our case study. We demonstrated how to use common Linux tools like binwalk, dd, strings, and unsquashfs to dissect the firmware file, extract its core components like the kernel and the filesystem, and identify the software versions within.
Our most striking discovery was that a firmware released in 2024 is built upon a Linux kernel from 2017 (3.10.108) and a GCC toolchain from 2012 (4.6.3). As our comparison with a more up-to-date ASUS firmware showed, this practice is a choice, not a necessity, and it represents a significant security liability. Such outdated components are often rife with known, unpatched vulnerabilities that could be exploited by attackers.