Smart contract vulnerability detection method based on utility adjustment strategy

Abstract

The present invention discloses a smart contract fuzz testing method and system based on utility adjustment strategy. First, the fuzz testing system pre-processes the smart contract to be tested, obtains the structural information and branch information related to each function in the contract, randomly generates initial test cases and equally distributes them to the branch coverage test case pool and data dependency test case pool generated by the fuzzer; then, the fuzz testing system optimizes and iterates the test cases contained in each test case pool according to its own test case optimization strategy in different test case pools; finally, the fuzz testing system executes the test cases in different test case pools respectively, analyzes the bytecode execution logic and reports vulnerabilities, calculates the utility values ​​of different test case pools after execution, and redistributes the number of test cases in the test case pool. The present invention effectively improves the test efficiency of smart contract fuzz testing, can explore more branches in the tested smart contract, and can find more contract vulnerabilities.

Description

Technical Field

[0001] The present invention belongs to the technical field of smart contract security vulnerability detection, and specifically relates to a smart contract vulnerability detection method and system based on utility adjustment strategy. Background Art

[0002] Smart contracts are Turing-complete programs executed on blockchain infrastructure. Unlike traditional programs, once deployed, smart contracts cannot be patched for exposed vulnerabilities. As a means of detecting smart contract vulnerabilities, smart contract fuzz testing has the advantages of automation and high detection accuracy.

[0003] The open source tools and patents related to smart contract vulnerability detection based on fuzz testing are as follows:

[0004] ContractFuzzer is the first tool to introduce fuzz testing technology into smart contract vulnerability detection. It generates smart contract fuzz testing input through the contract's ABI file and detects vulnerability issues through an oracle. The sFuzz tool considers how to break through complex branches in smart contracts and proposes a fuzz testing method based on distance measurement. SMARTIAN generates more effective transaction sequences by combining static and dynamic methods, and analyzes smart contract vulnerabilities through the fuzzy execution stage. ConFuzzius is a hybrid fuzz testing tool. When the fuzzer does not make progress, it will turn on the symbolic executor to solve the valid parameters.

[0005] CN115794625A proposes a fuzzy testing method based on a genetic algorithm, which generates new test cases for fuzzification by continuously selecting, crossing over and mutating a population containing test cases.

[0006] CN115659358A mutates each transaction sequence to be tested and its function parameters through a specific mutation method to generate executable test cases. CN115455435A uses the coverage information during the test case execution process to guide the generation of subsequent test cases. CN114840857A adopts a multi-level coverage strategy to guide the iteration process of test cases by whether new coverage features appear in the test cases.

[0007] However, the above-mentioned smart contract fuzz testing tools and patents all adopt a single test case optimization strategy, and do not consider dynamically adjusting the detection strategy according to the operation process of the smart contract, and are unable to perform targeted vulnerability detection on the current smart contract. As a result, fuzzy resources will be wasted in the normal test case execution process, thereby reducing the efficiency of fuzz testing in current smart contract vulnerability detection. In response to the above problems, the present invention proposes a smart contract fuzz testing method and system based on a utility adjustment strategy, which is characterized in that: there are multiple test case optimization schemes in the fuzzy system, and during the fuzzy execution process, different test cases have different vulnerability detection capabilities, so that more fuzzer resources are allocated to the test case optimization scheme that is more suitable for detecting the current smart contract vulnerabilities. Summary of the invention

[0008] Existing smart contract fuzz testing tools and patents all adopt a single test case optimization strategy, and do not consider dynamically adjusting the detection strategy according to the operation process of the smart contract, and are unable to perform targeted vulnerability detection on the current smart contract. As a result, fuzzy resources will be wasted in the normal test case execution process, thereby reducing the efficiency of fuzz testing in current smart contract vulnerability detection. In response to the above problems, the present invention proposes a smart contract fuzz testing method based on a utility adjustment strategy, which mainly includes three stages: preprocessing stage, optimization processing stage and execution analysis stage. First, the fuzz testing system pre-processes the smart contract to be tested, obtains the dependency information between each function and state variable in the contract and the branch information contained in each function, and the fuzzer randomly generates initial test cases by analyzing the ABI file compiled from the contract and equally distributes them to the branch coverage test case pool and data dependency test case pool generated by the fuzzer; then, the fuzz testing system optimizes and iterates the test cases contained in each test case pool according to its own test case optimization strategy in different test case pools; finally, the fuzz testing system executes the test cases in different test case pools respectively, analyzes their bytecode execution logic and reports vulnerabilities. After the execution, the fuzzer calculates the utility values ​​of different test case pools and reallocates the number of test cases in each test case pool.

[0009] 1. Pretreatment stage of the present invention

[0010] First, perform static analysis on the smart contract and obtain the ABI file of the smart contract. Use the Slither tool to convert the ABI file into Slither's intermediate representation (IR), namely Slither IR. Then use the data collection API in the Slither tool on Slither IR to collect the dependency information between functions and contract state variables, branch information contained in functions, etc.

[0011] Secondly, the solc tool is used to extract the public function signatures according to the ABI file, build a function selector mapping table, and cyclically select available functions to encode as initial test cases.

[0012] Finally, the fuzzer creates a branch coverage test case pool and a data dependency test case pool and distributes the initial test cases equally to the two test case pools.

[0013] 1.1 Static Analysis

[0014] 1.1.1ABI file generation

[0015] The fuzz testing system will compile the user-given smart contract into an Application Binary Interface (ABI) file, and convert the ABI file into the Slither IR intermediate representation through the Slither tool;

[0016] 1.1.2 Obtaining contract information

[0017] The fuzz testing system calls the Slither tool-related API on the Slither IR to collect three types of information in the contract and use it to guide the subsequent test case optimization process;

[0018] The three types of information collected include: function and state variable information defined by the function (F:S define ); function and the state variable information used by the function (F:S use ); function and its branch coverage data information (F∶B); where F represents the function in the contract, S define Represents the state variable defined in the function, S use Represents the state variables used in the function, and B represents the function branch coverage information.

[0019] 1.1.3 Available functions to obtain

[0020] The fuzz testing system is based on the ABI file in JSON format and uses the solc tool to extract the signatures of all public functions declared in the ABI. The system uses the first four bytes of the hash value to calculate the selector m of the function signature. l, where 0≤l≤max, max is the maximum number of available functions in the entire contract. And use this selector to build a mapping M. In the mapping M, each function selector corresponds to a tuple consisting of the function name and function input parameter information. For example, if the function name is "transfer" and the function input parameter is "address to,uint256 value", the tuple is ("transfer", ["address", "uint256"]), and the mapping M associates all function selectors with their corresponding tuples so that subsequent fuzz testing can randomly call all public functions. At the same time, the system will automatically filter out functions in the ABI file that will not change the contract state, such as view functions and pure functions, to ensure that fuzz testing is only performed on functions that will change the contract state.

[0021] 1.1.4 Branch Coverage Information Sorting

[0022] For the (F:B) information obtained in 1.1.2, the (F:B) information is arranged in descending order according to the principle of sequential arrangement, where the lowest branch coverage function is F min , the highest branch covering function is F max In particular, the coverage of each function branch is 0 at the beginning. After each test case is executed, the (F:B) information is updated and reordered.

[0023] 1.1.5 User Configuration Acquisition

[0024] The system reads user input and saves the following configuration information.

[0025] 1.2 Test case pool initialization

[0026] 1.2.1 Test case pool generation

[0027] The system first generates two sets of test cases of length c in memory, which store the encoded test cases. The two sets are initially defined as branch coverage test case pools Data dependency test case pool in Represents the i-th test case in the j-th test case pool, and i=c, j=(1,2). When j=1, it represents the test case in the branch coverage test case pool, and when j=2, it represents the test case in the data dependency test case pool.

[0028] 1.2.2 Value calculation formula registration

[0029] The system will cover the test case pool P for the branch branch and data-dependent test case pool P dataRegister different value calculation formulas, which are used to quantify the value of the current test case and are used in the subsequent test case replacement process.

[0030] 1.2.2.1 Registration of the value of the branch coverage test case pool: For the value of the test case Val_b in the branch coverage test case pool, the judgment formula is shown in formula (1-1):

[0031]

