Method, device and equipment for identifying firmware verifier function and storage medium

Abstract

This invention relates to the field of IoT firmware vulnerability detection technology, and particularly to a method, apparatus, device, and storage medium for identifying firmware verifier functions. The method includes: unpacking the target firmware and performing static taint analysis to identify the data flow path to be processed, from user-controllable input to dangerous function call points; recovering the complete basic block sequence of the data flow path to be processed, identifying and locating the predecessor candidate verifier function basic blocks of the jump basic blocks; extracting and filtering the candidate verifier functions corresponding to the candidate verifier function basic blocks, identifying those that can be directly determined to have input verification capabilities as verifier functions, and marking those that cannot be directly determined as uncertain candidate verifier functions; and performing semantic judgment on the decompiled code of the uncertain candidate verifier functions to determine the verifier functions with input purification capabilities. This invention can solve the problem of easy omission or false positives in the identification of verifier functions in the prior art.

Description

Technical Field

[0001] This invention relates to the field of IoT firmware vulnerability detection technology, and in particular to a method, apparatus, device, and storage medium for identifying firmware verifier functions. Background Technology

[0002] With the widespread adoption of IoT devices, taint vulnerabilities such as command execution and buffer overflows in firmware have become major security threats. Static analysis is the mainstream method for detecting these vulnerabilities. Among them, taint tracing based on defined reachability analysis is widely used for security testing of IoT firmware due to its efficiency and scalability, and can locate the propagation path from user-controlled input to dangerous functions.

[0003] Existing firmware taint detection tools mostly rely on control flow condition recovery, data dependency graph backtracking, and verifier function name whitelisting verification logic. They distinguish between safe and dangerous data flow paths by determining whether the input has been cleaned by the verifier function. Some tools also incorporate heuristic rules such as return value checks and error handling outputs to help determine whether the data flow is protected.

[0004] Existing technologies have significant drawbacks: the whitelist of dependency function names cannot identify vendor-defined validator functions, making them prone to missed detections; incomplete recovery of control flow conditions and incomplete construction of data dependency graphs can lead to omission of genuine verification logic, causing safe paths to be misjudged as dangerous paths. Summary of the Invention

[0005] This invention provides a method, apparatus, device, and storage medium for identifying firmware verifier functions, in order to solve the problem that verifier functions are easily missed or falsely reported in the prior art.

[0006] In a first aspect, embodiments of the present invention provide a method for identifying firmware verifier functions, comprising: The target firmware is unpacked, and static taint analysis is performed on the unpacked target firmware based on defined reachability analysis to identify the unprocessed data flow path that the user-controllable input propagates to the dangerous function call point; Based on the constructed control flow graph and data dependency graph, the complete basic block sequence of the data flow path to be processed is recovered, the jump basic blocks in the data flow path to be processed are identified, and the predecessor candidate validator function basic blocks of the jump basic blocks are located according to the adjacent arrangement rules of the basic blocks. Extract the candidate validator functions corresponding to the basic blocks of the candidate validator functions, and filter the candidate validator functions based on the classification strategy. The candidate validator functions that can be directly determined to have input verification capabilities are identified as validator functions, and the candidate validator functions that cannot be directly determined to have input verification capabilities through the classification strategy are marked as uncertain candidate validator functions. Semantic determination is performed on the decompiled code of the uncertain candidate validator function to identify the uncertain candidate validator function with input cleansing capability as the validator function.

[0007] In one possible implementation, the predecessor candidate verifier function basic block of the jump basic block is located according to the adjacent arrangement pattern of basic blocks, including: Traverse the complete sequence of basic blocks and identify the predecessor basic blocks whose addresses are less than those of the jump basic block and which are consecutively adjacent to the jump basic block in the control flow of the data flow path to be processed as the candidate validator function basic blocks.

[0008] In one possible implementation, the candidate validator functions include: standard library verification-related functions, semantically strong indicator named functions, program ontology and anonymous internal functions, filtered functions, and indeterminate candidate validator functions; The candidate validator functions are screened based on a classification strategy. Candidate validator functions that can be directly determined to have input validation capabilities are identified as validator functions, while candidate validator functions whose input validation capabilities cannot be directly determined by the classification strategy are marked as uncertain candidate validator functions, including: The standard library verification function and the semantically strong indicator naming function are identified as verifier functions; The program body and anonymous internal functions are determined to lack input validation capabilities and are excluded. Exclude the filtered functions; The remaining candidate validator functions among the candidate validator functions are marked as the uncertain candidate validator functions.

[0009] In one possible implementation, after unpacking the target firmware, the following is also included: Perform binary preprocessing on the unpacked target firmware to obtain the mapping relationship between dynamic link libraries and exported functions; Semantic analysis is performed on the decompiled code of the uncertain candidate validator functions to determine the uncertain candidate validator functions with input sanitization capabilities as validator functions, including: Based on the mapping relationship, locate the library where the implementation code of the uncertain candidate verifier function is located, and extract the first decompiled code of the uncertain candidate verifier function; A large language model is used to determine whether the first decompiled code has user input format constraint logic and whether the constraint logic is circumventable, and a binary judgment result is output. Based on the binary determination result, the function among the uncertain candidate verifier functions that contains the constraint logic and whose constraint logic cannot be bypassed is determined as the verifier function.

[0010] In one possible implementation, after performing semantic determination on the decompiled code of the uncertain candidate validator function and identifying the uncertain candidate validator function with input cleansing capabilities as the validator function, the method further includes: Determine the target data stream path protected by the verifier function in the data stream path to be processed; A large language model is used to perform semantic verification on the verifier function in the target data flow path, and the final security judgment result is output.

[0011] In one possible implementation, determining the target data flow path protected by the verifier function within the data flow path to be processed includes: Detect whether the complete sequence of basic blocks in the data stream path to be processed contains the basic block corresponding to the validator function; If the complete basic block sequence contains the basic block corresponding to the validator function, then the second decompiled code of the validator function is extracted, and the large language model is used to determine whether the second decompiled code has executed unbypassable input format constraint logic on the contaminated variables in the data flow path to be processed; If so, the data flow path to be processed is determined to be the target data flow path protected by the verifier function.

