Intelligent contract vulnerability mining method based on feedback information fuzzy test

Abstract

The invention discloses an intelligent contract vulnerability mining method based on feedback information fuzzy testing. Comprising the following steps: in a static analysis stage, converting a contract source code into an abstract syntax tree, extracting a control flow graph and function list information of a contract, and defining a function sequence priority calculation method; in the seed pool and test transaction construction stage, a seed pool is initialized, and a variation mode of a transaction sequence is defined. Then the system performs instrumentation in the EVM for collecting feedback information and defining judgment modes of different types of contract vulnerabilities; in the dynamic test stage, a mass fraction formula of a seed case is designed, whether the seed case is reserved or not is determined by comparing mass fractions, the seeds are varied according to a certain probability, and a seed pool is updated. According to the method, the fuzzy test technology based on the feedback information in the test process is constructed and is used for carrying out the vulnerability mining task for the smart contract, more deep states of the smart contract can be explored, and the efficiency and the accuracy of the vulnerability mining task are improved.

Description

Technical Field

[0001] The present invention belongs to the field of network security, and specifically designs a smart contract vulnerability mining method based on feedback information fuzzy testing. Background Art

[0002] As blockchain technology matures, blockchain platforms and decentralized applications are growing exponentially. Smart contract technology running on the top of the blockchain system has been widely used in financial management, the Internet of Things, and medical fields due to its decentralized, tamper-proof, open and transparent characteristics. Smart contracts, combined with blockchain technology, have realized more complex control logic functions under the premise of decentralized storage, and can meet more complex business needs. But at the same time, there are potential security risks. Smart contracts have the tamper-proof characteristics that cannot be modified once deployed, which also leads to inestimable losses once vulnerabilities occur. Therefore, vulnerability detection for smart contracts has become an important topic that needs to be studied urgently. Fuzz testing technology has become the current mainstream automated vulnerability detection technology due to its high degree of automation and excellent detection effect. Therefore, applying fuzz testing technology to vulnerability mining tasks in the field of smart contracts has high application value.

[0003] In the early stage, vulnerability mining of smart contracts was mainly carried out through manual audit, static analysis, symbolic execution and formal verification. Oyente takes bytecode as input, builds control flow graph through analysis, and uses constraint solver to remove unreachable paths. However, as the code size of smart contracts continues to increase, symbolic execution technology has encountered the problem of path explosion. ContractFuzzer extracts the source code and application binary interface of the contract, analyzes the parameter data type and function signature of the ABI function to generate test cases, and monitors the test process by inserting EVM. However, the whole process has the problems of low efficiency and low coverage. sFuzz combines the fuzz strategy in AFL, uses a lightweight multi-target adaptive strategy for difficult-to-cover branches, generates multiple transaction sequences by automatically deploying blockchain network smart contracts, and uses a quantitative strategy: calculating the distance to determine the change in the distance between a seed and the branch that is not touched.

[0004] However, the above smart contract fuzz testing tools all construct initial test cases after obtaining basic information of the contract through static analysis, and use traditional fuzz testing methods to dynamically run the contract for vulnerability mining. This method has the problem of being unable to identify key functions in the contract and functions that may have vulnerabilities, resulting in reduced test efficiency and low coverage, and it is impossible to test branch paths with complex conditions in a targeted manner. How to improve the code coverage and test efficiency of contracts during the test run is one of the important technical issues in this field. Summary of the invention

[0005] The mainstream smart contract fuzz testing technology has the following problems: it cannot identify the key functions of the smart contract technology and the functions that are more likely to have vulnerabilities in the contract, it cannot trigger complex conditional branch paths, and the generated test transaction sequence is illogical or insufficient to reach the state of triggering contract vulnerabilities, resulting in low testing efficiency. In order to solve the above problems, the present invention discloses a smart contract vulnerability mining method based on feedback information fuzz testing.

[0006] According to the method disclosed in the present invention, the testing process includes a contract static analysis phase, a seed pool and a test transaction sequence construction phase, an EVM plugging phase, a vulnerability analysis phase, and a dynamic testing phase;

[0007] S1. Static analysis phase: The system collects corresponding code information through static analysis based on the contract code provided by the user;

[0008] S1-1. Extract the Abstract Syntax Tree (AST) of the source code;

[0009] Specifically: the system compiles the smart contract source code provided by the user through the solc tool to obtain the ABI file, and converts it into the JSON file of Solidity's AST as the input of the Slither tool;

[0010] S1-2. Extract the control flow graph (CFG) of the contract;

[0011] After data integration, the system uses the Slither tool to generate the control flow graph G of the contract S =(B, i, E), where B represents a limited set of basic blocks in the contract. represents the initial position of the basic block (e.g., the starting point of the contract), and E represents the set of labeled edges;

[0012] S1-3. Extract the contract function list L fun ;

[0013] The system uses the Slither tool to extract the function list of the contract and the total number of functions M, where F is a mapping table containing function names , fi is the function name, P is the parameter tuple of the function , where i corresponds to the mapping of the function name and j represents the jth parameter type;

[0014] S1-4. Calculate the function order priority:

[0015] Specifically, the system uses the Slither tool to translate the contract code into Slither IR (an internal representation language). On this basis, the Slither tool reads the global variable V in the function through a predefined analysis, calculates the order priority (OP) of the function through the function global variable, and sorts F from large to small according to OP in combination with S1-3, and builds a mapping table between function name and OP. , get the dependency relationship between functions, and assist in the subsequent generation of transaction sequences that conform to the function dependency relationship. , where i is the i-th function and N is the total number of global variables contained in the function;

[0016] S2. Seed pool and test transaction construction phase: The system constructs the seed pool and constructs the transaction sequence and designs the variation method;

[0017] S2-1. Construction of initial seed pool S0: The system constructs the initial seed pool S0 through the information obtained in S1;

[0018] S2-1-1. Blockchain network configuration and initialization

[0019] The system generates a tuple δ to represent the network configuration of the seed being tested, which is defined as δ=(n, t, Add, balance, V), where n represents the currently executed blockchain number, t represents the timestamp of the current block, Add represents the contract address and the address set of its associated contracts, balance represents the initial balance allocated to the contract, and V represents the initial value of the state variable in the contract;

[0020] Initially, the system defaults to δ0, where n=0, t=0, Add={0xf0}, balance={0xff00..}, and V consists of the default values ​​in the contract;

[0021] S2-1-2. Function call sequence construction

[0022] During the test, the system uses a series of transaction sequences consisting of function calls to test the contract. A transaction sequence is represented as , m represents a call to a function;

[0023] Generate P in accordance with the collection in S1-3 by random generation i The actual parameter value of the function parameter type constraint in, where m0 must be the call to the construction contract function;

[0024] The transaction sequence Ʃ is created as a transaction TX through the transaction building module of the sFuzz tool;

[0025] S2-1-3. Initialize seed pool S0:

[0026] The system generates a set S in memory, which stores the encoded seeds;

[0027] Each seed generated by the system is represented by a tuple T = (δ, Ʃ) consisting of the elements generated in S2-1 and S2-2;

[0028] The set S is initially represented as S0, which contains the initial configuration of the contract and different function call sequences. If the user provides a contract containing n functions, the system randomly generates n call sequences for different functions according to the function parameter types extracted from S1-3 to ensure that the function coverage is 100%. Ʃ only contains the construction contract function and the test function, where the parameter value of the test function is randomly generated by the system;

[0029] S2-2. Transaction sequence mutation stage: The system combines the OP value calculated in S1-4 to mutate the transaction sequence in the seed pool to construct a new test case;

[0030] S2-2-1. Mutation process based on function call:

[0031] S2-2-1-1. Add mutations to the test transaction sequence according to OP:

[0032] The system mutates the test transaction sequence according to the OP value calculated in S1-4;

[0033] Test sequence , the system randomly selects a function call other than the constructor call m0 from the test transaction sequence , randomly select a function fj with a sequence number greater than i from the mapping table F of S1-4;

[0034] The system obtains the function f according to the function parameter tuple information generated in S1-3. j Parameter constraint information, randomly generate j Each parameter type in arg j The actual parameters of the constraint form a function call Insert into function call Before( ), forming a new transaction sequence ;

[0035] S2-2-1-2. Test transaction sequence deletion and mutation

[0036] The system can achieve more accurate contract construction by reducing the length of transaction sequences;

[0037] Test sequence , the system randomly selects a function call other than the constructor call m0 from the test transaction sequence , after deletion, a new transaction sequence is formed ;

[0038] S2-2-2. Mutation process based on function parameters:

[0039] The system tests the transaction sequence Perform parameter mutation operations and use the function parameter mutation module in the sFuzz tool to call all functions (except the constructor) Perform parameter mutation and transform into ;

[0040] The system generates a new test transaction sequence ;

[0041] S3. EVM instrumentation phase:

[0042] The system deploys smart contracts in the C++ Ethereum virtual machine cpp Ethereum and completes the contract testing process. During the dynamic testing process, a series of information needs to be collected, including seed information, opcode instruction information, and information used in the vulnerability analysis phase to determine the type of vulnerability in the tested smart contract. EVM needs to be instrumented;

[0043] The system collects three types of information during the EVM instrumentation phase: 1) seed execution information during testing; 2) various attributes about contract calls and state information; 3) opcodes called during smart contract execution, mainly jumpi instructions;

[0044] During the smart contract testing process, the EVM is instrumented to track the function calls of the contract, record the execution status of the function, and the parameter information of the function, which serves as the basis for the test module to judge the quality of the seed; at the same time, each basic block in the contract is instrumented to record the basic block ID to help collect feedback information in the subsequent dynamic testing process and calculate the quality score of the test case;

[0045] The system also collects the call, DelegateCall, and Send instructions of the contract during the test;

[0046] S4. Vulnerability analysis phase:

[0047] The system defines corresponding judgment conditions for different types, through the judgment conditions of different vulnerability types;

[0048] System generated collection , where O represents the judgment code for a specific type of vulnerability. The vulnerability analysis phase implementation method of the present invention is similar to the vulnerability monitoring method in sFuzz;

[0049] S5. Dynamic testing phase:

[0050] S5-1. Initial seed pool S0 vulnerability mining

[0051] S5-1-1. Initial seed pool S0 runs

