Directional fuzz testing method for wide adaptation of Windows platform application programs

Abstract

The invention discloses a directional fuzzy testing method for wide adaptation of Windows platform application programs. The directional fuzzy testing method comprises the steps that target program adaptation is carried out; the target function meeting the condition is positioned, the execution path of the monitoring program is dynamically instrumented during running, information is recorded, and detailed intermediate files and dump files are generated; in the static analysis stage, functions related to input file operation are focused, a series of target function offsets are generated for a command line program and a part of GUI programs, and most valuable targets are screened according to the coverage condition of performance functions and the calling depth of file operation functions; identifying a target station; determining potential vulnerabilities and key execution paths before executing the directional fuzzy test; performing directional fuzzy testing; performing directional fuzzy testing on the target program; and fuzzy test optimization: improving the test efficiency by implementing a time slicing strategy. The method has the advantages of simple principle, easiness in implementation, good test effect and the like.

Description

Technical Field

[0001] The present invention mainly relates to the technical field of vulnerability mining in the field of computer security, and in particular to a directional fuzzy testing method that is widely adapted to Windows platform applications. Background Art

[0002] Fuzz testing, as an efficient and lightweight automated vulnerability discovery technology, has established its important position in the field of software testing and security. According to data from Google Project Zero in 2019, fuzz testing accounted for as much as 37.2% of the ways of exploiting vulnerabilities in the past five years. Among them, AFL (American Fuzzy Lop), as a landmark gray-box fuzz testing tool, collects code coverage information through compile-time instrumentation, and uses evolutionary algorithms to use coverage as the fitness indicator of the algorithm to guide fuzz testing towards a path with increased coverage. Currently, most gray-box fuzz testing tools, like AFL, are code coverage-oriented, with the goal of covering as many program states as possible within a limited time. This is based on a common perception that higher code coverage usually means that more errors can be found. However, this coverage-based testing often wastes a lot of time in code areas that do not contain errors, and it is difficult to dig deep into potential problems.

[0003] To this end, practitioners have proposed a directed gray-box fuzz testing technology, which is a variant of gray-box fuzz testing. This testing method focuses more on specific areas in the program where problems may occur, such as parts with high code complexity and prone to errors. Directed fuzz testing spends a lot of time locating the target location and does not waste resources to emphasize irrelevant program modules. This good directionality can be applied to scenarios such as patch testing, vulnerability reproduction, suspected defects, or static analysis report verification.

[0004] At present, although many practitioners have conducted extensive research on directed gray-box fuzz testing, these studies are mainly focused on Unix-like platforms, while programs on the Windows platform also face security challenges. Due to the rapid update and iteration of Windows applications, corresponding vulnerabilities are constantly emerging. Applying fuzz testing technology to the Windows platform is crucial to reducing the burden of manual audits, reducing labor costs, and maintaining the Windows ecosystem. However, implementing directed fuzz testing on the Windows platform faces several challenges and still has some shortcomings:

[0005] (1) How to quickly locate the target function in the application? For closed-source commercial applications that do not have public source code and symbol information, it is impossible to directly obtain the location information of the target function from the source code. In addition, many Windows applications also have complex code structures that involve multiple modules and library functions, making it more challenging to accurately identify the target function. The traditional approach is usually to debug and accurately locate the target function through manual analysis through reverse engineering, but this method requires a lot of time and manpower. Therefore, there is an urgent need for an automated analysis method to reduce the operating cost of fuzz testing.

[0006] (2) How to bypass the graphical user interface and idle state in mainstream Windows applications; GUI applications rely on user interaction to receive input, such as mouse clicks, keyboard input, or menu selections. In addition, after processing an event, GUI applications will enter an idle state and wait for the next event to occur, which hinders program flow and iterative execution in testing. Therefore, it is necessary to analyze the code structure and logic of the target program and find a general solution.

[0007] (3) How to extract the control flow graph and function call graph of closed-source programs to calculate fitness metrics. Traditional targeted fuzz testing tools for Linux platforms, such as AFLGo, instrument programs during compilation and collect information during execution to construct control flow graphs and function call graphs. This is not applicable to already compiled Windows closed-source programs.

[0008] (4) Windows closed-source programs usually involve a large number of libraries and system calls, which makes the generated graph too large and complex. Indirect calls and branches in binary programs, such as virtual table function pointers, further increase the difficulty of graph integrity. It is necessary to explore a lightweight method customized for closed-source programs to extract the local control flow graph and function call graph required to calculate fitness indicators. Summary of the invention

[0009] The technical problem to be solved by the present invention is: in view of the technical problems existing in the prior art, the present invention provides a directional fuzzy testing method which is simple in principle, easy to implement and has good testing effect and is widely applicable to Windows platform applications.

[0010] In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0011] A directed fuzz testing method widely adapted for Windows platform applications, comprising:

[0012] Target program adaptation; locate the target function that meets the conditions, dynamically insert the execution path of the monitoring program at runtime, record information, and generate detailed intermediate files and dump files; the static analysis stage focuses on the functions related to input file operations, generates a series of target function offsets for command line programs and some GUI programs, and selects the most valuable targets based on the coverage of functional functions and the calling depth of file operation functions; for most GUI programs and shared libraries, generates a simple program harness that can directly call the target function and simulate the key behaviors of the program;

[0013] Target site identification; determine potential vulnerabilities and critical execution paths before performing targeted fuzz testing;

[0014] Directed fuzz testing: Perform directed fuzz testing on the target program;

