A Targeted Fuzz Testing Method Widely Adapted to Windows Platform Applications

Abstract

This invention discloses a targeted fuzzing method widely adaptable to Windows platform applications, comprising: target program adaptation; locating target functions that meet the conditions, dynamically instrumenting and monitoring the program's execution path at runtime, recording information, and generating detailed intermediate files and dump files; focusing on functions related to input file operations during the static analysis phase, generating a series of target function offsets for command-line programs and some GUI programs, and selecting the most valuable targets based on the coverage of functional functions and the call depth of file operation functions; target site identification; identifying potential vulnerabilities and critical execution paths before performing targeted fuzzing; targeted fuzzing; performing targeted fuzzing on the target program; and fuzzing optimization: improving testing efficiency by implementing a time-slicing strategy. This invention has the advantages of simple principle, easy implementation, and good testing results.

Description

Technical Field

[0001] This invention mainly relates to the field of vulnerability discovery technology in computer security, specifically a targeted fuzzing method that is widely compatible with Windows platform applications. Background Technology

[0002] Fuzzing, as a highly efficient and lightweight automated vulnerability discovery technique, has established its important position in the fields of software testing and security. According to data from Google Project Zero in 2019, fuzzing accounted for a staggering 37.2% of vulnerability discovery methods over the past five years. Among them, AFL (American Fuzzy Lop), a landmark gray-box fuzzing tool, collects code coverage information through compile-time instrumentation and utilizes an evolutionary algorithm, using coverage as a fitness metric to guide the fuzzing towards a path that increases coverage. Currently, most gray-box fuzzing tools, like AFL, are code coverage-oriented, aiming to cover as many program states as possible within a limited time. This is based on the common understanding that higher code coverage usually means finding more errors. However, this coverage-based testing often wastes a significant amount of time on code areas that do not contain errors and struggles to delve deeper into hidden problems.

[0003] To address this, practitioners have proposed a targeted gray-box fuzzing technique. This technique is a variant of gray-box fuzzing, focusing more on specific areas of the program that may contain problems, such as highly complex or error-prone parts of the code. Targeted fuzzing spends significant time locating the target, avoiding wasting resources on emphasizing irrelevant program modules. This superior targeting ability makes it applicable to scenarios such as patch testing, vulnerability reproduction, verification of suspicious defects, or static analysis reports.

[0004] Currently, while many practitioners have conducted extensive research on targeted gray-box fuzzing, this research has primarily focused on Unix-like platforms. Windows applications also face security challenges. Due to the rapid updates and iterations of Windows applications, corresponding vulnerabilities are constantly emerging. Applying fuzzing techniques to the Windows platform is crucial for reducing the burden of manual auditing, lowering labor costs, and maintaining the Windows ecosystem. However, implementing targeted fuzzing on the Windows platform faces several challenges and still has some shortcomings:

[0005] (1) How to quickly locate the target function in an application? For closed-source commercial applications without publicly available 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 have complex code structures involving multiple modules and library functions, making accurate identification of the target function even more challenging. The traditional approach is usually to manually analyze and debug the target function 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 running 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 selection. In addition, after processing an event, a GUI application enters an idle state, waiting 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 a closed-source program to calculate the fitness index. Traditional targeted fuzzing tools for the Linux platform, such as AFLGo, instrument the program during compilation and collect information during execution to construct the control flow graph and function call graph. This is not applicable to pre-compiled closed-source Windows programs.

[0008] (4) Windows closed-source programs typically involve a large number of libraries and system calls, resulting in excessively large and complex graphs. Indirect calls and branches in binary programs, such as virtual table function pointers, further complicate the graph integrity problem. A lightweight approach tailored for closed-source programs needs to be explored to extract the local control flow graphs and function call graphs required for calculating fitness metrics. Summary of the Invention

[0009] The technical problem to be solved by this invention is: in view of the technical problems existing in the prior art, this invention provides a targeted fuzz testing method that is simple in principle, easy to implement, and has good testing results, and is widely compatible with Windows platform applications.

[0010] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0011] A targeted fuzzing method for broad compatibility with Windows platform applications, comprising:

[0012] Target program adaptation; locating target functions that meet the conditions, dynamically instrumenting and monitoring the program's execution path at runtime, recording information, and generating detailed intermediate files and dump files; the static analysis phase focuses on functions related to input file operations, generating a series of target function offsets for command-line programs and some GUI programs, and selecting the most valuable targets based on the coverage of functional functions and the call depth of file operation functions; for most GUI programs and shared libraries, generating simple program harnesses that can directly call target functions and simulate key program behaviors.

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