[0012] In one possible implementation, a large language model is used to perform semantic verification on the validator function in the target data flow path, and the final security determination result is output, including: Determine whether the intermediate taint source call point and the dangerous function call point in the target data flow path belong to the same function; If they belong to the same function, then decompile the function and locate the tainted source call statement and the dangerous function call statement; The decompiled code of the function, the tainted source call statement, the dangerous function call statement, and the set of validator functions are input into the large language model. The large language model identifies the tainted variables, traces the propagation path of the tainted variables, and determines whether the validator functions form effective constraints on the tainted variables. Output the validity determination result of the verifier function, and correct the security mark of the target data flow path based on the validity determination result, and output the final security determination result.

[0013] Secondly, embodiments of the present invention provide a firmware verifier function identification device, comprising: The unpacking module is used to unpack the target firmware; The static taint analysis module is used to perform static taint analysis on the unpacked target firmware based on defined reachability analysis, and identify the unprocessed data flow path that propagates user-controllable input to dangerous function call points; The identification module is used to recover the complete basic block sequence of the data flow path to be processed based on the constructed control flow graph and data dependency graph, identify the jump basic blocks in the data flow path to be processed, and locate the predecessor candidate validator function basic blocks of the jump basic blocks according to the adjacent arrangement rules of the basic blocks. The filtering module is used to extract the candidate validator functions corresponding to the basic blocks of the candidate validator functions, and filter the candidate validator functions based on the classification strategy. The candidate validator functions that can be directly determined to have input verification capabilities are identified as validator functions, and the candidate validator functions that cannot be directly determined to have input verification capabilities through the classification strategy are marked as uncertain candidate validator functions. The semantic determination module is used to perform semantic determination on the decompiled code of the uncertain candidate validator functions, and to determine the uncertain candidate validator functions with input cleansing capabilities as validator functions.

[0014] Thirdly, embodiments of the present invention provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect or any possible implementation thereof.

[0015] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect or any possible implementation thereof.

[0016] This invention provides a method, apparatus, device, and storage medium for identifying firmware verifier functions. The method involves unpacking the target firmware and performing static taint analysis on the unpacked firmware based on defined reachability analysis to identify the data flow path to be processed, from user-controllable input to dangerous function call points. Based on the constructed control flow graph and data dependency graph, the complete basic block sequence of the data flow path to be processed is recovered, and jump basic blocks in the data flow path are identified. According to the adjacent arrangement rules of basic blocks, the predecessor candidate verifier function basic blocks of the jump basic blocks are located. Candidate verifier functions corresponding to the candidate verifier function basic blocks are extracted, and the candidate verifier functions are filtered based on a classification strategy. Candidate verifier functions that can be directly determined to have input verification capabilities are identified as verifier functions, while candidate verifier functions whose input verification capabilities cannot be directly determined by the classification strategy are marked as uncertain candidate verifier functions. Semantic judgment is performed on the decompiled code of the uncertain candidate verifier functions to determine uncertain candidate verifier functions with input cleanup capabilities as verifier functions. This invention locates candidate validator functions based on the adjacent arrangement of basic blocks, recovers them completely without relying on jump conditions, and has a wider coverage; it performs semantic judgment on decompiled code, breaks through the whitelist limitation, supports custom validator identification, improves the coverage and accuracy of validator function identification, and reduces the false positive rate and false negative rate. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the implementation of the firmware verifier function identification method provided in this embodiment of the invention. Figure 2 This is a flowchart illustrating the implementation of a firmware verifier function identification method according to another embodiment of the present invention. Figure 3 This is a schematic diagram of the structure of the firmware verifier function identification device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a firmware verifier function identification device provided in another embodiment of the present invention; Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0020] Validator functions are functionalities that perform validity checks, format constraints, length checks, range restrictions, or content filtering on user-controlled input to prevent illegal input from reaching dangerous functions. Validator functions play a crucial constraining role in the data stream propagation process, and their identification results directly affect the security determination of the data stream path.

[0021] Listing 1(a) shows a decompiled code snippet of the httpd program in the NETGEAR R6700 router firmware, containing the data flow path processed by the validator function. The function sub_19164 extracts the value of parameter KEY1_an from user request a1 and stores it in variable v97, then performs a length check using the validator function strlen. Subsequent control flow will only trigger a call to strcpy if the length of v97 is strictly 16. Listing 1(b) shows a decompiled code snippet of the httpd program in the TP-Link TL_WPA8630P router firmware, containing the data flow path processed by the validator function. The function httpGetEnv extracts the value of parameter pskSecret from user request a1 and stores it in v14, then calls strlen to get its length and saves it to v15. Next, the program performs a validity check on the length v15 using the validator function isIntBetween. Only if this check passes will v14 be passed to strcpy for processing; otherwise, control flow will enter the error handling function HttpErrorPage.

[0022] This demonstrates that validator functions can effectively filter unsafe input and reduce the risk of triggering vulnerabilities such as command execution and buffer overflows. Therefore, accurately identifying validator functions in firmware and determining their effectiveness in protecting data flow paths is crucial for improving the accuracy of tainted vulnerability detection and reducing false positives and false negatives.

[0023] For example, Listing 1(a) is a decompiled code snippet of the strlen validator function length check in NETGEAR R6700:

[0024] Listing 1(b) is a decompiled code snippet of the isIntBetween verifier function length check in the TP-Link TL_WPA8630P, which is:

[0025] See Figure 1 The document illustrates a flowchart of an implementation method for identifying firmware verifier functions according to an embodiment of the present invention, detailed below: Step 101: Unpack the target firmware and perform static taint analysis on the unpacked target firmware based on defined reachability analysis to identify the unprocessed data flow path that allows user-controllable input to propagate to dangerous function call points.

[0026] First, the target firmware of the IoT device is unpacked to extract the boundary binary program and the corresponding file system content, thus completing the basic parsing of the target firmware.