[0015] Fuzz testing optimization: Improve testing efficiency by implementing time slicing strategies.

[0016] As a further improvement of the method of the present invention: in the target program adaptation, the target function offset candidate list is generated by adopting an automatic target offset candidate generation method based on hybrid analysis, the dynamic instrumentation part tracks the file-related API and the target library function, and records the name and base address of the loaded module through two callback functions, as well as the direct call, return, indirect call, and indirect jump in the function; the dynamic instrumentation part pays attention to the function calls related to the input file operation and the library functions related to the program functions, and generates a function call sequence intermediate file; the static analysis script extracts the function call relationship, identifies the main program function that calls the file-related API, and when processing multi-threaded applications, only considers the file processing thread; the static analysis script counts the number of calls to the function library function inside the identified main program function, and uses this as the judgment criterion for subsequent target selection.

[0017] As a further improvement of the method of the present invention: accepting the call sequence callchunk and the stack memory dump file stack_mem as input parameters, traversing each function call in the call sequence, first checking whether it returns before calling the file-related API, if so, deleting this function call from the call sequence callchunk; next, judging whether the function call is related to the file operation, judging by marking and dumping the file, if the function call is related to the file operation, traversing the call sequence again, in this traversal, looking for all function calls with the same thread ID as the function and a call ID smaller than the function, ensuring that only those calls to the file operation API in the same thread are considered; after finding the function calls that meet the conditions, adding them to the result list, and finally returning the function call list related to the file operation.

[0018] The specific algorithm of function call callback function is as follows Figure 4 As shown, all calls related to file operations are marked as FR, calls within the main program are marked as T2T, and calls from the main program to external modules are marked as T2M. When recording calls related to file operations, it is necessary to dump the value of the stack value pointing to the memory space to facilitate subsequent positioning of APIs related to input files.

[0019] As a further improvement of the method of the present invention: in the target program adaptation, an automated path tracing framework for generating a harness that simulates the key behaviors of a GUI program is used to extract function call paths and parameter dependencies of key library files from Windows closed-source programs to generate a harness that simulates the key behaviors of the program.

[0020] As a further improvement of the method of the present invention: the automatic path tracking framework includes:

[0021] In the dynamic tracing phase, the program and input given by the user are first executed in the instrumentation monitoring environment, the path information of the execution process is extracted, and the library function is loaded through Pin monitoring; when processing multi-threaded applications, only the threads that call the file-related API are considered;

[0022] In the critical behavior recovery phase, the library-related function calls are first copied to the harness skeleton, and the IDA Python script is used to obtain the necessary information. After serialization, the information is temporarily stored in a local json file. Then, data dependency analysis is performed to determine the parameters, considering three types of relationships: the return value of the previous function as the input parameter of the subsequent function; the output parameter of the previous function as the input parameter of the subsequent function; and aliases.

[0023] As a further improvement of the method of the present invention: the process of identifying the target site includes:

[0024] a. Use static analysis tools to compare different versions of program code and identify key change points, which are often potential locations for introducing new vulnerabilities;

[0025] b. Use IDA Python script to audit dangerous functions and filter out functions that may cause security risks if used improperly;

[0026] c. Analyze the known crash information recorded in the CVE database and use these historical vulnerabilities as important references for the target site.

[0027] As a further improvement of the method of the present invention: in the process of the directed fuzzy test, according to different fitness indicators, it is divided into a path distance-oriented mode and a key basic block coverage-oriented mode, and the path distance-oriented mode and the key basic block coverage-oriented mode both include a preprocessing stage, a fitness indicator calculation stage and a power scheduling stage; wherein:

[0028] Preprocessing stage: obtain the distance file of basic blocks or the offset list file of key basic blocks through preprocessing;

[0029] Fitness index calculation phase: In the dynamic instrumentation phase of fuzz testing, the path distance and key basic block coverage are calculated using the files obtained in the above preprocessing phase;

[0030] Power scheduling stage: Based on the above information, the fuzzifier calculates the fitness score and performs power scheduling. Test cases with high fitness scores will be given more testing time or more mutation opportunities.

[0031] As a further improvement of the method of the present invention: the process based on the path distance guidance mode includes:

[0032] S2001: Creating CFG and FCG using IDA Python: Using IDA PRO's Python scripting capabilities, analyze binary files and draw control flow graphs and function call graphs;

[0033] S2002: Calculate basic block level distance: For a basic block in CFG, use Dijkstra algorithm to find the shortest path length to the next function jump basic block in the reachable target path in the same function. The calculation formula is:

[0034] d(b,f next )=min(d ijk (b, b next ))

[0035] Where b is a basic block in the function, f next is the next function in the path that can reach the target point of this function in the function call graph, b next To jump to f next The min() function indicates that there may be multiple jump basic blocks that jump to the same f next , so take the minimum value;

[0036] S2003: Calculate function-level distance: For a function node in FCG, use Dijkstra algorithm to find the shortest path length from the next function to the target function in the path to the target point. The formula is:

[0037] d(f next , T f) = d ijk (f next , T f )

[0038] S2004: Determine a constant multiple coefficient: multiply the function level distance by a constant multiple, so as to balance the influence of the basic block level distance and the function level distance in the fitness index;

[0039] S2005: Comprehensive distance calculation: Given a target basic block T b , the distance is the sum of the basic block level distance and the constant multiple function level distance, the formula is:

[0040] d(b,T b )=min(d(b,f next )+C*d(f next , T f ))

[0041] S2006: Calculate the fitness index: divide the cumulative distance of the basic blocks in the test running trajectory by the number of basic blocks covered by the test case to obtain the path distance, that is, the fitness index.