[0014] Targeted fuzz testing; performing targeted fuzz testing on the target program;

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

[0016] As a further improvement to the method of the present invention: In the target program adaptation, the generation of the target function offset candidate list adopts 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 the direct call, return, indirect call, and indirect jump situations within the function. The dynamic instrumentation part focuses on function calls related to input file operations and library functions related to program functions, and generates intermediate files of function call sequences. The static analysis script extracts function call relationships, identifies the main program function that calls file-related APIs, and only considers the file processing thread when processing multi-threaded applications. The static analysis script counts the number of function library functions called inside the identified main program function, and uses this as the evaluation criterion for subsequent target selection.

[0017] As a further improvement to the method of this invention: The method accepts a call sequence `callchunk` and a stack memory dump file `stack_mem` as input parameters. It iterates through each function call in the call sequence, first checking if it returned before calling file-related APIs. If so, this function call is removed from the call sequence `callchunk`. Next, it determines whether the function call is related to file operations using flags and the dump file. If the function call is related to file operations, the call sequence is iterated again. In this iteration, all function calls with the same thread ID and a call ID less than the function's are searched, ensuring that only calls to file operation APIs within the same thread are considered. After finding function calls that meet the conditions, they are added to the result list, and finally, a list of function calls related to file operations is returned.

[0018] The specific algorithm implementation of the function call callback function is as follows: Figure 4 As shown, all file operation-related calls 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 file operation-related calls, it is necessary to dump the stack value pointing to the memory space to facilitate subsequent location of APIs related to the input file.

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

[0020] As a further improvement to the method of the present invention: the automated path tracing framework includes:

[0021] During the dynamic tracing phase, the user-provided program and input are first executed in the instrumentation monitoring environment to extract the path information of the execution process, and the library loading function is monitored through Pin; when dealing with multi-threaded applications, only threads that call file-related APIs are considered.

[0022] During the critical behavior recovery phase, the library-related function calls are first copied into the harness skeleton, and an 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 preceding function as the input parameter of the subsequent function; the output parameter of the preceding function as the input parameter of the subsequent function; and aliases.

[0023] As a further improvement to the method of the present invention: the target site identification process 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 scripts to audit dangerous functions and identify functions that may pose security risks if used improperly;

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

[0027] As a further improvement to the method of the present invention: During the directional fuzzy testing process, based on different fitness indices, it is divided into a path distance-oriented mode and a key basic block coverage-oriented mode. Both the path distance-oriented mode and the key basic block coverage-oriented mode include a preprocessing stage, a fitness index calculation stage, and a power scheduling stage; wherein:

[0028] Preprocessing stage: Obtain distance files of basic blocks or offset list files of key basic blocks through preprocessing;

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

[0030] Power scheduling phase: Based on the above fuzzer, the fitness score is calculated and power scheduling is performed. Test cases with high fitness scores will be given more testing time or more mutation opportunities.

[0031] As a further improvement to 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: Utilizing the Python scripting capabilities of IDA PRO, analyze binary files and draw control flow diagrams and function call diagrams;

[0033] S2002: Calculating Basic Block-Level Distances: For a basic block in a CFG, Dijkstra's algorithm is used to find the shortest path length of the next function-hopping basic block among the reachable targets within the same function. The calculation formula is as follows:

[0034]

[0035] in For a basic block within a function, For the function call graph, the next function in the path to the target point is the function that can be reached by the function. To jump to Basic jump blocks; The parentheses indicate that multiple jump blocks may jump to the same basic block. Therefore, the minimum value is taken;

[0036] S2003: Calculating Function-Level Distance: For a function node in the FCG, use Dijkstra's 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]

[0038] S2004: Determine the constant multiplier coefficient: Multiply the function-level distance by a constant multiplier to balance the effects of the block-level distance and the function-level distance in the fitness index;

[0039] S2005: Comprehensive Distance Calculation: Given a target basic block The distance is the sum of the basic block-level distance and the constant multiple function-level distance, as shown in the formula:

[0040]

[0041] S2006: Calculate the fitness index: Divide the cumulative distance of basic blocks in the test run trajectory by the number of basic blocks covered by the test cases to obtain the path distance, which is the fitness index.

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

[0043] S3001: Recursive reverse analysis: Starting from the target basic block, recursively trace the edges of the function call graph and control flow graph to identify possible paths to the target point;

