Obstacle-aware fuzzing method for web service scripts of embedded devices

Abstract

The application discloses a kind of obstacles perception fuzzy testing methods for embedded device Web service script, the purpose is to solve the problem such as existing fuzzy testing method vulnerability related interface acquisition result is not accurate, constraint bypass method compatibility is poor, script fuzzy testing terminates in advance and so on.Techinical scheme is: construct the fuzzy testing system consisting of five modules of vulnerability trace analysis, test case generation, fuzzy testing, constraint bypass and real-time patching.The first three modules are analyzed from the control flow from the vulnerability sensitive point reverse, from the forward interface forward, and the test case generation is optimized according to the control flow intersection;Constraint bypass module uses the constraint bypass method of vulnerability sensitive point driving to mutate test case, realizes deep fuzzy testing;Real-time patching module uses the online repair method based on command influence to help test case bypass inaccurate embedded command, prevent fuzzy testing interruption.The application improves the adaptability and accuracy of Web service script vulnerability detection.

Description

Technical Field

[0001] This invention relates to the field of vulnerability detection technology, and specifically to an obstacle-aware directional fuzzy testing method for Web service scripts on embedded devices. Background Technology

[0002] The Internet of Things (IoT) has expanded rapidly over the past decade, with billions of embedded devices becoming commonplace in homes and businesses. To enhance flexibility, embedded devices often include PHP (Hypertext Preprocessor) or LUA scripts. These web service scripts are executed by an interpreter for system configuration or handling external requests to maintain web services. However, web service scripts inevitably contain vulnerabilities, such as command injection and cross-site scripting attacks, which pose risks to user privacy and device integrity. For example, CVE-2023-20273 is a vulnerability in the LUA script of Cisco devices that allows attackers to remotely execute commands without authentication, thereby compromising Cisco devices. Furthermore, because web service scripts are located close to the external boundaries of embedded devices, vulnerabilities are directly exposed to attackers, posing a high risk to embedded devices. Although research on embedded device emulation and binary program vulnerability detection is constantly evolving, the security risks associated with web service scripts have been largely overlooked. Therefore, there is an urgent need for a vulnerability discovery method targeting this new attack surface of embedded device web service scripts.

[0003] Web service scripts first appeared in desktop web applications, and corresponding vulnerability detection techniques exist. Typical static analysis techniques rely on taint analysis to discover vulnerabilities in PHP scripts. Static analysis tools that work on modern PHP versions and have been actively maintained for the past four years include SonarQube (https: / / www.sonarqube.org / ), Progpilot (https: / / github.com / designsecurity / progpilot), PSALM (https: / / psalm.dev / ), and PHPCSSECURITY-AUDIT (https: / / github.com / squizlabs / PHP_CodeSniffer). Furthermore, SYMPHP (“Holistic concolic execution for dynamic web applications via symbolic interpreter analysis,” published by P. Li et al. in Oakland), applies symbolic execution to enhance script vulnerability detection. However, the customization and diversity of scripting languages ​​limit the accuracy of these methods. Moreover, even in a uniform, ideal desktop environment, static analysis methods, when used alone, suffer from a high false positive rate, often leading developers to overlook actual vulnerabilities or waste time investigating false positives. Furthermore, static analysis cannot generate test cases that can help developers perform manual debugging.