[0042] As a further improvement of the method of the present invention: the process based on the key basic block coverage guidance mode includes:

[0043] S3001: Recursive reverse order analysis: Starting from the target basic block, recursively trace back the edges of the function call graph and the control flow graph to identify the path that may lead to the target point;

[0044] S3002: Iterative analysis: iteratively check the paths from the function entry to each jump basic block, and identify all basic blocks on these paths;

[0045] S3003: Path discovery: By analyzing the function call graph, it is determined that there are multiple paths that can reach the target point; the edge on the path represents the calling relationship between functions, corresponding to a jump basic block, which is a key transition point in the control flow graph;

[0046] S3004: Construction of key basic block set: A control flow graph is constructed inside the function where each jump basic block is located; in this graph, it is necessary to find all paths that can reach the jump basic block and determine the basic blocks on these paths; these basic blocks constitute the parent node set of the target location, that is, the key basic block set.

[0047] As a further improvement of the method of the present invention: the energy allocation optimization method based on the time slicing strategy is adopted in the fuzzy test optimization process, and the process includes:

[0048] Define time t as the transition point from the simulated annealing exploration phase to the exploitation phase;

[0049] In the exploration phase, the fuzzer accepts all possible seeds and explores a wide range of possibilities;

[0050] In the exploitation phase, testing focuses on in-depth analysis of those paths that are considered most likely to discover new vulnerabilities or trigger unusual behavior;

[0051] In the balancing phase, after time 10*t has passed, additional resources are allocated to those less executed paths based on the dynamically adjusted resource allocation guided by the fitness indicator.

[0052] Compared with the prior art, the advantages of the present invention are:

[0053] 1. The directional fuzzy testing method of the present invention, which is widely applicable to Windows platform applications, has a simple principle, is easy to implement, and has good testing effect, and can implement directional fuzzy testing that is widely applicable to Windows platform applications.

[0054] 2. The directional fuzz testing method of the present invention is widely adapted for Windows platform applications. In order to locate the target function, the present invention uses dynamic binary detection technology to monitor the program at runtime and record module loading and function call information. Then, a static analysis script is used to identify the functions involved in file I / O and parsing in the main program as candidate target functions. Based on the functional coverage and call depth of these functions and after verification, it is decided whether to use them as test target functions. Those functions that can cover as many functions as possible and have relatively small call depth for file-related APIs are selected as target test functions.

[0055] 3. The directional fuzzy testing method of the present invention is widely adapted for Windows platform applications. In order to deal with GUI problems, the present invention proposes three solutions. The first is to use automated testing tools such as AutoIt to simulate user interaction. The second is to select functions in the program before interaction and entering the idle state for testing. The third solution is based on hybrid analysis, which extracts the core functions of the target program and converts them into independent programs by monitoring the GUI application and its dependent libraries at runtime and performing reverse engineering. Then directly call a specific function through the command line to test this independent program. The third method can be implemented automatically, and the generated independent program can be reused, which has more general applicability.

[0056] 4. The present invention is a directed fuzz testing method that is widely adapted for Windows platform applications. In order to calculate the fitness index, the present invention focuses on the basic blocks and functions of the reachable targets. The basic idea is to identify a series of parent nodes in the target area. Use the IDA Python API to recursively build a reverse cross-reference control flow graph and function call graph of the target point. Although the generated graphs are limited to parts of the entire application, they contain enough information to calculate path distances and key basic blocks. The advantage of this method is that by focusing only on the target and its parent nodes, the complexity of the graph is simplified, thereby generating a valid graph faster, which is particularly suitable for closed-source binary programs that cannot be instrumented at compile time.

[0057] 5. The directional fuzz testing method of the present invention is widely adapted for Windows platform applications. Based on the program execution path tracing technology of hybrid analysis, the present invention uses the dynamic binary plugging tool Pin combined with static analysis to realize the tracking of the execution path of Windows applications, which allows the automatic generation of test target offset candidates and the construction of a simple test driver (harness), so as to realize the testing of the target program without user interaction; the present invention adopts two directional guidance modes, and designs the path distance guidance and key basic block coverage guidance modes according to the different fitness indicators. They calculate the fitness index through the control flow graph and function call graph obtained by IDA static analysis, select the test case with high fitness score for mutation in the power scheduling stage, and accelerate the fuzz test to reach the predetermined target. The present invention further adopts a time slicing strategy for optimizing the directional fuzz testing technology, giving priority to the fitness index in the early stage, and allocating more energy to the low-frequency path in addition to the fitness index guidance in the later stage, effectively utilizing the time dimension, improving the comprehensiveness of path exploration, and avoiding the ineffective consumption of resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 It is a schematic diagram of the principle of the present invention in a specific embodiment.

[0059] Figure 2 It is a schematic diagram of the automatic target offset candidate generation process in a specific embodiment of the present invention.

[0060] Figure 3 is a schematic diagram of an automated path tracing framework in a specific embodiment of the present invention.

[0061] Figure 4 It is a schematic diagram of a function calling callback function algorithm in a specific embodiment of the present invention.

[0062] Figure 5 It is a schematic diagram of a main program function for statistically calling a file API in a specific embodiment of the present invention. DETAILED DESCRIPTION

[0063] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0064] like Figure 1-Figure 3 As shown, a directional fuzzy testing method widely adapted to Windows platform applications of the present invention comprises:

