Intelligent contract fuzzy testing method based on state variable parameterization

Abstract

The invention discloses an intelligent contract fuzzy test method based on state variable parameterization, and the method comprises the steps: a preprocessing stage: obtaining a to-be-tested intelligent contract program, employing a static analysis tool to compile and extract compilation information, and generating state variable information based on a depth-first algorithm; in the parameterization stage, a population is initialized based on a genetic algorithm, a single-round test of the smart contract is executed, a to-be-parameterized state variable set is confirmed, substitute parameters which have the same name and the same type as the state variables are added, and a substitute contract corresponding to the original smart contract is generated; in the fuzzy test stage, whether the substitute parameters meet the constraint of the value range or not is checked, whether mutation is executed or not is judged, and in the fuzzy test process of the substitute contract, the values of the substitute parameters in the seeds triggering the vulnerabilities are verified. According to the method, the abrupt change data is checked by using the value range of the state variable, the data availability is ensured, and the reliability of the detection result is ensured by reversely deducing the state variable value of the trigger vulnerability on the original contract.

Description

Technical Field

[0001] The present invention relates to the technical field of vulnerability detection of smart contracts, and specifically relates to a method for fuzz testing of smart contracts based on state variable parameterization. Background Art

[0002] Fuzz testing is an automated testing technique. Its core idea is to input a large number of randomly generated unexpected data into the target program, and at the same time collect and monitor the abnormal information during the execution of test cases by the target program, so as to discover as many illegal inputs that cause errors in the target program as possible and find the vulnerable points of the target program. Fuzz testing has been widely developed in the field of smart contracts. For example, existing smart contract fuzzers such as sFuzz, Smartian, and Confuzzius have made certain progress in branch coverage and vulnerability detection.

[0003] A deployed smart contract is a runtime program that contains persistent state variables. The state variables are read and written and referenced inside each function in the contract, participate in data calculations and conditional judgments in the function, and affect the execution flow of conditional branches. Therefore, Confuzzius proposed the idea of "state exploration", using the write-after-read (RAW) data dependency relationship of state variables to guide the fuzzer to construct a function sequence that first writes and then reads the state variables, explores different state variable values, and tries to trigger the conditional branches containing state variables in the contract functions to improve the branch coverage of fuzz testing.

[0004] However, the state exploration method based on constructing a function sequence according to the RAW data dependency relationship is essentially to execute a function sequence that modifies state variables, and probabilistically collides with the conditional values of state variables in branch conditions. For example, when the branch condition of a smart contract requires the state variable to reach a specific value or fall within a specific value range, the probability of generating a state variable value that meets the conditions by the function sequence generated based on the RAW data dependency relationship is relatively low. This results in limited efficiency of state exploration, and it is difficult for the fuzzer to generate seeds that meet the branch conditions, thereby affecting the improvement of branch coverage and vulnerability detection capabilities.

[0005] In summary, the current smart contract fuzz testing tools still face the following challenges in state exploration: the state exploration method based on a random function sequence is inefficient and it is difficult to construct state variable values that meet specific branch conditions. Summary of the Invention

[0006] The present invention innovatively proposes a fuzz testing method based on state variable parameterization. By introducing substitute parameters with the same name and type as the state variables into the function input parameters and generating substitute contracts, the present invention directly integrates the control of the state variable value into the function call process, thereby achieving precise exploration of branch conditions. Different from the traditional method of randomly generating function sequences based on RAW data dependency relationships, the present invention accurately locks the state variables affecting the branch conditions through data operation perception and extraction of the state variable value range, and generates mutant data that satisfies the constraints using symbolic taint analysis. In addition, the present invention proposes a vulnerability verification mechanism based on function sequences, which ensures the reliability of the detection results by reverse-inferring the state variable values that trigger vulnerabilities on the original contract.

[0007] The fuzz testing method based on state variable parameterization mainly includes three stages: a preprocessing stage, a parameterization stage, and a fuzz testing stage. In the preprocessing stage, the static analysis tools solcx and Slither are used to compile the smart contract, and the static opcodes, the mapping table of opcodes and source code, the application binary interface (ABI), and the abstract syntax tree (AST) are extracted. The relevant information of the state variables is generated by analyzing the AST; in the parameterization stage, first, the state variable objects to be parameterized are confirmed through the method of data operation perception; then, substitute parameters with the same name and type as these state variables are added to the input parameters of the relevant functions of the contract, and the value range of the state variables is obtained to achieve the parameterization of the state variables; in the fuzz testing stage, mutation schemes are provided for the substitute parameters and their corresponding state variable value ranges, and a function sequence is constructed to verify the values of the substitute parameters after a vulnerability is detected.

[0008] The present invention provides a fuzz testing method for smart contracts based on state variable parameterization, including the following stages:

[0009] Preprocessing stage: First, obtain the smart contract program to be tested, and use the static analysis tools solcx and Slither for compilation to extract compilation information, including static opcodes, the mapping table source_map of opcodes and source code statements, the application binary interface ABI, and the abstract syntax tree AST;

