Fuzzing method and device for shared library

Abstract

Embodiments of the present disclosure provide a shared library-oriented fuzzer automatic generation method and device, which comprises: extracting an API function set requiring to be subjected to fuzz testing from source code and a header file of a target shared library; identifying control flow dependence and data flow dependence of an API interface based on the API function set, and constructing an API dependence graph; judging parameter types and deducing dependence relationships between parameters according to the API dependence graph, and distinguishing the parameters into independent variable parameters and state-dependent parameters; generating an executable fuzzer through combination scheduling based on function-to-function calling and dependence relationships in the API dependence graph, and embedding a LibFuzzer semantic coding structure into the fuzzer; and continuously tracking a coverage path during execution of the fuzzer, and preferentially selecting an unexecuted path for testing.

Description

Technical Field

[0001] The embodiments of this disclosure relate to the field of fuzz testing technology, and more specifically, to a method, apparatus, and computer-readable storage medium storing a computer program for automatically generating fuzzers for shared libraries. Background Technology

[0002] With the evolution of operating systems and various platform software frameworks, especially the design trends towards modularity, scalability, and security, dynamic shared libraries have become a key component of modern software systems. Shared libraries encapsulate a large amount of common business logic and third-party service interfaces, such as image codecs, network middleware, and encryption / decryption modules, for the main program to call via APIs. However, precisely because of the widespread sharing and application of shared libraries, vulnerabilities within them can have broader and more profound security implications.

[0003] Most existing fuzzing tools have achieved good results in application-level vulnerability discovery, such as AFL, LibFuzzer, and Driller, which are widely used in application vulnerability discovery. However, they have significant limitations in testing shared libraries. Although attempts have been made to synthesize API call sequences through semantic analysis to drive shared library testing, these methods have limitations such as relying on manual labeling, domain expert knowledge, or only targeting remote calls to IDL interfaces. In particular, because shared libraries lack a clear entry point (such as a main function) and a complete runtime context, traditional fuzzing tools cannot effectively cover the high-complexity logic or vulnerability points within the library. Due to the complex API dependency paths and call chains of shared libraries, fuzzing frameworks cannot automatically generate suitable test cases, making it difficult to meet the needs of large-scale shared library testing. For example, LibFuzzer requires developers to manually construct appropriate call formats and context state information, which becomes particularly cumbersome and difficult to scale, especially when dealing with unknown or third-party libraries, limiting the efficiency of automated testing. Summary of the Invention

[0004] The embodiments described herein provide a method, apparatus, and computer-readable storage medium storing computer programs for automatically generating fuzzers for shared libraries. By extracting API functions from source code and header files, constructing API dependency graphs, distinguishing parameter types and dependencies, and embedding the semantic encoding structure of LibFuzzer, it can dynamically track test paths and prioritize testing uncovered paths, maximizing the chance of vulnerability discovery and achieving efficient fuzz testing for shared library APIs.

[0005] According to a first aspect of this disclosure, an automatic fuzzer generation method for shared libraries is provided, comprising: extracting a set of API functions to be fuzz tested from the source code and header files of the target shared library; identifying control flow dependencies and data flow dependencies of the API interfaces based on the API function set, and constructing an API dependency graph; determining parameter types and deriving dependencies between parameters based on the API dependency graph, classifying parameters into independent variable parameters and state-dependent parameters; generating an executable fuzzer through combination scheduling based on function calls and dependencies in the API dependency graph, and embedding the LibFuzzer semantic encoding structure into the fuzzer; and continuously tracking coverage paths during fuzzer execution, prioritizing testing of unexecuted paths.

[0006] In some embodiments of this disclosure, extracting the set of API functions to be fuzzed from the source code and header files of the target shared library includes: loading and parsing the header files of the target shared library, identifying all exposed API interfaces, and constructing a set of exported functions that can be called externally; performing static analysis on the source code to identify all internal call function sets; calculating the intersection of the exported function set and the call function set, and using the intersection of the two sets as the target API function set for fuzzing.