[0052] The system uses the execution module (runner) of sFuzz to execute each seed use case T=(δ,Ʃ) in the initial seed pool S0. At the same time, the system uses the EVM hooking mechanism (hooking) to record each opcode executed by the EVM and create an event information E for each opcode. op , forming an operation code log, and designing the Crash indicator for each seed and initializing it to 0, which is used to record whether the seed triggers a vulnerability later;

[0053] During the execution of the current seed case T, the system collects the running time time.start and time.stop of the seed case, the number of basic blocks covered BN and the number of jumpi instructions JN (also used to calculate the path coverage), which are used to calculate the quality score of the seed later;

[0054] Event Information op Contains information about the stack, memory, the value of the program counter, and the currently executed opcode;

[0055] The operation code log contains every event information recorded during the seed operation. op ;

[0056] The running time time.start is the time record when the seed starts running, and time.stop is the time record when the seed stops running. The execution time of this seed is duration = time.stop-time.start;

[0057] The basic block coverage number BN is the number of basic blocks covered during the seed run, where the basic block information comes from the basic block information obtained in S1-2;

[0058] The system will traverse the operation code log to confirm the vulnerability according to the vulnerability judgment condition type specified in S4;

[0059] S5-1-2. Vulnerability Scanning

[0060] The system uses the operation code log recorded in S5-1-1 as the input of the vulnerability determination phase constructed in system S4, and determines whether the seed triggers the contract vulnerability by traversing the log information. If the vulnerability is triggered, the log report of the seed is output, and the Crash of the seed is set to 1;

[0061] S5-1-3. Seed pool update

[0062] S5-1-3-1. Seed case quality score formula

[0063] The present invention calculates the seed quality score Q according to the running time time.start and time.stop of the seed use case collected during the execution process, the number of basic blocks BN covered and the number of jumpi instructions JN as feedback information during the execution process. T ;

[0064] The system first calculates the average execution time of all seeds, average_time. The specific calculation method of seed quality score is shown in (5.2), where BN test is the number of basic blocks covered by the seed, BN total is the number of all basic blocks in the contract obtained by counting in S1-2, and Crash is the flag of whether the seed triggers the vulnerability. If it is not triggered, the value is 0, and if it is triggered, the value is 1:

[0065] +Crash (5.2)

[0066] S5-1-3-2. Calculate seed quality score based on feedback information

[0067] After all seed use cases in the initial seed pool S0 are executed, the system calculates the seed quality score Q for each seed use case through the running time time.start and time.stop of the seed use cases collected during the execution process in S5-1-1, the number of basic blocks covered BN and the number of jumpi instructions JN. T ;

[0068] S5-1-3-3. Seed pool update

[0069] The system records the quality score of the seed T=(δ, Ʃ) calculated through the feedback information and maintains a seed quality score mapping relationship (T:Q T );

[0070] The system mutates each seed with different probabilities: the system selects S2-2-1 with a probability of 0.4 to mutate the seed and generate a new seed T new , the new seed use case T new and T are saved in the seed pool S at the same time; S2-2-2 is selected with a probability of 0.4 to mutate the seed to generate a new seed T new , the new seed use case T newSave T to the seed pool S at the same time as T; with a probability of 0.2, no mutation is performed and T is directly saved to the new seed pool S. At this point, the first round of testing of the initialized seed pool S0 is completed;

[0071] S5-2. Vulnerability mining in seed pool S

[0072] S5-2-1. Seed pool S operation

[0073] The operating logic of the system in this stage is the same as S5-2. The execution module (runner) of sFuzz is used to execute each seed use case T=(δ, Ʃ) in the seed pool S. At the same time, the hooking mechanism of EVM is used to record each opcode executed by EVM, and an event information E is created for each opcode. op , forming an operation code log, and at the same time re-initializing the seed design indicator Crash to 0, which is used to subsequently record whether the seed triggers a vulnerability;

[0074] During the execution of the current seed case T, the system collects the running time time.start and time.stop of the seed case, the number of basic blocks covered BN and the number of jumpi instructions JN (also used to calculate the path coverage), which are used to calculate the quality score of the seed later;

[0075] The system will traverse the operation code log to confirm the vulnerability according to the vulnerability judgment condition type specified in S4;

[0076] S5-2-2. Vulnerability Scanning

[0077] The system uses the operation code log recorded in S5-2-1 as the input of the vulnerability determination phase constructed in system S4, and determines whether the seed triggers the contract vulnerability by traversing the log information. If the vulnerability is triggered, the log report of the seed is output, and the Crash of the seed is set to 1;

[0078] S5-2-3. Seed pool update

[0079] S5-2-3-1. Calculate seed quality score based on feedback information

[0080] After all seed use cases in the seed pool S are executed, the system calculates the seed quality score Q for each seed use case based on the quality score calculation method designed in S5-1-3-1, using the running time time.start and time.stop of the seed use cases collected during the execution process in S5-1-1, the number of basic blocks covered BN, and the number of jumpi instructions JN. T-new ;

[0081] S5-2-3-2. Seed pool update

[0082] The system compares the quality score Q obtained after executing this round of seeds T-new The quality score Q recorded before execution T The size of , then the seed is retained; otherwise, the seed is discarded and no subsequent operations are performed; the mapping relationship of the retained seed is updated (T:Q T );