[0044] S3002: Iterative analysis: Iteratively examines the path from the function entry point to each basic jump block, identifying all basic blocks on these paths;

[0045] S3003: Path Discovery: By analyzing the function call graph, multiple paths that can reach the target point are identified; the edges on the path represent the call relationship between functions and correspond to a basic jump block, which is a key transition point in the control flow graph;

[0046] S3004: Construction of the set of key basic blocks: The function containing each jump basic block forms a control flow graph; 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 set of parent nodes of the target location, that is, the set of key basic blocks.

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

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

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

[0050] During the exploitation phase, testing focuses on in-depth analysis of paths deemed most likely to uncover new vulnerabilities or trigger anomalous behavior;

[0051] During the equilibrium phase, after a period of time... Subsequently, based on the dynamically adjusted resource allocation guided by fitness metrics, additional resources were allocated to those paths that were executed less frequently.

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

[0053] 1. The targeted fuzz testing method of the present invention, which is widely compatible with Windows platform applications, is simple in principle, easy to implement, and has good testing results. It can realize targeted fuzz testing for wide compatibility with Windows platform applications.

[0054] 2. The targeted fuzzing method of this invention, which is widely adaptable to Windows platform applications, uses dynamic binary detection technology to monitor the program at runtime and record module loading and function call information in order to locate the target function. Then, a static analysis script is used to identify functions in the main program involved in file I / O and parsing as candidate target functions. Based on the functional coverage and call depth of these functions and after verification, a decision is made on whether to use them as test target functions. Functions that cover as many functions as possible and have a relatively low call depth for file-related APIs are selected as target test functions.

[0055] 3. The present invention provides a targeted fuzzing testing method widely adaptable to Windows platform applications. To address GUI issues, the 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 before entering a idling state for testing. The third solution is based on hybrid analysis, which involves monitoring the GUI application and its dependent libraries at runtime and performing reverse engineering to extract the core functions of the target program and convert them into independent programs. These independent programs are then tested by directly calling specific functions via the command line. The third method can be automated, and the generated independent programs are reusable, offering wider applicability.

[0056] 4. The present invention provides a targeted fuzzing method widely adaptable to Windows platform applications. To calculate fitness metrics, this invention focuses on the basic blocks and functions of reachable targets. The basic idea is to identify a series of parent nodes of the target region. The IDA Python API is used to recursively construct a back-cross-reference control flow graph and function call graph of the target points. Although the generated graphs are limited to a local portion of the entire application, they contain sufficient 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, it simplifies the complexity of the graph, thus generating effective graphs faster, and is particularly suitable for closed-source binaries that cannot be instrumented at compile time.

[0057] 5. This invention provides a directional fuzzing method widely adaptable to Windows platform applications. Based on hybrid analysis and program execution path tracing technology, this invention utilizes the dynamic binary instrumentation tool Pin combined with static analysis to trace the execution path of Windows applications. This allows for the automated generation of test target offset candidates and the construction of simple test drivers (harnesses), enabling testing of target programs without user interaction. This invention employs two directional guidance modes: path distance-oriented and key basic block coverage-oriented modes, designed according to different fitness metrics. These modes calculate fitness metrics using control flow graphs and function call graphs obtained through IDA static analysis. During the power scheduling phase, test cases with high fitness scores are selected for mutation, accelerating fuzzing to the predetermined target. Furthermore, this invention employs an optimized time-slicing strategy for directional fuzzing technology. In the early stages, fitness metrics are prioritized; in the later stages, in addition to fitness metric guidance, more energy is allocated to low-frequency paths, effectively utilizing the time dimension, improving the comprehensiveness of path exploration, and avoiding ineffective resource consumption. Attached Figure Description

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

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

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

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

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

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

[0064] like Figures 1-3 As shown, the present invention provides a targeted fuzz testing method for Windows platform applications that is widely adaptable, comprising:

[0065] Target program adaptation; Locating target functions that meet certain conditions. In order to effectively test console programs, GUI programs and shared libraries on the Windows platform, target program adaptation can locate target functions that meet specific conditions.

[0066] The target program adaptation primarily targets three types of common Windows applications. Specifically, it dynamically instrumentes the program's execution path at runtime, recording information such as module loading and function calls, and generating detailed intermediate and dump files. The static analysis phase focuses on functions related to input file operations, such as CreateFile and ReadFile. For command-line programs and some GUI programs, it generates a series of target function offsets, selecting the most valuable targets based on function coverage and the call depth of file operation functions. For most GUI programs and shared libraries, it generates simple program harnesses that can directly call target functions and simulate key program behaviors.

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