[0027] In one embodiment, such as Figure 2 As shown, binary preprocessing is performed on the unpacked target firmware to obtain the mapping relationship between dynamic link libraries and exported functions.

[0028] Optionally, during the preprocessing stage, the .dynamic and .dynstr segments of the boundary binary files are further parsed to determine the dynamic link libraries that the program depends on at runtime, and a mapping relationship between the dynamic link libraries and exported functions is constructed so as to quickly locate the library where the implementation code of the candidate validator functions is located.

[0029] Static taint analysis is performed on the unpacked target firmware based on Reaching Definitions Analysis (RDA). This process first traverses the program's basic blocks and constructs a Data Dependency Graph (DDG). Starting from the definition nodes involved in dangerous function call points, it backtracks through the DDG, checking the predecessor node's Tags attribute. If the backtracked predecessor node has a Tags attribute of type Return ValueTag, the corresponding function pointed to by the Tags attribute is marked as an intermediate taint source function, and the backtracking stops.

[0030] If the predecessor node traced back has a Tags attribute and is of type Local Variable Tag, then the corresponding function mentioned in the Tags attribute is recorded as the input processing function.

[0031] Through the above static taint analysis process, the entire data flow path from the intermediate taint source function to the dangerous function call point is identified. Such data flow paths with potential vulnerability risks are marked as data flow paths to be processed for subsequent verifier function identification and validity verification.

[0032] Step 102: Based on the constructed control flow graph and data dependency graph, restore the complete basic block sequence of the data flow path to be processed, identify the jump basic blocks in the data flow path to be processed, and locate the predecessor candidate validator function basic blocks of the jump basic blocks according to the adjacent arrangement rules of the basic blocks.

[0033] A control flow graph (CFG) is used to describe the execution jump relationships between basic blocks in a program. The construction process is as follows: Using the function containing the dangerous function call point as the smallest unit of analysis, disassembly traversal begins from the function entry address. The instruction sequence is segmented according to basic block rules: when encountering instructions such as unconditional jumps, conditional jumps, function returns, or function calls, the current basic block is segmented and terminated. A unique identifier is assigned to each basic block, typically using the address of the first instruction of the basic block. Directed edges are established based on the jump targets and execution flow directions between basic blocks: conditional jump basic blocks point to the "target basic block that satisfies the condition" and the "next basic block to be executed sequentially"; unconditional jump basic blocks point to their target basic block; and sequentially executed basic blocks are directly connected. This ultimately forms a control flow graph (CFG) with basic blocks as nodes and execution flow directions as edges, clearly reflecting all possible execution paths and their adjacency relationships with basic blocks.

[0034] Data dependency graphs are used to describe the data propagation relationships between variable definitions and usage in a program. The construction process is as follows: The algorithm iterates through all basic blocks within a function, identifying variable definitions (assignments) and variable uses (reads) in each instruction. For each variable assignment, a definition node is created, recording the definition location, the block it belongs to, the variable name, and its type. When an instruction uses a variable, the algorithm searches backward for the most recently effective definition node and establishes a data dependency edge between them. For scenarios such as function calls, parameter passing, and return values, corresponding parameter dependency edges and return value dependency edges are established. For nodes related to static taint analysis, the algorithm adds Tag attributes, including Local Variable Tag and ReturnValue Tag, to identify the input processing function and the intermediate taint source function. Finally, a data dependency graph is formed with definition nodes as vertices and data flow directions as edges.

[0035] In this step, the function containing the dangerous function call point in the data flow path to be processed is used as the analysis unit. All basic blocks within this function are traversed, and a corresponding data dependency graph is constructed based on the definition-use relationship. Starting from the definition node corresponding to the dangerous function call point, a reverse backtracking is performed in the data dependency graph, recursively visiting all predecessor definition nodes. During the backtracking process, the Tags attribute of each node is checked. If the backtracking reaches a node carrying a Return Value Tag, the function identified by that tag is recorded as an intermediate taint source function, and the backtracking terminates. Simultaneously, the addresses of the basic blocks corresponding to all definition nodes in the backtracking path are recorded, forming an initial list of basic block addresses for the data flow path.

[0036] Since data dependency graph backtracking only covers data-related basic blocks, this step combines the control flow graph to complete the missing control flow-related basic blocks in the initial data flow path, restoring a complete and reachable data flow path from the intermediate taint source call point to the dangerous function call point. The complete data flow path includes all connectable basic blocks involved in data propagation.

[0037] In one embodiment, locating the predecessor candidate validator function basic block of the jump basic block according to the adjacent arrangement pattern of basic blocks may include: Traverse the complete sequence of basic blocks and identify the predecessor basic blocks whose addresses are less than those of the jump basic block and are consecutively adjacent to the jump basic block in the control flow of the data flow path to be processed as candidate validator function basic blocks.

[0038] Based on the complete sequence of basic blocks, all basic blocks on the data flow path to be processed are traversed. According to the out-degree information of the basic blocks in the control flow graph (CFG), basic blocks with an out-degree greater than 1 are identified as jump basic blocks. Out-degree information refers to the number of successor basic blocks that a basic block can connect to after execution. For example, if out-degree = 0, there are no subsequent branches after the basic block is executed (e.g., the function returns directly), and no successor basic blocks. If out-degree = 1, there is only one sequential execution path after the basic block is executed, directly proceeding to the next basic block without generating branches. If out-degree > 1, multiple execution paths appear after the basic block is executed. The most common type is conditional jump basic blocks: if the condition is true, jump to the target basic block; if the condition is false, execute sequentially. Basic blocks with an out-degree greater than 1 are the jump basic blocks that this scheme aims to identify.

[0039] In this embodiment, the basic blocks of candidate validator functions are identified based on the adjacent arrangement pattern of basic blocks. The adjacent arrangement pattern of basic blocks is illustrated by the following example: First, during program analysis, we use basic blocks (BBs) as the smallest unit of analysis and abstract the data flow path into a sequence of basic blocks. To facilitate the identification of basic blocks, the address of the first assembly instruction of each basic block is usually chosen as its identifier, called the Basic Block Address (BBA). Thanks to the structural characteristics of basic blocks—single entry point, sequential execution, and single exit point—this address can effectively distinguish different basic blocks in the program.