[0007] In some embodiments of this disclosure, the process of identifying control flow dependencies and data flow dependencies of API interfaces and constructing an API dependency graph based on an API function set includes: converting each function into a compilation unit, where each compilation unit describes the function's interface, parameter types, and return value type information; traversing all basic blocks in the program starting from the entry function, collecting API calls within each function, identifying which API function calls' execution order depends on conditional statements or loop structures in the program, and establishing control dependencies for these calls; identifying data dependencies by analyzing the flow of variables, parameters, and return values ​​within the functions; mapping control dependencies and data dependencies to the API dependency graph structure; and merging API dependency graphs from multiple different program sources through shared state abstraction to construct a complete API dependency graph.

[0008] In some embodiments of this disclosure, nodes in the API dependency graph represent API functions, and edges between nodes represent the calling relationship between different APIs. The edges between nodes are divided into control dependency edges representing the calling order and data dependency edges representing the data dependency passed between functions.

[0009] In some embodiments of this disclosure, the construction of a complete API dependency graph by merging multiple API dependency graphs from different program sources through shared state abstraction includes: examining the transitive relationship of state variables in different function calls through static analysis; if multiple functions or paths use the same state variables, merging these state variables into one API dependency graph, so that the same API interface appears only once, the call relationship between APIs is fully preserved, and the shared state is correctly transmitted and maintained.

[0010] In some embodiments of this disclosure, determining parameter types and deriving dependencies between parameters based on the API dependency graph, classifying parameters into independent variable parameters and state-dependent parameters, includes: identifying the parameter types of the API, classifying parameter types into basic data types, pointer types, structure types, and nested collections; for pointer type parameters, determining whether different pointers point to the same memory location through static alias analysis; when the system cannot directly derive the dependencies of certain pointers or structures, deriving the dependencies between parameters by replacing complex types with simpler types or data structures; for nested structures or arrays, recursively parsing the nested structure into more basic elements to derive the dependencies between parameters; and classifying parameters into independent variable parameters and state-dependent parameters based on the derived dependencies.

[0011] In some embodiments of this disclosure, an executable fuzzer is generated through combinatorial scheduling based on function calls and dependencies in the API dependency graph, and the LibFuzzer semantic encoding structure is embedded in the fuzzer. This includes: constructing a combinatorial scheduling model based on function calls and path dependencies described in the API dependency graph; constructing a fuzzer based on the path structure and the combinatorial scheduling model, wherein the combinatorial scheduling model is used to maximize the coverage of different paths during the execution of the fuzzer; and embedding the LibFuzzer semantic encoding structure into the generated fuzzer, so that the fuzzer adjusts the testing strategy according to the execution results of different input paths.

[0012] In some embodiments of this disclosure, continuously tracking the coverage path during the execution of the fuzzer and prioritizing the testing of unexecuted paths includes: after each round of fuzzing, evaluating which code paths have been covered and recording the discovery of new test paths; and based on an entropy strategy, prioritizing the testing of paths with higher entropy values ​​according to the coverage and information entropy of each path.

[0013] According to a second aspect of this disclosure, an automatic fuzzer generation apparatus for shared libraries is provided. The apparatus includes at least one processor and at least one memory storing a computer program. When the computer program is executed by the at least one processor, the apparatus causes the following actions: extracting a set of API functions to be fuzzed from the source code and header files of the target shared library; identifying control flow dependencies and data flow dependencies of the API interfaces based on the API function set, and constructing an API dependency graph; determining parameter types and deriving dependencies between parameters based on the API dependency graph, classifying parameters into independent variable parameters and state-dependent parameters; generating an executable fuzzer through combinatorial scheduling based on function calls and dependencies in the API dependency graph, and embedding a LibFuzzer semantic encoding structure into the fuzzer; and continuously tracking coverage paths during fuzzer execution, preferentially selecting unexecuted paths for testing.