[0032] Where Val_b(T i 1 ) represents the branch coverage test case pool P branch The value of the i-th test case in newBranch(T i 1 ) is the test case T i 1 The number of newly found branches, that is, the number of branches that trigger jumps; totalFindBranch(T i 1 ) is the current test case T i 1 The total number of branches found; tatalBranch(T i 1 ) is the test case T i 1 The total number of branches owned.

[0033] 1.2.2.2 Data-dependent test case pool value registration: For the value of the test case Val_d in the data-dependent test case pool, the judgment formula is shown in formula (1-2):

[0034]

[0035] in Represents the data-dependent test case pool P data The value of the i-th test case in; For the current test case The number of newly discovered branches; Represents the current test case The number of read-write pairs of each state variable in, that is, the number of times a state variable is defined and then used.

[0036] 1.2.3 Utility Value Initialization

[0037] Test case pool P branch and P data Initially, a utility value of 0 is assigned, which is dynamically adjusted during the execution phase and used for P branchand P data The process of redistributing the number of test cases.

[0038] 1.3 Test case initialization

[0039] 1.3.1 Function selection

[0040] The system will select the function selectors in the M mapping table built by 1.1.3 in a circular order. For each selected function selector, the system will obtain the corresponding function name and function input parameter type in the M mapping table, and use this information to build a test case. The system will continue to select functions and build test cases until the number of selected functions equals the user configuration information c, and the system process ends.

[0041] 1.3.2 Function Input Parameter Generation

[0042] The system obtains the function name and function input parameters selected in 1.3.1, and constructs actual parameters of the same type as the function input parameters by random generation. At the same time, the fuzz testing system randomly generates environmental information parameters, including block number, timestamp and block difficulty.

[0043] 1.3.3 Test case construction

[0044] The ConFuzzius tool is used to encode the test cases. The function parameter information selected in 1.3.2 and the environment information are encoded into a transaction tx. At the same time, the extended encoding field θ is used to record the parameters that have mutated during the fuzzy execution process.

[0045] The present invention performs each test case The formal description is as follows:

[0046]

[0047] Test Cases is the i-th test case in the j-th test case pool, which is a series of transactions tx k The maximum value of k is obtained from the user configuration. The default value is 8, which means that the maximum length of the test case is limited to 8 transactions. When the test case is initialized, k = 1.

[0048] The present invention performs each transaction tx k The formal description is as follows:

[0049] tx k =(δ,ε,θ) k

[0050] Transaction tx kIt is a triple consisting of environmental information δ, parameter information ε, and additional information θ. Triple (δ, ε, θ) k Represents the kth transaction tx k .

[0051] The formal description of the environmental information δ in the present invention is as follows:

[0052] δ=(b,t,d)

[0053] The environmental information δ consists of three parts, where b is the block number, t is the timestamp, and d is the block difficulty.

[0054] The formal description of parameter information ε in the present invention is as follows:

[0055] ε=(f,gl)

[0056] The parameter information ε consists of two parts, one is the function-related information f, and the other is the minimum limit gl for gas consumption.

[0057] The formal description of the function-related information f in the present invention is as follows:

[0058] f∈(m1(p1,p2,...p m ),m2(p1,p2,...p m ),...,m l (p1,p2,...p m ))

[0059] The function related information f mainly includes two parts, one of which is the function selector m l , where 0≤l≤max, where max is the maximum number of available functions in the entire contract. The second is the function input parameter p m , m represents the maximum number of input parameters of the current function, where 0≤m.

[0060] The formal description of the additional information θ in the present invention is as follows:

[0061]

[0062] The additional information θ is the key to mutating the guiding parameters of the present invention in order to facilitate fuzz testing. θ stores the parameters mutated in the previous round, so it is a subset of the function parameters.

[0063] 1.3.4 Initial Test Case Allocation

[0064] All test cases generated during initialization in 1.3.3 will be equally assigned to the branch coverage test case pool P branch and data-dependent test case pool P dataIn, it is used for subsequent fuzzer optimization according to different optimization strategies.

[0065] 2. Optimization Processing Phase of the Present Invention

[0066] 2.1 Test case selection

[0067] The system will traverse the test case pool P in parallel branch and P data and obtain the test cases in it

[0068] 2.2 Selection of Transactions to be mutated

[0069] System traversal test cases All transactions in tx k And determine whether to mutate the current transaction parameters with a probability of P, which includes parameter information ε and environmental information δ.

[0070] 2.3 Parameter Information Mutation

[0071] Test case pool P branch and P data The same parameter information mutation scheme is adopted: the parameter part in the function information f is mutated.

[0072] Breadth mutation: The system will obtain the function parameter information (p i ,p j ,…,p k ), and no longer mutate parameters in the current parameter mutation phase (p i ,p j ,…,p k ), and randomly select the remaining parameters (p q ,p p ,…,p m ) are randomly mutated.

[0073] Deep mutation: The system will obtain the function parameter information (p i ,p j ,…,p k ), and continue to mutate parameters in the current parameter mutation phase (p i ,p j ,…,p k ).

[0074] Completely random mutation: the system will randomly select (p1, p2, ... p m ) to perform random mutation on one or more parameters.

[0075] 2.3.1θ Information Acquisition

[0076] The fuzz testing system obtains the θ information in the current transaction tx.

[0077] 2.3.2 Mutation method selection

[0078] The system will determine whether the current θ information is None. If it is None, the γ mutation method will be selected. Otherwise, the fuzzy test system will randomly select one of the three mutation methods to mutate the parameters.

[0079] 2.3.3 Mutation Execution

[0080] After the system determines the mutation method, it will select the parameters to be mutated. For the α mutation direction, the fuzz test system will mutate the parameters contained in the current transaction θ information again, and mutate the parameters through the bit flipping, byte flipping and other methods provided by the sFuzz tool. For the β mutation direction, the fuzz test system will mutate the remaining parameters except the current transaction θ information, and mutate the parameters through the bit flipping, byte flipping and other methods provided by the sFuzz tool, and finally update the θ information to the mutated parameters.

[0081] 2.4 Sudden changes in environmental information

[0082] The fuzz testing system will generate new environment information parameters through operations such as bit flipping and byte flipping.

[0083] 2.5 Transaction sequence optimization

[0084] 2.5.1 Branch Coverage Test Case Pool Transaction Sequence Optimization

[0085] The system will cover the test case pool P from the branch branch Recursively extract test case T i 1 , and optimize the transaction sequence in the test case until all test cases in the current test case pool complete the optimization process and end the current stage.

[0086] 2.5.1.1 Obtaining high branch coverage functions: The system will perform transaction-level scanning on the test cases obtained in 2.5.1 and obtain the function selector m in each transaction tx i , the branch coverage rate corresponding to the current function is recorded through the (F∶B) information collected in stage 1.1. The system will compare all branch coverage rates and obtain the current test case T through the M mapping table. i 1 The function F with the highest branch coverage in b-max .

[0087] 2.5.1.2 Test case optimization: For the branch coverage test case pool, the system will randomly select one of the three optimization methods:

[0088] First, select the low branch coverage function F based on the (F:B) information collected in Section 1.1.2 min Encoded as a transaction and appended to the current test case T i 1 Random positions in ;

[0089] Second, delete the current test case T i 1 The function F with the highest branch coverage in b-max The corresponding transaction;

[0090] Third, replace the test case T i 1 The highest branch cover function F b-max The corresponding transaction is the low branch coverage function F min Encoded transactions

[0091] 2.5.1.3 Temporary storage of new test cases: New test cases generated in stage 2.5.1.2 Will be temporarily stored in P ranch Waiting After execution, calculate its value and decide whether to perform test case coverage.

[0092] 2.5.2 Data Dependency Test Case Pool Transaction Sequence Optimization

[0093] The fuzzer will select from the data-dependent test case pool P data Extract test cases The transaction sequence in this test case is optimized. During the optimization process, the two types of information (F∶S define ) and (F:S use ) for guidance.

[0094] 2.5.2.1 Test Case Optimization For the data-dependent test case pool, the system will randomly select one of the three optimization methods:

[0095] First: Add a data-dependent transaction and randomly select test cases A transaction in tx λ , through (F:S define ) Information to find transaction tx λ The state variables defined by the corresponding function are then passed through (F:S use ) information to find the function that uses the state variable and use it as a transaction (transaction tx μ )Add to transaction tx λ Afterwards, if there is no transaction tx μ Then randomly select a function as a transaction tx vAppend to transaction tx λ After that, the process of adding the transaction sequence of the test case is completed;

[0096] Second: Randomly delete the current test case A transaction in

[0097] Third: Randomly replace the current test case A transaction in is a transaction of other functions. The fuzzer will wait for possible selection of the function selector in the M mapping table and obtain the corresponding function and then encode it into a transaction, ultimately ensuring that the length of the test case is not less than 1.

[0098] 2.5.2.2 Temporary storage of new test cases: New test cases generated through stage 2.5.2.1 It will be temporarily stored in P data Waiting After execution, calculate its value and decide whether to perform test case coverage.

[0099] 3. Execution Analysis Phase of the Present Invention

[0100] First, the fuzzer executes the test case and determines whether a vulnerability is triggered based on the bytecode path and state variable data flow during its execution; second, when all test case pools are executed, the system calculates the utility value of each test case pool based on information such as execution time, branch jump frequency, number of vulnerabilities found, and the degree of difference between test cases; finally, by comparing the utility values ​​of different test case pools, the number of test cases is redistributed, and the test cases in the low utility value test case pool are randomly transferred to the high utility value test case pool according to the redistribution number calculation formula.

[0101] 3.1 Vulnerability Detection

[0102] 3.1.1 Test Case Execution

[0103] The system will use the execution module of the ConFuzzius tool to execute the optimized test cases Simulation execution is performed through Py-EVM, where j=1 represents the branch coverage test case pool P branch , j = 2 represents the data dependent test case pool P data . And get the number of new branches found in the current test case during execution The total number of branches found by the test case The number of all branches included in the test case The number of read and write pairs of state variables in the test case Number of vulnerabilities discovered Branch jump frequency and execution time wait.

[0104] In particular, the fuzzer will record the number of JumpI, Jump and other bytecodes triggered by each test case in the current test case pool during execution as the branch jump frequency

[0105] 3.1.2 Value Calculation

[0106] The system calculates the current test case based on the value calculation formula registered in the current test case pool and the test case execution information obtained in 3.1.1. The value of .

[0107] 3.1.3 Test case replacement

[0108] The system is based on the test cases calculated in 3.1.2 The value of the original test case The value of is compared, specifically:

[0109] For the branch coverage test case pool P branch Test case T in i 1 The value of is Val_b(T i 1 ), test case The value of like Then replace the current test case pool P branch T i 1 The test case is Test case, otherwise Remove from the test case pool.

[0110] For the data-dependent test case pool P data Test cases in The value of Test Cases The value of like Then replace the current test case pool P data In The test case is Test case, otherwise Remove from the test case pool.

[0111] In particular, the initially generated test cases only calculate their value during execution and do not participate in the test case replacement process.

[0112] 3.1.4 Vulnerability Report

[0113] The system executes each test case in turn and analyzes the bytecode path and data flow during the execution process, and determines whether the current test case triggers a certain vulnerability through the vulnerability oracle constructed by the present invention. Specifically, the fuzzer will determine the dependency between bytecodes by analyzing the execution information of the current test case. The fuzzer analyzes this dependency to learn the execution process of the current test case and use it for vulnerability type judgment, and at the same time updates the (F∶B) information in Section 1.1.2 according to the degree of improvement of the function branch during the execution process.

[0114] 3.2 Test case pool utility value adjustment

[0115] In this stage, the fuzzer performs a test case pool P branch and P data The utility value is calculated, and the utility of the current test case pool is calculated through the utility value calculation formula according to the number of vulnerabilities, branch jump information and difference information generated by each test case in the test case pool during execution, and the result value is used in the test case reallocation process.

[0116] 3.2.1 Calculation of the overall execution time of the test case pool

[0117] For the test case pool P branch :The system accumulates the time t(T) consumed by each test case in the current test case pool during execution i 1 ) and calculate the final test case pool execution time t 1 .

[0118] For the test case pool P data : The system accumulates the time consumed by each test case in the current test case pool during execution And calculate the final test case pool execution time t 2 .

[0119] 3.2.2 Calculation of the number of vulnerabilities

[0120] For the test case pool P branch :The system accumulates the number of vulnerabilities found in each test case in the current test case pool during execution (T i 1 ) and calculate the total number of vulnerabilities found in the final test case pool b 1 .

[0121] For the test case pool P data : The system accumulates the number of vulnerabilities found during the execution of each test case in the current test case pool And calculate the final test case pool execution time b 2 .

[0122] 3.2.3 Branch jump frequency calculation:

[0123] For the test case pool P branch :The system accumulates the branch jump frequency b(T i 1 ) and calculate the total vulnerability jump frequency b of the final test case pool 1 .

[0124] For the test case pool P data : The system accumulates the branch jump frequency of each test case in the current test case pool during execution And calculate the total vulnerability jump frequency b of the final test case pool 2 .

[0125] 3.2.4 Test case pool difference calculation

[0126] For the test case pool P branch and P data The difference of test cases in j The calculation formula is as follows (3-2):

[0127]

[0128] where d j is the difference between different test case pools. When j=1, d 1 Cover the test case pool P for the branch branch The test case difference, when j = 2, d 2 For the data dependency test case pool P data The test case difference. n represents the number of test cases in the current test case pool. It represents the benchmark test case for calculating the difference between test cases. A test case in the current test case pool is selected as the benchmark test case by random selection. Representative Other test cases, Representative test case and The Jaccard coefficient between .

[0129] The Jaccard similarity coefficient calculation formula is as follows:

[0130]

[0131] The present invention defines, Represents the intersection of the transaction functions between two test cases, The union of transaction functions between representative test cases. Therefore, the greater the difference between test cases in the test case pool, the larger the value of d, where the value range of d is: 0≤d≤1;

[0132] In order to ensure the speed and efficiency of test case execution, the default option is to enable the test case utility value adjustment function every s seconds.

[0133] 3.2.5 Utility value calculation

[0134] The utility value of the current test case pool is calculated according to the utility formula based on the weight information configured by the user in 1.2.1 and the information counted by the system in 3.2.1-3.2.4. The utility formula defined in the present invention is as follows:

[0135]

[0136] In the utility formula, when j = 1, it is the branch coverage test case pool P branch The utility value of is, when j = 2, it is the data-dependent test case pool P data The utility value of Utilityj. Utilityj contains 9 parameters, namely:

[0137] (1) w1: The weight parameter of the time factor. As time goes by, the utility of the test case will gradually decrease. w1 controls the intensity of this utility factor.

[0138] (2) w2: exponential parameter of the time factor. The larger the exponent, the faster the utility decreases as time goes by.

[0139] (3) t: The execution time of the current test case pool, which is used to indicate the actual time that the fuzzer executes the current test case pool. The basic unit is seconds. The shorter the time, the higher the utility. As the execution time of the current test case pool increases, the utility value gradually tends to be flat. It is precisely because the number of test cases in each test case pool may be different and the execution time of the test cases may be different, that the time utility factors of different test case pools are different.

[0140] (4) w3: Branch jump frequency weight parameter. The higher the overall branch jump number in the test case pool, the higher the utility of the test case. w3 controls the strength of this utility factor.

[0141] (5) b: Branch jump frequency, indicating the total number of branch jumps in the current test case pool.

[0142] (6) w4: vulnerability discovery weight parameter. The more vulnerabilities discovered, the higher the utility of the test case pool. w4 controls the strength of this utility factor.

[0143] (7) v: number of vulnerabilities found, which indicates the total number of vulnerabilities found during the execution of each test case in the current test case pool.

[0144] (8) w5: test case pool difference weight parameter. The greater the difference, the higher the utility of the test case pool. w5 controls the intensity of this utility.

[0145] (9) d: Difference, which indicates the difference between the test cases in the current test case pool.

[0146] 3.2.6 Utility Value Update

[0147] The system will update the utility value of the current test case pool to the utility value calculated in 3.2.5 and use it for comparison operations in the test case number reallocation phase.

[0148] 3.3 Test Case Number Redistribution