[0040] Listing 1(c) is a disassembled code snippet of the corresponding verifier function in NETGEAR R6700, which is: … .text:00055B38MOVR0, R7; s .text:00055B3CBLstrlen .text:00055B40CMPR0, R10 .text:00055B44BNEloc_55B68 … Listing 1(d) is a disassembled code snippet of the corresponding verifier function in TP-Link TL_WPA8630P: … .text:0044924Cmove$a0, $v0 .text:00449250li$a1, 8 .text:00449254jalisIntBetween .text:00449258li$a2, 0x40# '@' .text:0044925Clw$gp, 0x30+var_10($sp) .text:00449260bnez$v0, loc_449294 .text:00449264move$a1, $s0# src … Listing 1(c) corresponds to the decompiled code of line 6 in Listing 1(a). In the snippet of Listing 1(c), the entry address of the basic block containing the verifier function strlen is 0x55B38 (covering the range 0x55B38–0x55B3C), and the entry address of the immediately following jump basic block is 0x55B40 (covering the range 0x55B40–0x55B44), both of which are arranged contiguously in memory. Similarly, Listing 1(d) shows the disassembled code in the TP-Link TL_WPA8630P firmware, corresponding to the decompiled code of line 6 in Listing 1(b). The entry address of the validator function `isIntBetween` basic block is 0x44924C (covering the range 0x44924C–0x449258), and the entry address of its subsequent jump basic block is 0x44925C (covering the range 0x44925C–0x449264). Both are also arranged adjacently. Our key observation is that the validator function basic block and the jump basic block are arranged adjacently in memory, and the basic block address of the validator function basic block is usually smaller than that of the jump basic block. Based on this observation, the system identifies jump basic blocks on the data flow path and further identifies the direct predecessor basic block of each jump basic block in the control flow order as candidate validator function basic blocks, thereby identifying more validator functions that process user input.

[0041] Step 103: Extract the candidate validator functions corresponding to the basic blocks of the candidate validator functions, and filter the candidate validator functions based on the classification strategy. The candidate validator functions that can be directly determined to have input verification capabilities are identified as validator functions, and the candidate validator functions that cannot be directly determined to have input verification capabilities through the classification strategy are marked as uncertain candidate validator functions.

[0042] Optionally, based on the assembly addresses and function symbol information corresponding to the basic blocks of the candidate validator functions, the candidate validator functions corresponding to each basic block are extracted. To quickly determine the validity of the candidate validator functions and reduce the inference overhead of large language models, this step performs classification filtering on the candidate validator functions.

[0043] In one embodiment, the candidate validator functions include: standard library validation-related functions, semantically strong indicator named functions, program body and anonymous internal functions, filtered functions, and uncertain candidate validator functions; Standard library validation-related functions, including strcmp, atoi, strlen, and other standard library functions commonly used for input comparison, numerical parsing, or length constraints; Semantically strong indicator named functions, that is, functions whose names contain significant verification semantic clues such as is, valid, safe, check, etc. The program body and anonymous internal functions, including the business functions implemented by the program itself and anonymous functions starting with sub; The filtered functions include intermediate taint source functions, configuration read functions, configuration write functions, string write functions, string parsing functions, memory management functions, file I / O functions, and command execution functions from a pre-built filter list; Finally, functions that do not belong to the above categories are marked as uncertain candidate validator functions.

[0044] In one embodiment, candidate validator functions are screened based on a classification strategy. Candidate validator functions that can be directly determined to have input validation capabilities are identified as validator functions, while candidate validator functions whose input validation capabilities cannot be directly determined through the classification strategy are marked as uncertain candidate validator functions. This includes: The standard library validation functions and semantically strong indicator named functions are identified as validator functions; The program body and anonymous internal functions are determined to lack input validation capabilities and are excluded. Excluded by the filtering function; The remaining candidate validator functions are marked as indeterminate candidate validator functions.

[0045] Optionally, functions implemented in the program body and anonymous inner functions starting with "sub" are not considered validator functions with verification capabilities because their internal logic is usually too complex to accurately identify their verification functions. The relevant data flow paths will not be directly judged as safe because of these functions and need to be further reviewed manually. Therefore, program body functions and anonymous inner functions are marked and manually reviewed to confirm whether they are validator functions.

[0046] Finally, candidate validator functions that cannot be directly determined to be valid by the above classification rules and do not belong to the filtering range are identified as uncertain candidate validator functions for subsequent semantic determination based on the large language model.

[0047] Step 104: Perform semantic determination on the decompiled code of the uncertain candidate validator function, and determine the uncertain candidate validator function with input cleansing capability as the validator function.

[0048] In one embodiment, semantic determination is performed on the decompiled code of the uncertain candidate validator function to identify the uncertain candidate validator function with input sanitization capability as the validator function, including: Based on the mapping relationship, locate the library where the implementation code of the uncertain candidate validator function is located, and extract the first decompiled code of the uncertain candidate validator function; The large language model is used to determine whether the first decompiled code contains user input format constraint logic and whether the constraint logic can be bypassed, and a binary judgment result is output. Based on the binary decision result, the function with constraint logic that cannot be bypassed among the uncertain candidate verifier functions is determined as the verifier function.

[0049] First, based on the mapping relationship between dynamic link libraries and exported functions built in the preprocessing stage, the dynamic link library where the implementation code of the uncertain candidate verifier function is located is located according to the name of the function. Then, the complete decompiled implementation code of the uncertain candidate verifier function is extracted through the decompile interface decompileFunction and used as the input for semantic determination.

[0050] Subsequently, a large language model is used to perform a two-layer semantic judgment on the decompiled code: the first layer judges whether there is verification logic in the decompiled code that restricts the format, length, range or legality of user input; the second layer judges whether the verification logic is bypassable, that is, whether there is maliciously constructed input that can still be judged as legal and bypass the constraints.