[0083] The system mutates each seed with different probabilities: the system selects S2-2-1 with a probability of 0.4 to mutate the seed and generate a new seed T new , the new seed use case T new and T are saved in the seed pool S at the same time; S2-2-2 is selected with a probability of 0.4 to mutate the seed to generate a new seed T new , the new seed use case T new Save T to the seed pool S at the same time as T; with a probability of 0.2, no mutation is performed and T is directly saved to the new seed pool S. At this point, the test process of the seed pool S is completed;

[0084] The beneficial effects of the present invention compared with the prior art include:

[0085] The present invention uses the reading and writing operations of contract functions on global variables to calculate the sequential priority of functions, and uses the size of the sequential priority to generate function calls of the corresponding order. The generated transactions are logically more consistent with the use of contracts in real scenarios, so that vulnerabilities in real scenarios can be discovered more accurately. The information of seeds during execution is obtained by plugging, and the quality scores of seed use cases are designed. Seeds with better vulnerability mining capabilities are retained, and further function calls are added or function parameters are mutated for these seeds. This can further improve the coverage rate while effectively reducing the size of the seed pool, reduce the space overhead during the test, and thereby improve the test efficiency while increasing the possibility of exploring deeper contract states. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] Figure 1 The figure is a schematic diagram of the overall process of a smart contract vulnerability mining method based on feedback information fuzzy testing according to the present invention. DETAILED DESCRIPTION

[0087] Reference will now be made in detail to exemplary embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings.

[0088] A smart contract vulnerability mining method based on feedback information fuzz testing, such as Figure 1 As shown, it mainly includes 5 stages:

[0089] S1. Static analysis phase: The system collects corresponding code information through static analysis based on the contract code provided by the user;

[0090] S1-1. Extract the Abstract Syntax Tree (AST) of the source code;

[0091] Specifically: the system compiles the smart contract source code provided by the user through the solc tool to obtain the ABI file, and converts it into the JSON file of Solidity's AST as the input of the Slither tool;

[0092] S1-2. Extract the control flow graph (CFG) of the contract;

[0093] After data integration, the system uses the Slither tool to generate the control flow graph of the contract Composition, B represents a limited set of basic blocks in the contract, represents the initial position of the basic block (e.g., the starting point of the contract), and E represents the set of labeled edges;

[0094] S1-3. Extract the contract function list L fun ;

[0095] The system uses the Slither tool to extract the function list of the contract and the total number of functions M, where F is a mapping table containing function names , fi is the function name, P is the parameter tuple of the function , where i corresponds to the mapping of the function name and j represents the jth parameter type;

[0096] S1-4. Calculate the function order priority:

[0097] Specifically, the system uses the Slither tool to translate the contract code into Slither IR (an internal representation language). On this basis, the Slither tool reads the global variable V in the function through a predefined analysis, calculates the order priority (OP) of the function through the function global variable, and sorts F from large to small according to OP in combination with S1-3, and builds a mapping table between function name and OP. , get the dependency relationship between functions, and assist in the subsequent generation of transaction sequences that conform to the function dependency relationship, where , where i is the i-th function and N is the total number of global variables contained in the function;

[0098] gather , where i is the i-th function and N is the total number of global variables contained in the function. The variable name of the variable is represented by Represents the function F i right A read operation was performed. Represents the function F i right A write operation is performed. By obtaining the types of read and write operations performed by each function on the same global variable, the system calculates the function call priority OP. The definition of OP is as follows (1.1), where M is the number of functions included in the contract;

[0099] (1.1)

[0100] The calculation formula of cmp is defined as (1.2)

[0101] (1.2)

[0102] S2. Seed pool and test transaction construction phase: The system constructs the seed pool and constructs the transaction sequence and designs the variation method;

[0103] S2-1. Construction of initial seed pool S0: The system constructs the initial seed pool S0 through the information obtained in S1;

[0104] S2-1-1. Blockchain network configuration and initialization

[0105] The system generates a tuple δ to represent the network configuration of the seed being tested, which is defined as δ=(n, t, Add, balance, V), where n represents the currently executed blockchain number, t represents the timestamp of the current block, Add represents the contract address and the address set of its associated contracts, balance represents the initial balance allocated to the contract, and V represents the initial value of the state variable in the contract;

[0106] Initially, the system defaults to δ0, where n=0, t=0, Add={0xf0}, balance={0xff00..}, and V consists of the default values ​​in the contract;

[0107] S2-1-2. Function call sequence construction

[0108] During the test, the system uses a series of transaction sequences consisting of function calls to test the contract. A transaction sequence is represented as , m represents a call to a function;

[0109] Generate P in accordance with the collection in S1-3 by random generation iThe actual parameter value of the function parameter type constraint in, where m0 must be the call to the construction contract function;

[0110] The transaction sequence Ʃ is created as a transaction TX through the transaction building module of the sFuzz tool;

[0111] S2-1-3. Initialize seed pool S0:

[0112] The system generates a set S in memory, which stores the encoded seeds;

[0113] Each seed generated by the system is represented by a tuple T = (δ, Ʃ) consisting of the elements generated in S2-1 and S2-2;

[0114] The set S is initially represented as S0, which contains the initial configuration of the contract and different function call sequences. If the user provides a contract containing n functions, the system randomly generates n call sequences for different functions according to the function parameter types extracted from S1-3 to ensure that the function coverage is 100%; Ʃ only contains the contract construction function and the test function, where the parameter value of the test function is randomly generated by the system;