[0065] Target program adaptation: locate the target function that meets the conditions. In order to effectively test console programs, GUI programs and shared libraries on the Windows platform, the target function that meets specific conditions can be located through target program adaptation;

[0066] Target program adaptation is mainly aimed at three types of common Windows applications. Specifically, it dynamically inserts and monitors the execution path of the program at runtime, records information such as module loading and function calls, and generates detailed intermediate files and dump files. The static analysis phase focuses on functions related to input file operations, such as CreateFile, ReadFile, etc. For command-line programs and some GUI programs, a series of target function offsets are generated, and the most valuable targets are selected based on the coverage of functional functions and the call depth of file operation functions; for most GUI programs and shared libraries, a simple program harness is generated that can directly call the target function and simulate the key behaviors of the program.

[0067] Target site identification; determine potential vulnerabilities and critical execution paths before performing targeted fuzz testing;

[0068] Directed gray-box fuzz testing focuses on locating the target location specified in the program. Determining the target location is a key step. Three methods are proposed for target site identification: static analysis determines functions with high difference scores as targets; IDA Python scripts identify dangerous functions through name matching, some common dangerous functions and their safe replacement functions such as alloca() and malloc(), strlen() and strnlens(); use the information in the CVE vulnerability library to locate known vulnerabilities, such as the user-mode write access violation vulnerability in Xnview 2.51 located at offset address 0x39c1da, which can be used as the target point for testing.

[0069] Directed fuzz testing: Perform directed fuzz testing on the target program;

[0070] There are two directional guidance modes: path distance guidance and key basic block coverage guidance. They both follow two stages. The preprocessing stage analyzes the control flow graph and function call graph of the program to generate basic block distance or offset list files of key basic blocks; in the fuzz test running stage, the closed-source program is dynamically plugged, and these files are used to count the path distance or key area basic block coverage, and fitness score calculation and power scheduling are performed based on these data.

[0071] Fuzz testing optimization: Improve testing efficiency by implementing time slicing strategies;

[0072] Fuzzy testing optimization improves the power scheduling scheme of simulated annealing to avoid repeatedly testing existing paths and ignoring new paths. It redivides the test time into three stages: exploration, utilization, and balance. The balance stage increases the energy allocation to low-frequency paths while maintaining the fitness indicator orientation.

[0073] In a specific application example, the conditions that the objective function needs to satisfy include:

[0074] a. Ability to open and read new input files in each iteration;

[0075] b. Be able to parse the file; be able to close the file after parsing to ensure that the fuzz tester can rewrite it; the function must use the "ret" command to return normally at the end, instead of "exit", so that the fuzz tester can capture this return and redirect execution;

[0076] c. While executing the above steps, the program cannot interact with the user or enter an idle state.

[0077] Furthermore, as a preferred embodiment, the functions of automatically generating a target function offset candidate list and automatically creating a harness for simulating the key behaviors of the program are integrated into the target program adaptation process, thereby optimizing the fuzz testing process. That is:

[0078] Automated target offset candidate generation: The present invention includes an automated target offset candidate generation function, which improves the accuracy and coverage of target function candidates by integrating the instant feedback of dynamic analysis and the global perspective of static analysis.

[0079] Adaptation of graphical interactive programs: The present invention designs an automated path tracing framework to generate a driver harness that simulates the key behaviors of Windows closed-source programs. The harness uses a command line interface instead of a GUI. By testing the harness, the problem of test iteration failure due to user interaction can be resolved.

[0080] The method of automatic target offset candidate generation based on hybrid analysis is used to generate the target function offset candidate list in the present invention. The dynamic instrumentation part tracks the file-related API and target library function. The specific implementation includes registering two callback functions, which respectively record the name and base address of the loaded module, and record the direct call, return, indirect call, and indirect jump in the function. The specific algorithm implementation of the function call callback function is as follows: Figure 4 As shown, all calls related to file operations are marked as FR, calls within the main program are marked as T2T, and calls from the main program to external modules are marked as T2M. When recording calls related to file operations, it is necessary to dump the value of the stack value pointing to the memory space to facilitate subsequent positioning of APIs related to input files.

[0081] See also Figure 2 ,This method mainly consists of two parts. The dynamic stub part focuses on the function calls related to the input file operations and the library functions related to the program functions, and generates the function call sequence intermediate files. The static analysis script extracts the function call relationship, identifies the main program functions that call the file-related APIs, and only considers the file processing threads when processing multi-threaded applications. In addition, in order to make the test scope cover as many functions as possible, the static analysis script counts the number of function library functions called inside the identified main program functions, and uses this as the criterion for the subsequent target selection.

[0082] The static analysis script counts the main program functions that call file operation related APIs, focusing only on file operations related to input files and ignoring configuration file related operations. When processing multi-threaded applications, only threads that call file-related APIs are considered. The specific algorithm implementation is as follows: Figure 5 shown.

[0083] The algorithm accepts the call sequence callchunk and the stack memory dump file stack_mem as input parameters, traverses each function call in the call sequence, first checks whether it returns before calling the file-related API, if so, removes this function call from the call sequence callchunk. Next, determine whether the function call is related to the file operation, by marking and dumping the file. If the function call is related to the file operation, then traverse the call sequence again. In this traversal, look for all function calls with the same thread ID as the function and a call ID smaller than the function, making sure to consider only those calls to the file operation API in the same thread. After finding the function calls that meet the conditions, add them to the result list, and finally return the list of function calls related to file operations.

[0084] The static analysis script also needs to count the number of function library functions called within the main program to cover as many functions as possible.