[0010] Then, traverse the AST based on the depth-first algorithm to generate state variable information including the names, initial values, and types of the state variables in the smart contract.

[0011] Parameterization stage: First, initialize the population based on the genetic algorithm and perform a single-round test of the smart contract to obtain dynamic opcodes, track the SLOAD and SSTORE opcodes and their operation addresses, construct a dictionary of functions for reading and writing state variables, and confirm the set of state variables to be parameterized;

[0012] Then, traverse the set of state variables to be parameterized, modify the input parameters of the functions in the smart contract that operate on these state variables, add substitute parameters with the same name and type as the state variables, and generate a substitute contract corresponding to the original smart contract;

[0013] Finally, use the static opcodes and source_map obtained in the preprocessing stage to extract the value ranges of the parameterized state variables.

[0014] Fuzz testing stage: First, check whether the mutated data of the substitute parameters satisfies the constraints of the corresponding state variable value range. If it does, perform the mutation; otherwise, retain the original data;

[0015] Then, during the fuzz testing process of the substitute contract, if a potential vulnerability is detected, verify the values of the substitute parameters in the seed that triggered the vulnerability;

[0016] Finally, if the verification fails, mark the triggered vulnerability as a false positive.

[0017] Preferably, the specific process of the preprocessing stage includes the following steps:

[0018] 1-1. Obtain the program to be tested, which is the smart contract code;

[0019] 1-2. Compile the program to be tested using a static analysis tool to obtain compilation information including static opcodes, the opcode - source code statement mapping table source_map, ABI, and abstract syntax tree AST;

[0020] 1-3. Use the depth - first algorithm to search the AST to obtain the state variable information in the contract, including the name name, initial value initvalue, and variable type type of the state variables, and record them in the sta_variable list, init_value dictionary, and type dictionary respectively.

[0021] Preferably, the parameterization stage can be specifically divided into the following stages: data operation perception sub - stage, state variable parameterization sub - stage, and state variable range extraction sub - stage.

[0022] 2-1. The data operation perception sub - stage specifically includes the following steps:

[0023] 2-1-1. First, initialize the population based on the genetic algorithm, and the seeds in the population only execute different single contract functions;

[0024] 2-1-2. Conduct the first - round fuzz testing loop, execute each seed one by one, and obtain the dynamic opcodes executed by each function;

[0025] 2-1-3. Track the read SLOAD and store SSTORE opcodes and their addresses to retrieve the access pattern of the runtime state variables, and store them as the read state variable dictionary D of the function. read and the function's write state variable dictionary D write ;

[0026] 2-1-4. Reading the state variable dictionary D of the function read and the function's write state variable dictionary D write Take the intersection of the state variables in and get the list of state variables to be parameterized.

[0027] 2-2. The specific process of the state variable parameterization sub-phase is as follows:

[0028] 2-2-1. Traverse the state variables in the state variable list to be parameterized, in D read and D write Matches reading or writing ps i function;

[0029] 2-2-2. Modify the function matched in 2-2-1. First, use a regular expression to match the entire line of code where the function is declared. Then, use a regular expression to locate the input parameter part within the brackets in the function declaration. Finally, combine the state variable information extracted in 1-3 and add the state variable ps to the input parameter. i Parameters with the same name and type are called substitute parameters;

[0030] 2-2-3. Repeat the process of 2-2-1 and 2-2-2 until all state variables in the state variable list parastate are parameterized. At this time, the smart contract with modified source code is called a substitute contract.

[0031] 2-3. The specific process of the state variable range extraction sub-phase is as follows:

[0032] 2-3-1. Among the static opcodes, identify operations related to state variables, prioritizing the matching of addition (ADD), subtraction (SUB), multiplication (MUL), and division (DIV).

[0033] 2-3-2. For each matched operation, extract the corresponding program counter (pc), scan source_map to obtain the source code statements related to the program counter (pc), and record all the hits in the variable operation list (lines).

[0034] 2-3-3. Traverse each source code statement line in the variable operation list lines i, extract the variable name `name` and operation step `step` for operation using regular expressions;

[0035] 2-3-4. Check that `name` is the name of a state variable included in the state variable information in 1-3;

[0036] 2-3-5. Check `step` to determine whether `step` comes from fixed step data or a function call;