[0014] According to a third aspect of this disclosure, a computer-readable storage medium storing a computer program is provided, wherein the computer program, when executed by a processor, implements the steps of the automatic fuzzer generation method for a shared library according to a first aspect of this disclosure.

[0015] The automatic fuzzer generation method and apparatus for shared libraries according to embodiments of this disclosure automatically extracts the set of API functions requiring fuzz testing from the source code and header files of the shared library, achieving automated identification and precise selection of test targets and reducing the workload of manual configuration. It derives the dependencies between parameters based on the API dependency graph and distinguishes between independent variable parameters and state-dependent parameters, further optimizing the construction of test inputs and ensuring that the generated test cases cover a wider range of paths and scenarios. During fuzzer execution, it continuously tracks the covered paths and prioritizes testing unexecuted paths, avoiding path saturation problems during testing, improving test depth and coverage, and ensuring the discovery of more potential vulnerabilities. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments will be briefly described below. It should be understood that the drawings described below only relate to some embodiments of this disclosure and are not intended to limit this disclosure, wherein:

[0017] Figure 1 An exemplary flowchart is shown for an automatic fuzzer generation method for a shared library according to an embodiment of the present disclosure;

[0018] Figure 2 This is a schematic block diagram of an automatic fuzzer generation apparatus for a shared library according to embodiments of the present disclosure.

[0019] It should be noted that the elements in the attached diagram are schematic and not drawn to scale. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are also within the scope of protection of this disclosure.

[0021] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this subject matter pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having meanings consistent with their meanings in the context of the specification and in the relevant art, and shall not be interpreted in an idealized or overly formal form unless otherwise explicitly defined herein. Furthermore, terms such as “first” and “second” are used only to distinguish one component (or part of a component) from another component (or another part of a component).

[0022] In automated testing, a thorough understanding of the dependencies between APIs and the ability to generate a reasonable call graph during program execution can significantly improve the efficiency and accuracy of fuzz testing. Therefore, automatically parsing API dependency information, constructing a reasonable call graph, and generating test cases based on this graph are key to solving the problem of automated testing of shared libraries. This disclosure provides an automatic fuzzer generation scheme for shared libraries. Through API dependency graph modeling and static analysis techniques, it can automatically parse the structure of the target codebase, uncover call dependencies between functions, and synthesize a semantically reasonable and executable fuzzer source code with high coverage and accuracy.

[0023] To further explain the embodiments of this disclosure in detail, Figure 1 An exemplary flowchart illustrates an automatic fuzzer generation method for a shared library according to embodiments of this disclosure. Figure 1 At box S102, all available API interfaces are identified from the source code and associated header files of the target shared library to obtain the API set for fuzz testing.

[0024] The target shared library includes one or more header files that define externally visible API interfaces (function declarations), containing information such as function prototypes, type definitions, and macro definitions. First, the header files of the target shared library (e.g., .so, .dll files) are loaded and parsed to identify all exposed API interfaces, constructing a set of all externally callable exported functions. This set includes the names and prototypes of all exported functions in the shared library. Functions declared using the `extern` keyword or `__declspec(dllexport)` (Windows platform) / `__attribute__((visibility("default")))` (Linux platform) can be searched in the header files; these functions are externally callable exported APIs. The symbol table of the shared library can be parsed, and tools such as `nm` or `objdump` can be used to obtain symbol information and identify which functions are exposed by the library. For example, the symbol table of the shared library `libexample.so` contains the following information:

[0025] plaintext

[0026] 00000000T foo

[0027] 00000000T bar

[0028] 00000000T calculate_sum

[0029] The symbols foo, bar, and calculate_sum indicate that these functions are exported functions visible outside the library and should be included in the exported function set Flib.