[0085] The method for automatically creating a harness for simulating key behaviors of a program in the present invention adopts an automated path tracing framework for generating a harness for simulating key behaviors of a GUI program. In order to overcome the reliance of the GUI program testing process on user interaction for iteration, the present invention proposes an automated path tracing framework combining a dynamic plugging tool Pin and IDA static analysis, which can extract the function call path and parameter dependency of key library files from Windows closed-source programs to generate a harness for simulating key behaviors of a program.

[0086] See also Figure 3 ,The framework consists of two stages: dynamic tracking and key behavior recovery, including:

[0087] In the dynamic tracing phase, the program and input given by the user are first executed in the instrumentation monitoring environment, the path information of the execution process is extracted, and the library function is loaded through Pin monitoring. This phase focuses on the external interface exposed by the library and does not record the control flow of the same module, because the internal function calls of these modules represent the internal logic of the library, and the same behavior of the original program can be restored by calling the exported functions of the library. When dealing with multi-threaded applications, only threads that call file-related APIs are considered. This is to avoid adding irrelevant calls that will damage the correctness of the harness.

[0088] In the critical behavior recovery phase, we first copy the library-related function calls into the harness skeleton and use an IDA Python script to obtain the necessary information. After serialization, the information is temporarily stored in a local json file. Then we perform data dependency analysis to determine the parameters, considering three types of relationships: the return value of the previous function as the input parameter of the subsequent function; the output parameter of the previous function (usually in the form of a pointer) as the input parameter of the subsequent function; and aliases.

[0089] The specific process of this method includes:

[0090] S1001: Dynamic path tracing: Execute the target program in the instrumentation monitoring environment and use Pin to track the program execution path. During this process, Pin will record the following information:

[0091] The loaded module name and base address;

[0092] Details of inter-module calls and jumps, including thread ID, address of caller and callee, symbol information, and parameters;

[0093] For calls within a module, only the relevant information of the main program module is recorded, and the values ​​in the stack are saved as potential parameters;

[0094] When a function executes a return instruction, the return value of the function is recorded;

[0095] For any value pointing to accessible memory, treat it as a pointer and dump the memory content it points to for subsequent parameter reconstruction and data dependency analysis. For multiple levels of pointers, repeat this process recursively.

[0096] S1002: Key Behavior Recovery: In this phase, the function calls related to the library are extracted from the trace data and copied into the framework of the test harness. Since the information provided by dynamic tracing often lacks the necessary symbol information and addresses, the present invention uses IDA Pro to supplement these key details, including:

[0097] The offset address of the function;

[0098] The type and return type of the function;

[0099] Function name;

[0100] Parameter types and number;

[0101] S1003: Data dependency analysis: Analyze the relationship between function parameters and return values, focusing on three situations:

[0102] The return value of a function is used as an input parameter of another function by checking whether a parameter always has the same value as the previous return value;

[0103] The output parameter of a function (usually in the form of a pointer) is used as the input parameter of the subsequent function;

[0104] Aliases between parameters. If the same non-constant value is used as a parameter in two different locations in a program, the two parameters are considered "aliases";

[0105] In a specific application example, the target site identification includes the following processes:

[0106] a. Use static analysis tools, such as Bindiff, to compare different versions of program code and identify key change points, which are often potential locations for introducing new vulnerabilities;

[0107] b. Use IDA Python script to audit dangerous functions and filter out functions that may cause security risks if used improperly;

[0108] c. Analyze the known crash information recorded in the CVE (Common Vulnerabilities and Exposures) database and use these historical vulnerabilities as an important reference for the target site.

[0109] In a specific application example, the directional fuzzy test process is divided into a path distance-oriented mode and a key basic block coverage-oriented mode according to different fitness indicators. Both the path distance-oriented mode and the key basic block coverage-oriented mode include a preprocessing stage, a fitness indicator calculation stage, and a power scheduling stage. Among them:

[0110] Preprocessing stage: obtain the distance file of basic blocks or the offset list file of key basic blocks through preprocessing;

[0111] Fitness index calculation phase: In the dynamic instrumentation phase of fuzz testing, the path distance and key basic block coverage are calculated using the files obtained in the above preprocessing phase;

[0112] Power scheduling stage: Based on the above information, the fuzzifier calculates the fitness score and performs power scheduling. Test cases with high fitness scores will be given more testing time or more mutation opportunities.

[0113] The collaborative work of the above three stages enables the directed fuzz testing component to efficiently detect vulnerable points in the program, thereby improving the fuzzer's ability to find errors.

[0114] Fitness index based on path distance: The test case path distance is defined as the average distance of the basic blocks covered in the path, and the distance from the basic block to the target block is defined as the minimum value of the basic block level shortest distance (the shortest path length from a basic block in a function to the jump basic block of the next function in the function-level target path) plus a constant times the function level shortest distance (the shortest path length from the next function to the target function in the path from the function node to the target point). The shortest distance calculation uses the Dijkstra algorithm.

[0115] Fitness indicators based on key basic block coverage: The key basic block coverage is defined as the ratio of the number of basic blocks in the key area covered by the test case execution process to the total number of basic blocks covered.

[0116] Power scheduling based on simulated annealing: The entire test process is divided into exploration and utilization phases according to the time threshold. The goal of the exploration phase is to explore the program space extensively, allocate energy to all test cases as fairly as possible, and avoid falling into the local optimal solution too early. After a certain period of exploration, it enters the utilization phase, tending to allocate more energy to test cases with large fitness scores.

