Dynamic library fuzzing method, related devices and computer program product
By generating test cases through a policy network and utilizing multi-dimensional feedback signals for reinforcement learning, the problem of insufficient vulnerability discovery caused by the single seed selection in existing technologies is solved, and more efficient dynamic library fuzzing results are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- IFLYTEK CO LTD
- Filing Date
- 2026-02-28
- Publication Date
- 2026-06-26
AI Technical Summary
Existing dynamic library fuzzing schemes only use code coverage as a guide when selecting seeds, resulting in insufficient vulnerability discovery capabilities and an inability to effectively focus on areas with high vulnerability probability.
A policy network is used to generate test cases based on the state features of a dynamic library and a baseline seed. Multidimensional feedback signals are obtained through instrumentation in the dynamic library, exploration rewards are calculated for reinforcement learning training, and the vulnerability value of the baseline seed is updated based on the vulnerability signal to guide each round of testing.
It improves the vulnerability discovery capabilities of dynamic library fuzzing, optimizes test case generation through policy networks, enhances the focus on high vulnerability probability areas and the diversity of test cases, and increases the likelihood of vulnerability discovery.
Smart Images
Figure CN121765736B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software security testing technology, and more specifically, to a dynamic library fuzzing method, related equipment, and computer program products. Background Technology
[0002] Fuzzing is one of the most effective core technologies in software vulnerability discovery, especially in cold start scenarios where there is not much real data. Fuzzing is used to generalize various robustness data and monitor abnormal program behavior (such as crashes and assertion failures) to discover vulnerabilities.
[0003] Current fuzzing solutions for dynamic libraries such as C / C++ include reinforcement learning-based fuzzing, such as the Q-Learning algorithm, which learns mutation strategies based on historical mutation data and code coverage information. Seed selection uses the UCB (Upper Confidence Bound) algorithm, which relies solely on a single value metric related to code coverage. This fails to guide testing towards areas with "high vulnerability probability," resulting in limited vulnerability discovery capabilities. Summary of the Invention
[0004] In view of the above problems, this application is proposed to provide a dynamic library fuzzing method, related equipment, and computer program products to improve vulnerability discovery capabilities and enhance the effectiveness of dynamic library fuzzing. The specific solution is as follows:
[0005] Firstly, a dynamic library fuzzing method is provided, including:
[0006] Based on the vulnerability value of each seed in the seed library, a benchmark seed for the current round of testing is selected. The seed consists of an API call sequence and the input parameters of each API call in the sequence.
[0007] Using a policy network, based on the state features of the dynamic library and the baseline seed, the action for each step of the current round is generated, and the action includes API calls and parameter mutation strategies.
[0008] The parameter mutation strategy within the current step is used to mutate the input parameters of the API call within the baseline seed. The mutated data and the API call together form the test case for the current step and are then executed.
[0009] After all test cases in the current round have been executed, feedback signals containing exploration signals and vulnerability signals are obtained through dynamic library instrumentation.
[0010] The exploration reward for the current round of the policy network is calculated based on the exploration signal, and the exploration reward is used to train the policy network through reinforcement learning.
[0011] The vulnerability value of the baseline seed is updated based on the vulnerability signal, and the next round of testing is initiated until the set termination conditions are met, and a test report is generated.
[0012] In one possible design, in another implementation of the first aspect of the embodiments of this application, the exploration signal includes code coverage and / or path sparseness, where the path is the code path in the dynamic library covered by the current round of test case execution.
[0013] The vulnerability signals include crashes, anomaly signals, and / or the rarity of the path.
[0014] In one possible design, in another implementation of the first aspect of this application, the process of updating the vulnerability value of the baseline seed based on the vulnerability signal includes:
[0015] Based on the vulnerability signals, determine the number of crashes triggered by the baseline seed in history, determine the number of anomalies of a set type triggered by the baseline seed in history, and determine the average rarity of the triggering path of the baseline seed in history;
[0016] The vulnerability value of the benchmark seed is determined based on the number of crashes triggered in the history of the benchmark seed, the number of exceptions of the specified type triggered in the history of the history of the benchmark seed, and the average rarity of the historical triggering path.
[0017] In one possible design, in another implementation of the first aspect of the embodiments of this application, after obtaining the exploration reward of the policy network in the current round, it further includes:
[0018] Store the complete experience sequence related to the current round of test cases into the experience replay pool. The complete experience sequence includes the state characteristics, actions, and exploration rewards of each step in the execution process of the current round of test cases.
[0019] When the set update timing is reached, batch sampling is performed from the experience replay pool, and the parameters of the policy network are updated asynchronously based on the sampling results.
[0020] In one possible design, in another implementation of the first aspect of the embodiments of this application, after all test cases in the current round have been executed and the feedback signal has been obtained, the following further step is taken:
[0021] The system detects whether a first condition is triggered based on the feedback signal. The first condition includes: discovering a new path, triggering a crash signal, or triggering an abnormal signal of a set type.
[0022] If the first condition is determined to be triggered, the test cases of the current round are added as a seed to the seed library.
[0023] In one possible design, in another implementation of the first aspect of the embodiments of this application, before selecting the benchmark seed for the first round of testing, the following is also included:
[0024] Parse the interface specification of the dynamic library to obtain the interface process knowledge base, which includes API call timing rules;
[0025] The process of generating the action for each step of the current round using a policy network, based on the state features of the dynamic library and the baseline seed, includes:
[0026] Based on the interface process knowledge base and the current state characteristics of the dynamic library, an action mask for the current step is generated. The action mask contains only the current time sequence and the legal API calls for the resources.
[0027] Using a policy network, the action probability distribution for the current step is generated based on the state features of the current step in the dynamic library and the baseline seed.
[0028] Set the probability value of API calls that do not exist in the action mask of the current step in the action probability distribution to 0, and determine the action of the current step based on the processed action probability distribution.
[0029] In one possible design, in another implementation of the first aspect of the embodiments of this application, the process of selecting the benchmark seed for the current round of testing based on the vulnerability value of each seed in the seed bank includes:
[0030] Based on the vulnerability value of each seed in the seed bank and the adjustable temperature parameter, the probability of each seed being selected is determined. The higher the temperature parameter, the more evenly the various seeds in the seed bank are selected. The lower the temperature parameter, the more the seeds with higher vulnerability values are selected. According to the test process, the temperature parameter value in the first test stage is higher than that in the second test stage. The first test stage is earlier than the second test stage.
[0031] Based on the probability of each seed being selected in the seed bank, the seed with the highest probability is selected as the benchmark seed for the current round of testing.
[0032] In one possible design, in another implementation of the first aspect of the embodiments of this application, the state characteristics of the dynamic library include at least one of the following:
[0033] The API call sequence phase describes the runtime lifecycle of a dynamic library.
[0034] A global resource table is used to describe a handle mapping graph that is maintained in real time.
[0035] A multithreaded context is used to describe the active state of each thread.
[0036] The exploration reward for the most recent K rounds, where K is a set constant.
[0037] In a second aspect, an electronic device is provided, comprising: a memory and a processor;
[0038] The memory is used to store programs;
[0039] The processor is configured to execute the program to implement the various steps of the dynamic library fuzzing method described in any of the first aspects of this application.
[0040] Thirdly, a readable storage medium is provided on which a computer program is stored, which, when executed by a processor, implements the various steps of the dynamic library fuzzing method described in any of the first aspects of this application.
[0041] Fourthly, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the steps of the dynamic library fuzzing method described in any of the first aspects of this application.
[0042] Using the above technical solution, this application generates test cases for the current round using a policy network based on the state characteristics of a dynamic library and the baseline seed selected in the current round. After the test cases in the current round are executed, multi-dimensional decoupled feedback signals, including exploration signals and vulnerability signals, are obtained through dynamic library instrumentation. Based on the exploration signals, the exploration reward for the current round of the policy network can be calculated and used for reinforcement learning training of the policy network. At the same time, based on the vulnerability signals, the vulnerability value of the baseline seed can be updated, and the vulnerability value is used to guide the selection of the baseline seed in each round of testing. The policy network of this application can be optimized and trained based on exploration rewards, learning how to generate test cases with better exploration capabilities. At the same time, the vulnerability signals guide the upper-level resource scheduling, i.e., the selection of the baseline seed in each round, so that test resources can be focused on areas with high vulnerability probability. This solves the shortcomings of traditional baseline seed selection strategies that are only guided by code coverage, and improves the vulnerability discovery capability.
[0043] Meanwhile, the policy network of this application is designed with dual output heads. The action generated in each step includes both API calls and parameter mutation strategies. That is, it can generalize the API call order and API input parameters of the baseline seed at the same time, which improves the diversity of the generated test cases and thus increases the possibility of the test cases discovering vulnerabilities. Attached Figure Description
[0044] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:
[0045] Figure 1 A schematic diagram of an implementation system architecture for the dynamic library fuzz testing method provided in this application embodiment;
[0046] Figure 2 This application provides a schematic flowchart of a dynamic library fuzz testing method.
[0047] Figure 3 This is a schematic diagram of another dynamic library fuzzing method provided in an embodiment of this application;
[0048] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0049] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0050] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.
[0051] This application provides a dynamic library fuzzing scheme, which is suitable for robustness testing of dynamic libraries and can be adapted to C / C++ dynamic libraries that support Windows (.dll), Linux (.so) and other platforms.
[0052] This application provides a dynamic library fuzzing method that can be applied to, for example... Figure 1 The system architecture shown may include a terminal 100 and a server 200. The server 200 may include one or more servers (…). Figure 1 (This example uses a server as an illustration).
[0053] Either terminal 100 or server 200 can be used independently to execute the dynamic library fuzzing method provided in the embodiments of this application. Alternatively, terminal 100 and server 200 can also be used collaboratively to execute the dynamic library fuzzing method provided in the embodiments of this application.
[0054] The following description Figure 1 The product form of the mid-terminal 100;
[0055] The terminal 100 in this application embodiment can be a mobile phone, tablet computer, learning machine, wearable device, conference terminal, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc., and this application embodiment does not impose any restrictions on it.
[0056] This application provides a dynamic library fuzz testing method, illustrated by applying the method to a computer device. Specifically, the computer device may be... Figure 1 The system consists of terminal 100 or a combination of terminal 100 and server 200. (Refer to...) Figure 2 The dynamic library fuzzing method specifically includes the following steps:
[0057] Step S100: Based on the vulnerability value of each seed in the seed library, select the benchmark seed for the current round of testing. The seed consists of an API call sequence and the input parameters of each API call in the sequence.
[0058] The seed library contains several seeds, which are high-value benchmark test cases, such as test cases that have triggered crashes, rare paths, or exceptions of a specific type. Seeds include API call sequences and the input parameters for each API call within the sequence. The API call sequence is a sequence of API calls, and each API call contains the parameters required by that API interface, referred to as input parameters.
[0059] Before testing begins, several seeds can be manually created and added to the seed library. During testing, newly discovered high-value test cases can also be added to the seed library as seeds.
[0060] The vulnerability value of a seed is used to characterize its ability to discover vulnerabilities. In this application, a baseline seed for the current round of testing is selected based on the vulnerability value of each seed in the seed library. This allows subsequent steps to generalize the baseline seed to obtain test cases, enabling a focus on high-probability vulnerability areas and improving the vulnerability discovery capability.
[0061] Before the test begins, the vulnerability value of each seed in the seed library can be set to a default value, or the vulnerability value of each seed can be manually set. After the test begins, the vulnerability value of each seed can be continuously updated based on the feedback signals during the test.
[0062] Step S110: Through the policy network, based on the state features of the dynamic library and the baseline seed, generate the action for each step of the current round, the action including API call and parameter mutation strategy.
[0063] Specifically, in this embodiment, multiple rounds of testing can be performed. Each round of testing can include test cases for multiple time steps, and the test cases for multiple steps constitute a round of test cases.
[0064] In this embodiment, a reinforcement learning policy network is pre-configured. The policy network can generate action 'a' for each step based on the state features of the dynamic library being tested and the baseline seed selected in the preceding steps. t t represents the t-th time step. In this embodiment, the policy network is configured with a dual-output header structure; one output header is used to output the API call a for the current time step. api Another output header is used to output the parameter mutation strategy a for the current time step. fuzz a is called by the API api and the corresponding parameter mutation strategy a fuzz The action a is combined into the action at the current time step. t .
[0065] The policy network in this embodiment is designed with dual output heads. Each step of the generated action includes both API calls and parameter mutation strategies. This means that the API call order and API input parameters of the baseline seed can be generalized simultaneously, which improves the diversity of the generated test cases and thus increases the possibility of the test cases discovering vulnerabilities.
[0066] Among them, the state characteristics s of the dynamic library t Including but not limited to the following:
[0067] (1) API call timing phase, which describes the runtime lifecycle of the dynamic library. It can use enumeration values, such as Pre_Init (0), Ready (1), Instance_Active (2), etc.
[0068] (2) Global resource table, used to describe the handle mapping graph maintained in real time. Dynamic libraries often manage objects through instance handles. The following is a partial example of a global resource table: digitized Map <ThreadID,Map<Handle,Status> > (Status: Active(1) / Destroyed(0)). This structure enables the policy network to be aware of the handle lifecycle in a multi-threaded environment.
[0069] (3) Multithreaded context, used to describe the active state of each thread. This application can monitor the "thread pool state" in real time, determine whether each thread is busy or idle, which handles are currently occupied by the thread, etc., and capture the active state of each thread in real time.
[0070] (4) The exploration reward of the most recent K rounds, where K is a set constant.
[0071] The policy network generates actions for the current time step based on the state characteristics of the dynamic library at the current time step, combined with the baseline seed. These actions include API calls and parameter mutation strategies.
[0072] It should be noted that the API calls in the actions generated by the policy network at each time step do not exceed the API calls contained in the baseline seed. For example, the API call sequence corresponding to the baseline seed is API interface 1-API interface 2-API interface 3. Then, when generating the action at each step, the policy network selects from the API calls contained in the baseline seed. For example, the API calls generated by the policy network for each time step in this round are as follows: API interface 2-API interface 3-API interface 1.
[0073] The parameter mutation strategy in the action at each time step is the mutation strategy used when mutating the input parameters of the API call within the action. Table 1 below provides an example of a parameter mutation strategy:
[0074] Table 1
[0075]
[0076] Step S120: Use the parameter mutation strategy within the current step to mutate the input parameters of the API call within the benchmark seed. The mutated data and the API call together form the test cases for the current step and execute them.
[0077] With the current step a t API call within a api and the corresponding parameter mutation strategy a fuzz For example, to obtain the same API call a within the baseline seed. api The input parameters are obtained, and the parameter mutation strategy a is used. fuzzThe input parameter is mutated to obtain mutated data, which is then used in conjunction with the API call a. api Construct the test case for the current step and execute the test case.
[0078] After executing the test cases of the current step, the state characteristics of the dynamic library for the next time step are obtained, and the action of the next time step is generated by the policy network until the generation end condition of the current round is met. For example, the API calls generated in the current round have traversed all API calls in the baseline seed.
[0079] Step S130: After all test cases in the current round have been executed, obtain feedback signals containing exploration signals and vulnerability signals through dynamic library instrumentation.
[0080] This application can perform multi-dimensional instrumentation on the dynamic library under test before testing. Through the instrumented dynamic library, multi-dimensional feedback signals after the execution of the current round of test cases can be obtained, including exploration signals and vulnerability signals.
[0081] The exploration signals can include code coverage and path sparseness. The path refers to the code paths in the dynamic libraries covered by the current round of test case execution. Path sparseness can be calculated based on the historical trigger rate of the path, as shown in the example below.
[0082] The path is hashed to generate a unique path signature H. path Maintain a global hash table to record each H path Total number of times F(H) is triggered path Then the rarity of path p can be expressed as:
[0083] Rarity(p) = 1 / ( F(H) path )+ ε), where ε is the set smoothing factor.
[0084] As can be seen from the above formula, the more times a path history is triggered, the lower the rarity of that path.
[0085] Vulnerability signals can include crashes, abnormal signals, and path rarity.
[0086] This embodiment provides a multi-dimensional stake-insertion method, as follows:
[0087] Code coverage instrumentation: When compiling with Clang, add -fsanitize=coverage and inject branch-level counting instrumentation (such as __sanitizer_cov_trace_pc_indir).
[0088] Signal and exception handling instrumentation: Register signal handlers (to capture crash signals such as SIGSEGV and SIGABRT), and inject try...catch blocks to catch C++ exceptions.
[0089] Memory safety instrumentation: Add AddressSanitizer (ASAN) (-fsanitize=address) to catch memory exceptions.
[0090] Thread-safe instrumentation: Add ThreadSanitizer (TSAN) (-fsanitize=thread) to capture concurrency errors and exceptions such as data races.
[0091] API call tracing instrumentation: Capture API call sequences, parameter values, and return codes through function hooks, and associate them with ThreadID and inst handles.
[0092] Step S140: Calculate the exploration reward for the current round of the policy network based on the exploration signal. The exploration reward is used to train the policy network through reinforcement learning.
[0093] Specifically, after each round of test cases is completed, the exploration reward for the current round of the policy network can be calculated based on the obtained exploration signals. This exploration reward is used to train the policy network through reinforcement learning.
[0094] Specifically, the goal of the policy network is path exploration. Therefore, in this embodiment, the exploration reward for the current round of the policy network is calculated based on the exploration signal, which does not include crash or anomaly signals. By decoupling the exploration signal and the vulnerability signal, the policy network can be prevented from stopping exploration due to "reward hacking," such as obtaining high rewards by repeatedly performing known crashes.
[0095] Exploration rewards can be expressed as the following formula:
[0096] R explore =α·R rarity +β·R corverage .
[0097] Among them, R rarity R represents the reward for rare paths. rarity = Rarity(p), obtained based on the aforementioned path rarity calculation formula. It can be mapped to a set score range, such as 1-10 points.
[0098] R corverage This indicates a new code coverage bonus, such as a bonus of a set number of points for each new code block triggered by the path, for example, +1 point.
[0099] By using the exploration reward calculated in this embodiment to train the policy network through reinforcement learning, the action combinations generated by the policy network can be encouraged to explore rare paths and trigger new code blocks after they become test cases, thereby improving the exploration capability of the test cases and increasing the likelihood of discovering vulnerabilities.
[0100] Step S150: Update the vulnerability value of the baseline seed based on the vulnerability signal, and proceed to the next round of testing until the set termination conditions are met, and generate a test report.
[0101] Among these, vulnerability signals are vulnerability-related signals that are fed back after the execution of the current round of test cases, such as anomalies and crashes. In addition, path rarity can also reflect vulnerabilities to some extent. The rarer the path, the more likely it is to discover hidden and deep vulnerabilities. Therefore, path rarity can also be regarded as a type of vulnerability signal.
[0102] In this step, the vulnerability value of the baseline seed is calculated based on the vulnerability signal, and then the vulnerability value of the baseline seed is updated.
[0103] In some possible implementations, the process of updating the vulnerability value of the baseline seed based on the vulnerability signal may include:
[0104] Based on vulnerability signals, determine the number of crashes triggered by the baseline seed in history, the number of exceptions of the specified type triggered by the baseline seed in history, and the average rarity of the triggering path in the baseline seed in history.
[0105] The vulnerability value of a benchmark seed is determined based on the number of crashes triggered by the benchmark seed in the past, the number of exceptions of the specified type triggered in the past, and the average rarity of the triggering path in the past.
[0106] Among them, the defined exception type can be a pre-defined type that represents a high-value exception, such as a memory exception.
[0107] The vulnerability value Q(s) of the baseline seed s can be expressed as follows:
[0108] Q(s) = W crash ·N crash (s)+ W exception ·N exception (s)+ W rarity ·AvgRarity(s).
[0109] Among them, W crash W exception W rarity Weighting coefficients are used to balance the importance of different signals.
[0110] N crash (s) represents the number of crashes triggered in the history of the baseline seed s;
[0111] N exception (s) represents the number of specified type exceptions triggered in the history of the baseline seed s;
[0112] AvgRarity(s) represents the average rarity of the historical trigger paths of the baseline seed s.
[0113] By calculating the vulnerability value of the benchmark seed using multi-dimensional vulnerability signals, we can more accurately assess the benchmark seed's ability to discover vulnerabilities. Subsequent testing processes can select the next benchmark seed based on the updated vulnerability value, guiding testing to focus on areas with high vulnerability probability.
[0114] The testing process of this application can be executed iteratively for multiple rounds until the set termination condition is met, at which point the testing process ends and a test report is generated.
[0115] The test report can record exceptions and crashes triggered by test cases, as well as the overall code coverage of all test cases, for users to review.
[0116] In this embodiment, there can be multiple termination conditions, for example:
[0117] Reaching the maximum number of test rounds, the longest test duration (e.g., 24 hours), the total number of test cases reaching a threshold, no new crashes, exceptions, or code blocks being found for N consecutive rounds (e.g., 200 rounds), no new rare paths being found for M consecutive rounds (e.g., 300 rounds), and the average rarity score of the paths being lower than a set threshold (e.g., 0.05) indicates that rare path exploration is saturated.
[0118] In some embodiments of this application, an asynchronous policy network update mechanism is described.
[0119] Specifically, after calculating the exploration reward of the strategy network for the current round based on the exploration signal in step S140, the following steps may be further included:
[0120] Store the complete experience sequence related to the current round of test cases into the experience replay pool. The complete experience sequence includes the state characteristics s of each step in the execution process of the current round of test cases. t Action a t And the current round of exploration rewards R explore A complete sequence of experiences related to a round of test cases can be represented as: (R explore , s0, a0, s1, a2, s3, a3...).
[0121] When the set update timing is reached, batch sampling is performed from the experience replay pool, and the parameters of the policy network are updated asynchronously based on the sampling results.
[0122] The update timing can be set at intervals of a certain number of rounds, such as every 128 rounds. Batch sampling is performed based on data collected from the experience replay pool, and the policy network is updated asynchronously. The exploration reward R is used during the update. explore Calculate the cumulative reward and advantage function, and update the parameters of the policy network.
[0123] In this embodiment, an asynchronous policy network update mechanism is adopted. After a sufficient amount of data has been accumulated in the experience replay pool, the policy network is updated. This ensures the stability required for training the policy network gradient algorithm, and the updated policy network can be used in the subsequent testing process in a timely manner, thus ensuring the timeliness of the policy network update.
[0124] In some embodiments of this application, a seed bank update mechanism is further provided. Specifically, after step S130, where all test cases in the current round have been executed and feedback signals have been obtained, the following further step is included:
[0125] The system detects whether the first condition has been triggered based on the feedback signal.
[0126] The first condition includes at least one of the following:
[0127] (1) Discovering new paths;
[0128] (2) Triggering a crash signal;
[0129] (3) Triggering an exception signal of a specified type. The specified type refers to the type of high-value exception, such as memory exceptions.
[0130] If the first condition is triggered, the test case in the current round is considered a high-value test case and can be added to the seed library as a seed.
[0131] In some embodiments of this application, considering that some dynamic libraries have strong constraints on API sequences, meaning that many functions of the dynamic library must be activated through API calls in a specific order (e.g., init() must be called first, then load_data(), and finally process()), an incorrect call order will directly lead to test failures and an excessively high rate of invalid test cases.
[0132] Therefore, this embodiment provides a solution. In this embodiment, the interface specification of the dynamic library can be parsed before the first round of testing to obtain an interface process knowledge base, which includes API call sequence rules.
[0133] The following is an example of a dynamic library interface specification:
[0134] / / Global initialization: Returns 0 for success, non-zero for error code;
[0135] intinit(constchar config_path);
[0136] / / Global destruction: Releases resources allocated by init, with no return value;
[0137] voidfinit();
[0138] / / Create instance: Returns an instance handle (non-NULL is valid), supports multi-threaded parallel creation;
[0139] void createInst(void inst,conststructProcessConfig cfg);
[0140] / / Process data: Input instance handle, data buffer, length, and return processing result code;
[0141] int process(void inst, constchar data_buf,constchar outdata_buf,size_tdata_len);
[0142] / / Destroy the instance: Releases the instance resources created by createInst, with no return value;
[0143] void destroyInst(void inst);
[0144] / / Example of structured parameters;
[0145] structProcessConfig{
[0146] int timeout; / / Timeout duration (1~1000ms)
[0147] boolenable_log; / / Log on / off switch (true / false)
[0148] }
[0149] This application can use the Clang AST parser to traverse dynamic library header files and call examples, extract interface metadata (function signatures, structured parameters), dependencies, and constraint rules, and build an interface process knowledge base.
[0150] API call timing rules can be stored in the form of a directed graph (DAG) in the interface process knowledge base, serving as a dynamic constraint source. This source is used to generate action masks for the policy network in real time during subsequent steps, thereby constraining the exploration space of the policy network.
[0151] Specifically, step S110, which involves generating the action for each step of the current round through the policy network based on the state features of the dynamic library and the baseline seed, includes:
[0152] S1. Based on the interface process knowledge base and the current state characteristics of the dynamic library, generate the action mask for the current step. The action mask only contains the current time sequence and the legal API calls for the resources.
[0153] Action masks indicate which APIs in a dynamic library can be called and which cannot. Uncallable APIs are masked out, guiding the policy network to generate only callable APIs for the next call. For example:
[0154] Call_init(Config) (only allowed in the Pre_Init phase);
[0155] Call_createInst(Cfg) (only allowed in the Ready phase);
[0156] Call_process(Handle, Data) (Allowed only if Instance_Active has an Active handle);
[0157] Call_destroyInst(Handle) (only allowed if Instance_Active has an Active handle).
[0158] S2. Using a policy network, generate the action probability distribution for the current step based on the state features and baseline seeds of the current step in the dynamic library.
[0159] S3. Set the probability value of API calls that do not exist in the action mask of the current step in the action probability distribution to 0, and determine the action of the current step based on the processed action probability distribution.
[0160] Specifically, the action probability distribution of the current step output by the policy network is post-processed using the action mask of the current step. The probability values of API calls that are not present in the action mask are set to 0, thus masking API calls that are invalid in timing or resource. From the processed action probability distribution, the API call with the highest probability value can be selected as the action of the current step.
[0161] In this embodiment, the interface specification of the dynamic library is parsed in advance to obtain an interface flow knowledge base including API call timing rules. At each step of the policy network, when generating an action, an action mask is generated based on the interface flow knowledge base and the current step's state characteristics of the dynamic library. This mask covers API calls with invalid timing or resources. Furthermore, the action mask is used to post-process the action probability distribution of the current step generated by the policy network, ensuring that the final determined API call for the current step is valid and reducing the generation of invalid test cases.
[0162] Optionally, at time t=0, the initial action of the policy network can be forced to be valid by using an action mask (e.g., the action mask at time t=0 contains only Call_init) to ensure that the cold start test is effective.
[0163] Optionally, during a round of test case generation, if the action mask at a certain time step does not contain any API calls, it means that there are no valid APIs available for call at the current time step, and therefore the current round of action generation can be terminated.
[0164] In some embodiments of this application, the aforementioned step S100, which selects the benchmark seed for the current round of testing based on the vulnerability value of each seed in the seed library, is described as an optional implementation.
[0165] In one alternative implementation, the benchmark seed for the current round of testing can be selected from the seeds with higher vulnerability values. For example, the seed with the highest vulnerability value can be selected as the benchmark seed for the current round of testing; alternatively, a seed can be randomly selected from the top K seeds with high vulnerability values as the benchmark seed for the current round of testing.
[0166] Another alternative implementation provides a dynamic annealing mechanism:
[0167] Based on the vulnerability value of each seed in the seed bank and the adjustable temperature parameter τ, the probability P of each seed being selected is determined. The higher the temperature parameter τ, the more evenly the various seeds in the seed bank are selected. The lower the temperature parameter τ, the more the seeds with higher vulnerability values are selected. According to the testing process, the temperature parameter τ is higher in the first testing phase than in the second testing phase, and the first testing phase is earlier than the second testing phase.
[0168] Based on the probability P of each seed being selected in the seed bank, the seed with the highest probability is selected as the benchmark seed for the current round of testing.
[0169] The following example shows each seed s in the seed library. i The formula for the probability of being selected:
[0170]
[0171] The temperature parameter τ is used to control the balance between exploration and exploitation. A high τ value tends to favor random exploration (the probability of each seed being selected is evenly distributed); a low τ value tends to favor exploiting the seed with the highest current vulnerability value.
[0172] A dynamic annealing mechanism is used to dynamically adjust the τ value. In the early stages of testing (as in the previous round), a higher τ value is set to encourage the exploration of diverse seeds. As the testing progresses, the τ value is gradually reduced to focus on the in-depth mining of seeds with high vulnerability value.
[0173] Reference Figure 3 This example illustrates a schematic diagram of a dynamic library fuzzing process.
[0174] The fuzzing process for dynamic libraries can be divided into several stages:
[0175] 1. Pre-processing stage
[0176] During the preprocessing stage, the interface specifications of the dynamic library can be parsed to build an interface process knowledge base.
[0177] Multi-dimensional instrumentation is performed on the dynamic library under test to obtain feedback signals, such as exploration signals and vulnerability signals, during the testing process.
[0178] After the above preprocessing, we can obtain the interface process knowledge base and the instrumented dynamic library under test.
[0179] 2. Upper-level resource scheduling
[0180] During the upper-level resource scheduling phase, the baseline seed for this round can be selected based on the vulnerability value of each seed in the seed library, and the state characteristics of the dynamic library can be constructed as input to the policy network.
[0181] 3. Generation of lower-level actions
[0182] In the lower-level action generation phase, an action mask is generated based on the constructed interface process knowledge base and dynamic library state characteristics. The action mask contains the current time step sequence, valid API calls to resources, and masks invalid API calls.
[0183] The policy network generates actions step-by-step based on the dynamic library's state features and the selected baseline seed. The policy network uses a dual-output head, and the generated actions include API calls and parameter mutation strategies.
[0184] The action probability distribution of the current step in the policy network is masked by the action mask of the current step. Only the probability of the API call that exists in the action mask in the action probability distribution is retained, and the API call with the highest probability value is selected as the API call generated in the current step.
[0185] Test cases are generated and executed based on the API calls and parameter mutation strategies generated in the current step. Specifically, the parameter mutation strategy of the current step is used to mutate the input parameters of the API calls of the current step in the benchmark seed, resulting in mutated data. The mutated data and the API calls of the current step are then combined to form the test cases for the current step.
[0186] 4. Collect feedback
[0187] After all test cases have been executed, multi-dimensional feedback signals, including exploration signals and vulnerability signals, can be collected through instrumentation.
[0188] The exploration signals can include code coverage and path rarity. Vulnerability signals can include vulnerabilities and anomaly signals. Furthermore, path rarity can also be included.
[0189] 5. Decoupling feedback closed loop
[0190] Based on the exploration signals collected in the previous stage, the exploration reward is calculated. For details, please refer to the relevant introduction above. The complete experience sequence related to the current round of test cases is stored in the experience replay pool. The complete experience sequence includes the state characteristics, actions, and exploration reward of each step in the execution process of the current round of test cases.
[0191] When the set update timing is reached, asynchronous batch sampling can be performed from the experience replay pool to update the parameters of the policy network. The updated policy network can then be used for subsequent testing.
[0192] Furthermore, the vulnerability value of the baseline seed for this round of testing is updated based on the vulnerability signals collected in the previous stage. The calculation process for the vulnerability value of the baseline seed can be found in the previous section and will not be repeated here. In the next round of selecting the baseline seed, it can be chosen based on the latest vulnerability values of various seeds in the seed database.
[0193] 6. Termination Judgment
[0194] This application allows setting termination criteria for the test. For example, based on the multidimensional feedback signals obtained during the feedback collection phase, it can determine whether the termination criteria are met.
[0195] No new crashes, exceptions, or code blocks were found in N consecutive rounds (e.g., 200 rounds);
[0196] If no new rare branches are found for M consecutive rounds (e.g., 300 rounds) and the average rarity score of the path is below the threshold (e.g., 0.05), it indicates that the exploration of rare paths is saturated.
[0197] The preset test duration (e.g., 24 hours) or the total number of test cases reaches the threshold.
[0198] If the termination conditions are not met, the test can return to the upper-level resource scheduling phase and continue to the next round of testing; if the termination conditions are met, the test ends and a test report is generated.
[0199] This application also provides an electronic device in its embodiments. (See reference...) Figure 4 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, tablet computers, learning machines, personal computers, etc. Figure 4 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0200] like Figure 4 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 1, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 2 or a program loaded from a storage device 8 into a random access memory (RAM) 3, to implement the dynamic library fuzzing method of the foregoing embodiments of this application. When the electronic device is powered on, the RAM 3 also stores various programs and data required for the operation of the electronic device. The processing unit 1, ROM 2, and RAM 3 are interconnected via a bus 4. An input / output (I / O) interface 5 is also connected to the bus 4.
[0201] Typically, the following devices can be connected to I / O interface 5: input devices 6 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 7 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 8 including, for example, memory cards, hard drives, etc.; and communication devices 9. Communication device 9 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.
[0202] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the dynamic library fuzzing methods provided in this application.
[0203] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the dynamic library fuzzing methods provided in this application.
[0204] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.
[0205] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0206] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.
[0207] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).
[0208] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.
Claims
1. A fuzz testing method for dynamic libraries, characterized in that, include: Based on the vulnerability value of each seed in the seed library, a benchmark seed for the current round of testing is selected. The seed consists of an API call sequence and the input parameters of each API call in the sequence. The vulnerability value characterizes the seed's ability to discover vulnerabilities. Using a policy network, based on the state features of the dynamic library and the baseline seed, the action for each step of the current round is generated, and the action includes API calls and parameter mutation strategies. The parameter mutation strategy within the current step is used to mutate the input parameters of the API call within the baseline seed. The mutated data and the API call together form the test case for the current step and are then executed. After all test cases in the current round have been executed, feedback signals containing exploration signals and vulnerability signals are obtained through dynamic library instrumentation. The exploration signals include code coverage and / or path rarity, where the path is the code path in the dynamic library covered during the execution of the current round of test cases. The vulnerability signals include crash, exception signals, and / or the path rarity. The exploration reward for the current round of the policy network is calculated based on the exploration signal, and the exploration reward is used to train the policy network through reinforcement learning. The vulnerability value of the baseline seed is updated based on the vulnerability signal, and the next round of testing is initiated until the set termination conditions are met, and a test report is generated.
2. The method according to claim 1, characterized in that, The process of updating the vulnerability value of the baseline seed based on the vulnerability signal includes: Based on the vulnerability signals, determine the number of crashes triggered by the baseline seed in history, determine the number of anomalies of a set type triggered by the baseline seed in history, and determine the average rarity of the triggering path of the baseline seed in history; The vulnerability value of the benchmark seed is determined based on the number of crashes triggered in the history of the benchmark seed, the number of exceptions of the specified type triggered in the history of the history of the benchmark seed, and the average rarity of the historical triggering path.
3. The method according to claim 1, characterized in that, After obtaining the exploration reward for the current round of the policy network, the following is also included: Store the complete experience sequence related to the current round of test cases into the experience replay pool. The complete experience sequence includes the state characteristics, actions, and exploration rewards of each step in the execution process of the current round of test cases. When the set update timing is reached, batch sampling is performed from the experience replay pool, and the parameters of the policy network are updated asynchronously based on the sampling results.
4. The method according to claim 1, characterized in that, After all test cases in the current round have been executed and the feedback signal has been obtained, the process also includes: The system detects whether a first condition is triggered based on the feedback signal. The first condition includes: discovering a new path, triggering a crash signal, or triggering an abnormal signal of a set type. If the first condition is determined to be triggered, the test cases of the current round are added as a seed to the seed library.
5. The method according to claim 1, characterized in that, Before selecting the baseline seed for the first round of testing, the following steps are also included: Parse the interface specification of the dynamic library to obtain the interface process knowledge base, which includes API call timing rules; The process of generating the action for each step of the current round using a policy network, based on the state features of the dynamic library and the baseline seed, includes: Based on the interface process knowledge base and the current state characteristics of the dynamic library, an action mask for the current step is generated. The action mask contains only the current time sequence and the legal API calls for the resources. Using a policy network, the action probability distribution for the current step is generated based on the state features of the current step in the dynamic library and the baseline seed. Set the probability value of API calls that do not exist in the action mask of the current step in the action probability distribution to 0, and determine the action of the current step based on the processed action probability distribution.
6. The method according to claim 1, characterized in that, The process of selecting the benchmark seed for the current round of testing based on the vulnerability value of each seed in the seed bank includes: Based on the vulnerability value of each seed in the seed bank and the adjustable temperature parameter, the probability of each seed being selected is determined. The higher the temperature parameter, the more evenly the various seeds in the seed bank are selected. The lower the temperature parameter, the more the seeds with higher vulnerability values are selected. According to the test process, the temperature parameter value in the first test stage is higher than that in the second test stage. The first test stage is earlier than the second test stage. Based on the probability of each seed being selected in the seed bank, the seed with the highest probability is selected as the benchmark seed for the current round of testing.
7. The method according to any one of claims 1-6, characterized in that, The state characteristics of a dynamic library include at least one of the following: The API call sequence phase describes the runtime lifecycle of a dynamic library. A global resource table is used to describe a handle mapping graph that is maintained in real time. A multithreaded context is used to describe the active state of each thread. The exploration reward for the most recent K rounds, where K is a set constant.
8. An electronic device, characterized in that, include: Memory and processor; The memory is used to store programs; The processor is used to execute the program to implement each step of the dynamic library fuzzing method as described in any one of claims 1 to 7.
9. A readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements each step of the dynamic library fuzzing method as described in any one of claims 1 to 7.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the dynamic library fuzzing method as described in any one of claims 1 to 7.