# EWVHunter: Grey-Box Fuzzing with Knowledge Guide on Embedded Web Front-Ends
## 5 EWVHunter
### Firmware Analysis to Obtain Vital Information and Site Map Construction  
We mainly get two kinds of information from the firmware to build the original knowledgebase, one being the strings used for program logic judgment, and the other being the information about the website path.  
We extract strings used for condition judgment and hidden in the firmware. If only the web front-end information is used, it is easy to miss the logical entry point of some key code block programs [43]. Thus we propose a static search solution for the firmware. This solution uses regular expressions to match the strings (e.g., hidden options) from the contents, which we get by using the \"strings\" command to handle the file of the unpacked firmware. We make sanitization rules to deal with these strings. For example, we will replace the value after the equal sign for the strings \"AUTHORIZED_GROUP=%d\". Then, we use sanitization strings to build a key information dictionary and add the dictionary to the knowledgebase. Later, during the fuzzing process, we use the strings in the key information dictionary to fill the web front-end input sources. The fuzzer can cover the program logic possibly and goes deep inside the program to find the vulnerability.  
The web file path information in firmware is mainly used to build an optimized site map. We use a site map to guide the embedded web front-end analysis by telling our fuzzer which URL should be analyzed. Ordinary web vulnerability detection programs only crawl websites to build site maps. However, this method is less efficient and often starts from a URL as an entrance. It is easy to miss some interfaces, especially hidden interfaces and thus miss some vulnerabilities [43]. Therefore, we collect the original site map information in the following three ways. Firstly, we determine the corresponding root directory starting point by retrieving crucial file directories (/bin/, /bin/, /HANP/, or /www/) or crucial files (/init, /linuxc, or /bin/sh). Then, we use the traversal file path method to extract the file (related to the web application) path information. Secondly, we utilize the \"strings\" command to get the strings in the file of the unpacked firmware, and then apply regular expressions to match the web page routing information from the strings. Thirdly, we obtain the site path from the web crawler. Finally, we combine the three pieces of information and delete duplicate data to get the original site map information. However, the web file path information of the original site map information is not all the web routing information. It may be an absolute path relative to the root file system. Therefore, the path information is combined with the HTTP response status code detection to construct the optimized site map and will be used as part of the knowledgebase.  
The site map constructed in this way may contain some hidden interfaces or some test pages left by the developer. These pages are most likely to have security vulnerabilities. Therefore, we use the optimized site map to guide the fuzzing that has the following two advantages. Firstly, the optimized site map can make the fuzzing performed efficiently because the fuzzer does not waste time analyzing unnecessary pages, such as CSS, JavaScript, and image files [43]. Secondly, it increases the chance of fuzzing the interfaces hidden in the firmware.  
We are targeting firmware that can be successfully decompressed. The decompression methods for encrypted firmware are temporarily outside the scope of this article. However, for most encrypted firmware we can also use specific techniques to decrypt it and decompress it. These methods can be implemented as EWVHunter extensions in the firmware analysis phase.