[0030] The source code contains the specific function implementations and call relationships, allowing for static analysis to identify all internally called function sets. This ensures that the actual function implementations and their roles within the library are considered when calculating API interfaces. During testing, only exported functions called by other functions are considered valid APIs, identified by analyzing function call paths to determine the called function set, Fincl. For example, if the `foo` function calls the `bar` function, `bar` should appear in the Fincl set. If the `foo` function calls `calculate_sum`, then `calculate_sum` should also be added to the Fincl set.

[0031] The intersection of the exported function set and the called function set is calculated, and this intersection is used as the target API set for fuzzing. In other words, functions that are both exported functions and called by other functions are identified, and this intersection constitutes the API function set Fapi that needs to be fuzzed. By precisely filtering out the API function set to be tested, test path explosion is avoided. Even if the target library contains a large number of functions or complex call paths, the system uses intersection calculation to ensure that testing focuses only on those interfaces that truly need verification, thereby improving testing efficiency.

[0032] Subsequently, in box S104, based on the API function set, all basic blocks in the program are traversed starting from the entry function to construct the API dependency graph.

[0033] An API Dependency Graph (ADG) is a graph structure built using a Control Flow Graph (CFG) and a Program Dependency Graph (PDG) to represent the calling relationships and data dependencies between different API interfaces throughout the program.

[0034] According to one embodiment of this disclosure, each function is converted into a compilation unit, which describes the function's interface, parameter types, and return value type information. Starting from the entry function, all basic blocks in the program are traversed, collecting API calls within each function. It is then identified which API function calls' execution order depends on conditional statements or loop structures in the program, and control dependencies are established for these calls. The entry function is the main function or other initialization function, serving as the starting point for program execution. For example, in a simple program with two basic blocks, where the first block calls API `foo` and the second block calls API `bar`, the control flow graph will form edges from `foo` to `bar`, representing the call order. By analyzing conditional statements and loop structures in the code, it is identified which API function calls are executed under specific conditions, and control dependencies are established for these calls in the control flow graph. For example, if the call to the `foo` function only executes when `x > 0`, there is a control dependency between `foo` and the control structure, and the control flow graph can accurately represent the order of API calls.

[0035] Program dependency graphs focus on capturing dependencies between data. During construction, data dependencies are identified by analyzing the flow of variables, parameters, and return values ​​within functions. For example, if function A depends on the return value of function B, there will be a data dependency edge between A and B in the ADG. Between different functions, the passing of data such as parameters, return values, and local variables affects the execution order and dependencies of the functions. Program dependency graphs help capture these data passing relationships. For example, if function foo accepts x as an argument and passes it to function bar, there is a data dependency between foo and bar, and x is the dependent data.

[0036] Control dependencies and data dependencies are mapped to the API dependency graph structure. When constructing the API dependency graph (ADG), if it's necessary to analyze multiple program modules or multiple API functions sharing certain execution states (e.g., file pointers (FILE*), file descriptors (fd), session structures, and other global or static states), multiple API dependency graphs may be generated. In this case, these graphs need to be merged into a unified ADG. Specifically, multiple API dependency subgraphs can be constructed from multiple different program sources. By analyzing the parameters and state propagation chains in multiple API call paths, parts with similar state dependency structures are identified. These parts with similar state dependency structures are merged into shared state nodes, while preserving the independent control flow of the paths, thus constructing a complete API dependency graph. This ensures that the same API interface appears only once, the call relationships between APIs are fully preserved, and shared state is correctly passed and maintained.

[0037] In the final generated API dependency graph, each API function is abstractly represented by a node. The edges between nodes represent the calling relationship between different APIs. The edges between nodes are divided into control dependency edges that represent the calling order and data dependency edges that represent the data dependencies passed between functions.

[0038] Next, in box S106, the parameter types are determined based on the API dependency graph, and the dependencies between parameters are deduced, classifying the parameters into independent variable parameters and state-dependent parameters.