[0149] This stage is the processing stage after each test case pool is executed. In this stage, two test case pools may have different utility values. In this stage, the number of test cases in the test case pool with high utility value will be increased, and the number of test cases in the test case pool with low utility value will be reduced. In order to achieve more allocation of fuzzy resources to valuable test case pools. After this stage, the utility value of each test case pool is reset to the initial value.

[0150] 3.3.1 Calculation of the number of redistributions

[0151] The system determines the number of reallocations based on the utility values ​​of different test case pools calculated in 3.2.6 and the reallocation number calculation formula, where the reallocation number calculation formula is as shown in formula (3-4):

[0152]

[0153] Where count represents the number of test cases reallocated in the current phase, Utility 1 Utility 2 are the utility values ​​in the two test case pools. The idea of ​​redistribution is to transfer the test cases in the low utility value test case pool to the high utility value test case pool. m and n represent the range of the number of redistributions each time, where m ≥ n. Users can configure the values ​​of m and n in a customized way.

[0154] 3.3.2 Redistributing Test Case Selection

[0155] After the system has redistributed the number of cases determined in 3.3.1, it randomly selects count test cases from the test case pool with low utility value and transfers them to the test case pool with high utility value. In this process, it is ensured that the value of count is less than the number of test cases in the current test case pool with low utility value T. count After this stage, T count ≥1

[0156] 3.3.3 Utility value reset

[0157] After the test case reallocation phase ends, the system will reset the utility values ​​of the two test case pools to 0 to prepare for the next phase of utility value calculation.

[0158] Another object of the present invention is to provide a smart contract fuzz testing system based on utility adjustment strategy, which mainly includes three modules: Fuzzy engine module: This module generates all test cases in the initial test case pool according to the smart contract related information, preparing for the subsequent execution analysis phase. This phase is the beginning of the cycle in the fuzz testing process.

[0159] Test case optimization module: This module is used to update and optimize all test cases in the test case pool. Different test case pools have different test case optimization schemes. The branch coverage test case pool is conducive to exploring deep branch vulnerabilities, and the data dependency test case pool needs to build complex test cases with data dependencies to explore the vulnerability problems between multiple transactions.

[0160] Execution analysis module: This module runs the test cases in each test case pool and uses the vulnerability oracle to determine whether there are vulnerabilities in the smart contract based on the information generated during the test case execution. At the same time, this module dynamically adjusts the number of test cases in each test case pool based on the number of vulnerabilities found during the test case execution.

[0161] The essential features of the present invention are: 1. The present invention adopts a combination of multiple test case optimization schemes, takes the test case pool as the overall optimization object, selects different optimization schemes for different test cases during the dynamic execution process, and provides a more comprehensive test case optimization method. 2. The present invention adopts the utility value formula to dynamically schedule the number of test cases, allocates more fuzzy resources to the test case pool with good effects, and further improves the utilization rate of fuzzy testing resources. 3. By using the present invention, the efficiency of vulnerability exploration can be significantly improved. Under the same test environment, compared with the existing fuzzy testing system, it can explore the vulnerabilities in the contract faster, thereby improving the efficiency of fuzzy testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0162] Figure 1This is a smart contract fuzzy testing method based on utility adjustment strategy and the overall flow chart of the system of the present invention.

[0163] Figure 2 The present invention is a smart contract fuzz testing method based on utility adjustment strategy and a schematic diagram of the static analysis phase process in the system.

[0164] Figure 3 The present invention provides a smart contract fuzzy testing method based on utility adjustment strategy and a system structured symbolic description.

[0165] Figure 4 The present invention is a smart contract fuzzy testing method based on utility adjustment strategy and a schematic diagram of the test case optimization process in the system branch coverage test case pool.

[0166] Figure 5 The present invention is a smart contract fuzzy testing method based on utility adjustment strategy and a schematic diagram of the test case optimization process in the system data dependency test case pool. DETAILED DESCRIPTION

[0167] The technical solution of the present invention is further described in detail below through specific embodiments in conjunction with the accompanying drawings.

[0168] A smart contract fuzz testing method based on utility adjustment strategy, such as Figure 1 As shown, it mainly includes three stages: preprocessing stage, optimization processing stage and execution analysis stage.

[0169] 1. Pretreatment stage of the present invention

[0170] First, perform static analysis on the smart contract and obtain the ABI file of the smart contract. Use the Slither tool to convert the ABI file into Slither's intermediate representation (IR), namely Slither IR. Then use the data collection API in the Slither tool on Slither IR to collect the dependency information between functions and contract state variables, branch information contained in functions, etc.

[0171] Secondly, the solc tool is used to extract the public function signatures according to the ABI file, build a function selector mapping table, and cyclically select available functions to encode as initial test cases.

[0172] Finally, the fuzzer creates a branch coverage test case pool and a data dependency test case pool and equally distributes the initial test cases to the two test case pools. Specifically, it includes the following:

[0173] 1.1 Static Analysis

[0174] 1.1.1ABI file generation

[0175] like Figure 2 As shown in the figure, the fuzz testing system will compile the smart contract given by the user into an Application Binary Interface (ABI) file, and convert the ABI file into the Slither IR intermediate representation through the Slither tool;

[0176] 1.1.2 Obtaining contract information

[0177] The fuzz testing system calls the Slither tool-related API on the Slither IR to collect three types of information in the contract and use it to guide the subsequent test case optimization process;

[0178] Specifically, the three types of information collected are shown in the table below:

[0179] Information type symbol describe <![CDATA[(F∶S define )]]> Function and state variable information defined by the function <![CDATA[(F∶S use )]]> Function and state variable information used by the function (F:B) Function and its branch coverage data information

[0180] Among them, F represents the function in the contract, S define Represents the state variable defined in the function, S use Represents the state variables used in the function, and B represents the function branch coverage information.

[0181] 1.1.3 Available functions to obtain

[0182] The fuzz testing system is based on the ABI file in JSON format and uses the solc tool to extract the signatures of all public functions declared in the ABI. The system uses the first four bytes of the hash value to calculate the selector m of the function signature. l , where 0≤l≤max, max is the maximum number of available functions in the entire contract. And use this selector to build a mapping M. In the mapping M, each function selector corresponds to a tuple consisting of the function name and function input parameter information. For example, if the function name is "transfer" and the function input parameter is "address to,uint256 value", the tuple is ("transfer", ["address", "uint256"]), and the mapping M associates all function selectors with their corresponding tuples so that subsequent fuzz testing can randomly call all public functions. At the same time, the system will automatically filter out functions in the ABI file that will not change the contract state, such as view functions, pure functions, etc., to ensure that fuzz testing is only performed on functions that will change the contract state.

[0183] 1.1.4 Branch Coverage Information Sorting

[0184] For the (F:B) information obtained in 1.1.2, the (F:B) information is arranged in descending order according to the principle of sequential arrangement, where the lowest branch coverage function is F min , the highest branch covering function is F max In particular, the coverage of each function branch is 0 at the beginning. After each test case is executed, the (F:B) information is updated and reordered.

[0185] 1.1.5 User Configuration Acquisition

[0186] The system reads the user input and saves the following configuration information, as shown in the following table:

[0187] symbol describe default value c Initial number of test cases generated 10 (pcs) t Fuzzy system execution time 600 (seconds) k Maximum transaction length of test cases 8 <![CDATA[w1]]> The weight parameter of time factor in the utility formula 6.0 <![CDATA[w2]]> Exponential parameter of time factor in utility formula 50.0 <![CDATA[w3]]> Branch jump frequency weight parameter in utility formula 2.0 <![CDATA[w4]]> Vulnerability discovery weight parameter in utility formula 3.0 <![CDATA[w5]]> Test case pool difference weight parameter in utility formula 5.0 m Redistribution formula maximum value 3 n Minimum value of redistribution formula 0

[0188] 1.2 Test case pool initialization

[0189] 1.2.1 Test case pool generation

[0190] The system first generates two sets of test cases of length c in memory, which store the encoded test cases. The two sets are initially defined as branch coverage test case pools Data dependency test case pool in represents the i-th test case in the j-th test case pool, and i=c, j=(1,2). When j=1, it represents the test case in the branch coverage test case pool, and when j=2, it represents the test case in the data dependency test case pool. Figure 3 The figure shows the overall symbolic description of the present invention.

[0191] 1.2.2 Value calculation formula registration