[0115] S2-2. Transaction sequence mutation stage: The system combines the OP value calculated in S1-4 to mutate the transaction sequence in the seed pool to construct a new test case;

[0116] S2-2-1. Mutation process based on function call:

[0117] S2-2-1-1. Add mutations to the test transaction sequence according to OP:

[0118] The system mutates the test transaction sequence according to the OP value calculated in S1-4;

[0119] Test sequence , the system randomly selects a function call other than the constructor call m0 from the test transaction sequence , randomly select a function fj with a sequence number greater than i from the mapping table F of S1-4;

[0120] The system obtains the function f according to the function parameter tuple information generated in S1-3. j Parameter constraint information, randomly generate j Each parameter type in arg j The actual parameters of the constraint form a function call Insert into function call Before( ), forming a new transaction sequence ;

[0121] S2-2-1-2. Test transaction sequence deletion and mutation

[0122] The system can achieve more accurate contract construction by reducing the length of transaction sequences;

[0123] Test sequence , the system randomly selects a function call other than the constructor call m0 from the test transaction sequence , after deletion, a new transaction sequence is formed ;

[0124] S2-2-2. Mutation process based on function parameters:

[0125] The system tests the transaction sequence Perform parameter mutation operations and use the function parameter mutation module in the sFuzz tool to call all functions (except the constructor) Perform parameter mutation and transform into ;

[0126] The system generates a new test transaction sequence ;

[0127] S3. EVM instrumentation phase:

[0128] The system deploys smart contracts in the C++ Ethereum virtual machine cpp Ethereum and completes the contract testing process. During the dynamic testing process, a series of information needs to be collected, including seed information, opcode instruction information, and information used in the vulnerability analysis phase to determine the type of vulnerability in the tested smart contract. EVM needs to be instrumented;

[0129] The system collects three types of information during the EVM instrumentation phase: 1) seed execution information during testing; 2) various attributes about contract calls and state information; 3) opcodes called during smart contract execution, mainly jumpi instructions;

[0130] During the smart contract testing process, EVM is instrumented to track the function calls of the contract, record the execution status of the function, and the parameter information of the function, which serves as the basis for the test module to judge the quality of the seed; at the same time, each basic block in the contract is instrumented to record the basic block ID to help collect feedback information in the subsequent dynamic testing process and calculate the quality score of the test case. Table 1 shows the information collected by instrumentation;

[0131] Table instrumentation collects seed execution information

[0132] information describe Seed execution time The start and end time of the seed execution Basic Block Coverage The basic block ID and number of basic blocks that the seed passes through Operation Code Each opcode executed by the seed and its related information (stack information, memory, value of the program counter and the currently executed opcode) Number of jumpi instructions Jump instructions, used to calculate path coverage

[0133] The system also needs to collect the call, DelegateCall, and Send instructions of the contract during the test. Table 2 shows the call instruction information collected by the instrumentation.

[0134] Table instrumentation collects call instruction information

[0135] Key instructions describe caller The contract caller's address callee The address of the called contract Function The function being called input Function parameter types and parameter values value The amount of ether sent to the called contract gas The gas value consumed by calling the instruction Internal_call Internal call of the contract opcode The contract's operation code

[0136] S4. Vulnerability analysis phase:

[0137] The system defines corresponding judgment conditions for different types, through the judgment conditions of different vulnerability types;

[0138] System generated collection , where O represents the judgment code for a specific type of vulnerability. The vulnerability analysis phase implementation method of the present invention is similar to the vulnerability monitoring method in sFuzz;

[0139] The vulnerability determination conditions are shown in Table 3:

[0140] Table Vulnerability Judgment Conditions

[0141] Vulnerability Type Vulnerability judgment conditions Reentrancy Vulnerability The original function is called more than once, and the ether sent is greater than 0; the called function has enough gas; the called contract is specified by the original contract caller; No gas delivery vulnerability The function call is made through the Send function, and the function call returns the error code ErrOutOfGas when executed; Abnormal disorder vulnerability A call in a nested call chain throws an exception; the original call does not throw an exception; DelegateCall Controlled Vulnerability The DelegateCall function makes a function call; the function parameters are specified by the current contract caller; Block dependency / timestamp dependency vulnerabilities The function call is made through the send function; the ether sent is greater than 0; the TIMESTAMP and NUMBER opcodes are executed; Ethereum Freezing Vulnerability Able to accept Ether; Function call is made through DelegateCall function; There are no transfer, send, call functions in the current contract code; Integer overflow vulnerability Ether was sent; the function performed arithmetic operations; no verification was performed before and after the arithmetic;

[0142] S5. Dynamic testing phase:

[0143] S5-1. Initial seed pool S0 vulnerability mining

[0144] S5-1-1. Initial seed pool S0 runs:

[0145] The system uses the execution module (runner) of sFuzz to execute each seed use case T=(δ,Ʃ) in the initial seed pool S0. At the same time, the system uses the EVM hooking mechanism (hooking) to record each opcode executed by the EVM and create an event information E for each opcode. op , forming an operation code log, and designing the Crash indicator for each seed and initializing it to 0, which is used to record whether the seed triggers a vulnerability later;