[0068] Targeted gray-box fuzzing focuses on locating a specified target position within a program. Determining the target position is a crucial step, and three main methods are proposed for target site identification: static analysis to identify functions with high difference scores as targets; IDA Python scripts to identify dangerous functions through name matching, including common dangerous functions and their safe replacements such as alloca() and malloc(), strlen() and strnlens(); and using information from the CVE vulnerability database 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] Targeted fuzz testing; performing targeted fuzz testing on the target program;

[0070] It includes two directional guidance modes: path distance guidance and critical basic block coverage guidance. Both follow two phases: the preprocessing phase analyzes the program's control flow graph and function call graph to generate a list file of basic block distances or critical basic block offsets; the fuzzing run phase dynamically instrumentes the closed-source program, uses these files to statistically analyze path distances or critical area basic block coverage, and calculates fitness scores and power scheduling based on this data.

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

[0072] Fuzzy testing optimization improves the power scheduling scheme of simulated annealing to avoid repeatedly testing existing paths while ignoring new paths. It re-divides the testing time into three phases: exploration, utilization, and balancing. In the balancing phase, while maintaining the fitness index orientation, energy allocation to low-frequency paths is increased.

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

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

[0075] b. The function must be able to parse the file; after parsing, it must be able to close the file to ensure that the fuzzer can rewrite it; the function must return normally using the "ret" command when it ends, instead of "exit", so that the fuzzer can capture this return and redirect the execution.

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

[0077] Furthermore, as a preferred embodiment, the fuzzing process integrates the functions of automatically generating a candidate list of objective function offsets and automatically creating harnesses that simulate key program behaviors, thereby optimizing the fuzzing process. That is:

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

[0079] Adaptation to graphical interactive programs: This invention designs an automated path tracing framework to generate driver harnesses that simulate the key behaviors of closed-source Windows programs. The harnesses use a command-line interface instead of a GUI. By testing the harnesses, the problem of user interaction preventing normal test iteration can be solved.

[0080] This invention employs an automated target offset candidate generation method based on hybrid analysis to generate the target function offset candidate list. The dynamic instrumentation part tracks file-related APIs and target library function calls. Specifically, this includes registering two callback functions, one recording the name and base address of the loaded module, and the other recording direct calls, returns, indirect calls, and indirect jumps within the function. The specific algorithm implementation for the function call callback functions is as follows... Figure 4 As shown, all file operation-related calls 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 file operation-related calls, it is necessary to dump the stack value pointing to the memory space to facilitate subsequent location of APIs related to the input file.

[0081] See Figure 2This method mainly consists of two parts. The dynamic instrumentation part focuses on function calls related to input file operations and library functions related to program functionality, generating intermediate files of function call sequences. The static analysis script extracts function call relationships, identifies the main program function that calls file-related APIs, and considers only the file processing thread when dealing with multi-threaded applications. In addition, to ensure that the test scope covers as many functions as possible, the static analysis script counts the number of library functions called internally by the identified main program functions, using this as a criterion for subsequent target selection.

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

[0083] The algorithm takes a call sequence `callchunk` and a stack memory dump file `stack_mem` as input parameters. It iterates through each function call in the call sequence, first checking if it returned before calling file-related APIs; if so, it removes the function call from the call sequence `callchunk`. Next, it determines if the function call is related to file operations using flags and the stack dump file. If the function call is related to file operations, it iterates through the call sequence again, this time searching for all function calls with the same thread ID but a smaller call ID than the function call, ensuring that only calls to file operation APIs within the same thread are considered. Once function calls meeting the criteria are found, they are added to the result list, ultimately returning a list of function calls related to file operations.

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

[0085] The method for automatically creating harnesses simulating key behaviors of a program in this invention employs an automated path tracing framework for generating harnesses that simulate key behaviors of a GUI program. To overcome the reliance on user interaction for iterative testing of GUI programs, this invention proposes an automated path tracing framework that combines the dynamic instrumentation tool Pin with IDA static analysis. This framework can extract function call paths and parameter dependencies of key library files from closed-source Windows programs to generate harnesses that simulate key program behaviors.

[0086] See Figure 3 The framework comprises two phases: dynamic tracking and key behavior recovery, specifically including:

[0087] In the dynamic tracing phase, the user-provided program and input are first executed in the instrumentation monitoring environment to extract the execution path information. Library loading functionality is monitored via pins. This phase primarily focuses on the external interfaces exposed by the library, omitting control flow within the same module. This is because function calls within these modules represent the library's internal logic, and the same behavior of the original program can be restored by calling the library's exported functions. When handling multi-threaded applications, only threads calling file-related APIs are considered. This is to avoid adding irrelevant calls that could compromise harness correctness.

[0088] During the critical behavior recovery phase, library-related function calls are first copied into the harness skeleton, and an IDA Python script is used to retrieve necessary information. After serialization, the information is temporarily stored in a local JSON file. Then, data dependency analysis is performed to determine parameters, primarily considering three types of relationships: the return value of a preceding function as the input parameter of a subsequent function; the output parameters of a preceding function (usually in the form of pointers) as the input parameters of a subsequent function; and aliases.

[0089] The specific steps of this method include:

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

[0091] The name and base address of the loaded module;

[0092] Details of inter-module calls and jumps, including thread ID, caller and callee addresses, 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, record the function's return value;

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

[0096] S1002: Key Behavior Recovery: In this stage, library-related function calls are extracted from the trace data and copied into the testing harness framework. Since dynamic traces often lack necessary symbolic information and addresses, this invention uses IDA Pro to supplement these key details, including:

[0097] The offset address of the function;

[0098] Function type and return type;

[0099] Function name;

[0100] Parameter type and number;

[0101] S1003: Data Dependency Analysis: Analyzes the relationship between function parameters and return values, focusing on three main scenarios:

[0102] The return value of one function is used as an input parameter of another function, and the determination is made by checking whether a parameter always has the same value as a past return value;

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

[0104] The aliasing relationship between parameters: if the same non-constant value is used as a parameter in two different places in the program, then these two parameters are considered "aliases".

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