[0192] The system will cover the test case pool P for the branch branch and data-dependent test case pool P data Register different value calculation formulas, which are used to quantify the value of the current test case and are used in the subsequent test case replacement process.

[0193] 1.2.2.1 Registration of the value of the branch coverage test case pool: For the value of the test case Val_b in the branch coverage test case pool, the judgment formula is shown in formula (1-1):

[0194]

[0195] Where Val_b(T i 1 ) represents the branch coverage test case pool P branchThe value of the i-th test case in newBranch(T i 1 ) is the test case T i 1 The number of newly found branches, that is, the number of branches that trigger jumps; totalFindBranch(T i 1 ) is the current test case T i 1 The total number of branches found; totalBranch(T i 1 ) is the test case T i 1 The total number of branches owned.

[0196] 1.2.2.2 Data-dependent test case pool value registration: For the value of the test case Val_d in the data-dependent test case pool, the judgment formula is shown in formula (1-2):

[0197]

[0198] in Represents the data-dependent test case pool P data The value of the i-th test case in; For the current test case The number of newly discovered branches; Represents the current test case The number of read-write pairs of each state variable in, that is, the number of times a state variable is defined and then used.

[0199] 1.2.3 Utility Value Initialization

[0200] Test case pool P branch and P data Initially, a utility value of 0 is assigned, which is dynamically adjusted during the execution phase and used for P branch and P data The process of redistributing the number of test cases.

[0201] 1.3 Test case initialization

[0202] 1.3.1 Function selection

[0203] The system will select the function selectors in the M mapping table built by 1.1.3 in a circular order. For each selected function selector, the system will obtain the corresponding function name and function input parameter type in the M mapping table, and use this information to build a test case. The system will continue to select functions and build test cases until the number of selected functions equals the user configuration information c, and the system process ends.

[0204] 1.3.2 Function Input Parameter Generation

[0205] The system obtains the function name and function input parameters selected in 1.3.1, and constructs actual parameters of the same type as the function input parameters by random generation. At the same time, the fuzz testing system will randomly generate environmental information parameters, including block number, timestamp, block difficulty, etc.

[0206] 1.3.3 Test case construction

[0207] The ConFuzzius tool is used to encode the test cases. The function parameter information selected in 1.3.2 and the environment information are encoded into a transaction tx. At the same time, the extended encoding field θ is used to record the parameters that have mutated during the fuzzy execution process.

[0208] The present invention performs each test case The formal description is as follows:

[0209]

[0210] Test Cases is the i-th test case in the j-th test case pool, which is a series of transactions tx k The maximum value of k is obtained from the user configuration. The default value is 8, which means that the maximum length of the test case is limited to 8 transactions. When the test case is initialized, k = 1.

[0211] The present invention performs each transaction tx k The formal description is as follows:

[0212] tx k =(δ,ε,θ) k

[0213] Transaction tx k It is a triple consisting of environmental information δ, parameter information ε, and additional information θ. Triple (δ, ε, θ) k Represents the kth transaction tx k .

[0214] The formal description of the environmental information δ in the present invention is as follows:

[0215] δ=(b,t,d)

[0216] The environmental information δ consists of three parts, where b is the block number, t is the timestamp, and d is the block difficulty.

[0217] The formal description of parameter information ε in the present invention is as follows:

[0218] ε=(f,gl)

[0219] The parameter information ε consists of two parts, one is the function-related information f, and the other is the minimum limit gl for gas consumption.

[0220] The formal description of the function-related information f in the present invention is as follows:

[0221] f∈(m1(p1,p2,...p m ),m2(p1,p2,...p m ),...,m l (p1,p2,...p m ))

[0222] The function related information f mainly includes two parts, one of which is the function selector m l , where 0≤l≤max, where max is the maximum number of available functions in the entire contract. The second is the function input parameter p m , m represents the maximum number of input parameters of the current function, where 0≤m.

[0223] The formal description of the additional information θ in the present invention is as follows:

[0224]

[0225] The additional information θ is the key to mutating the guiding parameters of the present invention in order to facilitate fuzz testing. θ stores the parameters mutated in the previous round, so it is a subset of the function parameters.

[0226] 1.3.4 Initial Test Case Allocation

[0227] All test cases generated during initialization in 1.3.3 will be equally assigned to the branch coverage test case pool P branch and data-dependent test case pool P data In, it is used for subsequent fuzzer optimization according to different optimization strategies.

[0228] 2. Optimization Processing Phase of the Present Invention

[0229] 2.1 Test case selection

[0230] The system will traverse the test case pool P in parallel branch and P data and obtain the test cases in it

[0231] 2.2 Selection of Transactions to be mutated

[0232] System traversal test cases All transactions in txk And determine whether to mutate the current transaction parameters with a probability of P, which includes parameter information ε and environmental information δ. According to empirical analysis, the P value is generally selected as 0.5.

[0233] 2.3 Parameter Information Mutation

[0234] Test case pool P branch and P data The same parameter information mutation scheme is used: the parameter part in the function information f is mutated. There are three mutation methods, which are described in the following table:

[0235]

[0236] Breadth mutation: The system will obtain the function parameter information (p i ,p j ,…,p k ), and no longer mutate parameters in the current parameter mutation phase (p i ,p j ,…,p k ), and randomly select the remaining parameters (p q ,p p ,…,p m ) are randomly mutated.

[0237] Deep mutation: The system will obtain the function parameter information (p i ,p j ,…,p k ), and continue to mutate parameters in the current parameter mutation phase (p i ,p j ,…,p k ).

[0238] Completely random mutation: the system will randomly select (p1, p2, ... p m ) to perform random mutation on one or more parameters.

[0239] The pseudo code of the parameter mutation process at this stage is as follows:

[0240]

[0241] 2.3.1θ Information Acquisition

[0242] The fuzz testing system obtains the θ information in the current transaction tx.

[0243] 2.3.2 Mutation method selection

[0244] The system will determine whether the current θ information is None. If it is None, the γ mutation method will be selected. Otherwise, the fuzzy test system will randomly select one of the three mutation methods to mutate the parameters.

[0245] 2.3.3 Mutation Execution

[0246] After the system determines the mutation method, it will select the parameters to be mutated. For the α mutation direction, the fuzz test system will mutate the parameters contained in the current transaction θ information again, and mutate the parameters through the bit flipping, byte flipping and other methods provided by the sFuzz tool. For the β mutation direction, the fuzz test system will mutate the remaining parameters except the current transaction θ information, and mutate the parameters through the bit flipping, byte flipping and other methods provided by the sFuzz tool, and finally update the θ information to the mutated parameters.

[0247] 2.4 Sudden changes in environmental information

[0248] The fuzz testing system will generate new environment information parameters through operations such as bit flipping and byte flipping.

[0249] 2.5 Transaction sequence optimization

[0250] 2.5.1 Branch Coverage Test Case Pool Transaction Sequence Optimization

[0251] like Figure 4 As shown, the system will cover the test case pool P from the branch branch Recursively extract test case T i 1 , and optimize the transaction sequence in the test case until all test cases in the current test case pool complete the optimization process and end the current stage.

[0252] 2.5.1.1 Obtaining high branch coverage functions: The system will perform transaction-level scanning on the test cases obtained in 2.5.1 and obtain the function selector m in each transaction tx i , the branch coverage of the current function is recorded by the (F∶B) information collected in Section 1.1.2. The system will compare all branch coverage situations and obtain the current test case T through the M mapping table. i 1 The function F with the highest branch coverage in b-max .

[0253] 2.5.1.2 Test case optimization: For the branch coverage test case pool, the system will randomly select one of the three optimization methods:

[0254] First, select the low branch coverage function F based on the (F:B) information collected in stage 1.1 min Encoded as a transaction and appended to the current test case Ti 1 Random positions in ;

[0255] Second, delete the current test case T i 1 The function F with the highest branch coverage in b-max The corresponding transaction;

[0256] Third, replace the test case T i 1 The highest branch cover function F b-max The corresponding transaction is the low branch coverage function F min Encoded transactions

[0257] 2.5.1.3 Temporary storage of new test cases: New test cases generated in stage 2.5.1.2 Will be temporarily stored in P branch Waiting After execution, calculate its value and decide whether to perform test case coverage.