[0146] During the execution of the current seed case T, the system collects the running time time.start and time.stop of the seed case, the number of basic blocks covered BN and the number of jumpi instructions JN (also used to calculate the path coverage), which are used to calculate the quality score of the seed later;

[0147] Event Information op Contains information about the stack, memory, the value of the program counter, and the currently executed opcode;

[0148] The operation code log contains every event information recorded during the seed operation. op ;

[0149] The running time time.start is the time record when the seed starts running, and time.stop is the time record when the seed stops running. The execution time of this seed is duration = time.stop-time.start;

[0150] The basic block coverage number BN is the number of basic blocks covered during the seed run, where the basic block information comes from the basic block information obtained in S1-2;

[0151] The system will traverse the operation code log to confirm the vulnerability according to the vulnerability judgment condition type specified in S4;

[0152] S5-1-2. Vulnerability Scanning

[0153] The system uses the operation code log recorded in S5-1-1 as the input of the vulnerability determination phase constructed in system S4, and determines whether the seed triggers the contract vulnerability by traversing the log information. If the vulnerability is triggered, the log report of the seed is output, and the Crash of the seed is set to 1;

[0154] S5-1-3. Seed pool update

[0155] S5-1-3-1. Seed case quality score formula

[0156] The present invention calculates the seed quality score Q according to the running time time.start and time.stop of the seed use case collected during the execution process, the number of basic blocks BN covered and the number of jumpi instructions JN as feedback information during the execution process. T ;

[0157] The system first calculates the average execution time of all seeds, average_time, as shown in (5.1), where TotalNum is the number of seeds that are effectively executed, and T is the set of all seed use cases in the initial seed pool:

[0158] (5.1)

[0159] The specific calculation method of seed quality score is shown in (5.2), where BN test is the number of basic blocks covered by the seed, BN total is the number of all basic blocks in the contract obtained by counting in S1-2, and Crash is the flag of whether the seed triggers the vulnerability. If it is not triggered, the value is 0, and if it is triggered, the value is 1:

[0160] +Crash (5.2)

[0161] S5-1-3-2. Calculate seed quality score based on feedback information

[0162] After all seed use cases in the initial seed pool S0 are executed, the system calculates the seed quality score Q for each seed use case through the running time time.start and time.stop of the seed use cases collected during the execution process in S5-1-1, the number of basic blocks covered BN and the number of jumpi instructions JN. T ;

[0163] S5-1-3-3. Seed pool update

[0164] The system records the quality score of the seed T=(δ, Ʃ) calculated through the feedback information and maintains a seed quality score mapping relationship (T:Q T );

[0165] The system mutates each seed with different probabilities: the system selects S2-2-1 with a probability of 0.4 to mutate the seed and generate a new seed T new , the new seed use case T new and T are saved in the seed pool S at the same time; S2-2-2 is selected with a probability of 0.4 to mutate the seed to generate a new seed T new , the new seed use case T new Save T to the seed pool S at the same time as T; with a probability of 0.2, no mutation is performed and T is directly saved to the new seed pool S. At this point, the first round of testing of the initialized seed pool S0 is completed;

[0166] S5-2. Vulnerability mining in seed pool S

[0167] S5-2-1. Seed pool S operation

[0168] The operating logic of the system in this stage is the same as S5-2. The execution module (runner) of sFuzz is used to execute each seed use case T=(δ, Ʃ) in the seed pool S. At the same time, the hooking mechanism of EVM is used to record each opcode executed by EVM, and an event information E is created for each opcode. op , forming an operation code log, and at the same time re-initializing the seed design indicator Crash to 0, which is used to subsequently record whether the seed triggers a vulnerability;

[0169] During the execution of the current seed case T, the system collects the running time time.start and time.stop of the seed case, the number of basic blocks covered BN and the number of jumpi instructions JN (also used to calculate the path coverage), which are used to calculate the quality score of the seed later;

[0170] The system will traverse the operation code log to confirm the vulnerability according to the vulnerability judgment condition type specified in S4;

[0171] S5-2-2. Vulnerability Scanning

[0172] The system uses the operation code log recorded in S5-2-1 as the input of the vulnerability determination phase constructed in system S4, and determines whether the seed triggers the contract vulnerability by traversing the log information. If the vulnerability is triggered, the log report of the seed is output, and the Crash of the seed is set to 1;

[0173] S5-2-3. Seed pool update

[0174] S5-2-3-1. Calculate seed quality score based on feedback information

[0175] After all seed use cases in the seed pool S are executed, the system calculates the seed quality score Q for each seed use case based on the quality score calculation method designed in S5-1-3-1, using the running time time.start and time.stop of the seed use cases collected during the execution process in S5-1-1, the number of basic blocks covered BN, and the number of jumpi instructions JN. T-new ;

[0176] S5-2-3-2. Seed pool update

[0177] The system compares the quality score Q obtained after executing this round of seeds T-new The quality score Q recorded before execution T The size of , then the seed is retained; otherwise, the seed is discarded and no subsequent operations are performed; the mapping relationship of the retained seed is updated (T:Q T );