[0051] Input purification capability refers to the ability of a function to perform legality checks, format constraints, length checks, range restrictions, or content filtering on user-controllable input, and the constraint mechanism cannot be bypassed by malicious input, effectively preventing illegal input from reaching dangerous functions.

[0052] Uncertain candidate validator functions that meet the following conditions are identified as validator functions: they possess constraint validation logic for user input, and this validation logic cannot be bypassed. During the determination process, the output of the large language model strictly follows a preset format, returning only binary Boolean results indicating whether validation exists and whether it can be bypassed. For example, v∈{true,false} indicates whether an input validation mechanism exists, and b∈{true,false} indicates whether the validation mechanism can be bypassed. No additional textual information is included to ensure that the determination results can be automatically parsed and reproduced.

[0053] In existing technologies, the lack of semantic verification of the validity of verification logic can easily lead to unprotected dangerous paths being incorrectly classified as safe, increasing the risk of missed vulnerability reports. Therefore, in this embodiment, after performing semantic determination on the decompiled code of the uncertain candidate validator function and identifying the uncertain candidate validator function with input sanitization capabilities as the validator function, the method further includes: Determine the target data flow path protected by the verifier function in the data flow path to be processed; A large language model is used to perform semantic verification on the validator functions in the target data flow path, and the final security judgment result is output.

[0054] In the previous stage, the system was able to identify the validator functions that might be passed between intermediate taint source call points and dangerous function call points. However, relying solely on this result is insufficient to guarantee the security of data flow paths. Therefore, it is necessary to perform semantic verification on dangerous data flow paths identified as protected by validator functions to confirm that user input has indeed been processed by validator functions and to supplement the identification of validator functions that may have been missed in the previous analysis.

[0055] Optionally, after determining the validator function, all data flow paths to be processed are traversed, and it is checked whether the complete basic block sequence of the data flow path to be processed contains the basic block corresponding to the validator function. If the complete basic block sequence contains the basic block corresponding to the validator function, the second decompiled code of the validator function is extracted, and the large language model is used to determine whether the second decompiled code has executed unbypassable input format constraint logic on the polluted variables in the data flow path to be processed. If so, the data flow path to be processed is determined to be the target data flow path protected by the validator function.

[0056] To further improve the accuracy of the verification results, this embodiment uses a large language model to perform semantic verification of the verification validity of the target data flow path. In one embodiment, a large language model is used to perform semantic verification of the validator functions in the target data flow path, and the final security determination result is output, including: Determine whether intermediate taint source call points and dangerous function call points in the target data flow path belong to the same function; If they belong to the same function, then decompile the function and locate the tainted source call statement and the dangerous function call statement; The decompiled code of the function, tainted source call statements, dangerous function call statements, and the set of validator functions are input into the large language model. The large language model identifies the tainted variables, traces the propagation path of the tainted variables, and determines whether the validator functions form effective constraints on the tainted variables. Output the validity determination result of the validator function, and correct the security mark of the target data flow path based on the validity determination result, and output the final security determination result.

[0057] It's important to note that in real-world IoT firmware binaries, user input introduced by intermediate taint sources often traverses multiple functions, ultimately leading to dangerous function call points located within different functions. For such cross-function data flow paths, semantic verification to identify the validity of the validator function's handling of user input requires analyzing the decompiled code of multiple functions and constructing more complex prompt templates. This significantly increases analysis complexity and reduces the reliability of the results. Therefore, for cross-function data flow paths—where the intermediate taint source call point and the dangerous function call point belong to different functions in the target data flow path—the system does not perform automated semantic verification. Instead, it directly uses the validator function identification results from the previous stage to avoid erroneously rejecting identified validator functions due to unreliable cross-function analysis.

[0058] Optionally, when the analysis task is handled by a large language model, a structured reasoning prompt template is carefully designed for the semantic verification of validator function validity. Specifically, this task uses decompiled function-level code as the analysis object, requiring the model to determine within the same function whether tainted data has undergone effective verification or filtering during its propagation from intermediate tainted source call points to dangerous function call points. This task includes a multi-stage semantic analysis objective. First, the model needs to identify tainted variables introduced by intermediate tainted source call points, including pointers, arrays, structure members, and their aliases. Second, the model needs to trace the propagation path of these tainted variables in the complete decompiled function code, analyzing whether they have been processed by validator functions before reaching the dangerous function call point. These validator functions include both the set of validator functions obtained in the previous stage and candidate functions dynamically identified on the actual execution path. If there is processing logic that performs length validation, boundary checks, or character filtering on the contaminated variable, the validator function is considered valid on that path; otherwise, if the validator function is not called, the object being processed is unrelated to the contaminated variable, or its return result does not impose a substantial constraint on the execution path, it is considered invalid.

[0059] The model's analysis results are formalized as a set of Boolean decisions with validator function names as keys. Each validator function is labeled as true or false, indicating whether it effectively enforces security constraints along the data propagation path from the source to the sink. To ensure the model output is easy to process later, the output is strictly limited to a compact, structured text format, containing only validator functions with explicit names and their corresponding decisions, without any additional explanatory content.

[0060] Optionally, the validity flag of the validator function can be corrected based on the semantic verification result, and the final security judgment result of the target data flow path can be output to distinguish between the secure path that is effectively protected and the high-risk path that is not protected.

[0061] To verify the effectiveness of this invention, an experimental dataset containing firmware from 24 real IoT devices was constructed. The samples were selected from five mainstream device manufacturers, including Tenda, TP-Link, NETGEAR, Linksys, and D-Link. The dataset covers mainstream IoT device architectures such as MIPSEL, MIPSEB, and ARM32, and is consistent with the datasets used in existing technologies such as OctopusTaint, Mango, and Karonte, ensuring fair and reliable experimental comparisons.

[0062] 1. The recognition effect of the basic block arrangement pattern.

[0063] Based on the identification strategy of basic block arrangement patterns, this scheme can effectively locate validator functions missed by existing technologies. Experimental results show that this scheme identifies a total of 169 data flow paths protected by validator functions, of which 46 are safe paths that the existing technology OctopusTaint failed to identify, involving functions such as strcmp, strlen, and agApi_fwGetServiceByName. The above results demonstrate that the basic block arrangement pattern can significantly expand the identification range of validator functions and reduce the problem of missed identification caused by incomplete recovery of control flow conditions and missing data dependency graphs.