[0258] The pseudo code of the branch coverage test case pool transaction sequence optimization process is as follows:

[0259]

[0260]

[0261] 2.5.2 Data Dependency Test Case Pool Transaction Sequence Optimization

[0262] like Figure 5 As shown, the fuzzer will select from the data-dependent test case pool P data Extract test cases The transaction sequence in this test case is optimized. During the optimization process, the two types of information (F∶S define ) and (F:S use ) for guidance.

[0263] 2.5.2.1 Test Case Optimization For the data-dependent test case pool, the system will randomly select one of the three optimization methods:

[0264] First: Add a data-dependent transaction and randomly select test cases A transaction in tx λ , through (F:S define ) Information to find transaction tx λ The state variables defined by the corresponding function are then passed through (F:S use ) information to find the function that uses the state variable and use it as a transaction (transaction tx μ)Add to transaction tx λ Afterwards, if there is no transaction tx μ Then randomly select a function as a transaction tx v Append to transaction tx λ After that, the process of adding the transaction sequence of the test case is completed;

[0265] Second: Randomly delete the current test case A transaction in

[0266] Third: Randomly replace the current test case A transaction in is a transaction of other functions. The fuzzer will wait for possible selection of the function selector in the M mapping table and obtain the corresponding function and then encode it into a transaction, ultimately ensuring that the length of the test case is not less than 1.

[0267] 2.5.2.2 Temporary storage of new test cases: New test cases generated through stage 2.5.2.1 Will be temporarily stored in P data Waiting After execution, calculate its value and decide whether to perform test case coverage.

[0268] The pseudo code of the data-dependent test case pool transaction sequence optimization process is as follows:

[0269]

[0270]

[0271] 3. Execution Analysis Phase of the Present Invention

[0272] First, the fuzzer executes the test case and determines whether a vulnerability is triggered based on the bytecode path and state variable data flow during its execution; second, when all test case pools are executed, the system calculates the utility value of each test case pool based on information such as execution time, branch jump frequency, number of vulnerabilities found, and the degree of difference between test cases; finally, by comparing the utility values ​​of different test case pools, the number of test cases is redistributed, and the test cases in the low utility value test case pool are randomly transferred to the high utility value test case pool according to the redistribution number calculation formula.

[0273] 3.1 Vulnerability Detection

[0274] 3.1.1 Test Case Execution

[0275] The system will use the execution module of the ConFuzzius tool to execute the optimized test cases The simulation is performed through Py-EVM, where j = 1 represents the branch coverage test case pool Pbranch , j = 2 represents the data-dependent test case pool P data . And get the number of new branches found in the current test case during execution The total number of branches found by the test case The number of all branches included in the test case The number of read and write pairs of state variables in the test case Number of vulnerabilities discovered Branch jump frequency and execution time wait.

[0276] In particular, the fuzzer will record the number of JumpI, Jump and other bytecodes triggered by each test case in the current test case pool during execution as the branch jump frequency

[0277] 3.1.2 Value Calculation

[0278] The system calculates the current test case based on the value calculation formula registered in the current test case pool and the test case execution information obtained in 3.1.1. The value of .

[0279] 3.1.3 Test case replacement

[0280] The system is based on the test cases calculated in 3.1.2 The value of the original test case The value of is compared, specifically:

[0281] For the branch coverage test case pool P branch Test case T in i 1 The value of is Val_b(T i 1 ), test case The value of like Then replace the current test case pool P branch T i 1 The test case is Test case, otherwise Remove from the test case pool.

[0282] For the data-dependent test case pool P data Test cases in The value of Test Cases The value of like Then replace the current test case pool P data In The test case is Test case, otherwise Remove from the test case pool.

[0283] In particular, the initially generated test cases only calculate their value during execution and do not participate in the test case replacement process.

[0284] 3.1.4 Vulnerability Report

[0285] The system executes each test case in turn and analyzes the bytecode path and data flow during the execution process, and determines whether the current test case triggers a certain vulnerability through the vulnerability oracle constructed by the present invention. Specifically, the fuzzer will determine the dependency between bytecodes by analyzing the execution information of the current test case. The fuzzer analyzes this dependency to learn the execution process of the current test case and use it to determine the vulnerability type, and at the same time updates the (F:B) information in stage 1.1 according to the degree of improvement of the function branch during the execution process.

[0286] 3.2 Test case pool utility value adjustment

[0287] In this stage, the fuzzer performs a test case pool P branch and P data The utility value is calculated, and the utility of the current test case pool is calculated through the utility value calculation formula according to the number of vulnerabilities, branch jump information and difference information generated by each test case in the test case pool during execution, and the result value is used in the test case reallocation process.

[0288] 3.2.1 Calculation of the overall execution time of the test case pool

[0289] For the test case pool P branch :The system accumulates the time t(T) consumed by each test case in the current test case pool during execution i 1 ) and calculate the final test case pool execution time t 1 .

[0290] For the test case pool P data : The system accumulates the time consumed by each test case in the current test case pool during execution And calculate the final test case pool execution time t 2 .

[0291] 3.2.2 Calculation of the number of vulnerabilities

[0292] For the test case pool P branch :The system accumulates the number of vulnerabilities found during the execution of each test case in the current test case pool v(T i1 ) and calculate the total number of vulnerabilities found in the final test case pool 1 .

[0293] For the test case pool P data : The system accumulates the number of vulnerabilities found during the execution of each test case in the current test case pool And calculate the final test case pool execution time v 2 .

[0294] 3.2.3 Branch jump frequency calculation:

[0295] For the test case pool P branch :The system accumulates the branch jump frequency b(T i 1 ) and calculate the total vulnerability jump frequency b of the final test case pool 1 .

[0296] For the test case pool P data : The system accumulates the branch jump frequency of each test case in the current test case pool during execution And calculate the total vulnerability jump frequency b of the final test case pool 2 .

[0297] 3.2.4 Test case pool difference calculation

[0298] For the test case pool P branch and P data The difference of test cases in j The calculation formula is as follows (3-2):

[0299]

[0300] where d j is the difference between different test case pools. When j=1, d 1 Cover the test case pool P for the branch branch The test case difference, when j = 2, d 2 The data dependency test case pool P data The test case difference. n represents the number of test cases in the current test case pool. It represents the benchmark test case for calculating the difference between test cases. A test case in the current test case pool is selected as the benchmark test case by random selection. Representative Other test cases, Representative test case and The Jaccard coefficient between .

[0301] The Jaccard similarity coefficient calculation formula is as follows:

[0302]

[0303] The present invention defines, Represents the intersection of the transaction functions between two test cases, The union of transaction functions between representative test cases. Therefore, the greater the difference between test cases in the test case pool, the larger the value of d, where the value range of d is: 0≤g≤1;

[0304] In order to ensure the speed and efficiency of test case execution, the default option is to enable the test case utility value adjustment function every s seconds. According to experience, it is found that 2.0 is the most suitable value for s.

[0305] 3.2.5 Utility value calculation

[0306] The utility value of the current test case pool is calculated according to the utility formula based on the weight information configured by the user in 1.2.1 and the information counted by the system in 3.2.1-3.2.4. The utility formula defined in the present invention is as follows:

[0307]

[0308] In the utility formula, when j = 1, it is the branch coverage test case pool P branch The utility value of is, when j = 2, it is the data-dependent test case pool P data The utility value of Utilityj. Utilityj contains 9 parameters, namely:

[0309] (10) w1: The weight parameter of the time factor. As time goes by, the utility of the test case will gradually decrease. w1 controls the strength of this utility factor. According to experience, when the initial number of test cases is 10, w1 is preferably 6.0.

[0310] (11) w2: exponential parameter of time factor. The larger the exponent, the faster the utility decreases with time. According to experience, when the number of initial test cases is 10, w2 is preferably 50.0.

[0311] (12) t: The execution time of the current test case pool, which is used to indicate the actual time that the fuzzer executes the current test case pool. The basic unit is seconds. The shorter the time, the higher the utility. As the execution time of the current test case pool increases, the utility value gradually tends to be flat. It is precisely because the number of test cases in each test case pool may be different and the execution time of the test cases may be different, that will cause different test case pools to have different time utility factors.

