# Optimizing IoT Web Fuzzing by Firmware Infomation Mining
## 2 Firmware Information Mining
### Shared Keywords Extraction  
The keywords transmitted by the front-end will be handed over to the back-end for processing, including various customized binary files, such as \"httpd\" and \"nvram\". After the back-end processing is completed, the output is handed over to the page handler for rendering and then returned to the front-end page for display. Figure 2 shows the request processing process of the web service in the ASUS RT-N53 router. Click the \"Apply\" button on the front end, and the two parameters, \"lan_dns1_x\" and \"lan_dns2_x\", will be sent together in the form of http packets to the router's back-end web server for processing. Looking at the back-end source code, you can see that the parameter values sent by the front-end are stored in nvram after being received, and then the init process will copy the stored \"lan_dns1_x\" and \"lan_dns2_x\" from nvram to the buffer for subsequent configuration. In the init process, the buffer size is 100 bytes, but the length of the \"lan_dns1_x\" and \"lan_dns2_x\" parameters is not judged. When the parameter length is greater than 100 bytes, a buffer overflow vulnerability is caused, allowing attackers to gain system privileges and execute arbitrary commands.  
Shared keywords are keywords that use the same name in the front-end web file and the back-end binary file. With the help of this sharing phenomenon, we can statically parse the firmware web file, extract all possible parameters, and determine whether these keywords are shared. Because shared keywords will be substituted into the back  
Figure 1: Process from page path to web path in ASUS RT-N53 router.  
Figure 2: The request processing process of the web service in ASUS RT-N53 router.  
end binary files, we can assume that shared keywords are more likely to be vulnerable. Among all the parameters transmitted by the front-end, not all parameters will be passed to the back-end for processing. Some of the parameters will be used for logical judgment, as shown in Figure 3, and some of the parameters are meaningless additional values in the form. For example, when the input tag is used as a form submit button, a meaningless \"submit\" parameter and timestamp, token, etc., will be submitted. A considerable part of the parameters sent by each request will not be passed to the back-end for calculation. Generally, it will not lead to vulnerabilities, except for some logical vulnerabilities, such as unauthorized access.  
After the firmware is decompressed, there are many types of web files, and we only extract the keywords related to the parameters. Therefore, the target file types we analyzed include PHP, HTML, ASP, JSP, JS, and XML, which can cover most IoT devices.  
For HTML files, we mainly extract forms and variable naming operations, such as \"id\", \"name\", etc. In PHP, parameters are mainly received in global variables, such as \"$_GET\", \"$_REQUEST\", etc., and keywords are obtained by matching these global variables. Similar to PHP, ASP, and JSP have standard functions to receive parameters. Similarly, we design corresponding extraction rules according to the characteristics of this type of file and use regular expressions to assist in extracting possible keywords. In the js file, we match and extract keywords for assignment behavior and functions related to data transfer.