[0039] Static alias analysis can determine whether there are shared memory regions or state dependencies between different API parameters. This is crucial for handling complex data structures and dynamic memory allocation. In one embodiment of this disclosure, the parameter types of the API are first identified and categorized into basic data types, pointer types, structure types, and nested collections. Basic data types include integers, floating-point numbers, and characters. Pointer types include int* and char*. Structure types include user-defined complex data structures. Nested collections include arrays, linked lists, and hash tables.

[0040] For pointer-type parameters, static aliasing is used to determine whether two pointers point to the same memory location. Direct aliasing or indirect aliasing can be used. Direct aliasing analyzes the pointer's value (e.g., memory address) to determine if they point to the same location. Indirect aliasing, if the pointer points to another variable, such as a memory location indirectly obtained through another pointer or array, further infers whether they might point to the same memory block. When dealing with complex pointers, more refined analysis is performed by considering contextual conditions, such as the pointer's initial assignment and modification history. For example, if two pointers p1 and p2 point to the same memory block through different paths (e.g., passed through different pointers or array indices), the system uses aliasing analysis to mark them as pointers that may share state.

[0041] When the system cannot directly deduce the dependencies of certain pointers or structures, it utilizes type substitution techniques to replace complex types with simpler types or data structures for deduction. For example, for a pointer to a structure, the structure can be replaced with pointers to its internal fields for analysis, simplifying complex dependency deduction. For nested structures or arrays, the nested structure is broken down into more basic elements for recursive parsing to analyze their dependencies in greater detail. For instance, if one structure contains another structure, the system recursively analyzes every field of the nested structure, ensuring comprehensive coverage of dependencies across all fields.

[0042] Through the aliasing analysis, type substitution, and recursive resolution described above, the dependencies between different API parameters can be derived. These dependencies are categorized into data dependencies and state dependencies. Based on the derived dependencies, parameters are distinguished into independent variable parameters and state-dependent parameters. For example, a pointer-type parameter depends on the memory block pointed to by another pointer. Two function parameters may share a file descriptor (fd) and be passed between multiple API calls. In some APIs, parameters may be variable or have dynamic properties, such as variable-length parameters (e.g., ...) or parameters that depend on the program's runtime state (e.g., global variables, external configurations, etc.). These variable parameters and state-dependent parameters require special handling to avoid errors during test input construction.

[0043] Next, in box S108, based on the function calls and dependencies in the API dependency graph, an executable fuzzer is generated through combination scheduling, and the LibFuzzer semantic encoding structure is embedded in the fuzzer.

[0044] Based on the function call and path dependency relationships described in the API dependency graph, a reasonable combinatorial scheduling model is constructed according to the existing path structure and execution order. This combinatorial scheduling model not only guarantees path traversal but also generates semantically correct test code in an appropriate order. The combinatorial scheduling model selects paths to be covered and generates corresponding code snippets. The generation of each path follows control flow and data flow rules, ensuring that the generated code accurately triggers different program states and executes the relevant API functions. In one embodiment of this disclosure, a combinatorial scheduling model can be constructed based on the function call and path dependency relationships described in the API dependency graph; a fuzzer is constructed according to the path structure and the combinatorial scheduling model, and the combinatorial scheduling model is used to maximize the coverage of different paths during execution. For example, for pointer parameters, test cases pointing to the same or different memory addresses are constructed to verify the program's behavior under different dependencies. For complex parameter types, such as structures and nested sets, it is verified whether the program correctly handles these complex dependencies. Throughout the analysis process, the legality of each parameter is continuously verified to ensure that they meet type and constraint requirements. By parsing all parameter types and dependencies, we ensure that the final generated test input fully covers the functionality and possible execution paths of all APIs, avoiding the omission of important dependencies. We embed the semantic encoding structure of LibFuzzer into the generated fuzzer, allowing the fuzzer to adjust its testing strategy based on the execution results of different input paths.

[0045] Finally, in box S110, the coverage path is continuously tracked during the execution of the fuzzer, and the unexecuted path is selected for testing first.

