# A Vulnerability Scanning Method for Web Services in Embedded Firmware
## 3 Background and Motivation
### Challenges and Methods  
Current research on embedded web services primarily faces two challenges. We manually analyzed firmware from six manufacturers, comprising 25 distinct versions, and integrated these findings with the relevant literature to synthesize and propose our solutions.  
Challenge 1: Given the complexities of interaction and implicit dependencies between the front end and back end, how can we accurately trace the entry points of front-end data?  
Within unpacked firmware, front-end code is relatively distinguishable; however, a significant challenge arises from the plethora of binary files. Identifying code that processes front-end data amid such a high volume of binaries--precisely tracing the data entry points amid intricate front-end and back-end interactions--remains a problem that requires urgent resolution. Existing research has made strides toward this aim. For example, in DTaint [9], the authors manually specify vendor-customized functions (e.g., \"_find_var_\" and \"_websGetVar_\") as taint sources. In KARONTE [11], a pre-defined list of network encoding strings (like \"_soap_\" or \"_HTTP_\") are utilized as keywords to infer taint sources. [PERSON] [12] proposes utilizing shared keyword-aware taint checking to track user input data flow between the front end and back end. Researchers like [PERSON] [13] and [PERSON] [14] have suggested identifying external data input functions to increase analytical precision. Through our analysis of the associations between the front end and back end, we deduced that boundary binary files, which facilitate data interactions with the front end, exhibit salient HTTP service-related characteristics. Invariably, front end-transmitted data manifest as key-value pairs in which boundary binary files typically read values by indexing keys through external data input functions associated with key-value pairs. Thus, by extracting and assessing features, we can identify boundary binary files and external data input functions, effectively pinpointing external data entry points.  
Challenge 2: During the process of data flow tracking, how can we achieve a better balance between efficiency and accuracy?  
A program's complexity and size limit the precision and speed of taint analysis. Intricate rules for taint propagation have been established in existing work which, when applied to substantial and complex programs, can result in a time-consuming analysis with the potential for reduced accuracy. Previous methodologies often designated dangerous functions in the program as sinks. However, within the voluminous code of real-world firmware, such functions may be called extensively, making the indiscriminate designation of these functions as sinks analytically expensive. We have identified that for firmware with higher complexity, taint analysis outcomes necessitate further manual or automated verification due to the inherent limitations of static analysis. The unwarranted focus on accuracy is not advisable; thus, we propose developing lightweight taint propagation rules. This approach aims to balance accuracy and efficiency, allowing for swift tracking and querying of potential vulnerabilities. To increase the precision of queries, we not only focus on accurately locating external data entry points but also implement the filtering of dangerous functions. Our observations indicate that analysts prefer perusing decompiled code as it presents information more amenable to analysis, such as data types and higher-level control flows. Therefore, deploying rules on decompiled code's abstract syntax tree (AST) nodes for dangerous function filtration could be valuable.