[0037] 2-3-6. Combine the state variable information (including name `name`, type `type`, and initial value `initvalue`) in 1-3 with the step `step` to generate a string in the format of `opcode_type_initvalue_step` for the value range of the state variable `name`; when multiple operations are involved for a state variable, generate multiple different value ranges and store them in the corresponding list `RangeList` i =[opcode i1 _type i _initvalue i _step i1 ,…,opcode in _type i _initvalue i _step in . All state variables and their corresponding value range lists are integrated into a dictionary `RangeDict={name1:RangeList1,…, name n :RangeList n}`;

[0038] 2-3-7. Use the proxy contract as the program under test, regenerate the population, and enter the fuzz testing loop.

[0039] Preferably, the fuzz testing stage can be specifically divided into the following stages: the proxy parameter mutation stage and the vulnerability verification stage

[0040] 3-1. The proxy parameter mutation stage specifically includes the following steps:

[0041] 3-1-1. Initialize the mutation pool to store the mutant values solved through symbolic taint analysis; the mutation pool supports reusing the legal values solved in subsequent steps of the symbol during the test to replace the current value of the proxy parameter;

[0042] 3-1-2. For the executed seeds, analyze their opcode sequences, program counters, and execution stacks, identify the opcodes related to data transfer, inject taints, and track their propagation in the stack and memory, generate symbolic constraints, use a symbolic solver to solve the symbolic constraints, and store the results in the mutation pool;

[0043] 3-1-3. For the seeds to be mutated, select the mutated values from the mutation pool as the substitution parameter values for the current seeds, or when the mutation pool is empty, generate random values as the mutated values according to the variable types of the substitution parameters;

[0044] 3-1-4. Conduct a legality check on the mutated values to ensure that they conform to the value ranges of the state variables extracted in the 2-3 phase. If the legality check passes, assign the mutated values to the substitution parameters to generate new test cases; if the legality check fails, generate random values according to the variable types of the substitution parameters and repeat the range check.

[0045] 3-2. The vulnerability verification phase specifically includes the following steps:

[0046] 3-2-1. Construct a two-dimensional impact array Effect: Extract the function name list F = [f1, f2, …, f m of the smart contract. For each function f i , check whether it modifies the state variable s j in the state variable list sta_variable generated in the preprocessing phase. Extract the value initvalue ij , operation type op ij (such as ADD, SUB, MUL, or DIV), and step size step ij from the corresponding value range of the state variable, and record it as Effect[f i [s j =(op ij , step ij , initvalue ij ), indicating that the i-th function f i modifies the j-th state variable s j in the form of an op ij operation with initvalue ij as the initial value and step ij as the step size;

[0047] 3-2-2. When a vulnerability is detected on the substitution contract, extract the names and values of the substitution parameters in the test case that triggers the vulnerability, and record the target values of the corresponding state variables;

[0048] 3-2-3. Use the pre-constructed influence array Effect to solve the function sequence that can make the state variables in the original contract reach the target values; the sequence consists of function calls that affect the state variables and satisfies the constraints of the operation types and step sizes in Effect;

[0049] 3-2-4. If the function sequence is successfully solved, deploy the original contract on the virtual machine, use this sequence to test the original contract, and observe whether the same vulnerability can be triggered; if so, confirm that the vulnerability is real; if the sequence cannot be constructed or the test results are inconsistent, mark the vulnerability as a false positive.

[0050] The present invention has the following features and beneficial effects:

[0051] (1) The present invention proposes a method of parameterizing state variables. Based on the state variables on the original contract, function input parameters called stand-in parameters are added to the functions to obtain a stand-in contract, which replaces the original contract and enters the fuzz testing loop.

[0052] (2) The present invention proposes a mutation strategy that adapts to stand-in parameters, uses the value range of state variables to check mutation data, and ensures data availability.

[0053] (3) Based on the state variable parameterization method, the present invention proposes a method for vulnerability verification. After detecting a vulnerability on the stand-in contract, the function sequence that triggers the same branch is deduced on the original contract to prove that the vulnerability originates from the original contract. Brief Description of the Drawings

[0054] Figure 1 is the overall flowchart of the intelligent contract fuzz testing method based on state variable parameterization of the present invention;

[0055] Figure 2 is the flowchart of the stand-in parameter mutation stage of the intelligent contract fuzz testing method based on state variable parameterization of the present invention;

[0056] Figure 3 is the flowchart of the vulnerability detection stage of the intelligent contract fuzz testing method based on state variable parameterization of the present invention; Detailed Embodiments

[0057] The present invention will be described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the invention, but do not limit the invention in any form. It should be noted that, without conflict, the embodiments in the present invention and the features in the embodiments can be combined with each other.

[0058] As Figure 1 shown, the intelligent contract fuzz testing method based on state variable parameterization includes a preprocessing stage, a parameterization stage, and a fuzz testing stage, where:

[0059] In the preprocessing stage, first, use the static analysis tools solcx and Slither to compile the program under test, and obtain the compilation information of the contract, including the static opcode, the mapping table of opcode and source code, ABI, and the abstract syntax tree AST. Then, parse the AST and use the depth-first algorithm to search the AST to obtain the names, initial values, and variable types of the state variables in the contract, collectively referred to as state variable information.

[0060] In the parameterization stage, first, initialize the seeds based on the genetic algorithm, and each seed only executes a single contract function. Then, perform a single round of fuzz testing to obtain the dynamic opcode of each function, track the SLOAD and SSTORE opcodes and their operating addresses to retrieve the access patterns of runtime state variables. Then, based on the state variables read and written by the traced functions and the state variable information in the preprocessing stage, identify the set of state variables to be parameterized through data operation perception, modify the relevant functions, and add dummy parameters with the same name and type as the state variables to obtain a dummy contract. Subsequently, identify the addition, subtraction, multiplication, and division operations of the static opcode, combine the mapping table to locate the source code, and extract the value ranges of the state variables. Finally, initialize the seeds of the dummy contract based on the genetic algorithm.

[0061] In the fuzz testing stage, first, use symbolic taint analysis to generate mutant values, perform directed mutation on the dummy parameters, and check through the value ranges of the corresponding state variables. Finally, when a vulnerability is detected, extract the values of the dummy parameters that trigger the vulnerability, and reverse-infer the function sequence of the original contract for verification. If the verification passes, confirm that the vulnerability is a true positive, otherwise mark it as a false positive.

[0062] I. The preprocessing stage described in the present invention specifically includes the following steps:

[0063] Obtain the program under test, where the program under test is the smart contract code written in the solidity to be tested;

[0064] Use the static analysis tools solcx and Slither to compile the program under test, and obtain the compilation information including the static opcode, the source_map of the mapping table of opcode and source code statements, ABI, and the abstract syntax tree AST;

[0065] Use the depth - first algorithm to find the AST, and obtain the names, initial values, and variable types of state variables in the contract. First, traverse the key - value pairs of the AST. The key is an attribute name of the node (such as "type", "name"), and the value is the corresponding value. Then, check whether the value of the current node is "VariableDeclaration", indicating that the node is a variable declaration node. Add the variable name to the sta_variable list, add its corresponding initial value to the init_value dictionary in the form of key - value pairs, and add its corresponding variable type to the type dictionary in the form of key - value pairs. Finally, recursively execute this method, using the value value of the current node as the new AST input, and continue to traverse the child nodes. The set of names, initial values, and variable types of the generated state variables is collectively called state variable information.

[0066] II. The parameterization stage described in the present invention specifically includes the following steps: data operation perception stage, parameterization stage, and state variable range extraction stage.

[0067] 2 - 1. Data operation perception stage: Initialize the population based on the genetic algorithm, perform the first - round fuzzing loop, obtain the dynamic opcodes executed by each function, and get the list of state variables to be parameterized. The specific steps are as follows:

[0068] 2 - 1 - 1. For a smart contract to be tested with m functions, first initialize the population population = {seed1, seed2, …, seed m} according to the method of the fuzzing tool Confuzzius. This population contains m initialization seeds. Confuzzius defines that each seed consists of a sequence of functions. The function sequence of the initialization seed only contains a single non - repeating function, and randomly generates input data according to the parameter types of each function in the ABI.

[0069] 2 - 1 - 2. Perform the first - round fuzzing loop, execute each seed one by one, and obtain the dynamic opcodes executed by each function;

[0070] 2 - 1 - 3. Trace the SLOAD and SSTORE opcodes and their operation addresses to retrieve the access patterns of runtime state variables, and record the state variables read (SSLOAD) and written (SSTORE) by each function in the contract, and store them as the read state variable dictionary D read of the function and the write state variable dictionary D write of the function;

[0071] 2 - 1 - 4. For the read state variable dictionary D read of the function and the write state variable dictionary D writeTake the intersection of the state variables in it, count the state variables in the contract that can be read and written, and record them as the list of state variables to be parameterized parastate = [ps1, ps2, … ps m .

[0072] 2-2. Parameterization stage: Traverse the state variables in the list of state variables, perform function matching, and add input parameters with the same name and type as the state variables to the input parameters to obtain a substitute contract. The specific steps are as follows:

[0073] 2-2-1. Traverse the list of state variables to be parameterized parastate obtained in 2-1-3. For each state variable psi to be parameterized, traverse the read state variable dictionary D read and the write state variable dictionary D write of the function to match the function that reads or writes the state variable psi;

[0074] 2-2-2. Modify the function matched in the 2-2-1 stage. First, use the regular expression re.compile(r"function\s+(\w+)\s*\(([^)]*)\)\s*(public|external|internal|private)?\s*{?") to match the entire line of code where the function declaration is located; then use the regular expression re.compile(r"\(([^)]*)\)") to further locate the input parameter part within the parentheses in the function declaration; finally, according to the state variable information extracted in 1-3, confirm the i variable type of ps i and add an input parameter with the same name and type as the state variable ps

[0075] to the input parameters, which is called a substitute parameter. The modified function is the substitute function of the original function;

[0076] 2-3. State variable range extraction stage: In the static opcode sequence, identify the arithmetic operations related to the state variables, extract the corresponding program counter, extract the variable name and arithmetic step length for the operation, and use the substitute contract as the program to be tested to regenerate the population. The specific steps are as follows:

[0077] 2-3-1. Based on the statistical analysis of the operations on the state variables of the smart contract, four opcodes, namely addition (ADD), subtraction (SUB), multiplication (MUL), and division (DIV), are matched because they have the highest frequencies in the modification of state variables. In the static opcode sequence in 1-1, identify the above four arithmetic operations. For each identified opcode, check whether there is an EQ instruction in its preceding and succeeding instructions to determine whether the operation affects the judgment of the branch condition;

[0078] 2-3-2. For the matched arithmetic operations, extract the corresponding program counter pc, scan the source_map to obtain the source code statement line related to the program pc, and record all the hit results in the variable operation list lines;

[0079] 2-3-3. Traverse each source code statement line in the variable operation list lines, and extract the variable name and operation step of the operation. First, call.lstrip() to remove the whitespace characters of line, and intercept the first 6 characters ([0:6]) of the statement, denoted as the code field; then define the regular expression re.compile(code + ".*?" + ";") to determine the code line result that modifies the variable in line; then traverse whether the characters in result contain the operators of addition (+), subtraction (-), multiplication (*), and division ( / ). For the code lines that do not contain them, no further analysis will be performed; finally, define four types of regular expressions re.compile(r'[\w]+'), re.compile(r'[\w]-'), re.compile(r'[\w]*'), and re.compile(r'[\w] / ') to extract the operation object names name and operation steps step of the four different operations;

[0080] 2-3-4. Check name, match the name in the state variable information obtained in 1-3, traverse all the keys in the state variable information dictionary in step 1-3, and determine whether it is equal to the variable name name extracted in step 2-3-3 to confirm that the variable performing the operation is a state variable, rather than a temporary variable or a function parameter;

[0081] 2-3-5. Check step. First, determine whether step is msg.value or a function name in the ABI. When the above judgment hits, set the value of step to r, indicating any value (random); finally, determine whether step is a number. If it is, keep it, otherwise discard this value range;

[0082] 2-3-6. After the checks on name and step, combine the status variable information (name, type, initvalue) in 1-3 with the step size step to generate a string in the format of opcode_type_initvalue_step for the value range of the status variable name; when a certain status variable name i involves multiple operations, generate multiple different value ranges and store them in the corresponding list RangeList i =[opcode i1 _type i _initvalue i _step i1 ,…,opcode in _type i _initvalue i _step in . Integrate all status variables and their corresponding value range lists into a dictionary RangeDict = {name1: RangeList1, …, name n : RangeList n} as keys and values respectively;

[0083] 2-3-7. Use the proxy contract as the program under test, regenerate the population according to the method in 2-1-1, and enter the fuzz testing phase.

[0084] III. In the fuzz testing phase described in the present invention, as Figure 2 shown, it specifically includes the following steps: the proxy parameter mutation phase and the vulnerability verification phase.

[0085] 3-1. In the proxy parameter mutation phase, initialize the mutation pool. For the seeds that have been executed, inject taints to generate symbolic constraints, use the symbolic solver to solve the symbolic constraints and store the results in the mutation pool. For the seeds to be mutated, generate random values as mutation values according to the variable types of the proxy parameters and perform legality checks. Specifically, it includes the following steps:

[0086] 3-1-1. Initialize the mutation pool for storing the mutation values obtained by symbolic taint analysis; the mutation pool supports reusing the previously solved legal values during the testing process to replace the current values of the proxy parameters;

[0087] 3-1-2. For the executed seeds, analyze their opcode sequences, identify opcode related to data transfer (such as CALLDATALOAD, CALLVALUE), inject taints and track their propagation in the stack, memory, and storage, generate symbolic constraints and solve the constraints using a symbolic solver (such as Z3), and store the mutated values in the list of corresponding variables in the mutation pool;

[0088] 3-1-3. For the seeds to be mutated, select the mutated values from the mutation pool as the substitution parameter values of the current seeds, or when the mutation pool is empty, generate random values as the mutated values according to the variable types of the substitution parameters;

[0089] 3-1-4. Conduct a legality check on the used mutated values, find the value range opcode_type_initvalue_step of the state variable with the same name corresponding to the substitution parameter, and obtain that the acceptable range is the hash value of the opcode operation with initvalue as the initial value and step as the step size. When there are multiple value ranges, passing the check as long as one of them is satisfied. If the legality check is passed, assign the mutated value to the substitution parameter; if the legality check fails, discard the data and generate a random value according to the variable type of the substitution parameter and repeat the range check.

[0090] 3-2. In the vulnerability detection stage, as Figure 3 shown, construct a two-dimensional influence array. When a vulnerability is detected on the substitution contract, extract the names and values of the substitution parameters in the test case that triggers the vulnerability, record the target values of the corresponding state variables, and use the influence array to solve the function sequence that can make the state variables in the original contract reach the target values, and observe whether the same vulnerability can be triggered for verification. Specifically, it includes the following steps:

[0091] 3-2-1. Construct a two-dimensional influence array Effect: Extract the list of function names of the smart contract F = [f1, f2,..., f m , for each function f i , check whether it modifies the state variable s j in the list of state variables sta_variable generated in the preprocessing stage, extract the value initvalue ij , operation type op ij (such as ADD, SUB, MUL or DIV) and step size step ij from the corresponding value range of this state variable, and record it as Effect[f i [s j =(op ij , step ij , initvalue ij ), indicating the i-th function fi The modification of the j-th state variable s j is performed by an op ij operation with initvalue ij as the initial value and step ij as the step size;

[0092] 3-2-2. When the proxy contract detects a vulnerability, extract the name and value of the proxy parameters in the test case that triggers the vulnerability, and record them as the target values that the corresponding state variables need to reach;

[0093] 3-2-3. Use the pre-constructed influence array Effect to solve the function sequence that makes the state variables in the original contract reach the target values. Traverse the influence array Effect to identify the functions that affect the target state variables, their operation types, and step sizes. Initialize an empty function sequence, iteratively add function calls, and update the state variable values based on the operation types and step sizes. Verify whether the sequence makes the state variables reach the target values. If there are multiple feasible sequences, preferentially select the function sequence with the fewest function calls. If there are multiple value ranges for the target state variable, construct an operation combination space. Take the operation types and step sizes of each constraint as independent paths, judge the possible operation sequence combinations to reach the target value, and obtain the corresponding function sequences;

[0094] 3-2-4. If the function sequence is successfully solved, deploy the original contract on the virtual machine and use this sequence to test the original contract to observe whether the same vulnerability can be triggered; if so, confirm that the vulnerability is real; if the function sequence cannot be constructed or the test results are inconsistent, mark the vulnerability as a false positive.

[0095] Experimental results:

[0096] To verify the effectiveness of the present invention, three groups of experiments were conducted. The method ParaFuzz of the present invention was compared with the advanced smart contract fuzzer Confuzzius and the variant fuzzer of ParaFuzz, and evaluated on two datasets. The first dataset was statistically obtained from the blockchain browser Etherscan and the datasets used by other fuzzers, and contained 448 smart contracts; the second dataset was 10 smart contracts selected from the blockchain browser Etherscan that contained only single state variables and 6 multi-state variables.

[0097] The variant fuzzer is ParaFuzz-NP, which removes the function of proxy parameter mutation, making the parameterized results of the state variables perceived by data operations ineffective, and is used to evaluate the effectiveness of the state variable parameterization method of ParaFuzz.

[0098] Experiment 1: On Dataset 1, ParaFuzz can identify a larger number of vulnerabilities. The number of detections for five types of vulnerabilities, namely Re-entrancy (RE), Integer Overflow (OF), Assertion Failure (AF), Block Dependency (BD), and Unprotected Self-Destruction (US), is 394, accounting for 87.9% of the total 448, which is 57.8% higher than Confuzzius. In terms of the recall rate for the five types of vulnerabilities, it has a significant improvement compared to the fuzz testing tool Confuzzius, with the maximum difference being 72% and the minimum being 38%. The accuracy rate for the detection of the five types of vulnerabilities all reaches over 90%, with the maximum difference compared to the fuzz testing tool Confuzzius being 36.4% and the minimum being 13.5%.

[0099] Experiment 2: On Dataset 1, the total testing time of ParaFuzz is 2214.19 seconds, while that of ConFuzzius is 949.23 seconds, with a difference of 3.53 times. Among them, the average vulnerability detection time of ParaFuzz is 16.4 seconds, while that of ConFuzzius is 2.4 seconds, with a difference of nearly 6.83 times. Then, the "unique test cases" generated are counted. Since these test cases can drive the fuzzer to explore new execution paths, ConFuzzius has a lower rate of generating unique test cases and requires a larger average number of unique test cases to detect each vulnerability. Finally, the branch coverage is counted. The coverage rate of ParaFuzz for smart contracts is more than 10% higher than that of ConFuzzius. In addition, the time required for ParaFuzz to reach the highest coverage rate is significantly less than that of ConFuzzius, and the growth rate of its branch coverage is always faster than that of ConFuzzius. These improvements further confirm the effectiveness of the method.

[0100] Experiment 3: The ablation effect of the state variable parameterization strategy is shown in Table 1

[0101] Table 1. Executability rate after program repair

[0102]

[0103] The function of dummy parameter mutation was removed in ParaFuzz, making the results of state variable parameterization unable to be invalidated. ParaFuzz-NP and ParaFuzz were tested on Dataset 1.

[0104] In terms of the recall rates of detecting five types of vulnerabilities, namely reentrancy vulnerability, integer overflow vulnerability, assertion failure vulnerability, block dependency vulnerability, and unprotected self-destruction vulnerability, ParaFuzz is approximately 2%, 0%, 2%, 1%, and 0% higher than ParaFuzz-NP respectively; in terms of the precision rates of detecting these five types of vulnerabilities, ParaFuzz is approximately 29%, 19%, 23%, 12%, and 19% higher than ParaFuzz-NP respectively.

[0105] Experiment 3: The detection results of the vulnerability verification strategy are shown in Table 2:

[0106] Table 2 Detection Results of Vulnerability Verification Strategy

[0107]

[0108] The number of successfully verified vulnerability detections was tested on Dataset 2. Among them, all vulnerabilities can be successfully verified on contracts containing a single state variable; most vulnerabilities were successfully verified on contracts containing multiple state variables.

[0109] Result Analysis:

[0110] The state variable parameterization strategy significantly improves ParaFuzz's ability to break through branches. By solving the constraints of branch conditions and specifically mutating the surrogate parameters, ParaFuzz can efficiently explore the state space of smart contracts and quickly construct seeds that satisfy the branch conditions. Compared with the method of generating function sequences based on RAW data dependencies, this strategy reduces the generation of invalid seeds, thus significantly improving the branch coverage rate and test efficiency.

[0111] In terms of vulnerability verification, ParaFuzz provides an efficient verification mechanism. For smart contracts involving only a single state variable, ParaFuzz can accurately verify vulnerabilities, significantly reducing the false positive rate; for complex contracts containing multiple state variables, ParaFuzz verifies the target values of state variables by constructing function call sequences, showing good verification results. This mechanism effectively reduces the number of false positive vulnerabilities and improves the accuracy and reliability of vulnerability detection.

[0112] The above shows and describes the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited by the above embodiments. The above embodiments and descriptions in the specification are only preferred examples of the present invention and are not used to limit the present invention. Without departing from the spirit and scope of the present invention, the present invention will have various changes and improvements, and these changes and improvements all fall within the scope of the present invention claimed. The scope of protection claimed by the present invention is defined by the appended claims and their equivalents.

Claims

1. An intelligent contract fuzz testing method based on state variable parameterization, characterized in that, It includes the following stages: Preprocessing stage: Obtain the smart contract program to be tested, compile it using a static analysis tool, extract compilation information, and generate state variable information based on the depth-first algorithm; Parameterization stage: Initialize the population based on the genetic algorithm and perform a single-round test of the smart contract to confirm the set of state variables to be parameterized, add substitute parameters with the same name and type as the state variables, and generate a substitute contract corresponding to the original smart contract; Fuzz testing stage: Check whether the substitute parameters meet the constraints of the value range, determine whether to perform mutation, and during the fuzz testing process of the substitute contract, verify the values of the substitute parameters in the seeds that trigger vulnerabilities.

2. The intelligent contract fuzz testing method based on state variable parameterization according to claim 1, wherein The specific process of the preprocessing stage is as follows: S1-1. Obtain the program to be tested, which is the smart contract code; S1-2. Compile the program to be tested using a static analysis tool to obtain compilation information including static opcodes, the opcode and source code statement mapping table source_map, ABI, and abstract syntax tree AST; S1-3. Use the depth-first algorithm to search the AST to obtain the state variable information in the contract, including the name, initial value, and variable type of the state variables.

3. The intelligent contract fuzz testing method based on state variable parameterization according to claim 2, characterized in that, The parameterization stage includes: data operation perception sub-stage, state variable parameterization sub-stage, and state variable range extraction sub-stage. The specific implementation process is as follows: S2-1. Data operation perception sub-stage: Initialize the population based on the genetic algorithm, perform the first-round fuzz testing loop, obtain the dynamic opcodes executed by each function, and obtain the list of state variables to be parameterized; S2-2. State variable parameterization sub-stage: Traverse the state variables in the state variable list, perform function matching, and add input parameters with the same name and type as the state variables to the input parameters to obtain a substitute contract; S2-3. State variable range extraction sub-stage: In the static opcode sequence, identify the arithmetic operations related to the state variables, extract the corresponding program counters, extract the variable names and arithmetic step sizes for the operations, use the substitute contract as the program to be tested, and regenerate the population.

4. The method for fuzz testing of smart contracts based on state variable parameterization according to claim 3, wherein, The specific implementation of the data operation perception sub-stage is as follows: S2-1-1. Initialize the population based on the genetic algorithm, and the seeds in the population execute different single contract functions; S2-1-2. Perform the first-round fuzz testing loop, execute each seed one by one, and obtain the dynamic opcodes executed by each function; S2-1-3. Trace and read the SLOAD and store the SSTORE opcodes and their operation addresses, retrieve the access patterns of runtime state variables, and store them separately as the read state variable dictionary D of the function read and the write state variable dictionary D of the function write ; S2-1-4. Read the state variable dictionary D of the function read and the write state variable dictionary D of the function write Take the intersection of the state variables in to obtain the list of state variables to be parameterized.

5. The intelligent contract fuzz testing method based on state variable parameterization according to claim 4, wherein The specific implementation of the state variable parameterization sub-stage is as follows: S2-2-1. Traverse the state variables in the list of state variables to be parameterized, and match the functions for reading or writing state variables in D read and D write ; S2-2-2. Modify the function matched in S2-2-1. First, use regular expressions to match the code where the function declaration is located; Then use regular expressions to locate the input parameter part in the function declaration; finally, combine the state variable information and add input parameters with the same name and type as the state variables to the input parameters, which are called substitute parameters; S2-2-3. Repeat the processes of S2-2-1 and S2-2-2 until all the state variables in the state variable list are parameterized. At this time, the smart contract with the modified source code is called a substitute contract.

6. The intelligent contract fuzz testing method based on state variable parameterization according to claim 5, characterized in that The specific implementation of the state variable range extraction sub-stage is as follows: S2-3-1. In the static opcode, identify the arithmetic operations related to state variables, and preferentially match the four opcodes of addition, subtraction, multiplication, and division; S2-3-2. For the matched arithmetic operations, extract the corresponding program counter, scan the source_map to obtain the source code statements related to the program counter, and record all the hit results in the variable operation list; S2-3-3. Traverse each source code statement in the variable operation list, and use regular expressions to extract the variable name name and operation step step for the operation; S2-3-4. Check whether name is the state variable name included in the state variable information, and check step to determine whether step comes from fixed step data or a function call; S2-3-5. Combine the state variable information with step, and generate a string in the format of opcode_type_initvalue_step based on the state variable name; When the state variable involves multiple operations, multiple different value ranges are generated and stored in the corresponding list RangeList i =[opcode i1 _type i _initvalue i _step i1 ,…,opcode in _type i _initvalue i _step in ; All state variables and their corresponding lists of value ranges are integrated into a dictionary RangeDict = {name1: RangeList1, …, name n : RangeList n}; S2-3-7. Use the proxy contract as the program under test, regenerate the population, and enter the fuzz testing loop.

7. The intelligent contract fuzz testing method based on state variable parameterization according to claim 6, characterized in that The specific implementation process of the fuzz testing stage is as follows: S3-1. Initialize the mutation pool. For the executed seeds, inject taints to generate symbolic constraints, use a symbolic solver to solve the symbolic constraints and store the results in the mutation pool. For the seeds to be mutated, generate random values as mutation values according to the variable types of the proxy parameters, and perform legality checks; S3-2. Construct a two-dimensional impact array. When a vulnerability is detected in the proxy contract, extract the names and values of the proxy parameters in the test case that triggers the vulnerability, record the target values of the corresponding state variables, use the impact array to solve the function sequence that can make the state variables in the original contract reach the target values, and observe whether the same vulnerability can be triggered for verification.

8. The intelligent contract fuzz testing method based on state variable parameterization according to claim 7, wherein The specific implementation process of S3-1 is as follows: S3-1-1. Initialize the mutation pool to store the mutation values obtained by symbolic taint analysis; the mutation pool supports reusing the legal values obtained by symbolic solving in subsequent steps to replace the current values of the proxy parameters; S3-1-2. For the executed seeds, analyze their opcode sequences, program counters, and execution stacks, identify the opcodes related to data transfer, inject taints and track their propagation in the stack and memory, generate symbolic constraints, and use a symbolic solver to solve the symbolic constraints and store the results in the mutation pool; S3-1-3. For the seeds to be mutated, select mutation values from the mutation pool as the values of the proxy parameters of the current seeds; when the mutation pool is empty, generate random values as mutation values according to the variable types of the proxy parameters; S3-1-4. Perform a legality check on the mutation values to ensure that they conform to the value range of the state variables extracted in S2-3; if the legality check passes, assign the mutation values to the proxy parameters to generate new test cases; if the legality check fails, generate random values according to the variable types of the proxy parameters and repeat the range check.

9. The intelligent contract fuzz testing method based on state variable parameterization according to claim 8, wherein, The specific implementation process of S3-2 is as follows: S3-2-1. Construct a two-dimensional impact array Effect: Extract the function name list F = [f1, f2, …, f m of the smart contract. For each function f i , check whether it modifies the state variables in the state variable list generated in the preprocessing stage, and extract the value initvalue ij , operation type op ij , and step size step ij from the corresponding value range of the state variable, and record it as Effect[f i [s j = (op ij , step ij , initvalue ij ), indicating that the i-th function f i modifies the j-th state variable s j in a way that is an op ij operation with initvalue ij as the initial value and step ij as the step size; S3-2-2. When a vulnerability is detected in the proxy contract, extract the names and values of the proxy parameters in the test case that triggers the vulnerability, and record the target values of the corresponding state variables; S3-2-3. Use the influence array Effect to solve the function sequence that can make the state variables in the original contract reach the target values; the function sequence consists of function calls that affect the state variables and satisfies the constraints of the operation types and step sizes in Effect; S3-2-4. If the function sequence is successfully solved, deploy the original contract on the virtual machine, use this sequence to test the original contract, and observe whether the same vulnerability can be triggered; if so, confirm that the vulnerability is real; If the sequence cannot be constructed or the test results are inconsistent, mark the vulnerability as a false positive.

Images