[0046] During the fuzzer's operation, the path and context execution coordination strategy module is responsible for selecting new execution paths based on the fuzzer's coverage paths and improving test coverage through optimization strategies. Specifically, after each round of fuzzing, it assesses which code paths have been covered and records the discovery of new test paths. Based on the entropy strategy, paths with higher entropy values ​​are prioritized for testing based on the coverage and information entropy of each path. The entropy strategy is a strategy based on randomness and information gain. Program calls are typically divided into shallow and deep layers. Shallow calls refer to paths in function calls that are easily triggered, while deep logic refers to more complex paths that may involve multiple states or conditional judgments. Through the entropy strategy, path exploration can gradually penetrate the boundaries of shallow calls and enter deep logic. Paths with higher entropy values ​​indicate the existence of more unknown information; these paths may be potential sources of errors, so prioritizing the testing of these paths can improve test effectiveness. In this way, fuzzing path exploration becomes more diversified, effectively covering those hard-to-reach paths.

[0047] Figure 2This is a schematic block diagram of an automatic fuzzer generation apparatus for a shared library according to embodiments of the present disclosure. Figure 2 As shown, the device 200 may include a processor 210 and a memory 220 storing a computer program. When the computer program is executed by the processor 210, the device 200 is made capable of performing actions such as... Figure 1 The steps of the method are shown. In one example, device 200 may be a computer device or a cloud computing node. Device 200 may: extract a set of API functions to be fuzzed from the source code and header files of the target shared library; based on the set of API functions, identify the control flow dependencies and data flow dependencies of the API interfaces and construct an API dependency graph; determine the parameter types and deduce the dependencies between parameters according to the API dependency graph, classifying parameters into independent variable parameters and state-dependent parameters; based on the function calls and dependencies in the API dependency graph, generate an executable fuzzer through combinatorial scheduling, and embed the LibFuzzer semantic encoding structure into the fuzzer; continuously track the coverage path during the execution of the fuzzer, and preferentially select unexecuted paths for testing.

[0048] In embodiments of this disclosure, the device 200 can load and parse the header file of the target shared library, identify all exposed API interfaces, and construct a set of exported functions that can be called externally; perform static analysis on the source code to identify all internal call function sets; calculate the intersection of the exported function set and the call function set, and use the intersection of the two sets as the target API function set for fuzz testing.

[0049] In embodiments of this disclosure, apparatus 200 can convert each function into a compilation unit, which describes the function's interface, parameter types, and return value type information; starting from the entry function, it traverses all basic blocks in the program, collects API calls within each function, identifies which API function calls' execution order depends on conditional statements or loop structures in the program, and establishes control dependencies for these calls; identifies data dependencies by analyzing the flow of variables, parameters, and return values ​​within the function; maps control dependencies and data dependencies to an API dependency graph structure; and, by merging API dependency graphs from multiple different program sources through shared state abstraction, constructs a complete API dependency graph.

[0050] In embodiments of this disclosure, apparatus 200 can examine the transit relationships of state variables in different function calls through static analysis; if multiple functions or paths use the same state variables, these state variables are merged into an API dependency graph, so that the same API interface appears only once, the call relationships between APIs are fully preserved, and the shared state is correctly transmitted and maintained.

[0051] In the embodiments of this disclosure, the device 200 can identify the parameter types of the API and classify them into basic data types, pointer types, structure types, and nested sets. For pointer type parameters, static alias analysis is used to determine whether different pointers point to the same memory location. When the system cannot directly deduce the dependencies between certain pointers or structures, the dependencies between parameters are deduced by replacing complex types with simpler types or data structures. For nested structures or arrays, the nested structure is decomposed into more basic elements and recursively parsed to deduce the dependencies between parameters. Based on the deduced dependencies, the parameters are distinguished into independent variable parameters and state-dependent parameters.