[0312] (13) w3: Branch jump frequency weight parameter. The higher the total branch jump times in the test case pool, the higher the utility of the test case. w3 controls the strength of this utility factor. According to experience, when the initial number of test cases is 10, w3 is preferably 2.0.

[0313] (14) b: Branch jump frequency, indicating the total number of branch jumps in the current test case pool.

[0314] (15) w4: vulnerability discovery weight parameter. The more vulnerabilities discovered, the higher the utility of the test case pool. w4 controls the strength of this utility factor. According to experience, when the initial number of test cases is 10, w4 is preferably 3.0.

[0315] (16) v: Number of vulnerabilities found, which indicates the total number of vulnerabilities found during the execution of each test case in the current test case pool.

[0316] (17) w5: The weight parameter of the test case pool’s difference. The greater the difference, the higher the utility of the test case pool. w5 controls the strength of this utility. According to experience, when the initial number of test cases is 10, w5 is preferably 5.0.

[0317] (18) d: Difference, which indicates the difference between the test cases in the current test case pool.

[0318] 3.2.6 Utility Value Update

[0319] The system will update the utility value of the current test case pool to the utility value calculated in 3.2.5 and use it for comparison operations in the test case number reallocation phase.

[0320] 3.3 Test Case Number Redistribution

[0321] This stage is the processing stage after each test case pool is executed. In this stage, two test case pools may have different utility values. In this stage, the number of test cases in the test case pool with high utility value will be increased, and the number of test cases in the test case pool with low utility value will be reduced. In order to achieve more allocation of fuzzy resources to valuable test case pools. After this stage, the utility value of each test case pool is reset to the initial value.

[0322] 3.3.1 Calculation of the number of redistributions

[0323] The system determines the number of reallocations based on the utility values ​​of different test case pools calculated in 3.2.6 and the reallocation number calculation formula, where the reallocation number calculation formula is as shown in formula (3-4):

[0324]

[0325] Where count represents the number of test cases reallocated in the current phase, Utility 1 Utility 2 are the utility values ​​in the two test case pools. The idea of ​​redistribution is to transfer the test cases in the low utility value test case pool to the high utility value test case pool. m and n represent the range of the number of redistributions each time, where m≥n. When the initial number of test cases in the test case pool is 10, m is generally selected as 3 and n is generally selected as 0 based on empirical value judgment. This means that the range of the number of test cases reallocated in the redistribution phase is 0≤i≤3, and users can configure the values ​​of m and n in a customized way.

[0326] 3.3.2 Redistributing Test Case Selection

[0327] After the system has redistributed the number of cases determined in 3.3.1, it randomly selects count test cases from the test case pool with low utility value and transfers them to the test case pool with high utility value. In this process, it is ensured that the value of count is less than the number of test cases in the current test case pool with low utility value T. count After this stage, ensure that T count ≥1

[0328] 3.3.3 Utility value reset

[0329] After the test case reallocation phase ends, the system will reset the utility values ​​of the two test case pools to 0 to prepare for the next phase of utility value calculation.

Claims

1. A smart contract fuzz testing method based on utility adjustment strategy, characterized in that: include: In the preprocessing stage, the fuzz testing system preprocesses the smart contract to be tested, obtains the structural information and branch information related to each function in the contract, randomly generates initial test cases and distributes them equally to the branch coverage test case pool and data dependency test case pool generated by the fuzzer; Optimization processing stage: The fuzz testing system will perform targeted test case optimization iterations based on the test case optimization strategies in different test case pools; Including: iterative optimization of transaction sequences in test cases and iterative optimization of parameters in a single transaction; During the fuzz testing process, the test cases in each independent test case pool will undergo parameter mutation and transaction sequence optimization; For transaction sequence optimization, the branch coverage test case pool focuses more on improving function branch coverage; the data dependency test case pool focuses more on creating test cases with data dependency. The execution analysis phase includes: the fuzz testing system executes the test case and determines whether the vulnerability is triggered based on the bytecode path and state variable data flow during its execution; Secondly, when all test case pools are executed, the fuzz testing system will calculate the utility value of each test case pool based on the execution time, branch jump frequency, number of vulnerabilities found, and the difference between test cases; By comparing the utility values ​​of different test case pools, the number of test cases is redistributed. The test cases in the low utility value test case pool are randomly transferred to the high utility value test case pool according to the redistribution number calculation formula.

2. According to claim 1, a smart contract fuzz testing method based on utility adjustment strategy is characterized in that: The preprocessing stage includes: Perform static analysis on smart contracts to collect smart contract related information, including: function and state variable information defined by the function (F∶S define ); function and the state variable information used by the function (F:S use ); function and its branch coverage data information (F:B); Among them, F represents the function in the contract, S define Represents the state variable defined in the function, S use Represents the state variables used in the function, and B represents the function branch coverage information; Generate initial test cases based on ABI file information; The fuzzer creates two test case pools and assigns initial test cases.

3. According to claim 2, a smart contract fuzz testing method based on utility adjustment strategy is characterized in that: Test case pool generation, including: 2.1 The system generates two sets of test cases of length c in memory, which store the encoded test cases; The two collections are initially defined as branch coverage test case pools Data dependency test case pool in represents the i-th test case in the j-th test case pool, and i=c, j=(1,2). When j=1, it represents the test case in the branch coverage test case pool, and when j=2, it represents the test case in the data dependency test case pool; 2.2 Value calculation formula registration The system will cover the test case pool P for the branch branch and data-dependent test case pool P data Register different value calculation formulas, which are used to quantify the value of the current test case and to be used in the subsequent test case replacement process; 2.3 Utility Value Initialization Test case pool P branch and P data Initially, a utility value of 0 is assigned, which is dynamically adjusted during the execution phase and used for P branch and P data The process of redistributing the number of test cases between them; 2.4 Test Case Initialization 2.4.1 Test case construction For the coding of test cases, the selected function parameter information and environment information are encoded together into a transaction tx, and the extended coding field θ is used to record which parameters have mutated during the fuzzy execution process; For each test case The formal description is as follows: Test Cases is the i-th test case in the j-th test case pool, which is a series of transactions tx k The maximum value of k is obtained through user configuration. The default value is 8, which means that the maximum length of the test case is limited to 8 transactions. When the test case is initialized, k = 1. For each transaction tx k The formal description is as follows: tx k =(d,e,i) k Transaction tx k It is a triple consisting of environmental information δ, parameter information ε and additional information θ; triple (δ, ε, θ) k Represents the kth transaction tx k ; The formal description of environmental information δ is as follows: δ=(b,t,d) The environmental information δ consists of three parts, where b is the block number, t is the timestamp, and d is the block difficulty; The formal description of parameter information ε is as follows: ε=(f,gl) The parameter information ε consists of two parts, one is the function-related information f, and the other is the minimum limit gl for gas consumption; the formal description of the function-related information f is shown in the following formula: f∈(m1(p1,p2,...p m ),m2(p1,p2,...p m ),...,m l (p1,p2,...p m )) Function related information f includes: one is the function selector m l , where 0≤l≤max, where max is the maximum number of available functions in the entire contract; the second is the function input parameter p m , m represents the maximum number of input parameters of the current function, where 0≤m; The formal description of the additional information θ is as follows: Additional information θ, in order to facilitate the key to guide parameter mutation in fuzz testing, θ stores the parameters mutated in the previous round, so it is a subset of the function parameters; 2.4.2 Initial Test Case Allocation All test cases generated during initialization in 2.4.1 will be equally assigned to the branch coverage test case pool P branch and data-dependent test case pool P data In, it is used for subsequent fuzzer optimization according to different optimization strategies.

4. According to claim 3, a smart contract fuzz testing method based on utility adjustment strategy is characterized in that: Registration of value calculation formula, including: 2.2.1 Registration of the value of the branch coverage test case pool: For the value of the test case Val_b in the branch coverage test case pool, the judgment formula is shown in formula (1-1): in Represents branch coverage test case pool P branch The value of the i-th test case in; For test cases The number of newly discovered branches, that is, the number of branches that trigger jumps; For the current test case The total number of branches found; For this test case The number of all branches owned; 2.2.2 Data-dependent test case pool value registration: For the value of the test case in the data-dependent test case pool, Val_d, the judgment formula is shown in formula (1-2): in Represents the data-dependent test case pool P data The value of the i-th test case in; For the current test case The number of newly discovered branches; Represents the current test case The number of read-write pairs of each state variable in, that is, the number of times a state variable is defined and then used.