[0178] The system mutates each seed with different probabilities: the system selects S2-2-1 with a probability of 0.4 to mutate the seed and generate a new seed T new , the new seed use case T new and T are saved in the seed pool S at the same time; S2-2-2 is selected with a probability of 0.4 to mutate the seed to generate a new seed T new , the new seed use case T newSave T to the seed pool S at the same time as T; with a probability of 0.2, no mutation is performed and T is directly saved to the new seed pool S. At this point, the test process of the seed pool S is completed;

[0179] Finally, it should be noted that the above is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, it is still possible for those skilled in the art to modify the technical solutions described in the aforementioned embodiments or to make equivalent replacements for some of the technical features therein.

[0180] Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A smart contract vulnerability mining method based on feedback information fuzz testing, characterized in that: The methods include: S1: Static analysis stage: According to the contract code provided by the user, the corresponding code information is collected through static analysis to obtain the abstract syntax tree, control flow graph and function list information of the code, and the sequential priority of each function in the contract is calculated based on the collected code information; S2: Seed pool and test transaction construction phase: The system constructs the seed pool and constructs the transaction sequence and designs the mutation method. The seed pool is initialized by configuring the blockchain network configuration and generating the function call sequence, and the mutation method of the test transaction in the seed use case is defined; S3: EVM stub stage: The system deploys smart contracts in the C++ Ethereum virtual machine cpp Ethereum and completes the contract testing process. During the dynamic testing process, a series of information needs to be collected, including seed information, opcode instruction information, and information used in the vulnerability analysis phase to determine the type of vulnerability in the tested smart contract, and stub the EVM; S4: Vulnerability analysis phase: The system defines the criteria for determining different types of vulnerabilities; S5: Dynamic testing phase: The system runs the seed use cases in the seed pool while collecting feedback information during the execution process. It defines the quality score calculation method for the seed use cases, and decides whether to retain the seed use cases by comparing the quality scores of the seeds before and after execution. At the same time, it designs a method to select mutation methods for the seed use cases with a certain probability.

2. According to claim 1, a method for mining smart contract vulnerabilities based on feedback information fuzzy testing is characterized in that: In step S1: S1-1. Extract the abstract syntax tree of the source code; Specifically: the system compiles the smart contract source code provided by the user through the solc tool to obtain the ABI file, and converts it into the JSON file of Solidity's AST as the input of the Slither tool; S1-2. Extract the control flow graph (CFG) of the contract; After data integration, the system uses the Slither tool to generate the control flow graph of the contract composition, Represents a limited set of basic blocks in a contract, Indicates the initial position of the basic block (e.g. the starting point of the contract), represents a set of labeled edges; S1-3. Extract the contract function list L fun The system uses the Slither tool to extract the function list of the contract and the total number of functions M, where F is a mapping table containing function names , fi is the function name, P is the parameter tuple of the function , where i corresponds to the mapping of the function name and j represents the jth parameter type; S1-4. Calculate the function order priority: Specifically, the system uses the Slither tool to translate the contract code into Slither IR (an internal representation language). On this basis, the Slither tool reads the global variable V in the function through a predefined analysis, calculates the order priority (OP) of the function through the function global variable, and sorts F from large to small according to OP in combination with S1-3, and builds a mapping table between function name and OP. , get the dependency relationship between functions, and assist in the subsequent generation of transaction sequences that conform to the function dependency relationship, where , where i is the i-th function and N is the total number of global variables contained in the function.

3. A method for mining smart contract vulnerabilities based on feedback information fuzzy testing according to claim 1 or 2, characterized in that: In step S2: S2-1-3. Initialize seed pool S0: The system generates a set S in memory, which stores the encoded seeds; Each seed generated by the system is represented by a tuple T = (δ, Ʃ) consisting of the elements generated in S2-1 and S2-2; The set S is initially represented as S0, which contains the initial configuration of the contract and different function call sequences. If the user provides a contract containing n functions, the system randomly generates n call sequences for different functions according to the function parameter types extracted from S1-3 to ensure that the function coverage is 100%; Ʃ only contains the contract construction function and the test function, where the parameter value of the test function is randomly generated by the system; S2-2. Transaction sequence mutation stage: The system combines the OP value calculated in S1-4 to mutate the transaction sequence in the seed pool to construct a new test case; S2-2-1. Mutation process based on function call: S2-2-1-1. Add mutations to the test transaction sequence according to OP: The system mutates the test transaction sequence according to the OP value calculated in S1-4; Test sequence , the system randomly selects a function call other than the constructor call m0 from the test transaction sequence , randomly select a function fj with a sequence number greater than i from the mapping table F of S1-4; The system obtains the function f according to the function parameter tuple information generated in S1-3. j Parameter constraint information, randomly generate j Each parameter type in arg j The actual parameters of the constraint form a function call Insert into function call Before( ), forming a new transaction sequence ; S2-2-1-2. Test transaction sequence deletion and mutation The system can achieve more accurate contract construction by reducing the length of transaction sequences; Test sequence , the system randomly selects a function call other than the constructor call m0 from the test transaction sequence , after deletion, a new transaction sequence is formed ; S2-2-2. Mutation process based on function parameters: The system tests the transaction sequence Perform parameter mutation operations and use the function parameter mutation module in the sFuzz tool to call all functions (except the constructor) Perform parameter mutation and transform into ; The system generates a new test transaction sequence .