[0064] 2. Recognition performance of large-scale semantic classification.

[0065] This solution employs a large language model to perform semantic judgment on candidate functions, breaking through the limitations of traditional function name whitelists and effectively identifying vendor-defined validator functions. Experiments show that this solution additionally identifies 649 data flow paths protected by validator functions outside the whitelist, including custom functions such as isValidMacAddr, isValidNetworkAddr, isValidNetmask, SafeForShell, and isIntBetween, significantly reducing the false positive rate of vulnerability detection.

[0066] 3. The effect of semantic verification on improving the false negative rate.

[0067] To balance the recall rate and the false negative rate, this solution introduces a large language model semantic verification mechanism. In the 286 sampled high-risk data flow paths of this solution, without semantic verification, the recall rate of protected paths increased to 82.50%, but the false negative rate rose to 35.87%. After enabling semantic verification, the recall rate of protected paths further increased to 85.00%, and the false negative rate decreased from 11.96% to 8.70%.

[0068] Experimental results show that semantic verification can effectively correct the over-security judgment caused by the adjacency pattern of basic blocks, avoid misjudging real dangerous paths as safe paths, and at the same time retain the ability to identify real safe paths, achieving a balance between high recall and low false negative rate.

[0069] This invention provides a method for identifying firmware verifier functions. The method involves unpacking the target firmware and performing static taint analysis on the unpacked firmware based on defined reachability analysis to identify the data flow path from user-controllable input to dangerous function call points. Based on the constructed control flow graph and data dependency graph, the complete basic block sequence of the data flow path is restored, and jump basic blocks in the data flow path are identified. According to the adjacent arrangement of basic blocks, the predecessor candidate verifier function basic blocks are located. Candidate verifier functions corresponding to the candidate verifier function basic blocks are extracted, and these candidates are screened based on a classification strategy. Candidate verifier functions that can be directly determined to have input verification capabilities are identified as verifier functions, while those that cannot be directly determined to have input verification capabilities are marked as uncertain candidate verifier functions. Semantic judgment is performed on the decompiled code of the uncertain candidate verifier functions to determine those with input purification capabilities as verifier functions. This invention locates candidate validator functions based on the adjacent arrangement of basic blocks, recovering them completely without relying on jump conditions, thus providing broader coverage. It employs a large language model to perform semantic judgment on decompiled code, breaking through whitelist limitations and supporting custom validator identification. This improves the coverage and accuracy of validator function identification, reduces false positive and false negative rates, and ultimately achieves high recall, low false positive, and low false negative detection of IoT firmware taint vulnerabilities.

[0070] This invention also introduces a semantic verification mechanism within the same function context to confirm whether the verifier truly constrains the contaminated variables, thereby reducing false negatives. Experiments show that this invention increases the recall rate of data flow path identification protected by the verifier function from 27.50% to 85.00%, and reduces the false negative rate of vulnerabilities from 11.96% to 8.70%. It can significantly reduce the cost of manual analysis, improve the reliability and accuracy of firmware security detection, and is applicable to static security analysis of firmware in various Linux architecture IoT devices.

[0071] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0072] The following are device embodiments of the present invention. For details not described in detail, please refer to the corresponding method embodiments described above.

[0073] Figure 3 The diagram shows a structural schematic of a firmware verifier function identification device according to an embodiment of the present invention. For ease of explanation, only the parts related to the embodiment of the present invention are shown, and are described in detail below: like Figure 3As shown, the firmware verifier function identification device includes: unpacking module 31, static taint analysis module 32, identification module 33, filtering module 34, and semantic determination module 35.

[0074] The unpacking module 31 is used to unpack the target firmware; Static taint analysis module 32 is used to perform static taint analysis on the unpacked target firmware based on defined reachability analysis, and identify the unprocessed data flow path that the user-controllable input propagates to the dangerous function call point; The identification module 33 is used to recover the complete basic block sequence of the data flow path to be processed based on the constructed control flow graph and data dependency graph, identify the jump basic blocks in the data flow path to be processed, and locate the predecessor candidate validator function basic blocks of the jump basic blocks according to the adjacent arrangement rules of the basic blocks. The filtering module 34 is used to extract the candidate validator functions corresponding to the basic blocks of the candidate validator functions, and to filter the candidate validator functions based on the classification strategy. The candidate validator functions that can be directly determined to have input verification capabilities are identified as validator functions, and the candidate validator functions that cannot be directly determined to have input verification capabilities through the classification strategy are marked as uncertain candidate validator functions. The semantic determination module 35 is used to perform semantic determination on the decompiled code of uncertain candidate validator functions and determine the uncertain candidate validator functions with input cleanup capabilities as validator functions.

[0075] In one possible implementation, when the identification module 33 locates the predecessor candidate verifier function basic block of the jump basic block according to the adjacent arrangement pattern of basic blocks, it is used for: Traverse the complete sequence of basic blocks and identify the predecessor basic blocks whose addresses are less than those of the jump basic block and are consecutively adjacent to the jump basic block in the control flow of the data flow path to be processed as candidate validator function basic blocks.

[0076] In one possible implementation, candidate validator functions include: standard library verification-related functions, semantically strong indicator named functions, program body and anonymous internal functions, filtered functions, and indeterminate candidate validator functions; The filtering module 34 filters candidate validator functions based on a classification strategy. It identifies candidate validator functions whose input validation capability can be directly determined as validator functions, and marks candidate validator functions whose input validation capability cannot be directly determined by the classification strategy as uncertain candidate validator functions. This is used for: The standard library validation functions and semantically strong indicator named functions are identified as validator functions; The program body and anonymous internal functions are determined to lack input validation capabilities and are excluded. Excluded by the filtering function; The remaining candidate validator functions are marked as indeterminate candidate validator functions.