5. According to claim 2, a smart contract fuzz testing method based on utility adjustment strategy is characterized in that: Test case optimization, including: 3.1 Parameter mutation The same parameter mutation scheme is used for the two test case pools, which focuses on the parameter part of the function information f and the additional information θ; 3.1.1 Test case selection The system will traverse the test case pool P in parallel branch and P data and obtain the test cases in it 3.1.2 Selection of Transactions to be mutated System traversal test cases All transactions in tx k And determine whether to mutate the current transaction parameters with a probability of P, which includes parameter information ε and environmental information δ; 3.1.3 Parameter Information Mutation Test case pool P branch and P data The same parameter information mutation scheme is used: the parameter part in the function information f is mutated; the mutation methods include: Breadth mutation α: The system will obtain the function parameter information (p i ,p j ,…,p k ), and no longer mutate parameters in the current parameter mutation phase (p i ,p j ,…,p k ), and randomly select the remaining parameters (p q ,p p ,…,p m ) are subjected to random mutation of one or more of the Deep mutation β: The system will obtain the function parameter information (p i ,p j ,…,p k ), and continue to mutate parameters in the current parameter mutation phase (p i ,p j ,…,p k ); Completely random mutation γ: The system will randomly select (p1, p2, ... p m ) to perform random mutation on one or more parameters; 3.1.4θ Information Acquisition The fuzz testing system obtains the θ information in the current transaction tx; 3.1.5 Mutation method selection The system will determine whether the current θ information is None. If it is None, the γ mutation method will be selected. Otherwise, the fuzzy test system will randomly select one of the three mutation methods to mutate the parameters. 3.1.6 Mutation Execution After the system determines the mutation method, it will select the parameters to be mutated. For the α mutation direction, the fuzz test system will mutate the parameters contained in the current transaction θ information again, and mutate the parameters through the bit flipping and byte flipping methods provided by the sFuzz tool. For the β mutation direction, the fuzz test system will mutate the remaining parameters except those contained in the current transaction θ information, and mutate the parameters through the bit flipping and byte flipping methods provided by the sFuzz tool, and finally update the θ information to the mutated parameters. 3.2 Sudden changes in environmental information The fuzz testing system generates new environment information parameters through bit flipping and byte flipping operations; 3.3 Transaction sequence optimization 3.3.1 Branch Coverage Test Case Pool Transaction Sequence Optimization The system will cover the test case pool P from the branch branch Recursively extract test cases The transaction sequence in the test case is optimized until all test cases in the current test case pool complete the optimization process and end the current stage; 3.3.2 Data Dependent Test Case Pool Transaction Sequence Optimization The fuzzer will select from the data-dependent test case pool P data Extract test cases The transaction sequence in the test case is optimized; in the optimization process, according to the two types of information collected (F:S define ) and (F:S use ) for guidance.

6. According to claim 5, a smart contract fuzz testing method based on utility adjustment strategy is characterized in that the branch coverage test case pool transaction sequence optimization includes: 3.3.1.1 Obtaining high branch coverage functions: The system will perform transaction-level scanning on the test cases obtained in 3.1.1 and obtain the function selector m in each transaction tx i , the branch coverage corresponding to the current function is recorded by the collected (F:B) information, and the system will compare all branch coverage situations and obtain the current test case through the M mapping table The function F with the highest branch coverage in b-max ; 3.3.1.2 Test case optimization: For the branch coverage test case pool, the system will randomly select one of the three optimization methods: First, select the low branch coverage function F according to the collected (F:B) information min Encoded as a transaction appended to the current test case Random positions in ; Second, delete the current test case The function F with the highest branch coverage in b-max The corresponding transaction; Third, replace the test case The highest branch cover function F b-max The corresponding transaction is the low branch coverage function F min Coded transactions; 3.3.1.3 Temporary storage of new test cases: New test cases generated through stage 3.3.1.2 It will be temporarily stored in P branch Waiting After execution, calculate its value and decide whether to perform test case coverage; Data-dependent test case pool transaction sequence optimization, including: 3.3.2.1 Test Case Optimization For the data-dependent test case pool, the system randomly selects one of three optimization methods: First: Add a data-dependent transaction and randomly select test cases A transaction in tx λ , through (F:S define ) Information to find transaction tx λ The state variables defined by the corresponding function are then passed through (F:S use ) information to find the function that uses the state variable and use it as a transaction tx μ , added to the transaction tx λ Afterwards, if there is no transaction tx μ Then randomly select a function as a transaction tx ν Append to transaction tx λ After that, the process of adding the transaction sequence of the test case is completed; Second: Randomly delete the current test case A transaction in Third: Randomly replace the current test case A transaction in is another function transaction; the fuzzer will wait for possible selection of the function selector in the M mapping table and obtain the corresponding function and then encode it into a transaction, ultimately ensuring that the length of the test case is not less than 1; 3.3.2.2 Temporary storage of new test cases: New test cases generated through stage 3.3.2.1 It will be temporarily stored in P data Waiting After execution, calculate its value and decide whether to perform test case coverage.

7. According to claim 1, a smart contract fuzz testing method based on utility adjustment strategy is characterized in that: The calculation of the utility value in the test case pool is as shown in formula (3-1): Where w1: the weight parameter of the time factor. As time goes by, the utility of the test case will gradually decrease. w1 controls the strength of this utility factor. w2: the exponential parameter of the time factor. The larger the exponent, the faster the utility decreases as time goes by. t: the execution time of the current test case pool. The time is used to represent the actual execution time of the current test case. The basic unit is seconds. The shorter the time, the higher the utility. As the execution time of the current test case pool increases, the utility value gradually tends to be flat. w3: the branch jump frequency weight parameter. The higher the overall branch jump number in the test case pool, the higher the utility of the test case. w3 controls the strength of this utility factor. b: branch jump frequency, which indicates the total number of branch jumps in the current test case pool, and is counted by recording the bytecode JumpI and Jump; w4: vulnerability discovery weight parameter, the more vulnerabilities are discovered, the higher the utility of the test case pool, and w4 controls the strength of this utility factor; v: number of vulnerabilities discovered, which indicates the number of vulnerabilities discovered in the current test case pool; w5: test case pool difference weight parameter, the greater the difference, the higher the utility of the test case pool, and w5 controls the strength of this utility; d: difference parameter, which indicates the difference between test cases in the current test case pool; The calculation formula for the difference in the test case pool is as follows: Where n represents the number of test cases in the current test case pool, A represents the benchmark test case for calculating the difference between test cases, and the benchmark test case is selected by random selection. i represents the test cases other than A, J(A, B i ) represents test cases A and B i Jaccard coefficient between; The Jaccard similarity coefficient calculation formula is as follows: Definition, A∩B i Represents the intersection of transactions between two test cases, A∪B i Represents the union of all transactions between two test cases; therefore, the greater the difference between the test cases in the test case pool, the larger the value of d, where the value range of d is: 0≤d≤1; The calculation for redistribution of the number of test cases is shown in formula (3-4): Where count represents the number of test cases reallocated in the current stage. The idea of ​​reallocation is to transfer test cases from low utility value test cases to high utility value test case pool; m and n represent the range of the number of redistributions each time, where m≥n; x2 and x1 are the utility values ​​in the two test case pools.

8. A smart contract fuzzy testing system based on utility adjustment strategy applicable to the smart contract fuzzy testing method based on utility adjustment strategy according to claim 1, characterized in that: include: Fuzzy engine module: This module generates all test cases in the initial test case pool based on the smart contract related information. Prepare for the subsequent execution and analysis phase; Test case optimization module: This module is used to update and optimize all test cases in the test case pool. Different test case pools have different test case optimization schemes. The branch coverage test case pool is conducive to exploring deep branch vulnerabilities, and the data dependency test case pool needs to build complex test cases with data dependency relationships to explore the vulnerability problems between multiple transactions. Execution analysis module: This module runs the test cases in each test case pool, and uses the vulnerability oracle to determine whether there are vulnerabilities in the smart contract based on the information generated during the test case execution. At the same time, this module dynamically adjusts the number of test cases in each test case pool based on the number of vulnerabilities found during the test case execution.

Images