[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 scripts to audit dangerous functions and identify functions that may pose security risks if used improperly;

[0108] c. Analyze 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 specific application examples, the directional fuzzy testing process is divided into path distance-oriented mode and key basic block coverage-oriented mode, depending on the fitness index. Both the path distance-oriented mode and the key basic block coverage-oriented mode include a preprocessing stage, a fitness index calculation stage, and a power scheduling stage. Among them:

[0110] Preprocessing stage: Obtain distance files of basic blocks or offset list files of key basic blocks through preprocessing;

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

[0112] Power scheduling phase: Based on the above fuzzer, the fitness score is calculated and power scheduling is performed. Test cases with high fitness scores will be given more testing time or more mutation opportunities.

[0113] The coordinated work of these three stages enables the directional fuzzing component to efficiently detect vulnerabilities in the program, thereby improving the fuzzer's ability to find errors.

[0114] Fitness metrics based on path distance: The path distance for test cases is defined as the average distance between covered basic blocks in the path. The distance from a basic block to the target block is defined as the minimum of the basic block-level shortest distance (the shortest path length from a basic block within a function to the next basic block in the path from the function-level reachable target) plus a constant multiple of the function-level shortest distance (the shortest path length from the next function in the path from the function node to the target point to the target function). The shortest distance is calculated using Dijkstra's algorithm.

[0115] The fitness metric based on critical basic block coverage is defined as the proportion of the number of critical basic blocks covered during test case execution to the total number of basic blocks covered.

[0116] Power scheduling based on simulated annealing: The entire testing process is divided into exploration and exploitation phases according to time thresholds. The goal of the exploration phase is to extensively explore the program space, distributing energy as fairly as possible to all test cases and avoiding premature entrapment in local optima. After a certain period of exploration, the exploitation phase begins, which tends to allocate more energy to test cases with higher fitness scores.

[0117] The fitness metric based on path distance in this invention measures how close a test case is to a specific target (such as an error location, a specific execution path, or a code region). Test cases can be dynamically adjusted based on their fitness metric to explore code regions with high-risk potential more frequently. The specific process includes:

[0118] S2001: Creating CFG and FCG using IDA Python: Utilizing the Python scripting capabilities of IDA PRO, analyze binary files and draw control flow diagrams and function call diagrams;

[0119] S2002: Calculating Basic Block-Level Distances: For a basic block in a CFG, Dijkstra's algorithm is used to find the shortest path length of the next function-hopping basic block among the reachable targets within the same function. The calculation formula is as follows:

[0120]

[0121] in For a basic block within a function, For the function call graph, the next function in the path to the target point is the function that can be reached by the function. To jump to The basic jump block. The parentheses indicate that multiple jump blocks may jump to the same basic block. Therefore, the minimum value is taken.

[0122] S2003: Calculating Function-Level Distance: For a function node in the FCG, use Dijkstra's 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]

[0124] S2004: Determine the constant multiplier coefficient: Multiply the function-level distance by a constant multiplier (this constant can be obtained from experiments or experience) to balance the effects 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 The distance is the sum of the basic block-level distance and the constant multiple function-level distance, as shown in the formula:

[0126]

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

[0128] S2006: Calculate the fitness index: Divide the cumulative distance of basic blocks in the test run trajectory by the number of basic blocks covered by the test cases to obtain the path distance, which is the fitness index.

[0129] In this invention, the fitness metric based on critical basic block coverage is defined as the ratio of the number of basic blocks covering the critical region during test case execution to the total number of basic blocks covered. This metric reflects the coverage effect of the test cases within the critical region. Higher coverage indicates that the test cases are more effective in probing the critical region and are therefore more likely to uncover potential defects. To determine the set of critical basic blocks, automated analysis is performed using IDAPro's Python scripting capabilities; the process includes:

[0130] S3001: Recursive Reverse 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 possible paths to the target point.

[0131] S3002: Iterative Analysis: Iteratively examines the paths from the function entry point to each jump base block, identifying all base blocks on these paths.

[0132] S3003: Path Discovery: By analyzing the function call graph, multiple paths to the target point are identified. The edges on the path represent the call relationships between functions and correspond to a basic jump block, which is a key transition point in the control flow graph.

[0133] S3004: Construction of the Key Basic Block Set: The function containing each jump basic block can form a control flow graph. In this graph, all paths leading to the jump basic block need to be found, and the basic blocks along these paths need to be identified. These basic blocks constitute the set of parent nodes for the target location, i.e., the key basic block set.

[0134] The energy allocation optimization based on the time-slicing strategy in this invention is a dynamically adjusted optimization strategy aimed at balancing comprehensive exploration with concentrated utilization. By dividing the testing process into three stages—exploration, utilization, and balancing—and adjusting the energy allocation strategy in each stage, the program space can be explored more effectively.

[0135] In the above strategy, the period before time t is defined as the simulated annealing exploration phase, where the fuzzer accepts all possible seeds; after time t, it enters the "exploitation" phase, favoring seeds with high fitness and allocating more resources to them to enhance the exploration of effective paths. Subsequently, based on the fitness metric, more energy is allocated to low-frequency paths. The time segmentation parameter t was initially set based on empirical values. In actual testing, if significant underperformance is observed in a certain stage, the time segmentation can be adjusted in subsequent test iterations to adapt to the dynamic changes in the testing process, ensuring the flexibility, predictability, and stability of the test.

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

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

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

[0139] During the exploitation phase, testing focuses on in-depth analysis of paths deemed most likely to uncover new vulnerabilities or trigger anomalous behavior;

[0140] During the equilibrium phase, after a period of time... Subsequently, based on the dynamically adjusted resource allocation guided by fitness metrics, additional resources were allocated to those paths that were executed less frequently.

[0141] In practical applications, the strategy is less determined by two metrics: the number of times a test case is selected from the queue for execution, and the execution path frequency of that test case.

[0142] The power scheduling based on the simulated annealing algorithm in this invention is as follows: Power scheduling based on the simulated annealing algorithm is a heuristic optimization strategy inspired by the annealing phenomenon in the cooling process of metals in solid-state physics. The algorithm can effectively explore the global search space to find the optimal solution. In the application of this algorithm, the entire testing process is divided into exploration and exploitation phases based on time thresholds. The exploration phase allocates energy fairly to all test cases, while the exploitation phase allocates more energy to test cases with short path distances or high coverage of critical basic blocks. This avoids the situation of excessive concentration of local optima before extensive exploration. Given test cases... and target location The energy based on path distance is:

[0143]

[0144] in This is the energy calculated by WinAFL based on the execution speed of the test cases, the number of covered paths, and the path depth. It is the power factor. It is the normalized path distance of the use case, calculated using the following formula:

[0145]

[0146] The maximum test case distance is maxD, and the minimum is minD. Calculate the normalized distance for each seed range in (0, 1).

[0147] The energy based on the coverage of key basic blocks is:

[0148]

[0149] in The energy is calculated by WinAFL based on the execution speed of the test cases, the number of covered paths, and the path depth. It is the power factor. It is the normalized critical area coverage of the use cases, calculated using the following formula:

[0150]

[0151] The current maximum critical region coverage rate for test cases is maxC, and the minimum is minC. Calculate the normalized critical region coverage rate for each test case within the range of (0, 1).

[0152] In a specific application example, the detailed process of this invention includes:

[0153] Step S100: Testing Adaptation and Determining the Target Site:

[0154] Program Classification: First, the target programs are classified to determine whether to use the method of generating target offsets or generating harness programs for adaptation;

[0155] Vulnerability identification: Analyze the target program using the target site identification component, identify its potential vulnerabilities, and use them as target sites for fuzz testing;

[0156] Step S200: Generate cross-reference control flow chart and function call graph;

[0157] The function call graph is as follows: 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;

[0158] The control flow diagram is as follows: Based on the target site and function call graph, a cross-reference control flow diagram of the program is generated to facilitate understanding of the program's execution flow;

[0159] Step S300: Generation of preprocessed intermediate files;

[0160] Determine the fuzz testing mode, calculate the basic block distance or critical basic block offset by combining the control flow diagram and function call diagram, and generate the corresponding list file;

[0161] Step S400: Fuzz test performed;

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

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

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

[0165] Step S500: Fuzz test optimization;

[0166] Further refine the time division in the simulated annealing algorithm. Subsequently, the seed selection and arrangement strategies were adjusted, and the path execution frequency was incorporated into the fitness score calculation to improve the comprehensiveness of the test.

[0167] Those skilled in the art will understand that the above embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0168] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should be considered within the scope of protection of the present invention.