[0077] In one possible implementation, such as Figure 4 As shown, it also includes a preprocessing module 36; After the unpacking module 31 unpacks the target firmware, the preprocessing module 36 is used for: Perform binary preprocessing on the unpacked target firmware to obtain the mapping relationship between dynamic link libraries and exported functions; In one possible implementation, the semantic determination module 35 performs semantic determination on the decompiled code of the uncertain candidate validator function. When it determines that the uncertain candidate validator function with input cleansing capability is a validator function, it is used for: Based on the mapping relationship, locate the library where the implementation code of the uncertain candidate validator function is located, and extract the first decompiled code of the uncertain candidate validator function; The large language model is used to determine whether the first decompiled code contains user input format constraint logic and whether the constraint logic can be bypassed, and a binary judgment result is output. Based on the binary decision result, the function with constraint logic that cannot be bypassed among the uncertain candidate verifier functions is determined as the verifier function.

[0078] In one possible implementation, such as Figure 4 As shown, it also includes a verification module 37; After the semantic determination module 35 performs semantic determination on the decompiled code of the uncertain candidate validator function and determines that the uncertain candidate validator function with input cleansing capability is the validator function, the verification module 37 is used for: Determine the target data flow path protected by the verifier function in the data flow path to be processed; A large language model is used to perform semantic verification on the validator functions in the target data flow path, and the final security judgment result is output.

[0079] In one possible implementation, when the verification module 37 determines the target data flow path protected by the verifier function in the data flow path to be processed, it is used to: Detect whether the complete sequence of basic blocks in the data stream path to be processed contains the basic block corresponding to the validator function; If the complete basic block sequence contains the basic block corresponding to the validator function, then the second decompiled code of the validator function is extracted, and the large language model is used to determine whether the second decompiled code has executed the unavoidable input format constraint logic on the polluted variables in the data flow path to be processed. If so, the data flow path to be processed will be determined as the target data flow path protected by the verifier function.

[0080] In one possible implementation, the verification module 37 uses a large language model to perform semantic verification on the verifier functions in the target data flow path, and when outputting the final security determination result, it is used for: Determine whether intermediate taint source call points and dangerous function call points in the target data flow path belong to the same function; If they belong to the same function, then decompile the function and locate the tainted source call statement and the dangerous function call statement; The decompiled code of the function, tainted source call statements, dangerous function call statements, and the set of validator functions are input into the large language model. The large language model identifies the tainted variables, traces the propagation path of the tainted variables, and determines whether the validator functions form effective constraints on the tainted variables. Output the validity determination result of the validator function, and correct the security mark of the target data flow path based on the validity determination result, and output the final security determination result.

[0081] The above embodiments provide a firmware verifier function identification device. An unpacking module unpacks the target firmware, and a static taint analysis module performs static taint analysis on the unpacked target firmware based on defined reachability analysis to identify the data flow path to be processed, from user-controllable input to dangerous function call points. Based on the constructed control flow graph and data dependency graph, the identification module recovers the complete basic block sequence of the data flow path to be processed, identifies the jump basic blocks in the data flow path, and locates the predecessor candidate verifier function basic blocks according to the adjacent arrangement rules of the basic blocks. A filtering module extracts the candidate verifier functions corresponding to the candidate verifier function basic blocks and filters the candidate verifier functions based on a classification strategy. Candidate verifier functions that can be directly determined to have input verification capabilities are identified as verifier functions, while candidate verifier functions whose input verification capabilities cannot be directly determined by the classification strategy are marked as uncertain candidate verifier functions. A semantic determination module performs semantic determination on the decompiled code of uncertain candidate verifier functions to identify uncertain candidate verifier functions with input purification capabilities as verifier functions. This invention locates candidate validator functions based on the adjacent arrangement of basic blocks, recovering them completely without relying on jump conditions, thus providing broader coverage. It employs a large language model to perform semantic judgment on decompiled code, breaking through whitelist limitations and supporting custom validator identification. This improves the coverage and accuracy of validator function identification, reduces false positive and false negative rates, and ultimately achieves high recall, low false positive, and low false negative detection of IoT firmware taint vulnerabilities.

[0082] This invention also introduces a semantic verification mechanism within the same function context to confirm whether the verifier truly constrains the contaminated variables, thereby reducing false negatives. Experiments show that this invention increases the recall rate of data flow path identification protected by the verifier function from 27.50% to 85.00%, and reduces the false negative rate of vulnerabilities from 11.96% to 8.70%. It can significantly reduce the cost of manual analysis, improve the reliability and accuracy of firmware security detection, and is applicable to static security analysis of firmware in various Linux architecture IoT devices.

[0083] Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. For example... Figure 5 As shown, the electronic device 5 of this embodiment includes a processor 50 and a memory 51. The memory 51 stores a computer program 52. When the processor 50 executes the computer program 52, it implements the steps in the various method embodiments described above. Alternatively, when the processor 50 executes the computer program 52, it implements the functions of each module / unit in the various device embodiments described above.

[0084] For example, computer program 52 may be divided into one or more modules / units, which are stored in memory 51 and executed by processor 50 to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 52 in electronic device 5.

[0085] Electronic device 5 may include, but is not limited to, processor 50 and memory 51. Those skilled in the art will understand that... Figure 5 This is merely an example of electronic device 5 and does not constitute a limitation on electronic device 5. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device 5 may also include input / output devices, network access devices, buses, etc.

[0086] The processor 50 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0087] The memory 51 can be an internal storage unit of the electronic device 5, such as a hard disk or RAM. The memory 51 can also be an external storage device of the electronic device 5, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 51 can include both internal and external storage units of the electronic device 5. The memory 51 is used to store the computer program 52 and other programs and data required by the electronic device 5. The memory 51 can also be used to temporarily store data that has been output or will be output.

[0088] For the sake of simplicity and clarity, only the above-described functional modules / units are used as examples. In practical applications, the functions described above can be assigned to different functional modules / units as needed. These modules / units can be implemented in hardware, software, or a combination of both.

[0089] This invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the methods described in the above-described method embodiments.

[0090] This invention also provides a computer program product, including a computer program. When the computer program is executed by a processor, it implements the methods described in the above-described method embodiments.