[0004] Many existing studies do not focus on improving the accuracy of static analysis, but instead apply fuzzing (the purpose of fuzzing is to generate a large number of test cases, input these test cases into the system under test, and then observe the system's anomalies to obtain test cases that can trigger vulnerabilities, thus completing vulnerability detection) to script vulnerability detection. Compared to simple random fuzzing, these methods benefit from a unified open-source desktop environment, extracting script-level information to assist fuzzing. For example, the paper "Atropos: Effective fuzzing of web applications for server-side vulnerabilities," published at USENIX Security 2024, improves vulnerability detection efficiency by modifying the interpreter to extract the expected values ​​of comparison operations from the script, thereby bypassing path constraints. Furthermore, C. Wang et al.'s paper "Predator: Directed web application fuzzing for efficient vulnerability validation," published at the 2025 IEEE Symposium on Security and Privacy (SP), introduces targeted fuzzing into script vulnerability mining by selective dynamic instrumentation and vulnerability-related interface identification, thereby improving the coverage of high-risk execution paths. Greenhouse (“Greenhouse:{Single Service} rehostingof {Linux-Based} firmware binaries in {User-Space} emulation”) is one of the most advanced user-mode firmware emulation platforms and is widely used. Its associated fuzzing tool, GH3Fuzz, receives test cases through a web server interface to perform fuzzing on embedded devices, theoretically potentially triggering the execution of web service scripts. While these methods are effective in fuzzing desktop web applications, their applicability in embedded environments is limited. Designing an effective fuzzing method for vulnerability detection in web service scripts on embedded devices presents the following three challenges:

[0005] (1) The problem of identifying vulnerability-related interfaces in multilingual environments. Similar to desktop web applications, web service scripts in embedded devices also have public interfaces, and the script is only invoked when the requested URL matches one of these interfaces. Furthermore, only some of these interfaces are associated with triggering vulnerability-sensitive points (vulnerability-related interfaces). Identifying vulnerability-related interfaces and performing fuzzing on them is key to improving vulnerability detection efficiency. For example, Predator uses function-level slicing reverse analysis to identify vulnerability-related interfaces. However, this method is limited by cross-language calls in embedded environments. In desktop environments, the control flow graph (CFG) of web service scripts is typically in a single language (PHP), and function calls from vulnerability-sensitive points to interfaces are connected. However, in embedded environments, web service scripts can be called by binary files or shell scripts, forming cross-language control flows. Existing control flow analysis techniques (such as angr, https: / / github.com / angr / angr) are generally suitable for monolingual environments. When applied to embedded environments with multilingual component interactions, they often result in broken call chains due to the lack of control flow information between components. This hinders backward analysis from vulnerability-sensitive points to vulnerability-related interfaces, leading to inaccurate results obtained from vulnerability-related interfaces and affecting the quality of test cases in fuzzing.

[0006] (2) Constraint Bypass Problem in Closed-Source Diverse Parser Environments (Path Barrier 1: Script Constraints). Web service scripts typically contain conditional branches and comparison operations (constraints). During fuzzing, test cases can only bypass shallow validation and trigger deeper paths if they satisfy the constraints of the target path. Traditional fuzzing methods extract constraints through data flow analysis, modifying the parser to achieve symbolic execution, and input-to-state feedback. While these techniques are effective in desktop environments, their applicability in embedded environments is limited. The dynamic nature of scripting languages ​​makes it difficult for static analysis techniques (such as data flow analysis) to accurately extract constraint values. Furthermore, existing symbolic execution and input-to-state feedback methods require modification of the firmware interpreter (the binary program used for script parsing and execution) to obtain constraints and thus support fuzzing. However, firmware interpreters in embedded environments are often closed-source and heterogeneous, leading to poor compatibility and high implementation costs for existing constraint bypassing methods.

[0007] (3) Inaccurate embedded command execution results lead to premature termination of script fuzzing (Path Obstacle 2: Inaccurate embedded command execution). Unlike desktop environments, web service scripts in embedded devices typically contain embedded commands (commands that call binary programs on the device to perform specific functions, such as `cat / proc / devinfo`). The execution results are captured and returned to the script context as input for subsequent logical processing. Firmware emulation is the foundation of embedded device fuzzing and is crucial for supporting the dynamic operation of embedded device firmware on high-performance computers. However, existing firmware emulation methods are insufficient to support the accurate execution of embedded commands. Existing firmware emulation methods typically assume that firmware emulation is successful when the web service's homepage is accessible, without the ability to account for and emulate the complex behavior of the firmware during subsequent operation. In this case, the simulated embedded device may encounter problems during runtime, such as uninitialized daemons, missing file systems, and unrecognized system calls. These problems are closely related to embedded commands in web service scripts and often lead to inaccurate execution results. When the script receives inaccurate execution results, script parsing errors occur, causing premature termination of fuzzing and reducing the depth and breadth of vulnerability discovery. Summary of the Invention

[0008] The technical problem this invention aims to solve is that existing embedded device security research focuses on binary program vulnerability detection and firmware emulation, while neglecting the security of Web service scripts themselves. Furthermore, the closed-source and heterogeneous nature of embedded environments, coupled with diverse script calling mechanisms, leads to inaccurate results from vulnerability-related interfaces, affecting the quality of test cases in fuzzing. Additionally, constraint bypassing issues in closed-source environments with diverse parsers result in poor compatibility and high implementation costs for existing constraint bypassing methods. Inaccurate embedded command execution results cause premature termination of script fuzzing, limiting the migration of vulnerability discovery methods designed for desktop Web applications. This invention proposes an obstacle-aware fuzzing method for embedded device Web service scripts.

[0009] To address the aforementioned technical problems, the technical solution of this invention is as follows: An embedded device Web service script fuzzing system is constructed, comprising a vulnerability source analysis module, a test case generation module, a fuzzing module, a constraint bypass module, and a real-time patching module. The vulnerability source analysis module, test case generation module, and fuzzing module cooperate to analyze the control flow from the vulnerability-sensitive point in reverse and from the forward interface in forward. Based on the control flow intersection, they obtain a set of vulnerability-related interfaces, thereby improving the quality of test cases. The constraint bypass module uses a vulnerability-sensitive point-driven, script instrumentation-based constraint bypass method to help test cases bypass script path constraints (i.e., path obstacle 1), achieving deep fuzzing. The real-time patching module uses an online patching method based on command influence to help test cases bypass inaccurate embedded commands (i.e., path obstacle 2), ensuring that fuzzing is not prematurely interrupted.

[0010] This invention includes the following steps:

[0011] Step 1: Build an embedded device web service script fuzzing system. This system consists of a vulnerability tracing and analysis module, a test case generation module, a fuzzing module, a constraint bypass module, and a real-time patching module.

[0012] The vulnerability tracing and analysis module is connected to the fuzzing module. The vulnerability tracing and analysis module reads all Web service scripts (WebFiles) in the embedded device under test, starts from the vulnerability-sensitive point, obtains the control flow that can reach the vulnerability-sensitive point through reverse tracing, and obtains an initialized vulnerability association graph (Graph) and a set of vulnerability-sensitive point locations (LU). The Graph is sent to the fuzzing module, and the LU is sent to the constraint bypassing module.

[0013] The test case generation module is connected to the fuzzing module. The test case generation module reads WebFiles, extracts text semantics from them, extracts network transmission protocol formats from the HTTP protocol specification, receives the vulnerability-related interface set Vulinterfaces from the fuzzing module, generates a test case input based on the text semantics, the vulnerability-related interface set Vulinterfaces, and the network transmission protocol formats, adds the input to the test case set Inputs, and sends Inputs to the fuzzing module.

[0014] The fuzzing module is connected to the vulnerability tracing and analysis module, test case generation module, constraint bypass module, and real-time patching module. The fuzzing module receives Inputs from the test case generation module, randomly selects a test case as the real-time test case input', receives the vulnerability association graph Graph from the vulnerability tracing and analysis module, executes input' and obtains the test case execution path Trace, updates the Graph based on the Trace, obtaining the updated vulnerability association graph NewGraph, and sends input', Trace, and NewGraph to the constraint bypass module. Simultaneously, the fuzzing module monitors whether the vulnerability association graph has been updated, monitors the execution status of the embedded device's web service script, the operation status of the real-time patching module, and the operation status of the constraint bypass module. If the vulnerability association graph has been updated, i.e., the test case's execution path intersects with the existing vulnerability association graph's control flow, this module extracts the vulnerability-related interface set Vulinterfaces from the test case input' of this round of fuzzing and sends Vulinterfaces to the test case generation module. The fuzzing module monitors the execution status of the embedded device's web service script in real time. If the fuzzing is interrupted, it sends the monitored embedded device error information Error to the real-time patching module. The fuzzing module receives the patched web service script (PatchedFile) from the real-time patching module, and replaces the original web service script file corresponding to PatchedFile with the path information of PatchedFile to prevent premature termination of the fuzzing test. The fuzzing module also receives mutated test cases (NewInput) from the constraint bypass module and adds NewInput to the test case set Inputs.

[0015] The constraint bypass module is connected to the fuzzing module. The constraint bypass module receives input', Trace, and NewGraph from the fuzzing module, and the set of vulnerability sensitive point locations LU from the vulnerability tracing and analysis module. Based on NewGraph, Trace, and LU, it instrumentes the embedded device web service script to obtain constraint values, uses the constraint values ​​to mutate input', obtains the mutated test case NewInput, and sends NewInput to the fuzzing module.

[0016] The real-time patching module is connected to the fuzzing module. The real-time patching module reads WebFiles, parses the embedded device Web service script content in the WebFiles, obtains the Domain of the embedded command's impact, receives runtime error information from the fuzzing module, repairs the Web service script based on the Error and Domain, and sends the repaired Web service script (PatchedFile) to the fuzzing module.

[0017] Step 2: The vulnerability tracing and analysis module reads WebFiles from the embedded device, analyzes the Web service scripts, generates a vulnerability graph (Graph) and a set of vulnerability-sensitive point locations (LU), sends the Graph to the fuzzing module, and sends the set of vulnerability-sensitive point locations (LU) to the constraint bypass module. The method is as follows:

[0018] 2-1 The vulnerability tracing and analysis module reads WebFiles from the embedded device and determines the characteristics of vulnerability-sensitive points (functions or code locations that may trigger vulnerabilities) in the Web service scripts within the WebFiles. These characteristics can be categorized into function-based and character-based features. Function-based features refer to common functions in Web service scripts (PHP or LUA scripts) related to command execution and cross-site scripting vulnerabilities, including: file handling functions (such as io.open, include_once, dophp); command execution functions (such as os.execute, nixio.exec, nixio.exece, nixio.execp, execl, Popen, exec, system, util.exec, util.execi, sys.exec, forkExec, fork_exec, fork_c, ltn12_popen, process.exec, cmd\(.*)\b); and information output functions (such as echo). Character-based features refer to common characters in Web service scripts related to command execution, such as #! / bin / sh (the first line of the script file, used to specify the interpreter path for executing the script).

[0019] 2-2 The vulnerability tracing and analysis module uses regular expressions (also known as regular expressions, which use a single string to describe and match a series of strings that match a certain syntax rule, usually used to search for and replace text that matches a certain pattern (rule)) to match the vulnerability sensitive point features in the Web service script, obtaining a vulnerability sensitive point location set LU. Let the number of vulnerability sensitive points in LU be N, where N is a positive integer. Simultaneously, the vulnerability sensitive point location set LU is sent to the constraint bypass module;

[0020] The 2-3 vulnerability tracing and analysis module starts from N vulnerability-sensitive points in LU and constructs M reverse function call chains based on the function call relationships (for example, if a vulnerability-sensitive point is located in function B, and function A calls function B, then a reverse function call chain A -> B is constructed, with the starting point being the vulnerability-sensitive point and the ending point being the outermost function found through iteration). These M reverse function call chains are then placed into the reverse function call chain set Liang. In the reverse function call chain, function nodes represent functions in the Web service script, and edges represent the call relationships between functions; M is a positive integer and M ≥ N.

[0021] The 2-4 vulnerability tracing and analysis module generates a vulnerability association graph (Graph) based on M reverse function call chains. The Graph contains function nodes and edges of the reverse function call chains and expands upon the sub-control flow graphs of the function nodes. The method is as follows:

[0022] 2-4-1 Let variable m = 1;

[0023] 2-4-2 Transform the function nodes in the m-th reverse function call chain in the set of reverse function call chains Liang into function nodes in the initial vulnerability association graph InitGraph. The transformation method is to directly use the function nodes on the m-th reverse function call chain as graph nodes (also function nodes) in InitGraph, and at the same time, transform the call relationships in the m-th reverse function call chain into directed edges in InitGraph, thereby completing the initialization of InitGraph.

[0024] 2-4-3 If m=M, then the InitGraph has been generated. Compared with the reverse function call chain, the InitGraph is more convenient for calculating the distance between nodes and guiding fuzz testing. Go to 2-4-5; otherwise, let m=m+1 and go to 2-4-4.

[0025] 2-4-4 Treat the function node on the m-th reverse function call chain as a function node in the InitGraph. If the function node already exists in the InitGraph, skip the function node. At the same time, convert the call relationship in the m-th reverse function call chain into a directed edge in the InitGraph. Go to 2-4-3.

[0026] 2-4-5 Supplement the internal control flow relationships for each function node in the InitGraph. For each function node, the basic blocks inside the function are taken as basic block nodes, and the jump relationships between basic blocks (conditional branches, unconditional jumps, etc.) are taken as edges. Construct the sub-control flow graph of this function node to obtain the vulnerability association graph Graph with the sub-control flow graphs expanded;

[0027] 2-5 The vulnerability tracing and analysis module sends the Graph to the fuzzing module;

[0028] Step 3: The test case generation module initializes the global variable test case set Inputs to an empty set, and the fuzzing module initializes the vulnerability-related interface set Vulinterfaces to an empty set.

[0029] Step 4: The test case generation module, fuzzing module, constraint bypass module, and real-time patching module work together to complete the fuzzing task. The test case generation module generates a set of test cases (Inputs) and sends them to the fuzzing module. The fuzzing module receives Inputs from the test case generation module, randomly selects and runs a test case (Input'), receives the vulnerability association graph (Graph) from the vulnerability source analysis module, executes Input' and obtains the test case execution path (Trace), updates the Graph based on the Trace, and obtains the updated vulnerability association graph (NewGraph). It then sends Input', Trace, and NewGraph to the constraint bypass module. Simultaneously, the fuzzing module monitors whether the vulnerability association graph has been updated, the execution status of the embedded device's web service script, the operation of the real-time patching module, and the operation of the constraint bypass module. If the vulnerability association graph has been updated, meaning the test case's execution path intersects with the existing vulnerability association graph's control flow, this module extracts the vulnerability-related interface set (Vulinterface) from the test case Input' in this round of fuzzing and sends Vulinterface to the test case generation module. In addition, the fuzzing module monitors the execution of the embedded device's Web service script in real time during fuzzing and sends error messages (Error) to the real-time patching module. The fuzzing module receives the patched Web service script (PatchedFile) from the real-time patching module and replaces the corresponding original Web service script file based on the path information of PatchedFile to prevent premature termination of the fuzzing test. The constraint bypass module receives input', Trace, and NewGraph from the fuzzing module and uses a vulnerability-sensitive point-driven, script instrumentation-based constraint bypass method to mutate input', obtaining the mutated test case NewInput, which is then sent to the fuzzing module. The real-time patching module receives Error from the fuzzing module and uses an online patching method based on command impact to repair the erroneous Web service script, obtaining the patched Web service script (PatchedFile), which is then sent to the fuzzing module. The specific method is as follows:

[0030] 4-1 The test case generation module reads WebFiles, parses the Web service scripts within the WebFiles to obtain text semantics, extracts the network transmission protocol format from the HTTP protocol specification, and generates a test case input based on the text semantics, the vulnerability-related interface set Vulinterfaces, and the network transmission protocol format. This input is then added to the test case set Inputs. The method is as follows:

[0031] 4-1-1 The test case generation module reads WebFiles, parses the Web service scripts within them to obtain text semantics, extracts the forward interfaces, and obtains the forward interface set `Interfaces`. The method is as follows:

[0032] 4-1-1-1 If the Web service script in WebFiles is a LUA script, the forward interface set is extracted by analyzing the script semantic information. The method is as follows: the forward interface in the Web service script contains the keyword "entry". This keyword comes from the UCI specification (Unified Configuration Interface). The test case generation module automatically extracts all interfaces defined by the keyword "entry" and adds the interfaces to the forward interface set Interfaces. Go to 4-1-2.

[0033] 4-1-1-2 If the web service script in WebFiles is a PHP script based on HNAP (Home Network Administration Protocol) services, the forward interface set is identified by analyzing the semantics of the web file system. The method is as follows: For PHP scripts that can send requests via the HNAP protocol, the test case generation module analyzes the HNAP protocol-related file system structure, obtains the relative path of the PHP service script, and adds the relative path and the fixed string "HNAP1" as an interface to the forward interface set Interfaces, then proceed to 4-1-2; for PHP scripts that cannot send requests via the HNAP protocol, proceed to 4-1-1-3.

[0034] 4-1-1-3 If the embedded device's web service script is a PHP-based MVC (Model-View-Controller, a software architecture pattern consisting of three interrelated parts: model, view, and controller) web service script, the test case generation module analyzes the script's semantics to identify the forward interface set. The method is as follows: based on the "controller" keyword included in the forward interface definition in the web service script, locate the custom class in the web service script, and extract the forward interface according to the relative file path and function name of the custom class, in accordance with the MVC specification, and add the interface to the forward interface set Interfaces, then go to 4-1-2; if the PHP-MVC architecture is not supported, then add the relative path of the PHP file to the forward interface set Interfaces, then go to 4-1-2.

[0035] 4-1-2 The test case generation module randomly selects an interface from Interfaces and Vulinterfaces, let it be interface, and extracts the network transmission protocol format from the HTTP protocol specification. Based on the text semantics of the Web service script and the network transmission protocol format, it generates a structured test case input, adds the input to the test case set Inputs, and sends Inputs to the fuzz testing module.

[0036] 4-2 The fuzzing module receives a Graph from the vulnerability tracing and analysis module and Inputs from the test case generation module. It randomly selects and runs a test case from the Inputs, while simultaneously monitoring and handling four different scenarios during the execution of the Web service script. The method is as follows:

[0037] 4-2-1 The fuzzing module receives Graphs from the vulnerability tracing and analysis module and Inputs from the test case generation module;

[0038] 4-2-2 Determine whether the mutated test case NewInput has been received from the constraint bypass module. If NewInput has been received, add NewInput to the test case set Inputs and go to 4-2-3. If NewInput has not been received from the constraint bypass module, go directly to 4-2-3.

[0039] 4-2-3 Randomly select a test case from the test case set Inputs, let it be input', inject the test case input' into the running Web service script, perform fuzz testing to run input', and obtain the Trace of the running path of input';

[0040] 4-2-4 The fuzzing module compares the control flow information in the Trace and the Graph. If the Graph lacks some control flow information from the Trace, it obtains a vulnerability-related interface (Vulinterface) from input' using string truncation according to the network transmission protocol format. This Vulinterface is then added to the vulnerability-related interface set (Vulinterfaces). Simultaneously, the control flow information from the Trace is supplemented to the existing Graph to obtain NewGraph. Input', NewGraph, and Trace are then sent to the constraint bypass module, proceeding to 4-4. If the Graph completely contains the control flow information from the Trace, proceed to 4-2-5.

[0041] 4-2-5 The fuzzing module monitors error messages during the execution of the web service scripts, monitors whether the patching module sends the patched script information, monitors whether test cases trigger vulnerabilities, and monitors whether the user enters a fuzzing termination message. The specific method is as follows:

[0042] 4-2-5-1 If the fuzzing module detects an error message "Error" during the runtime of the Web service script (the "Error" contains the path of the Web service script file that caused the fuzzing test to terminate prematurely in a single fuzzing test and the number of the error line), it sends the "Error" to the real-time patching module and proceeds to step 4-3. If the fuzzing module receives the repaired Web service script "PatchedFile" from the real-time patching module, it replaces the original Web service script file corresponding to "PatchedFile" with the path information of "PatchedFile" to prevent a single test case from stopping at the previous crash point during fuzzing and proceeds to step 4-2-3. If the fuzzing module receives a fuzzing termination signal sent by the user, proceeds to step 5. If the fuzzing module neither detects an error message "Error" during the runtime of the Web service script, nor receives "PatchedFile" from the real-time patching module, nor receives a fuzzing termination signal sent by the user, proceeds to step 4-2-5-2.

[0043] 4-2-5-2 The fuzzing module determines whether a vulnerability has been triggered based on its impact. The method is as follows: For command injection or cross-site scripting (XSS) vulnerabilities, the fuzzing module adds a command with an observable effect to the input' (e.g., `echo lll > / hacked`, which creates or overwrites a file named `hacked` in the system's root directory and writes the text "lll" to it). It then verifies whether the expected effect occurs in the file created after the vulnerability is triggered. If the vulnerability is triggered, the input' is added to the test case set `VulInputs`, which can trigger the vulnerability, and proceeds to 4-1-2; otherwise, it directly proceeds to 4-1-2.

[0044] 4-3 The real-time patching module reads WebFiles and, based on the runtime error information (Error) received from the fuzzing module, patches the Web service script (ErrorFile) that caused the fuzzing test to terminate prematurely, obtaining the patched Web service script (PatchedFile). PatchedFile is then sent to the fuzzing module. The method is as follows:

[0045] 4-3-1 The real-time patching module reads WebFiles, parses the Web service script content within them, locates the embedded commands in all Web service scripts within the WebFiles, determines the scope of influence of the embedded commands, and obtains the set of embedded command influence domains, Domain-A. The method is as follows:

[0046] 4-3-1-1 specifies the characteristics of embedded commands. The main characteristic of embedded commands is that they are commands embedded in the web service script that call other binary programs in the embedded device to complete specific functions. They are the same as the characteristics of the vulnerability sensitive points in 2-1, except that dophp, echo, and include_once are missing.

[0047] 4-3-1-2 Use regular expressions to identify all Web service scripts that have the embedded command-related features specified in 4-3-1-1, thereby extracting all embedded command locations in the Web service scripts and forming the embedded command location set embedded-A;

[0048] 4-3-1-3 Parse all Web service scripts and use a syntax tree conversion tool (such as LuaParser, https: / / github.com / fstirlitz / luaparse) to convert all Web service scripts into Q abstract syntax trees (Q is a positive integer, determined by the result of the syntax tree conversion tool);

[0049] 4-3-1-4 Starting from any embedded command position in embedded-A, taint propagation is performed on Q abstract syntax trees to determine the scope of influence of each embedded command position in embedded-A (the scope of influence refers to which specific lines of the web service script the effect of the command execution can cover), and the scope of influence of each embedded command is placed into the set of embedded command scopes Domain-A;

[0050] 4-3-2 The real-time patching module repairs ErrorFile based on Domain-A and Error, using the following method:

[0051] 4-3-2-1 Parse the specific Web service script file path and error line number in the Error to locate the breakpoint interrupt-A in the execution of the Web service script;

[0052] 4-3-2-2 Determine if interrupt-A is located within Domain-A;

[0053] 4-3-2-3 If interrupt-A is within Domain-A, insert a comment instruction at the interrupt-A location to repair the Web service script, resulting in a repaired Web service script, PatchedFile. Send PatchedFile to the fuzzing module and proceed to 4-2-5-1; if interrupt-A is not within Domain-A, proceed to 4-1-2.

[0054] 4-4 The constraint bypass module receives test case input', its execution path Trace, and the updated vulnerability association graph NewGraph from the fuzzing module. It also receives the vulnerability sensitive point set LU from the vulnerability source analysis module, extracts the path constraints of the basic blocks closest to the vulnerability sensitive points in the Trace, mutates test case input' based on these path constraints, obtains the mutated test case NewInput, and sends NewInput to the fuzzing module. The method is as follows:

[0055] 4-4-1 The constraint bypass module receives test case input', the execution path Trace of input', and the updated vulnerability association graph NewGraph from the fuzz testing module, and receives the vulnerability sensitive point set LU from the vulnerability tracing and analysis module;

[0056] 4-4-2 The constraint bypass module confirms the script instrumentation content based on Trace, NewGraph, and LU, and obtains the Comparison-set set output by the instrumentation statement. The method is as follows:

[0057] 4-4-2-1 Constraint Bypass Module Analysis Trace: Based on NewGraph, using Dijkstra's algorithm from EW Dijkstra's paper "A note on two problems in connexion with graphs" published in Numerische Mathematik 1959, we calculate the basic block BB in the trace that has the closest average distance to N vulnerability-sensitive points in LU (where the distance between two nodes is 1 if there is a call relationship between them; and infinite if there is no call relationship between them).

[0058] 4-4-2-2 Read the script content of BB and extract the last branch conditional statement (Constatement) in BB;

[0059] 4-4-2-3 Parse the Constatement, obtain the script variables it contains (variables created in the script file and used to store data), and put the script variables into the script variable collection Set;

[0060] 4-4-2-4 Generate instrumentation statements for the output set Comparison-set based on the script variable set Set and script variable value output statements. (An instrumentation statement is composed of multiple script variable value output functions, whose parameters are variables in the script variable set Set or path constraint values ​​in the Constatement.)

[0061] 4-4-2-5 Add an instrumentation statement Instrument to the last line of the basic block BB to obtain the instrumented BB';

[0062] 4-4-2-6 Replace the basic block BB in the Web service script with BB', inject the test case input' into the running Web service script, and perform fuzz testing to run input', resulting in a Comparsion-set set output by the instrumentation statement. The Comparsion-set set consists of P key-value pairs, each in the form (value1-value2), where value1 is the specific value of the script variable in the Constatement when the test case input' runs, value2 is the path constraint value in the Constatement, and P is a positive integer;

[0063] 4-4-3 The constraint bypass module parses input' and determines whether input' contains value1 from any key-value pair in Comparison-set. If it does, input' is mutated by replacing value1 in the key-value pair with value2 at the same position, generating a mutated test case NewInput, which is then sent to the fuzz testing module, proceeding to 4-2-2; if the determination result is no, proceeding to 4-1-2.

[0064] The fifth step involves the fuzzing module ending the embedded device web service script fuzzing system operation, outputting a set of test cases, VulInputs, that can trigger vulnerabilities to the user, helping the user further determine the location of the vulnerabilities, and then ending the process.

[0065] Compared with the prior art, the present invention can achieve the following beneficial effects:

[0066] 1. This invention is a gray-box fuzzy testing method for Web service scripts in embedded devices, which solves the problem of poor adaptability and low accuracy of existing Web service script vulnerability detection methods in embedded environments for different language scripts (PHP, LUA).

[0067] 2. In step 4 of this invention, 4-4 employs a vulnerability-sensitive point-driven, script instrumentation-based constraint bypass method, and 4-5 employs a command-influence-driven online patching method, enabling fuzz testing to overcome path barriers and thereby improve the depth and breadth of vulnerability discovery.

[0068] 3. Using this invention, web service scripts on 22 real-world embedded devices were tested, revealing 65 vulnerabilities. Of these, 36 vulnerabilities have been assigned CVE identifiers, and the remaining 27 have been patched by the vendors. These results highlight the largely unexplored attack surface in embedded web service scripts. Attached Figure Description

[0069] Figure 1 This is the overall flowchart of the present invention.

[0070] Figure 2 This is a system framework diagram of the embedded device Web service script fuzzing system constructed in the first step of this invention. Detailed Implementation

[0071] The present invention will now be described with reference to the accompanying drawings.

[0072] like Figure 1 As shown, the present invention includes the following steps:

[0073] Step 1: Build an embedded device web service script fuzzing system. The embedded device web service script fuzzing system is as follows: Figure 2 As shown, the system consists of a vulnerability tracing and analysis module, a test case generation module, a fuzz testing module, a constraint bypass module, and a real-time patching module.

[0074] The vulnerability tracing and analysis module is connected to the fuzzing module. The vulnerability tracing and analysis module reads all Web service scripts (WebFiles) in the embedded device under test, starts from the vulnerability-sensitive point, obtains the control flow that can reach the vulnerability-sensitive point through reverse tracing, and obtains an initialized vulnerability association graph (Graph) and a set of vulnerability-sensitive point locations (LU). The Graph is sent to the fuzzing module, and the LU is sent to the constraint bypassing module.

[0075] The test case generation module is connected to the fuzzing module. The test case generation module reads WebFiles, extracts text semantics from them, extracts network transmission protocol formats from the HTTP protocol specification, receives the vulnerability-related interface set Vulinterfaces from the fuzzing module, generates a test case input based on the text semantics, the vulnerability-related interface set Vulinterfaces, and the network transmission protocol formats, adds the input to the test case set Inputs, and sends Inputs to the fuzzing module.

[0076] The fuzzing module is connected to the vulnerability tracing and analysis module, test case generation module, constraint bypass module, and real-time patching module. The fuzzing module receives Inputs from the test case generation module, randomly selects a test case as the real-time test case input', receives the vulnerability association graph Graph from the vulnerability tracing and analysis module, executes input' and obtains the test case execution path Trace, updates the Graph based on the Trace, obtaining the updated vulnerability association graph NewGraph, and sends input', Trace, and NewGraph to the constraint bypass module. Simultaneously, the fuzzing module monitors whether the vulnerability association graph has been updated, monitors the execution status of the embedded device's web service script, the operation status of the real-time patching module, and the operation status of the constraint bypass module. If the vulnerability association graph has been updated, i.e., the test case's execution path intersects with the existing vulnerability association graph's control flow, this module extracts the vulnerability-related interface set Vulinterfaces from the test case input' of this round of fuzzing and sends Vulinterfaces to the test case generation module. The fuzzing module monitors the execution status of the embedded device's web service script in real time. If the fuzzing is interrupted, it sends the monitored embedded device error information Error to the real-time patching module. The fuzzing module receives the patched web service script (PatchedFile) from the real-time patching module, and replaces the original web service script file corresponding to PatchedFile with the path information of PatchedFile to prevent premature termination of the fuzzing test. The fuzzing module also receives mutated test cases (NewInput) from the constraint bypass module and adds NewInput to the test case set Inputs.

[0077] The constraint bypass module is connected to the fuzzing module. The constraint bypass module receives input', Trace, and NewGraph from the fuzzing module, and the set of vulnerability sensitive point locations LU from the vulnerability tracing and analysis module. Based on NewGraph, Trace, and LU, it instrumentes the embedded device web service script to obtain constraint values, uses the constraint values ​​to mutate input', obtains the mutated test case NewInput, and sends NewInput to the fuzzing module.

[0078] The real-time patching module is connected to the fuzzing module. The real-time patching module reads WebFiles, parses the embedded device Web service script content in the WebFiles, obtains the Domain of the embedded command's impact, receives runtime error information from the fuzzing module, repairs the Web service script based on the Error and Domain, and sends the repaired Web service script (PatchedFile) to the fuzzing module.

[0079] Step 2: The vulnerability tracing and analysis module reads WebFiles from the embedded device, analyzes the Web service scripts, generates a vulnerability graph (Graph) and a set of vulnerability-sensitive point locations (LU), sends the Graph to the fuzzing module, and sends the set of vulnerability-sensitive point locations (LU) to the constraint bypass module. The method is as follows:

[0080] 2-1 The vulnerability tracing and analysis module reads WebFiles from the embedded device and determines the characteristics of vulnerability-sensitive points (functions or code locations that may trigger vulnerabilities) in the Web service scripts within the WebFiles. These characteristics can be categorized into function-based and character-based features. Function-based features refer to common functions in Web service scripts (PHP or LUA scripts) related to command execution and cross-site scripting vulnerabilities, including: file handling functions (such as io.open, include_once, dophp); command execution functions (such as os.execute, nixio.exec, nixio.exece, nixio.execp, execl, Popen, exec, system, util.exec, util.execi, sys.exec, forkExec, fork_exec, fork_c, ltn12_popen, process.exec, cmd\(.*)\b); and information output functions (such as echo). Character-based features refer to common characters in Web service scripts related to command execution, including #! / bin / sh (the first line of the script file, used to specify the interpreter path for executing the script).

[0081] 2-2 The vulnerability tracing and analysis module uses regular expressions (also known as regular expressions, which use a single string to describe and match a series of strings that match a certain syntax rule, usually used to search for and replace text that matches a certain pattern (rule)) to match the vulnerability sensitive point features in the Web service script, obtaining a vulnerability sensitive point location set LU. Let the number of vulnerability sensitive points in LU be N, where N is a positive integer. Simultaneously, the vulnerability sensitive point location set LU is sent to the constraint bypass module;

[0082] The 2-3 vulnerability tracing and analysis module starts from N vulnerability-sensitive points in LU and constructs M reverse function call chains based on the function call relationships. These M reverse function call chains are then placed into the reverse function call chain set Liang. In the reverse function call chain, function nodes represent functions in the Web service script, and edges represent the call relationships between functions; M is a positive integer and M≥N.

[0083] The 2-4 vulnerability tracing and analysis module generates a vulnerability association graph (Graph) based on M reverse function call chains. The Graph contains function nodes and edges of the reverse function call chains and expands upon the sub-control flow graphs of the function nodes. The method is as follows:

[0084] 2-4-1 Let variable m = 1;

[0085] 2-4-2 Transform the function nodes in the m-th reverse function call chain in the set of reverse function call chains Liang into function nodes in the initial vulnerability association graph InitGraph. The transformation method is to directly use the function nodes on the m-th reverse function call chain as graph nodes (also function nodes) in InitGraph, and at the same time, transform the call relationships in the m-th reverse function call chain into directed edges in InitGraph, thereby completing the initialization of InitGraph.

[0086] 2-4-3 If m=M, then the InitGraph has been generated. Compared with the reverse function call chain, the InitGraph is more convenient for calculating the distance between nodes and guiding fuzz testing. Go to 2-4-5; otherwise, let m=m+1 and go to 2-4-4.

[0087] 2-4-4 Treat the function node on the m-th reverse function call chain as a function node in the InitGraph. If the function node already exists in the InitGraph, skip the function node. At the same time, convert the call relationship in the m-th reverse function call chain into a directed edge in the InitGraph. Go to 2-4-3.

[0088] 2-4-5 Supplement the internal control flow relationships for each function node in the InitGraph. For each function node, the basic blocks inside the function are taken as basic block nodes, and the jump relationships between basic blocks (conditional branches, unconditional jumps, etc.) are taken as edges. Construct the sub-control flow graph of this function node to obtain the vulnerability association graph Graph with the sub-control flow graphs expanded;

[0089] 2-5 The vulnerability tracing and analysis module sends the Graph to the fuzzing module.

[0090] Step 3: The test case generation module initializes the global variable test case set Inputs to an empty set, and the fuzzing module initializes the vulnerability-related interface set Vulinterfaces to an empty set.

[0091] Step 4: The test case generation module, fuzzing module, constraint bypass module, and real-time patching module work together to complete the fuzzing task. The test case generation module generates a set of test cases (Inputs) and sends them to the fuzzing module. The fuzzing module receives Inputs from the test case generation module, randomly selects and runs a test case (Input'), receives the vulnerability association graph (Graph) from the vulnerability source analysis module, executes Input' and obtains the test case execution path (Trace), updates the Graph based on the Trace, and obtains the updated vulnerability association graph (NewGraph). It then sends Input', Trace, and NewGraph to the constraint bypass module. Simultaneously, the fuzzing module monitors whether the vulnerability association graph has been updated, the execution status of the embedded device's web service script, the operation of the real-time patching module, and the operation of the constraint bypass module. If the vulnerability association graph has been updated, meaning the test case's execution path intersects with the existing vulnerability association graph's control flow, this module extracts the vulnerability-related interface set (Vulinterface) from the test case Input' in this round of fuzzing and sends Vulinterface to the test case generation module. In addition, the fuzzing module monitors the execution of the embedded device's Web service script in real time during fuzzing and sends error messages (Error) to the real-time patching module. The fuzzing module receives the patched Web service script (PatchedFile) from the real-time patching module and replaces the corresponding original Web service script file based on the path information of PatchedFile to prevent premature termination of the fuzzing test. The constraint bypass module receives input', Trace, and NewGraph from the fuzzing module and uses a vulnerability-sensitive point-driven, script instrumentation-based constraint bypass method to mutate input', obtaining the mutated test case NewInput, which is then sent to the fuzzing module. The real-time patching module receives Error from the fuzzing module and uses an online patching method based on command impact to repair the erroneous Web service script, obtaining the patched Web service script (PatchedFile), which is then sent to the fuzzing module. The specific method is as follows:

[0092] 4-1 The test case generation module reads WebFiles, parses the Web service scripts within the WebFiles to obtain text semantics, extracts the network transmission protocol format from the HTTP protocol specification, and generates a test case input based on the text semantics, the vulnerability-related interface set Vulinterfaces, and the network transmission protocol format. This input is then added to the test case set Inputs. The method is as follows:

[0093] 4-1-1 The test case generation module reads WebFiles, parses the Web service scripts within them to obtain text semantics, extracts the forward interfaces, and obtains the forward interface set `Interfaces`. The method is as follows:

[0094] 4-1-1-1 If the Web service script in WebFiles is a LUA script, the forward interface set is extracted by analyzing the script semantic information. The method is as follows: the forward interface in the Web service script contains the keyword "entry". This keyword comes from the UCI specification (Unified Configuration Interface). The test case generation module automatically extracts all interfaces defined by the keyword "entry" and adds the interfaces to the forward interface set Interfaces. Go to 4-1-2.

[0095] 4-1-1-2 If the web service script in WebFiles is a PHP script based on HNAP (Home Network Administration Protocol) services, the forward interface set is identified by analyzing the semantics of the web file system. The method is as follows: For PHP scripts that can send requests via the HNAP protocol, the test case generation module analyzes the HNAP protocol-related file system structure, obtains the relative path of the PHP service script, and adds the relative path and the fixed string "HNAP1" as an interface to the forward interface set Interfaces, then proceed to 4-1-2; for PHP scripts that cannot send requests via the HNAP protocol, proceed to 4-1-1-3.

[0096] 4-1-1-3 If the embedded device's web service script is a PHP-based MVC (Model-View-Controller, a software architecture pattern consisting of three interrelated parts: model, view, and controller) web service script, the test case generation module analyzes the script's semantics to identify the forward interface set. The method is as follows: based on the "controller" keyword included in the forward interface definition in the web service script, locate the custom class in the web service script, and extract the forward interface according to the relative file path and function name of the custom class, in accordance with the MVC specification, and add the interface to the forward interface set Interfaces, then go to 4-1-2; if the PHP-MVC architecture is not supported, then add the relative path of the PHP file to the forward interface set Interfaces, then go to 4-1-2.

[0097] 4-1-2 The test case generation module randomly selects an interface from Interfaces and Vulinterfaces, let it be interface, and extracts the network transmission protocol format from the HTTP protocol specification. Based on the text semantics of the Web service script and the network transmission protocol format, it generates a structured test case input, adds the input to the test case set Inputs, and sends Inputs to the fuzz testing module.

[0098] 4-2 The fuzzing module receives a Graph from the vulnerability tracing and analysis module and Inputs from the test case generation module. It randomly selects and runs a test case from the Inputs, while simultaneously monitoring and handling four different scenarios during the execution of the Web service script. The method is as follows:

[0099] 4-2-1 The fuzzing module receives Graphs from the vulnerability tracing and analysis module and Inputs from the test case generation module;

[0100] 4-2-2 Determine whether the mutated test case NewInput has been received from the constraint bypass module. If NewInput has been received, add NewInput to the test case set Inputs and go to 4-2-3. If NewInput has not been received from the constraint bypass module, go directly to 4-2-3.

[0101] 4-2-3 Randomly select a test case from the test case set Inputs, let it be input', inject the test case input' into the running Web service script, perform fuzz testing to run input', and obtain the Trace of the running path of input';

[0102] 4-2-4 The fuzzing module compares the control flow information in the Trace and the Graph. If the Graph lacks some control flow information from the Trace, it obtains a vulnerability-related interface (Vulinterface) from input' using string truncation according to the network transmission protocol format. This Vulinterface is then added to the vulnerability-related interface set (Vulinterfaces). Simultaneously, the control flow information from the Trace is supplemented to the existing Graph to obtain NewGraph. Input', NewGraph, and Trace are then sent to the constraint bypass module, proceeding to 4-4. If the Graph completely contains the control flow information from the Trace, proceed to 4-2-5.

[0103] 4-2-5 The fuzzing module monitors error messages during the execution of the web service scripts, monitors whether the patching module sends the patched script information, monitors whether test cases trigger vulnerabilities, and monitors whether the user enters a fuzzing termination message. The specific method is as follows:

[0104] 4-2-5-1 If the fuzzing module detects an error message "Error" during the runtime of the Web service script (the "Error" contains the path of the Web service script file that caused the fuzzing test to terminate prematurely in a single fuzzing test and the number of the error line), it sends the "Error" to the real-time patching module and proceeds to step 4-3. If the fuzzing module receives the repaired Web service script "PatchedFile" from the real-time patching module, it replaces the original Web service script file corresponding to "PatchedFile" with the path information of "PatchedFile" to prevent a single test case from stopping at the previous crash point during fuzzing and proceeds to step 4-2-3. If the fuzzing module receives a fuzzing termination signal sent by the user, proceeds to step 5. If the fuzzing module neither detects an error message "Error" during the runtime of the Web service script, nor receives "PatchedFile" from the real-time patching module, nor receives a fuzzing termination signal sent by the user, proceeds to step 4-2-5-2.

[0105] 4-2-5-2 The fuzzing module determines whether a vulnerability has been triggered based on its impact. The method is as follows: For command injection or cross-site scripting (XSS) vulnerabilities, the fuzzing module adds a command with an observable effect to the input' (e.g., `echo lll > / hacked`, which creates or overwrites a file named `hacked` in the system's root directory and writes the text "lll" to it). It then verifies whether the expected effect occurs in the file created after the vulnerability is triggered. If the vulnerability is triggered, the input' is added to the test case set `VulInputs`, which can trigger the vulnerability, and proceeds to 4-1-2; otherwise, it directly proceeds to 4-1-2.

[0106] 4-3 The real-time patching module reads WebFiles and, based on the runtime error information (Error) received from the fuzzing module, patches the Web service script (ErrorFile) that caused the fuzzing test to terminate prematurely, obtaining the patched Web service script (PatchedFile). PatchedFile is then sent to the fuzzing module. The method is as follows:

[0107] 4-3-1 The real-time patching module reads WebFiles, parses the Web service script content within them, locates the embedded commands in all Web service scripts within the WebFiles, determines the scope of influence of the embedded commands, and obtains the set of embedded command influence domains, Domain-A. The method is as follows:

[0108] 4-3-1-1 specifies the characteristics of embedded commands. The main characteristic of embedded commands is that they are commands embedded in the web service script that call other binary programs in the embedded device to complete specific functions. They are the same as the characteristics of the vulnerability sensitive points in 2-1, except that dophp, echo, and include_once are missing.

[0109] 4-3-1-2 Use regular expressions to identify all Web service scripts that have the embedded command-related features specified in 4-3-1-1, thereby extracting all embedded command locations in the Web service scripts and forming the embedded command location set embedded-A;

[0110] 4-3-1-3 Parse all Web service scripts and use a syntax tree conversion tool (such as LuaParser, https: / / github.com / fstirlitz / luaparse) to convert all Web service scripts into Q abstract syntax trees (Q is a positive integer, determined by the result of the syntax tree conversion tool);

[0111] 4-3-1-4 Starting from any embedded command position in embedded-A, taint propagation is performed on Q abstract syntax trees to determine the scope of influence of each embedded command position in embedded-A (the scope of influence refers to which specific lines of the web service script the effect of the command execution can cover), and the scope of influence of each embedded command is placed into the set of embedded command scopes Domain-A;

[0112] 4-3-2 The real-time patching module repairs ErrorFile based on Domain-A and Error, using the following method:

[0113] 4-3-2-1 Parse the specific Web service script file path and error line number in the Error to locate the breakpoint interrupt-A in the execution of the Web service script;

[0114] 4-3-2-2 Determine if interrupt-A is located within Domain-A;

[0115] 4-3-2-3 If interrupt-A is within Domain-A, insert a comment instruction at the interrupt-A location to repair the Web service script, resulting in a repaired Web service script, PatchedFile. Send PatchedFile to the fuzzing module and proceed to 4-2-5-1; if interrupt-A is not within Domain-A, proceed to 4-1-2.

[0116] 4-4 The constraint bypass module receives test case input', its execution path Trace, and the updated vulnerability association graph NewGraph from the fuzzing module. It also receives the vulnerability sensitive point set LU from the vulnerability source analysis module, extracts the path constraints of the basic blocks closest to the vulnerability sensitive points in the Trace, mutates test case input' based on these path constraints, obtains the mutated test case NewInput, and sends NewInput to the fuzzing module. The method is as follows:

[0117] 4-4-1 The constraint bypass module receives test case input', the execution path Trace of input', and the updated vulnerability association graph NewGraph from the fuzz testing module, and receives the vulnerability sensitive point set LU from the vulnerability tracing and analysis module;

[0118] 4-4-2 The constraint bypass module confirms the script instrumentation content based on Trace, NewGraph, and LU, and obtains the Comparison-set set output by the instrumentation statement. The method is as follows:

[0119] 4-4-2-1 Constraint Bypass Module Analysis Trace: Based on NewGraph, using Dijkstra's algorithm from EW Dijkstra's paper "A note on two problems in connexion with graphs" published in Numerische Mathematik 1959, we calculate the basic block BB in the trace that has the closest average distance to N vulnerability-sensitive points in LU (where the distance between two nodes is 1 if there is a call relationship between them; and infinite if there is no call relationship between them).

[0120] 4-4-2-2 Read the script content of BB and extract the last branch conditional statement (Constatement) in BB;

[0121] 4-4-2-3 Parse the Constatement, obtain the script variables it contains (variables created in the script file and used to store data), and put the script variables into the script variable collection Set;

[0122] 4-4-2-4 Generate instrumentation statements for the output set Comparison-set based on the script variable set Set and script variable value output statements. (An instrumentation statement is composed of multiple script variable value output functions, whose parameters are variables in the script variable set Set or path constraint values ​​in the Constatement.)

[0123] 4-4-2-5 Add an instrumentation statement Instrument to the last line of the basic block BB to obtain the instrumented BB';

[0124] 4-4-2-6 Replace the basic block BB in the Web service script with BB', inject the test case input' into the running Web service script, and perform fuzz testing to run input', resulting in a Comparsion-set set output by the instrumentation statement. The Comparsion-set set consists of P key-value pairs, each in the form (value1-value2), where value1 is the specific value of the script variable in the Constatement when the test case input' runs, value2 is the path constraint value in the Constatement, and P is a positive integer;

[0125] 4-4-3 The constraint bypass module parses input' and determines whether input' contains value1 from any key-value pair in Comparison-set. If it does, input' is mutated by replacing value1 in the key-value pair with value2 at the same position, generating a mutated test case NewInput, which is then sent to the fuzz testing module, proceeding to 4-2-2; if the determination result is no, proceeding to 4-1-2.

[0126] The fifth step involves the fuzzing module ending the embedded device web service script fuzzing system operation, outputting a set of test cases, VulInputs, that can trigger vulnerabilities to the user, helping the user further determine the location of the vulnerabilities, and then ending the process.

[0127] To verify the effectiveness of this invention, it was used to test 22 real-world embedded device web service scripts. The testing process is as follows:

[0128] This invention was run on an Ubuntu 20.04LTS machine equipped with a 2.30 GHz Intel Xeon(R) Gold 5218 CPU and 245 GB of memory. Throughout the fuzzing process, an authentication-enabled scripted testing environment was provided, in which the target firmware was pre-configured with authenticated user identifiers. Each test case was accompanied by a corresponding identifier (stok or cookie).

[0129] To evaluate the effectiveness of this invention in various aspects of vulnerability detection, 19 devices containing Web service scripts from 8 manufacturers (Xiaomi, Hikvision, Trendnet, Tenda, Linksys, Netgear, D-Link, and FLAIR) were selected (as shown in Table 1).

[0130]

[0131] To verify the vulnerability detection capabilities of this invention, tests were first conducted on a dataset of 14 publicly disclosed vulnerabilities. A comparative experiment was performed on five vulnerability detection tools: GH3Fuzz (described in this invention and background technology) and four static analysis tools (SonarQube, PROGPILOT, PSALM, and PHPCSSECURITY-AUDIT (PSA)). This invention and GH3Fuzz underwent five rounds of 12-hour fuzz testing to evaluate their vulnerability discovery effectiveness. The other four static analysis tools scanned PHP scripts in embedded systems to detect vulnerabilities. The experimental results are shown in Table 2.

[0132]

[0133] The CVE ID column indicates the general vulnerability and disclosure, referring to a unique, general, and standard number assigned to each publicly released cybersecurity vulnerability. The Type column indicates the vulnerability type and scripting language. For example, XSS-PHP indicates a cross-site scripting vulnerability in PHP scripts, while CI-LUA indicates a command injection vulnerability in LUA scripts. Additionally, for this invention and GH3fuzz, if the vulnerability is not identified in five 12-hour rounds, the result is marked as timeout. The remaining four columns, SonarQube, Progpilot, PSALM, and PSA (i.e., PHPCSSECURITY-AUDIT), indicate whether the static analysis tool successfully detected the vulnerability.

[0134] On the 14 publicly disclosed vulnerabilities shown in Table 2, the vulnerability detection rate of this invention is 2.5 times higher than that of existing tools (this invention detected 10 vulnerabilities, while other existing tools only detected 4). When limited to PHP vulnerabilities, this invention is 125% higher than existing static analysis methods (this invention detected 9 vulnerabilities, while other existing tools only detected 4). GH3Fuzz cannot detect any embedded system web service script vulnerabilities, mainly due to its lack of support for script-level interface access and constraint extraction.

[0135] SonarQube, Progpilot, PSALM, and PSA primarily focus on detecting vulnerabilities in PHP scripts, and therefore failed to identify any LUA-related vulnerabilities, such as CVE-2019-12272. For PHP script vulnerabilities, the customization and diversity of embedded scripting languages ​​limit the accuracy of SonarQube, Progpilot, PSALM, and PSA. For example, the four existing static analysis tools do not fully support custom PHP syntax (e.g., CVE-2024-33111, CVE-2018-6527). For instance, the i18n() function and global environment variables in PHP files can affect source identification and data flow propagation. Furthermore, even with the integration of custom PHP syntax, these static tools still cannot detect vulnerabilities involving cross-language control flow. For example, CVE-2018-19986, which involves cross-language calls from PHP to shell and back to PHP, was not detected by static tools, but was successfully discovered by EmesFuzz.

[0136] The invention was then used for large-scale Web service script vulnerability detection, testing over 19 different series of IoT devices from eight IoT vendors (Xiaomi, Hikvision, Trendnet, Tenda, Linksys, Netgear, D-Link, and FLAIR) (Table 1). Multiple rounds of fuzz testing were performed on each firmware on the simulation platform. Finally, the invention successfully identified 36 vulnerabilities across devices from multiple vendors, as shown in Table 3.

[0137]

[0138] The background technology describes the use of SonarQube, Progpilot, PSALM, and PSA to detect the PHP vulnerabilities listed in Table 3. Of all the vulnerabilities, these tools were only able to successfully identify one (CVE-2025-44224), representing 5% of the total vulnerabilities. This limited performance is primarily due to the custom framework (PHP-MVC) and script syntax, which interfere with source identification and data propagation in data flow analysis. Furthermore, these tools exhibit a significant false positive problem. For example, Progpilot reported a false positive rate as high as 52.1% (12 / 23) during analysis of AX8 firmware.

[0139] It is clear from the above testing process that:

[0140] (1) In terms of adaptability to vulnerability discovery targets, this invention demonstrates broader compatibility and applicability. Compared with existing tools, it can not only effectively handle a variety of common embedded scripting languages ​​(such as LUA and PHP), but also supports script analysis for embedded devices with different architectures and operating environments (multi-language operating environments), expanding the coverage of detectable targets and solving the problem that existing tools are limited to serving only a single language version.

[0141] (2) In terms of detection performance, this invention significantly improves the accuracy of vulnerability discovery. By combining static vulnerability sensitivity analysis with dynamic fuzz testing, this invention effectively reduces the number of false positives, especially avoiding the false positive problem common in traditional static analysis. Test results show that this invention can more accurately identify real vulnerabilities and reduce irrelevant notifications, thereby improving the credibility and efficiency of security assessment.

[0142] In summary, this invention is not only more versatile and flexible in its application scope, but also makes significant progress in the reliability of detection results, providing a more efficient and reliable solution for script security analysis in embedded environments.

Claims

1. A method for obstacle-aware fuzzy testing of Web service scripts for embedded devices, characterized in that... Includes the following steps: Step 1: Build an embedded device web service script fuzzing system. This system consists of a vulnerability tracing and analysis module, a test case generation module, a fuzzing module, a constraint bypass module, and a real-time patching module; the web service script refers to PHP script or Lua script. The vulnerability tracing and analysis module reads all Web service scripts (WebFiles) in the embedded device under test, obtains the control flow to reach the vulnerability-sensitive points, and gets the initialized vulnerability association graph (Graph) and vulnerability-sensitive point location set (LU). The test case generation module generates a test case input, adds the input to the test case collection Inputs, and sends Inputs to the fuzz testing module. The fuzzing module receives Inputs from the test case generation module, selects a test case as the real-time test case input' from the Inputs, receives the vulnerability association graph Graph from the vulnerability tracing and analysis module, executes input' and obtains the test case execution path Trace, updates the Graph, and obtains the updated vulnerability association graph NewGraph. The fuzzing module then sends input', Trace, and NewGraph to the constraint bypass module. The fuzzing module monitors whether the vulnerability association graph has been updated, monitors the execution status of the embedded device web service script, the working status of the real-time patching module, and the working status of the constraint bypass module. The constraint bypass module mutates input' to obtain the mutated test case NewInput; The real-time patching module repairs the Web service script and sends the repaired Web service script, PatchedFile, to the fuzzing module. Step 2: The vulnerability tracing and analysis module reads WebFiles from the embedded device, analyzes the Web service scripts, generates a vulnerability graph (Graph) and a set of vulnerability-sensitive point locations (LUs), and sends the Graph to the fuzzing module and the LUs to the constraint bypassing module. The method is as follows: The 2-1 vulnerability tracing and analysis module reads WebFiles from the embedded device and determines the characteristics of vulnerability-sensitive points in the Web service scripts within the WebFiles. Vulnerability-sensitive points refer to the locations of functions or code that can trigger vulnerabilities. The characteristics of vulnerability-sensitive points are divided into function-type and character-type. 2-2 The vulnerability tracing and analysis module uses regular expressions to match the vulnerability sensitive point features in the Web service script, and obtains the vulnerability sensitive point location set LU. Let the number of vulnerability sensitive points in LU be N, where N is a positive integer; send LU to the constraint bypass module. The 2-3 vulnerability tracing and analysis module starts from N vulnerability-sensitive points in LU and constructs M reverse function call chains based on the function call relationships. These M reverse function call chains are then placed into the reverse function call chain set Liang. In the reverse function call chain, function nodes represent functions in the Web service script, and edges represent the call relationships between functions. M is a positive integer and M≥N. The 2-4 vulnerability tracing and analysis module generates a vulnerability association graph based on M reverse function call chains. The graph contains function nodes and edges of the reverse function call chains and expands the sub-control flow graphs of the function nodes. 2-5 The vulnerability tracing and analysis module sends the Graph to the fuzzing module; The third step is to initialize the global variable test case set Inputs to an empty set in the test case generation module, and at the same time, initialize the vulnerability-related interface set Vulinterfaces to an empty set in the fuzzing module. Step 4: The test case generation module, fuzzing module, constraint bypassing module, and real-time patching module work together to complete the fuzzing task. The test case generation module is responsible for generating a set of test cases (Inputs) and sending them to the fuzzing module. The fuzzing module receives Inputs from the test case generation module, randomly selects and runs a test case (Input'), receives the vulnerability association graph (Graph) from the vulnerability tracing and analysis module, executes Input' and obtains the test case execution path (Trace), updates the Graph based on the Trace, and obtains the updated vulnerability association graph (NewGraph). It then sends Input', Trace, and NewGraph to the constraint bypassing module. Simultaneously, the fuzzing module monitors whether the vulnerability association graph has been updated, monitors the execution status of the embedded device's web service script, the operation status of the real-time patching module, and the operation status of the constraint bypassing module. If the vulnerability association graph has been updated, i.e., the execution path of the test case intersects with the existing vulnerability association graph in terms of control flow, this module extracts the vulnerability-related interface set (Vulinterface) from the test case (Input') of this round of fuzzing and sends Vulinterface to the test case generation module. During fuzzing, the fuzzing module monitors the running status of the embedded device's Web service script in real time and sends error messages to the real-time patching module. The fuzzing module receives the patched Web service script (PatchedFile) from the real-time patching module and replaces the corresponding original Web service script file according to the path information of PatchedFile to prevent premature termination of the fuzzing test. The constraint bypassing module receives input', Trace, and NewGraph from the fuzzing module, and uses a constraint bypassing method driven by vulnerability sensitivity points and script instrumentation to mutate input', obtaining the mutated test case NewInput, which is then sent to the fuzzing module. The real-time patching module receives errors from the fuzzing module, uses an online patching method based on command impact to repair the faulty web service script, and obtains the repaired web service script, PatchedFile, which is then sent to the fuzzing module. The specific method is as follows: 4-1 The test case generation module reads WebFiles, parses the Web service scripts in the WebFiles to obtain text semantics, extracts the network transmission protocol format from the HTTP protocol specification, and generates a test case input based on the text semantics, the vulnerability-related interface set Vulinterfaces, and the network transmission protocol format. This input is then added to the test case set Inputs. The method is as follows: 4-1-1 The test case generation module reads WebFiles, parses the Web service scripts in WebFiles to obtain text semantics, extracts the forward interfaces, and obtains the forward interface set Interfaces; 4-1-2 The test case generation module randomly selects an interface from Interfaces and Vulinterfaces, let it be interface, and extracts the network transmission protocol format from the HTTP protocol specification. Based on the text semantics of the Web service script and the network transmission protocol format, it generates a structured test case input, adds the input to the test case set Inputs, and sends Inputs to the fuzz testing module. 4-2 The fuzzing module receives a Graph from the vulnerability tracing and analysis module and Inputs from the test case generation module. It randomly selects and runs a test case from the Inputs, and simultaneously monitors and handles four different scenarios during the runtime of the Web service script. The method is as follows: 4-2-1 The fuzzing module receives Graphs from the vulnerability tracing and analysis module and Inputs from the test case generation module; 4-2-2 Determine whether the mutated test case NewInput has been received from the constraint bypass module. If NewInput has been received, add NewInput to the test case set Inputs and go to 4-2-3; if NewInput has not been received from the constraint bypass module, go directly to 4-2-3. 4-2-3 Randomly select a test case from the test case set Inputs, let it be input', inject the test case input' into the running Web service script, perform fuzz testing to run input', and obtain the Trace of the running path of input'; 4-2-4 The fuzzing module compares the control flow information in the Trace and the Graph. If the Graph lacks some control flow information from the Trace, it obtains a vulnerability-related interface (Vulinterface) in input' by string truncation according to the network transmission protocol format. The Vulinterface is added to the vulnerability-related interface set (Vulinterfaces). At the same time, the control flow information from the Trace is supplemented on the existing Graph to obtain NewGraph. Input', NewGraph, and Trace are sent to the constraint bypass module, and then proceed to 4-4. If the Graph completely contains the control flow information from the Trace, then proceed to 4-2-5. 4-2-5 The fuzzing module monitors error messages during the execution of the Web service script, monitors whether the patching module sends the patched script information, monitors whether test cases trigger vulnerabilities, and monitors whether the user enters fuzzing termination information. The method is as follows: 4-2-5-1 If the fuzzing module detects an error message "Error" during the runtime of the Web service script, it sends the "Error" to the real-time patching module and proceeds to 4-3; if the fuzzing module receives the repaired Web service script "PatchedFile" from the real-time patching module, it replaces the original Web service script file corresponding to "PatchedFile" with the path information of "PatchedFile" and proceeds to 4-2-3. If the fuzz testing module receives a fuzz test termination signal sent by the user, proceed to step five; If the fuzzing module neither detects an Error message during the runtime of the Web service script, nor receives a PatchedFile from the real-time patching module, nor receives a fuzzing termination signal sent by the user, proceed to 4-2-5-2. 4-2-5-2 The fuzzing module determines whether a vulnerability has been triggered based on its impact. The method is as follows: For command injection or cross-site scripting vulnerabilities, the fuzzing module adds a command with observable effects to the input' and verifies whether the expected effect occurs in the file created after the vulnerability is triggered. If the vulnerability triggering effect occurs, the input' is added to the test case set VulInputs that can trigger the vulnerability, and then proceeds to 4-1-2; if the vulnerability triggering effect does not occur, proceed directly to 4-1-2. 4-3 The real-time patching module reads WebFiles and, based on the Error received from the fuzzing module, patches the Web service script ErrorFile that caused the fuzzing test to terminate prematurely, obtaining the patched Web service script PatchedFile. PatchedFile is then sent to the fuzzing module. The method is as follows: 4-3-1 The real-time patching module reads WebFiles, parses the Web service script content in WebFiles, locates the embedded command positions in all Web service scripts in WebFiles and determines the scope of influence of the embedded commands, and obtains the set of embedded command influence scopes, Domain-A. 4-3-2 The real-time patching module repairs ErrorFile based on Domain-A and Error, using the following method: 4-3-2-1 Parse the specific Web service script file path and error line number in the Error to locate the breakpoint interrupt-A in the execution of the Web service script; 4-3-2-2 Determine if interrupt-A is located within Domain-A; 4-3-2-3 If interrupt-A is within Domain-A, insert a comment instruction at the interrupt-A location to repair the Web service script, resulting in a repaired Web service script, PatchedFile. Send PatchedFile to the fuzzing module and proceed to 4-2-5-1; if interrupt-A is not within Domain-A, proceed to 4-1-2. 4-4 The constraint bypass module receives test case input', its execution path Trace, and the updated vulnerability association graph NewGraph from the fuzzing module. It also receives LU from the vulnerability tracing and analysis module, extracts the path constraints of the basic block closest to the vulnerability's sensitive point in the Trace, mutates test case input' based on these constraints, and obtains the mutated test case NewInput. NewInput is then sent to the fuzzing module. The method is as follows: 4-4-1 The constraint bypass module receives test case input', the execution path Trace of input', and the updated vulnerability association graph NewGraph from the fuzz testing module, and receives the vulnerability sensitive point set LU from the vulnerability tracing and analysis module; 4-4-2 The constraint bypass module confirms the script instrumentation content based on Trace, NewGraph, and LU, and obtains the Comparsion-set set output by the instrumentation statement Instrument. The Comparsion-set set consists of P key-value pairs, with the key-value pair in the form of (value1-value2), where value1 is the specific value of the script variable in the Constatement when the test case input is run, value2 is the path constraint value in the Constatement, and P is a positive integer. 4-4-3 The constraint bypass module parses input' and determines whether input' contains value1 in any key-value pair in Comparison-set. If it does, input' is mutated, that is, value1 in the key-value pair is replaced with value2 in the same position, and test case NewInput is generated after input' is mutated. NewInput is sent to the fuzz testing module and then proceeds to 4-2-2. If the result is negative, proceed to 4-1-2; The fifth step involves the fuzzing module ending the embedded device web service script fuzzing system operation, outputting a set of test cases, VulInputs, that can trigger vulnerabilities to the user, helping the user further determine the location of the vulnerabilities, and then ending the process.

2. The obstacle-aware fuzzy testing method for embedded device web service scripts as described in claim 1, characterized in that... The vulnerability tracing and analysis module is connected to the fuzzing module. Starting from the vulnerability sensitive point, the vulnerability tracing and analysis module obtains the control flow that can reach the vulnerability sensitive point through reverse tracing, and obtains the initialized vulnerability association graph Graph and the vulnerability sensitive point location set LU. The Graph is then sent to the fuzzing module and the LU is sent to the constraint bypassing module. The test case generation module is connected to the fuzzing module. The test case generation module reads WebFiles, obtains text semantics from WebFiles, extracts network transmission protocol format from the HTTP protocol specification, receives the vulnerability-related interface set Vulinterfaces from the fuzzing module, generates a test case input based on the text semantics, the vulnerability-related interface set Vulinterfaces, and the network transmission protocol format, adds the input to the test case set Inputs, and sends Inputs to the fuzzing module. The fuzzing module is connected to the vulnerability tracing and analysis module, the test case generation module, the constraint bypass module, and the real-time patching module. The fuzzing module receives Inputs from the test case generation module, randomly selects a test case from the Inputs as the real-time test case input', receives the vulnerability association graph Graph from the vulnerability tracing and analysis module, executes input' and obtains the test case execution path Trace, updates the Graph based on the Trace, and obtains the updated vulnerability association graph NewGraph. It then sends input', Trace, and NewGraph to the constraint bypass module. The fuzzing module monitors whether the vulnerability association graph has been updated, monitors the execution of embedded device web service scripts, the operation of the real-time patching module, and the operation of the constraint bypass module. When the fuzzing module is running, if the vulnerability association graph has been updated (i.e., the test case execution path intersects with the existing vulnerability association graph in terms of control flow), the module extracts the vulnerability-related interface set Vulinterfaces from the test case input' of this round of fuzzing and sends Vulinterfaces to the test case generation module. The fuzzing module monitors the execution of the embedded device's Web service script in real time. If the fuzzing is interrupted, it sends the monitored embedded device error information (Error) to the real-time patching module. The fuzzing module receives the repaired Web service script (PatchedFile) from the real-time patching module and replaces the original Web service script file corresponding to PatchedFile with the path information of PatchedFile to prevent the fuzzing from terminating prematurely. The fuzzing module also receives mutated test cases (NewInput) from the constraint bypassing module and adds NewInput to the test case set Inputs. The constraint bypass module is connected to the fuzzing module. The constraint bypass module receives input', Trace and NewGraph from the fuzzing module, receives LU from the vulnerability tracing and analysis module, obtains constraint values ​​based on NewGraph and Trace instrumentation of embedded device web service scripts, uses constraint values ​​to mutate input', obtains the mutated test case NewInput, and sends NewInput to the fuzzing module. The real-time patching module is connected to the fuzzing module. This module reads WebFiles, parses the embedded device Web service script content in WebFiles, obtains the Domain of the embedded command, receives runtime error information from the fuzzing module, repairs the Web service script based on the Error and Domain, and sends the repaired Web service script (PatchedFile) to the fuzzing module.

3. The obstacle-aware fuzzy testing method for embedded device web service scripts as described in claim 1, characterized in that... The function classes in the vulnerability-sensitive points of the Web service script described in step 2-1 refer to common functions in Web service scripts related to command execution and cross-site scripting vulnerability triggering, including: functions related to file processing; functions related to command execution; and the information output function echo. The character classes refer to common characters in Web service scripts related to command execution, including #! / bin / sh, which is on the first line of the script file and is used to specify the interpreter path for executing the script. The functions related to file processing include io.open, include_once, and dophp. The functions related to command execution include os.execute, nixio.exec, nixio.exece, nixio.execp, execl, Popen, exec, system, util.exec, util.execi, sys.exec, forkExec, fork_exec, fork_c, ltn12_popen, process.exec, and cmd\(.*)\b.

4. The obstacle-aware fuzzy testing method for embedded device web service scripts as described in claim 1, characterized in that... The reverse function call chain mentioned in steps 2-3 refers to the following: a vulnerability-sensitive point is located in function B, function A calls function B, and a reverse function call chain A -> B is constructed, with the starting point being the vulnerability-sensitive point and the ending point being the outermost function found through iteration.

5. The obstacle-aware fuzzy testing method for embedded device web service scripts as described in claim 1, characterized in that... The method used by the vulnerability tracing and analysis module in steps 2-4 to generate a vulnerability association graph based on M reverse function call chains is as follows: 2-4-1 Let variable m = 1; 2-4-2 Transform the function nodes in the m-th reverse function call chain in the set of reverse function call chains Liang into function nodes in the initial vulnerability association graph InitGraph. The transformation method is to directly use the function nodes on the m-th reverse function call chain as graph nodes in InitGraph, that is, function nodes. At the same time, the call relationships in the m-th reverse function call chain are transformed into directed edges in InitGraph to complete the initialization of InitGraph. 2-4-3 If m=M, then InitGraph has been generated, go to 2-4-5; otherwise, let m=m+1, go to 2-4-4; 2-4-4 Treat the function node on the m-th reverse function call chain as a function node in the InitGraph. If the function node already exists in the InitGraph, skip the function node. At the same time, convert the call relationship in the m-th reverse function call chain into a directed edge in the InitGraph. Go to 2-4-3. 2-4-5 Supplement the internal control flow relationships for each function node in the InitGraph; for each function node, take the basic blocks inside the function as basic block nodes, and the jump relationships between basic blocks as edges, construct the sub-control flow graph of the function node, and obtain the vulnerability association graph Graph with the sub-control flow graphs expanded.

6. The obstacle-aware fuzzy testing method for embedded device web service scripts as described in claim 1, characterized in that... The method described in step 4-1-1 for the test case generation module to parse the Web service scripts in WebFiles to obtain text semantics, extract the forward interfaces, and obtain the forward interface set Interfaces is as follows: 4-1-1-1 If the Web service script in WebFiles is a Lua script, the forward interface set is extracted by analyzing the script semantic information. The method is as follows: the forward interface in the Web service script contains the keyword "entry". This keyword comes from the UCI specification. The test case generation module automatically extracts all interfaces defined by the keyword "entry" and adds the interfaces to the forward interface set Interfaces, and then ends. 4-1-1-2 If the web service script in WebFiles is a PHP script based on the HNAP service, the forward interface set is identified by analyzing the semantics of the web file system. The method is as follows: For PHP scripts that can send requests via the HNAP protocol, the test case generation module analyzes the file system structure related to the HNAP protocol, obtains the relative path of the PHP service script, and adds the relative path and the fixed string "HNAP1" together as an interface to the forward interface set Interfaces, and then ends; For PHP scripts that cannot send requests via the HNAP protocol, go to 4-1-1-3; 4-1-1-3 If the embedded device's web service script is a PHP-MVC-based web service script, the test case generation module analyzes the script's semantics to identify the forward interface set. The method is as follows: based on the "controller" keyword included in the forward interface definition in the web service script, locate the custom class in the web service script, and extract the forward interface according to the relative file path and function name of the custom class, in accordance with the MVC specification. Add the interface to the forward interface set Interfaces, and then the process ends. If the PHP-MVC architecture is not supported, add the relative path of the PHP file to the forward interface set Interfaces, and then the process ends.

7. The obstacle-aware fuzzy testing method for embedded device web service scripts as described in claim 1, characterized in that... The Error mentioned in step 4-2-5-1 includes the path of the Web service script file and the number of the error line that caused the fuzz test to terminate prematurely in a single fuzz test.

8. The obstacle-aware fuzzy testing method for embedded device web service scripts as described in claim 1, characterized in that... The command with observable effects described in step 4-2-5-2 is `echo lll > / hacked`, which creates or overwrites a file named `hacked` in the system's root directory and writes the text "lll" to it.

9. The obstacle-aware fuzzy testing method for embedded device web service scripts as described in claim 1, characterized in that... The method described in step 4-3-1 for the real-time patching module to parse the Web service script content in WebFiles, locate the embedded command positions in all Web service scripts in WebFiles, and determine the scope of influence of the embedded commands is as follows: 4-3-1-1 specifies the characteristics related to embedded commands. These characteristics refer to commands embedded within a Web service script that call other binary programs in an embedded device to perform specific functions. These include: functions related to file processing (io.open), functions related to command execution, and character classes (common characters related to command execution in Web service scripts, including #! / bin / sh). The functions related to command execution include os.execute, nixio.exec, nixio.exece, nixio.execp, execl, Popen, exec, system, util.exec, util.execi, sys.exec, forkExec, fork_exec, fork_c, ltn12_popen, process.exec, and cmd\(.*)\b. 4-3-1-2 Use regular expressions to identify all Web service scripts that have the embedded command-related features specified in 4-3-1-1, thereby extracting all embedded command locations in the Web service scripts and forming the embedded command location set embedded-A; 4-3-1-3 Parse all Web service scripts and use a syntax tree conversion tool to convert all Web service scripts into Q abstract syntax trees, where Q is a positive integer determined by the result of the syntax tree conversion tool; the syntax tree conversion tool is LuaParser; 4-3-1-4 Starting from any embedded command position in embedded-A, taint propagation is performed on Q abstract syntax trees to determine the scope of influence of each embedded command position in embedded-A. The scope of influence refers to which specific lines of the web service script the effect of the command execution can cover. The scope of influence of each embedded command is placed into the set of scope of influence of embedded commands, Domain-A.

10. The obstacle-aware fuzzy testing method for embedded device web service scripts as described in claim 1, characterized in that... The constraint bypass module described in step 4-4-2 confirms the script instrumentation content based on Trace, NewGraph, and LU using the following method: 4-4-2-1 Constraint Bypass Module Analysis Trace: Based on NewGraph, using Dijkstra's algorithm, calculate the basic block BB in the trace that is closest to the average distance of N vulnerability sensitive points in LU. If two nodes have a call relationship, their distance in the graph is 1; if two nodes do not have a call relationship, their distance in the graph is infinite. 4-4-2-2 Read the script content of BB and extract the last branch conditional statement (Constatement) in BB; 4-4-2-3 Parse the Constatement, obtain the script variables it contains, and put the script variables into the script variable collection Set; 4-4-2-4 Generates instrumentation statements for outputting a Comparison-set based on the script variable set Set and script variable value output statements. An instrumentation statement is composed of multiple script variable value output functions. The parameters of the script variable value output functions are variables in the script variable set Set or path constraint values ​​in the Constatement. 4-4-2-5 Add an instrumentation statement Instrument to the last line of the basic block BB to obtain the instrumented BB'; 4-4-2-6 Replace the basic block BB in the Web service script with BB', inject the test case input' into the running Web service script, and perform fuzz testing to run input', obtaining the set Comparsion-set output by the instrumentation statement Instrument.

Images