[0052] In embodiments of this disclosure, apparatus 200 can construct a combined scheduling model based on the function calls and path dependencies described in the API dependency graph; construct a fuzzer according to the path structure and the combined scheduling model, the combined scheduling model being used to enable the fuzzer to maximize coverage of different paths during execution; and embed the semantic encoding structure of LibFuzzer into the generated fuzzer, enabling the fuzzer to adjust the testing strategy according to the execution results of different input paths.

[0053] In the embodiments of this disclosure, the device 200 can evaluate which code paths have been covered after each round of fuzz testing and record the discovery of new test paths; based on the entropy strategy, according to the coverage and information entropy of each path, the path with the higher entropy value is preferentially selected for testing.

[0054] In embodiments of this disclosure, processor 210 may be, for example, a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a processor based on a multi-core processor architecture, etc. Memory 220 may be any type of memory implemented using data storage technologies, including but not limited to random access memory, read-only memory, semiconductor-based memory, flash memory, disk storage, etc.

[0055] Furthermore, in embodiments of this disclosure, device 200 may also include input device 230, such as a keyboard, mouse, etc. Additionally, device 200 may also include output device 240, such as a display, etc.

[0056] In other embodiments of this disclosure, a computer-readable storage medium storing a computer program is also provided, wherein the computer program, when executed by a processor, is capable of performing the following functions: Figure 1 The steps of the automatic fuzzer generation method for shared libraries are shown.

[0057] In summary, the automatic fuzzer generation method and apparatus for shared libraries according to embodiments of this disclosure automatically extracts the set of API functions requiring fuzz testing from the source code and header files of the shared library, achieving automated identification and precise selection of test targets and reducing the workload of manual configuration. By deriving the dependencies between parameters based on the API dependency graph and distinguishing parameters into independent variable parameters and state-dependent parameters, the construction of test inputs is further optimized, ensuring that the generated test cases cover a wider range of paths and scenarios. During fuzzer execution, the coverage paths are continuously tracked, and unexecuted paths are prioritized for testing, avoiding path saturation problems during testing, improving test depth and coverage, and ensuring the discovery of more potential vulnerabilities.

[0058] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatuses and methods according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0059] Unless otherwise expressly indicated by the context, the singular form of words used herein and in the appended claims includes the plural form, and vice versa. Thus, when referring to the singular, the plural form of the corresponding term is generally included. Similarly, the terms “comprising” and “including” shall be interpreted as including rather than exclusively. Likewise, the terms “including” and “or” shall be interpreted as including unless such interpretation is expressly prohibited herein. Where the term “example” is used herein, particularly when it follows a set of terms, “example” is merely exemplary and illustrative and should not be considered exclusive or extensive.

[0060] Further aspects and scope of adaptation become apparent from the description provided herein. It should be understood that various aspects of this application may be implemented individually or in combination with one or more other aspects. It should also be understood that the descriptions and specific embodiments herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0061] Several embodiments of this disclosure have been described in detail above. However, it is obvious that those skilled in the art can make various modifications and variations to the embodiments of this disclosure without departing from the spirit and scope of this disclosure. The scope of protection of this disclosure is defined by the appended claims.

Claims

1. A method for automatically generating fuzzers for shared libraries, characterized in that, The method includes: Extract the set of API functions that need to be fuzzed from the source code and header files of the target shared library; Based on the API function set, identify the control flow dependency and data flow dependency of the API interface, and construct the API dependency graph; Based on the API dependency graph, parameter types are determined and dependencies between parameters are deduced. Parameters are categorized into independent variable parameters and state-dependent parameters. This includes: identifying API parameter types, classifying them into basic data types, pointer types, structure types, and nested collections; for pointer type parameters, static alias analysis is used to determine whether different pointers point to the same memory location; when the system cannot directly deduce the dependencies of certain pointers or structures, the dependencies between parameters are deduced by replacing complex types with simpler types or data structures; for nested structures or arrays, the nested structure is decomposed into more basic elements and recursively parsed to deduce the dependencies between parameters; based on the deduced dependencies, parameters are categorized into independent variable parameters and state-dependent parameters. Based on the function calls and dependencies in the API dependency graph, an executable fuzzer is generated through combinatorial scheduling, and the LibFuzzer semantic encoding structure is embedded in the fuzzer; and During the execution of the fuzzer, the coverage path is continuously tracked, and the unexecuted path is selected for testing first.