[0091] Computer programs include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0092] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not detailed or described in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Unless otherwise specified or in conflict with logic, the terminology and / or descriptions between different embodiments are consistent and can be referenced interchangeably. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0093] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method of identifying a firmware verifier function, the method comprising: include: The target firmware is unpacked, and static taint analysis is performed on the unpacked target firmware based on defined reachability analysis to identify the unprocessed data flow path that the user-controllable input propagates to the dangerous function call point; Based on the constructed control flow graph and data dependency graph, the complete basic block sequence of the data flow path to be processed is recovered, the jump basic blocks in the data flow path to be processed are identified, and the predecessor candidate validator function basic blocks of the jump basic blocks are located according to the adjacent arrangement rules of the basic blocks. Extract the candidate validator functions corresponding to the basic blocks of the candidate validator functions, and filter the candidate validator functions based on the classification strategy. The candidate validator functions that can be directly determined to have input verification capabilities are identified as validator functions, and the candidate validator functions that cannot be directly determined to have input verification capabilities through the classification strategy are marked as uncertain candidate validator functions. Semantic determination is performed on the decompiled code of the uncertain candidate validator function to identify the uncertain candidate validator function with input cleansing capability as the validator function.

2. The method of claim 1, wherein, Based on the adjacent arrangement pattern of basic blocks, the predecessor candidate verifier function basic block of the jump basic block is located, including: Traverse the complete sequence of basic blocks and identify the predecessor basic blocks whose addresses are less than those of the jump basic block and which are consecutively adjacent to the jump basic block in the control flow of the data flow path to be processed as the candidate validator function basic blocks.

3. The method for identifying firmware verifier functions according to claim 1, characterized in that, The candidate validator functions include: standard library verification-related functions, semantically strong indicator named functions, program body and anonymous internal functions, filtered functions, and uncertain candidate validator functions; The candidate validator functions are screened based on a classification strategy. Candidate validator functions that can be directly determined to have input validation capabilities are identified as validator functions, while candidate validator functions whose input validation capabilities cannot be directly determined by the classification strategy are marked as uncertain candidate validator functions, including: The standard library verification function and the semantically strong indicator naming function are identified as verifier functions; The program body and the anonymous internal functions are determined to lack input validation capabilities and are excluded. Exclude the filtered functions; The remaining candidate validator functions among the candidate validator functions are marked as the uncertain candidate validator functions.

4. The method for identifying firmware verifier functions according to claim 3, characterized in that, After unpacking the target firmware, the following is also included: Perform binary preprocessing on the unpacked target firmware to obtain the mapping relationship between dynamic link libraries and exported functions; Semantic analysis is performed on the decompiled code of the uncertain candidate validator functions to determine the uncertain candidate validator functions with input sanitization capabilities as validator functions, including: Based on the mapping relationship, locate the library where the implementation code of the uncertain candidate verifier function is located, and extract the first decompiled code of the uncertain candidate verifier function; A large language model is used to determine whether the first decompiled code has user input format constraint logic and whether the constraint logic is circumventable, and a binary judgment result is output. Based on the binary determination result, the function among the uncertain candidate verifier functions that contains the constraint logic and whose constraint logic cannot be bypassed is determined as the verifier function.

5. The method for identifying firmware verifier functions according to any one of claims 1-4, characterized in that, After performing semantic determination on the decompiled code of the uncertain candidate validator function and identifying the uncertain candidate validator function with input sanitization capability as the validator function, the process further includes: Determine the target data stream path protected by the verifier function in the data stream path to be processed; A large language model is used to perform semantic verification on the verifier function in the target data flow path, and the final security judgment result is output.

6. The method for identifying firmware verifier functions according to claim 5, characterized in that, Determining the target data stream path protected by the validator function within the data stream path to be processed includes: Detect whether the complete sequence of basic blocks in the data stream path to be processed contains the basic block corresponding to the validator function; If the complete basic block sequence contains the basic block corresponding to the validator function, then the second decompiled code of the validator function is extracted, and the large language model is used to determine whether the second decompiled code has executed unbypassable input format constraint logic on the contaminated variables in the data flow path to be processed; If so, the data flow path to be processed is determined to be the target data flow path protected by the verifier function.

7. The method for identifying firmware verifier functions according to claim 6, characterized in that, A large language model is used to perform semantic verification on the validator function in the target data flow path, and the final security determination result is output, including: Determine whether the intermediate taint source call point and the dangerous function call point in the target data flow path belong to the same function; If they belong to the same function, then decompile the function and locate the tainted source call statement and the dangerous function call statement; The decompiled code of the function, the tainted source call statement, the dangerous function call statement, and the set of validator functions are input into the large language model. The large language model identifies the tainted variables, traces the propagation path of the tainted variables, and determines whether the validator functions form effective constraints on the tainted variables. Output the validity determination result of the verifier function, and correct the security mark of the target data flow path based on the validity determination result, and output the final security determination result.

8. A device for identifying firmware verifier functions, characterized in that, include: The unpacking module is used to unpack the target firmware; The static taint analysis module is used to perform static taint analysis on the unpacked target firmware based on defined reachability analysis, and identify the unprocessed data flow path that propagates user-controllable input to dangerous function call points; The identification module is used to recover the complete basic block sequence of the data flow path to be processed based on the constructed control flow graph and data dependency graph, identify the jump basic blocks in the data flow path to be processed, and locate the predecessor candidate validator function basic blocks of the jump basic blocks according to the adjacent arrangement rules of the basic blocks. The filtering module is used to extract the candidate validator functions corresponding to the basic blocks of the candidate validator functions, and filter the candidate validator functions based on the classification strategy. The candidate validator functions that can be directly determined to have input verification capabilities are identified as validator functions, and the candidate validator functions that cannot be directly determined to have input verification capabilities through the classification strategy are marked as uncertain candidate validator functions. The semantic determination module is used to perform semantic determination on the decompiled code of the uncertain candidate validator function, and determine the uncertain candidate validator function with input cleanup capability as the validator function.

9. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images