[0117] The fitness index based on path distance in the present invention is: The fitness index based on path distance is intended to measure the degree to which a test case is close to a specific target (such as an error location, a specific execution path or a code area). The test case can be dynamically adjusted according to its fitness index to explore code areas with high risk potential more frequently. The specific process includes:

[0118] S2001: Creating CFG and FCG using IDA Python: Using IDA PRO's Python scripting capabilities, analyze binary files and draw control flow graphs and function call graphs;

[0119] S2002: Calculate basic block level distance: For a basic block in CFG, use Dijkstra algorithm to find the shortest path length to the next function jump basic block in the reachable target path in the same function. The calculation formula is:

[0120] d(b,f next )=min(d ijk (b,b next ))

[0121] Where b is a basic block in the function, f next is the next function in the path that can reach the target point of this function in the function call graph, b next To jump to f next The min() function indicates that there may be multiple jump basic blocks that jump to the same f next , so take the minimum value.

[0122] S2003: Calculate function-level distance: For a function node in FCG, use Dijkstra algorithm to find the shortest path length from the next function to the target function in the path to the target point. The formula is:

[0123] d(f next , T f ) = d ijk (f next , T f )

[0124] S2004: Determine a constant multiple coefficient: multiply the function-level distance by a constant multiple (this constant can be obtained based on experiments or experience) so as to balance the influence of the basic block-level distance and the function-level distance in the fitness index.

[0125] S2005: Comprehensive distance calculation: Given a target basic block T b , the distance is the sum of the basic block level distance and the constant multiple function level distance, the formula is:

[0126] d(b,T b )=min(d(b,f next )+C*d(f next ,T f ))

[0127] Because a basic block may have multiple paths to reach the target basic block, the minimum value of these sums is taken as the distance to the target block.

[0128] S2006: Calculate the fitness index: divide the cumulative distance of the basic blocks in the test running trajectory by the number of basic blocks covered by the test case to obtain the path distance, that is, the fitness index.

[0129] The fitness index based on key basic block coverage in the present invention is: Based on the coverage of key basic blocks, the fitness index can be defined as the ratio of the number of basic blocks covered in the key area during the test case execution process to the total number of basic blocks covered. This index reflects the coverage effect of the test case in the key area. The higher the coverage rate, the more effective the test case is in detecting the key area, and therefore it is more likely to touch potential defects. In order to determine the set of key basic blocks, the Python script function of IDAPro is used for automated analysis; the process includes:

[0130] S3001: Recursive reverse order analysis: This involves starting from the target basic block and recursively tracing back the edges of the function call graph and control flow graph to identify paths that may lead to the target point.

[0131] S3002: Iterative analysis: Iteratively check the paths from the function entry to each jump basic block, and identify all basic blocks on these paths.

[0132] S3003: Path discovery: By analyzing the function call graph, determine that there are multiple paths that can reach the target point. The edges on the path represent the calling relationship between functions, corresponding to a jump basic block, which is a key transition point in the control flow graph.

[0133] S3004: Construction of key basic block set: A control flow graph can be constructed inside the function where each jump basic block is located. In this graph, it is necessary to find all the paths that can reach the jump basic block and determine the basic blocks on these paths. These basic blocks constitute the parent node set of the target location, that is, the key basic block set.

[0134] The energy allocation optimization based on the time slicing strategy in the present invention is as follows: The energy allocation optimization based on the time slicing strategy is a dynamically adjusted optimization strategy that aims to balance the relationship between comprehensive exploration and concentrated utilization. By dividing the test process into three stages: exploration, utilization, and balance, and adjusting the energy allocation strategy in each stage, the program space can be explored more effectively.

[0135] In the above strategy, the simulated annealing exploration phase is defined before time t, and the fuzzer accepts all possible seeds; after time t, it enters the "utilization" phase, preferring seeds with high fitness and allocating more resources to them to strengthen the exploration of effective paths. After time 10*t, more energy is also allocated to low-frequency paths based on the fitness indicator. The setting of the time slicing parameter t was initially based on empirical values. In actual testing, if it is observed that the performance of a certain stage is significantly insufficient, the time segmentation can be adjusted in subsequent test iterations to adapt to the dynamic changes of the test process, ensuring the flexibility, predictability and stability of the test.

[0136] In a specific application example, the fuzzy test optimization process includes:

[0137] Define time t as the transition point from the simulated annealing exploration phase to the exploitation phase;

[0138] In the exploration phase, the fuzzer accepts all possible seeds and explores a wide range of possibilities;

[0139] In the exploitation phase, testing focuses on in-depth analysis of those paths that are considered most likely to discover new vulnerabilities or trigger unusual behavior;

[0140] In the balancing phase, after time 10*t has passed, additional resources are allocated to those less executed paths based on the dynamically adjusted resource allocation guided by the fitness indicator.

[0141] In the specific application process, the strategy mentioned is less determined by two indicators: the number of times the test case is selected from the queue for execution, and the execution path frequency of the test case.

[0142] The power scheduling based on the simulated annealing algorithm in the present invention is: The power scheduling based on the simulated annealing algorithm is a heuristic optimization strategy, which is inspired by the annealing phenomenon in the metal cooling process in solid physics. The algorithm can effectively explore in the global search space to find the optimal solution. In the application of this algorithm, the entire test process is divided into exploration and utilization stages according to the time threshold. The exploration stage will allocate energy to all test cases more fairly, and the utilization stage will allocate more energy to test cases with small path distances or large key basic block coverage. In this way, it is possible to avoid over-concentration of local optimal situations in the early stage without extensive exploration. Given a test case s and a target position T b , the energy based on the path distance is:

[0143] p(s,T b )=(1-d~(s,T b ))*(1-T)+0.5T

[0144]

[0145] Where P(s) is the energy calculated by WinAFL based on the execution speed, number of covered paths and path depth of the test case. is the power factor. d~(s,T b ) is the normalized path distance of the use case, calculated as:

[0146]

[0147] The current maximum test case distance is maxD, and the minimum is minD. The normalized distance of each seed in the range (0, 1) is calculated.

[0148] The energy based on key basic block coverage is:

[0149] p(s,T b )=cov~(s,T b )*(1-T)+0.5T

[0150]

[0151] Where P(s) is the energy calculated by WinAFL based on the execution speed, number of covered paths and path depth of the test case. is the power factor, cov~(s,T b ) is the normalized critical area coverage of the use case, calculated as:

[0152]

[0153] The current maximum testcase critical area coverage is maxC, and the minimum is minC. The normalized critical area coverage of each test case in the range of (0, 1) is calculated.

[0154] In a specific application example, the detailed process of the present invention includes:

[0155] Step S100: Test adaptation and target site determination:

[0156] Program classification: First, classify the target program to determine whether to adapt it by generating target offsets or harness programs.

[0157] Vulnerability identification: Use the target site identification component to analyze the target program, identify its potential vulnerabilities, and use them as the target site for fuzz testing;

[0158] Step S200: generating a cross-reference control flow graph and a function call graph;

[0159] The function call graph is: for the target site identified in the previous stage, a cross-reference function call graph of the program is generated to reveal the calling relationship between functions;

[0160] The control flow graph is: generating a cross-reference control flow graph of the program based on the target site and the function call graph, so as to facilitate understanding of the execution flow of the program;

[0161] Step S300: preprocessing intermediate file generation;

[0162] Determine the fuzz testing mode, calculate the basic block distance or key basic block offset based on the control flow graph and function call graph, and generate the corresponding list file;

[0163] Step S400: fuzzy test execution;

[0164] Step S401: Test entry selection: the target function selected in the adaptation phase or the main function in the harness is used as the test entry point;

[0165] Step S402: Dynamic instrumentation: During the execution of the fuzz test, program running information is collected through dynamic instrumentation to calculate the path distance and the coverage of key basic blocks;

[0166] Step S403: Power scheduling: Calculate the fitness score and use the simulated annealing algorithm to perform power scheduling on the test cases, allocate more energy to the test cases with high fitness scores, and optimize the test efficiency;

[0167] Step S500: fuzzy test optimization;

[0168] The time division in the simulated annealing algorithm was further refined. After 10*t, the seed selection and arrangement related strategies were adjusted, and the path execution frequency was included in the calculation of the fitness score to improve the comprehensiveness of the test.

[0169] Those skilled in the art will appreciate that the above-mentioned embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes. The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the functions in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide for implementing the process in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0170] The above are only preferred embodiments of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should be regarded as the protection scope of the present invention.

Claims

1. A directional fuzzy testing method widely adapted for Windows platform applications, characterized in that: include: Target program adaptation; locate the target function that meets the conditions, dynamically insert the execution path of the monitoring program at runtime, record information, and generate detailed intermediate files and dump files; the static analysis stage focuses on the functions related to input file operations, generates a series of target function offsets for command line programs and some GUI programs, and selects the most valuable targets based on the coverage of functional functions and the calling depth of file operation functions; for most GUI programs and shared libraries, generates a simple program harness that can directly call the target function and simulate the key behaviors of the program; Target site identification: Identify potential vulnerabilities and critical execution paths before performing targeted fuzz testing; Directed fuzz testing: Perform directed fuzz testing on the target program; Fuzz testing optimization: Improve testing efficiency by implementing time slicing strategies.

2. According to claim 1, the directional fuzzy testing method for Windows platform applications is widely adapted, characterized in that: In the target program adaptation, a target function offset candidate list is generated by using an automated target offset candidate generation method based on hybrid analysis. The dynamic instrumentation part tracks file-related APIs and target library function functions, and records the name and base address of the loaded module through two callback functions, as well as direct calls, returns, indirect calls, and indirect jumps in the function; the dynamic instrumentation part focuses on function calls related to input file operations and library functions related to program functions, and generates a function call sequence intermediate file; the static analysis script extracts function call relationships, identifies the main program function that calls the file-related API, and only considers the file processing thread when processing multi-threaded applications; the static analysis script counts the number of calls to the function library function inside the identified main program function, and uses this as a criterion for subsequent target selection.

3. The directional fuzzy testing method for Windows platform applications widely adapted according to claim 2 is characterized in that: Accept the call sequence callchunk and the stack memory dump file stack_mem as input parameters, traverse each function call in the call sequence, first check whether it returns before calling the file-related API, if so, delete this function call from the call sequence callchunk; next, determine whether the function call is related to the file operation, through marking and dumping the file to determine, if the function call is related to the file operation, then traverse the call sequence again, in this traversal, find all function calls with the same thread ID as the function and a call ID smaller than the function, and make sure to consider only those calls to the file operation API in the same thread; after finding the function calls that meet the conditions, add them to the result list, and finally return the list of function calls related to the file operation; The specific algorithm of the function call callback function includes marking all calls related to file operations as FR, marking the calls within the main program as T2T, and marking the calls from the main program to external modules as T2M. When recording calls related to file operations, it is necessary to dump the value of the stack value pointing to the memory space to facilitate the subsequent positioning of the API related to the input file.