2. The automatic fuzzer generation method for shared libraries according to claim 1, characterized in that, The set of API functions to be fuzzed, extracted from the source code and header files of the target shared library, includes: Load and parse the header files of the target shared library, identify all exposed API interfaces, and build a set of exported functions that can be called externally; Perform static analysis on the source code to identify all sets of internal function calls; and The intersection of the exported function set and the called function set is calculated, and the intersection of the two sets is used as the target API function set for fuzz testing.

3. The automatic fuzzer generation method for shared libraries according to claim 1, characterized in that, The step of identifying control flow dependencies and data flow dependencies of API interfaces based on the API function set and constructing an API dependency graph includes: Each function is converted into a compilation unit, which describes the function's interface, parameter types, and return value type information; Starting from the entry function, traverse all basic blocks in the program, collect the API calls inside each function, identify which API function calls depend on the conditional statements or loop structures in the program for execution order, and establish control dependencies for these calls; By analyzing the flow of variables, parameters, and return values ​​within a function, data dependencies can be identified. Map the control dependencies and data dependencies to the API dependency graph structure; and By merging API dependency graphs from multiple different program sources through shared state abstraction, a complete API dependency graph is constructed.

4. The automatic fuzzer generation method for shared libraries according to claim 3, characterized in that, The nodes in the API dependency graph represent API functions, and the edges between nodes represent the calling relationships between different APIs. The edges between nodes are divided into control dependency edges that represent the calling order and data dependency edges that represent the data dependencies passed between functions.

5. The automatic fuzzer generation method for shared libraries according to claim 3, characterized in that, The process of merging API dependency graphs from multiple different program sources through shared state abstraction to construct a complete API dependency graph includes: Multiple API dependency subgraphs are constructed from multiple different program sources. By analyzing the parameters and state propagation chains in multiple API call paths, parts with similar state dependency structures are identified. The parts with similar state dependency structures are merged into shared state nodes, and the independent control flow of the paths is preserved to construct a complete API dependency graph.

6. The automatic fuzzer generation method for shared libraries according to claim 1, characterized in that, The process of generating an executable fuzzer through combined scheduling based on the function calls and dependencies in the API dependency graph, and embedding the LibFuzzer semantic encoding structure into the fuzzer, includes: Based on the function call and path dependency relationships described in the API dependency graph, a composite scheduling model is constructed. A fuzzer is constructed based on the path structure and the combined scheduling model, which is used to maximize the coverage of different paths by the fuzzer during execution; and The semantic encoding structure of LibFuzzer is embedded into the generated fuzzer, allowing the fuzzer to adjust the testing strategy based on the execution results of different input paths.

7. The automatic fuzzer generation method for shared libraries according to claim 1, characterized in that, The step of continuously tracking the coverage path during the execution of the fuzzer and prioritizing testing of unexecuted paths includes: After each round of fuzzing, assess which code paths have been covered and record the discovery of new test paths; and Based on the entropy strategy, paths with higher entropy values ​​are prioritized for testing, according to the coverage and information entropy of each path.

8. An automatic fuzzer generation device for shared libraries, characterized in that, The device includes: At least one processor; and At least one memory storing a computer program; When the computer program is executed by the at least one processor, the apparatus performs the steps of the automatic fuzzer generation method for a shared library according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program, characterized in that, The computer program, when executed by a processor, implements the steps of the automatic fuzzer generation method for shared libraries according to any one of claims 1 to 7.

Images