Claims

1. A targeted fuzz testing method widely adaptable to Windows platform applications, characterized in that, include: Target program adaptation; locating target functions that meet the conditions, dynamically instrumenting and monitoring the program's execution path at runtime, recording information, and generating detailed intermediate files and dump files; the static analysis phase focuses on functions related to input file operations, generating a series of target function offsets for command-line programs and some GUI programs, and selecting the most valuable targets based on the coverage of functional functions and the call depth of file operation functions; for most GUI programs and shared libraries, generating simple program harnesses that can directly call target functions and simulate key program behaviors. Target site identification: Identify potential vulnerabilities and critical execution paths before performing targeted fuzz testing; Targeted fuzz testing: Performing targeted fuzz testing on the target program; Fuzz testing optimization: Improve testing efficiency by implementing a time slicing strategy; The directional fuzzy testing process is divided into path distance-oriented mode and key basic block coverage-oriented mode based on different fitness indices. Both the path distance-oriented mode and the key basic block coverage-oriented mode include a preprocessing stage, a fitness index calculation stage, and a power scheduling stage; wherein: Preprocessing stage: Obtain distance files of basic blocks or offset list files of key basic blocks through preprocessing; Fitness index calculation stage: In the dynamic instrumentation stage of fuzz testing, the path distance and key basic block coverage of the files obtained in the above preprocessing stage are calculated. Power scheduling phase: Based on the fuzzer, the fitness score is calculated and power scheduling is performed. Test cases with high fitness scores will be given more testing time or more mutation opportunities.

2. The targeted fuzz testing method for broad adaptation to Windows platform applications according to claim 1, characterized in that, In the target program adaptation process, the generation of the target function offset candidate list adopts an automated target offset candidate generation method based on hybrid analysis. The dynamic instrumentation part tracks file-related APIs and target library functions, 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 situations within the function. The dynamic instrumentation part focuses on function calls related to input file operations and library functions related to program functions, generating intermediate files of function call sequences. The static analysis script extracts function call relationships, identifies the main program function that calls file-related APIs, and considers only the file processing thread when dealing with multi-threaded applications. The static analysis script counts the number of library functions called within the identified main program function, which is used as the evaluation criterion for subsequent target selection.

3. The targeted fuzz testing method for broad adaptation to Windows platform applications according to claim 2, characterized in that, This function accepts a call sequence `callchunk` and a stack memory dump file `stack_mem` as input parameters. It iterates through each function call in the call sequence, first checking if it returned before calling file-related APIs; if so, it removes the function call from the call sequence `callchunk`. Next, it determines if the function call is related to file operations using flags and the dump file. If the function call is related to file operations, it iterates through the call sequence again, this time searching for all function calls with the same thread ID and a call ID less than the function's, ensuring that only calls to file operation APIs within the same thread are considered. Once the function calls that meet the criteria are found, they are added to the result list, ultimately returning a list of function calls related to file operations. The specific algorithm for function call callback functions includes marking all file operation-related calls as FR, calls within the main program as T2T, and calls from the main program to external modules as T2M. When recording file operation-related calls, it is necessary to dump the stack value pointing to the memory space to facilitate subsequent location of APIs related to the input file.