4. The directional fuzzy testing method for Windows platform applications widely adapted according to claim 1 is characterized in that: In the target program adaptation, an automated path tracing framework for generating a harness that simulates the key behaviors of a GUI program is used to extract function call paths and parameter dependencies of key library files from Windows closed-source programs to generate a harness that simulates the key behaviors of the program.

5. The directional fuzzy testing method for Windows platform applications widely adapted according to claim 4 is characterized in that: The automated path tracking framework includes: In the dynamic tracing phase, the program and input given by the user are first executed in the instrumentation monitoring environment, the path information of the execution process is extracted, and the library function is loaded through Pin monitoring; when processing multi-threaded applications, only threads that call file-related APIs are considered; In the critical behavior recovery phase, the library-related function calls are first copied to the harness skeleton, and the IDAPython script is used to obtain the necessary information. After serialization, the information is temporarily stored in a local json file. Then, data dependency analysis is performed to determine the parameters, considering three types of relationships: the return value of the previous function as the input parameter of the subsequent function; the output parameter of the previous function as the input parameter of the subsequent function; and aliases.

6. The directional fuzzy testing method for Windows platform applications widely adapted according to any one of claims 1 to 5, characterized in that: The target site identification process includes: a. Use static analysis tools to compare different versions of program code and identify key change points, which are often potential locations for introducing new vulnerabilities; b. Use IDA Python script to audit dangerous functions and filter out functions that may cause security risks if used improperly; c. Analyze the known crash information recorded in the CVE database and use these historical vulnerabilities as important references for the target site.

7. The directional fuzzy testing method for Windows platform applications widely adapted according to any one of claims 1 to 5, characterized in that: The directional fuzzy test process is divided into a path distance oriented mode and a key basic block coverage oriented mode according to different fitness indicators. The path distance oriented mode and the key basic block coverage oriented mode both include a preprocessing stage, a fitness indicator calculation stage and a power scheduling stage; wherein: Preprocessing stage: obtain the distance file of basic blocks or the offset list file of key basic blocks through preprocessing; Fitness index calculation phase: In the dynamic instrumentation phase of fuzz testing, the path distance and key basic block coverage are calculated using the files obtained in the above preprocessing phase; Power scheduling stage: Based on the above information, the fuzzifier calculates the fitness score and performs power scheduling. Test cases with high fitness scores will be given more testing time or more mutation opportunities.

8. The directional fuzzy testing method for Windows platform applications widely adapted according to claim 7 is characterized in that: The process based on the path distance guidance mode includes: S2001: Creating CFG and FCG using IDA Python: Using IDA PRO's Python scripting capabilities, analyze binary files and draw control flow graphs and function call graphs; S2002: Calculate basic block level distance: For a basic block in CFG, use Dijkstra algorithm to find the shortest path length to the next function jump basic block in the reachable target path in the same function. The calculation formula is: d(b,f next )=min(d ijk (b,b next )) Where b is a basic block in the function, f next is the next function in the path that can reach the target point of this function in the function call graph, b next To jump to f next The min() function indicates that there may be multiple jump basic blocks that jump to the same f next , so take the minimum value; S2003: Calculate function-level distance: For a function node in FCG, use Dijkstra algorithm to find the shortest path length from the next function to the target function in the path to the target point. The formula is: d(f next ,T f )=d ijk (f next ,T f ) S2004: Determine a constant multiple coefficient: multiply the function level distance by a constant multiple, so as to balance the influence of the basic block level distance and the function level distance in the fitness index; S2005: Comprehensive distance calculation: Given a target basic block T b , the distance is the sum of the basic block level distance and the constant multiple function level distance, the formula is: d(b,T b )=min(d(b,f next )+c*d(f next ,T f )) S2006: Calculate the fitness index: divide the cumulative distance of the basic blocks in the test running trajectory by the number of basic blocks covered by the test case to obtain the path distance, that is, the fitness index.

9. The directional fuzzy testing method for Windows platform applications widely adapted according to claim 7 is characterized in that: The process based on the key basic block coverage-oriented model includes: S3001: Recursive reverse order analysis: Starting from the target basic block, recursively trace back the edges of the function call graph and the control flow graph to identify the path that may lead to the target point; S3002: Iterative analysis: iteratively check the paths from the function entry to each jump basic block, and identify all basic blocks on these paths; S3003: Path discovery: By analyzing the function call graph, it is determined that there are multiple paths that can reach the target point; the edge on the path represents the calling relationship between functions, corresponding to a jump basic block, which is a key transition point in the control flow graph; S3004: Construction of key basic block set: A control flow graph is constructed inside the function where each jump basic block is located; in this graph, it is necessary to find all paths that can reach the jump basic block and determine the basic blocks on these paths; these basic blocks constitute the parent node set of the target location, that is, the key basic block set.

10. The directional fuzzy testing method for Windows platform applications widely adapted according to any one of claims 1 to 5, characterized in that: The fuzzy test optimization process adopts an energy allocation optimization method based on a time slicing strategy, and its process includes: Define time t as the transition point from the simulated annealing exploration phase to the exploitation phase; In the exploration phase, the fuzzer accepts all possible seeds and explores a wide range of possibilities; In the exploitation phase, testing focuses on in-depth analysis of those paths that are considered most likely to discover new vulnerabilities or trigger unusual behavior; In the balancing phase, after time 10*t has passed, additional resources are allocated to those less executed paths based on the dynamically adjusted resource allocation guided by the fitness indicator.

Images