4. According to claim 1, a method for mining smart contract vulnerabilities based on feedback information fuzz testing is characterized in that: In step S3: The system collects three types of information during the EVM instrumentation phase: 1) seed execution information during testing; 2) various attributes about contract calls and state information; 3) opcodes called during smart contract execution, mainly jumpi instructions.

5. According to claim 1, a method for mining smart contract vulnerabilities based on feedback information fuzz testing is characterized in that: In step S4: The system defines corresponding judgment conditions for different types, through the judgment conditions of different vulnerability types; System generated collection , where O represents the judgment code for a specific type of vulnerability. The implementation method of the vulnerability analysis phase of the system is similar to the vulnerability monitoring method in sFuzz.

6. According to claim 1, a method for mining smart contract vulnerabilities based on feedback information fuzz testing is characterized in that: Collect seed feedback information during dynamic analysis and calculate the seed quality score: S5-1-1. Initial seed pool S0 runs: The system uses the execution module (runner) of sFuzz to execute each seed use case T=(δ,Ʃ) in the initial seed pool S0. At the same time, the system uses the EVM hooking mechanism (hooking) to record each opcode executed by the EVM and create an event information E for each opcode. op , forming an operation code log, and designing the Crash indicator for each seed and initializing it to 0, which is used to record whether the seed triggers a vulnerability later; During the execution of the current seed case T, the system collects the running time time.start and time.stop of the seed case, the number of basic blocks covered BN and the number of jumpi instructions JN (also used to calculate the path coverage), which are used to calculate the quality score of the seed later; Event Information op Contains information about the stack, memory, the value of the program counter, and the currently executed opcode; The operation code log contains every event information recorded during the seed operation. op ; The running time time.start is the time record when the seed starts running, and time.stop is the time record when the seed stops running. The execution time of this seed is duration = time.stop-time.start; The basic block coverage number BN is the number of basic blocks covered during the seed run, where the basic block information comes from the basic block information obtained in S1-2; The system will traverse the operation code log to confirm the vulnerability according to the vulnerability judgment condition type specified in S4; S5-1-2. Vulnerability Scanning The system uses the operation code log recorded in S5-1-1 as the input of the vulnerability determination phase constructed in system S4, and determines whether the seed triggers the contract vulnerability by traversing the log information. If the vulnerability is triggered, the log report of the seed is output, and the Crash of the seed is set to 1; S5-1-3-1. Seed case quality score formula The system calculates the seed quality score Q based on the running time time.start and time.stop of the seed case collected during the execution process, the number of basic blocks covered BN and the number of jumpi instructions JN as feedback information during the execution process. T ; The system first calculates the average execution time of all seeds, average_time. The specific calculation method of seed quality score is shown in (5.2), where BN test is the number of basic blocks covered by the seed, BN total is the number of all basic blocks in the contract obtained by counting in S1-2, and Crash is the flag of whether the seed triggers the vulnerability. If it is not triggered, the value is 0, and if it is triggered, the value is 1: +Crash (5.2) S5-1-3-2. Calculate seed quality score based on feedback information After all seed use cases in the initial seed pool S0 are executed, the system calculates the seed quality score Q for each seed use case through the running time time.start and time.stop of the seed use cases collected during the execution process in S5-1-1, the number of basic blocks covered BN and the number of jumpi instructions JN. T .

7. According to claim 1, a method for mining smart contract vulnerabilities based on feedback information fuzzy testing is characterized in that: During the dynamic analysis, the seed pool is updated according to the calculated seed quality score: S5-1-3-3. Seed pool update The system records the quality score of the seed T=(δ, Ʃ) calculated through the feedback information and maintains a seed quality score mapping relationship (T:Q T ); The system mutates each seed with different probabilities: the system selects S2-2-1 with a probability of 0.4 to mutate the seed and generate a new seed T new , the new seed use case T new and T are saved in the seed pool S at the same time; Select S2-2-2 with a probability of 0.4 to mutate the seed and generate a new seed T new , the new seed use case T new and T are saved in the seed pool S at the same time; With a probability of 0.2, no mutation is performed and T is directly saved in the new seed pool S. At this point, the first round of testing of the initialized seed pool S0 is completed. S5-2-3. Seed pool update S5-2-3-1. Calculate seed quality score based on feedback information After all seed use cases in the seed pool S are executed, the system calculates the seed quality score Q for each seed use case based on the quality score calculation method designed in S5-1-3-1, using the running time time.start and time.stop of the seed use cases collected during the execution process in S5-1-1, the number of basic blocks covered BN, and the number of jumpi instructions JN. T-new ; S5-2-3-2. Seed pool update The system compares the quality score Q obtained after executing this round of seeds T-new The quality score Q recorded before execution T The size of , then the seed is retained; otherwise, the seed is discarded and no subsequent operations are performed; the mapping relationship of the retained seed is updated (T:Q T ); The system mutates each seed with different probabilities: the system selects S2-2-1 with a probability of 0.4 to mutate the seed and generate a new seed T new , the new seed use case T new and T are saved in the seed pool S at the same time; Select S2-2-2 with a probability of 0.4 to mutate the seed and generate a new seed T new , the new seed use case T new and T are saved in the seed pool S at the same time; With a probability of 0.2, no mutation is performed and T is directly saved in the new seed pool S. At this point, the test process of the seed pool S is completed.

Images