4. The targeted fuzz testing method for broad adaptation to Windows platform applications according to claim 1, characterized in that, In the target program adaptation, an automated path tracing framework is used to generate harnesses that simulate key behaviors of GUI programs. This framework is used to extract function call paths and parameter dependencies of key library files from Windows closed-source programs and generate harnesses that simulate key program behaviors.

5. The targeted fuzz testing method for broad adaptation to Windows platform applications according to claim 4, characterized in that, The automated path tracing framework includes: During the dynamic tracing phase, the user-provided program and input are first executed in the instrumentation monitoring environment to extract the path information of the execution process, and the library loading function is monitored through Pin; when dealing with multi-threaded applications, only threads that call file-related APIs are considered. During the critical behavior recovery phase, library-related function calls are first copied into the harness skeleton, and an 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 preceding function as the input parameter of the subsequent function; the output parameter of the preceding function as the input parameter of the subsequent function; and aliases.

6. The targeted fuzz testing method for broad adaptation to Windows platform applications according to any one of claims 1-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 scripts to audit dangerous functions and identify functions that may pose security risks if used improperly; c. Analyze the known crash information recorded in the CVE database and use these historical vulnerabilities as an important reference for the target site.

7. The targeted fuzz testing method for broad adaptation to Windows platform applications according to claim 1, characterized in that, The process based on the path distance guidance mode includes: S2001: Creating CFG and FCG using IDA Python: Utilizing the Python scripting capabilities of IDA PRO, analyze binary files and draw control flow diagrams and function call diagrams; S2002: Calculating Basic Block-Level Distances: For a basic block in a CFG, Dijkstra's algorithm is used to find the shortest path length of the next function-hopping basic block among the reachable targets within the same function. The calculation formula is as follows: in For a basic block within a function, For the function call graph, the next function in the path to the target point is the function that can be reached by the function. To jump to Basic jump blocks; The parentheses indicate that multiple jump blocks may jump to the same basic block. Therefore, the minimum value is taken; S2003: Calculating Function-Level Distance: For a function node in the FCG, use Dijkstra's 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: S2004: Determine the constant multiplier coefficient: Multiply the function-level distance by a constant multiplier to balance the effects of the block-level distance and the function-level distance in the fitness index; S2005: Comprehensive Distance Calculation: Given a target basic block The distance is the sum of the basic block-level distance and the constant multiple function-level distance, as shown in the formula: S2006: Calculate the fitness index: Divide the cumulative distance of basic blocks in the test run trajectory by the number of basic blocks covered by the test cases to obtain the path distance, which is the fitness index.

8. The targeted fuzz testing method for broad adaptation to Windows platform applications according to claim 1, characterized in that, The process based on the key basic block coverage-oriented pattern includes: S3001: Recursive reverse analysis: Starting from the target basic block, recursively trace the edges of the function call graph and control flow graph to identify possible paths to the target point; S3002: Iterative analysis: Iteratively examines the path from the function entry point to each basic jump block, identifying all basic blocks on these paths; S3003: Path Discovery: By analyzing the function call graph, multiple paths that can reach the target point are identified; the edges on the path represent the call relationship between functions and correspond to a basic jump block, which is a key transition point in the control flow graph; S3004: Construction of the set of key basic blocks: The function containing each jump basic block forms a control flow graph; 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 set of parent nodes of the target location, that is, the set of key basic blocks.

9. The targeted fuzz testing method for broad adaptation to Windows platform applications according to any one of claims 1-5, characterized in that, The energy allocation optimization method based on time-slicing strategy is used in the fuzzing optimization process, and its process includes: Define time t as the transition point from the simulated annealing exploration phase to the development phase; During the exploration phase, the fuzzer accepts all possible seeds and explores a wide range of possibilities; During the exploitation phase, testing focuses on in-depth analysis of paths deemed most likely to uncover new vulnerabilities or trigger anomalous behavior; During the equilibrium phase, after a period of time... Subsequently, based on the dynamically adjusted resource allocation guided by fitness metrics, additional resources were allocated to those paths that were executed less frequently.

Images