A smart contract vulnerability detection method

Abstract

The present invention discloses a smart contract vulnerability detection method. First, the smart contract is used as the input of the static processing stage. Secondly, the fuzzy testing system will reversely construct the test cases containing data flow dependency facts through the suspected vulnerability code line, and assign them to the fixed test case pool. At the same time, the test cases are randomly constructed using the optimization idea and assigned to the non-fixed test case pool. Finally, the fuzzy testing system dynamically executes the test cases in the two test case pools. For the non-fixed test case pool, the optimization of the test case includes transaction sequence optimization and parameter mutation, and the test case value judgment formula with comprehensive coverage information proposed by the present invention is used to guide the optimization process of the test case pool. The present invention effectively improves the test efficiency of the smart contract fuzzy test, can explore more paths in the tested smart contract, and can discover more contract vulnerabilities.

Description

Technical Field

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

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

[0003] Related work on smart contract vulnerability detection: SMARTIAN generates more effective transaction sequences by combining static and dynamic methods. The static analysis phase is also used to generate test cases with data dependencies and serve as elements of the initial test case pool for fuzz testing. CN202211633210 proposes a smart contract vulnerability detection method that performs basic detection through static analysis and generates test cases through symbolic execution. CN202210641690 proposes a smart contract reentrancy vulnerability detection method based on a combination of static and dynamic methods. It determines vulnerable tool functions through static analysis, and then automatically generates attacker contracts, executes interactions, and reproduces the reentrancy attack process.

[0004] However, the above-mentioned smart contract fuzz testing tools and patents all determine test cases based on static analysis execution, and optimize the test cases in the subsequent execution process. This method has a defect, that is, the test case optimization process will destroy the structure of valuable test cases. As a result, the optimized test cases are too long to be reproduced, or the length is reduced and the data dependency is lost. In addition, the above-mentioned tools and patent methods are not comprehensive enough in measuring the value of test cases, and it is difficult to characterize the true value of test cases after optimization, resulting in the loss of valuable test cases and reducing the efficiency of vulnerability detection. Summary of the invention

[0005] In view of the above problems, the present invention proposes a smart contract vulnerability detection method and system, which are characterized by: (1) Determine the suspected vulnerability code line through static analysis means, construct a fixed-length test case in reverse order, and continuously iterate the parameters to verify whether the vulnerability exists. (2) Retain the optimization means, randomly construct test cases of non-fixed length for continuous optimization to make up for the defects of static analysis means, that is, the defect of poor detection effect of logical vulnerabilities in the dynamic execution process. (3) Provide a value calculation formula with simple calculation and comprehensive coverage information to comprehensively measure whether a test case is worth continuing to optimize.

[0006] The present invention proposes a smart contract vulnerability detection method and system, which mainly includes three stages: static processing stage, pooling stage and dynamic execution stage. First, the smart contract is used as the input of the static processing stage, which mainly consists of two parts. First, the data dependency facts and the number of keyword code instructions of each function in the smart contract are analyzed by static tools; second, the static analysis tool is directly run on the smart contract to obtain suspicious vulnerability code lines. The stage results generated in this stage are used for the allocation of different test cases in the pooling stage and the execution of different test cases in the dynamic execution stage. Secondly, the fuzzy testing system will reversely construct test cases containing data flow dependencies through suspicious vulnerability code lines and allocate them to a fixed test case pool. At the same time, the idea of ​​test case optimization is retained for randomly constructing test cases and allocating them to a non-fixed test case pool. Finally, the fuzzy testing system dynamically executes test cases in two test case pools. In order to ensure the length of the test cases in the fixed case pool, the test cases therein are not optimized for transaction sequences, and only the parameters of the test cases are mutated during the dynamic execution process. By executing the test cases, the bytecode sequence related information is obtained and analyzed to determine whether the vulnerability exists. For a non-fixed test case pool, the optimization of the test cases includes transaction sequence optimization and parameter mutation, and the optimization process of each test case in the test case pool is guided by the test case value judgment formula with comprehensive coverage information proposed by the present invention.

[0007] 1. Static treatment stage of the present invention

[0008] First, the system performs static analysis on the smart contract input by the user, converts the smart contract source code into an ABI file through the solc tool, and uses the solc tool to obtain the public function signature based on the ABI file and build a function selector mapping table.

[0009] Secondly, the ABI file is converted into Slither Intermediate Representation (IR) through the Slither tool and the Slither tool is used on the Slither IR to obtain the dependency of each function on the contract state variables. The py-solc tool is used to count the number of keyword byte codes of each function in the contract.

[0010] Finally, run the Slither tool to detect suspicious vulnerability code lines in the current smart contract. Specifically, it includes the following:

[0011] 1.1 Obtaining ABI Files

[0012] During this processing phase, the solc tool is run to convert the smart contract into an ABI file.

[0013] Run the solc tool to obtain each contract function f in the ABI filei The function signature S i , where i represents the i-th function in the contract and its input parameter type Where j represents the jth parameter.

[0014] In particular, the system will automatically filter out functions in the ABI file that do not change the contract state, such as view functions, pure functions, etc., to ensure that fuzz testing is only performed on functions that change the contract state.

[0015] 1.2 Function selector mapping table construction

[0016] The system converts the function f obtained in Section 1.1 into i The function signature S i , S is converted into i The first four bytes are hashed to obtain the function selector k i .

[0017] The system takes the function input parameter type obtained in Section 1.1 Constructed as a parameter tuple V i ,in j represents the jth parameter type, 0≤j.

[0018] The system creates a function selector mapping table M, where M = {m1,m2,…,m i},m i By k i With V i The mapping relationship formed is m i ={k i :V i}.

[0019] 1.3 Contract Intermediate Representation Conversion

[0020] The system runs the Slither tool and converts the ABI file generated in Section 1.1 into Slither IR.

[0021] 1.4 Function Information Acquisition

[0022] The system calls the Slither API based on the Slither IR to obtain each function f i Read the state variable S read And construct a mapping relationship (f i :S read ).

[0023] The system calls the Slither API based on the Slither IR to obtain each function f i Defined state variable S writeAnd construct a mapping relationship (f i :S write ).

[0024] The system calls the Slither API based on the Slither IR to obtain the code lines of each function fil m～n Information and construct a mapping relationship (f i :l m～n )

[0025] 1.5 Obtaining the number of key word codes

[0026] The system uses the ABI file generated in Section 1.1 as the input of the py-solc tool to count the functions f in the smart contract. i The number of key bytecode instructions.

[0027] 1.6 Obtaining Suspected Vulnerability Code Lines

[0028] Run the static analysis tool Slither to perform preliminary testing on the smart contract and detect suspicious vulnerability code lines in the contract that match the vulnerability description rules. c .

[0029] The system constructs a set of suspected vulnerability code lines Point.

[0030] The definition of the suspicious vulnerability code line set Point is as follows:

[0031] Point=(l1,l2,l3…l c ) (1.1)

[0032] Point refers to the set of smart contract code lines that are judged to have vulnerabilities during the static analysis phase. c Refers to the suspicious vulnerability code lines in the current contract, and c represents the number of code lines. In the actual execution process, the value range of c is: c≥0.

[0033] 2. The pooling stage of the present invention

[0034] The fuzzer creates a fixed test case pool P fix and a non-fixed test case pool P dyn The fuzzer finds suspicious functions through the suspected vulnerability code lines and builds test cases in reverse order, and distributes them in the fixed test case pool P. fix middle.

[0035] Fixed test case pool P fix The test cases in the above are valuable test cases identified in the static analysis phase, so their transaction sequences will not be optimized to prevent the structure of valuable test cases from being damaged;

[0036] The fuzzer randomly selects a function f from the ABI file. i , and the function f i Encoded as initial test cases, allocated to the non-fixed test case pool P dyn middle.

[0037] Non-fixed test case pool P dyn The test cases in are mainly used for optimization iteration to explore smart contract vulnerabilities that cannot be explored in the static analysis phase. Specifically include the following:

[0038] 2.1 Test case pool construction

[0039] The system first generates two sets of length l in memory (usually the empirical value of l is 10), which store the encoded test cases.

[0040] The two collections are initially defined as fixed test case pools Non-fixed test case pool in Represents the i-th test case in the j-th test case pool, and i=l, j=(1,2). When j=1, it represents the test case in the fixed test case pool, and when j=2, it represents the test case in the non-fixed test case pool.

[0041] 2.2 Test Case Construction

[0042] 2.2.1 Reverse construction of suspected vulnerability code lines

[0043] 2.2.1.1 Obtaining suspicious functions

[0044] The system obtains the code line location where the suspected vulnerability is located by traversing Point c .

[0045] The system generates the function f through Section 1.4 i With the code line l m～n The mapping relationship (f i :l m～n ) Get the suspicious function f k .

[0046] In particular, the current phase ends when all suspected vulnerability code lines in Point are scanned.

[0047] 2.2.1.2 Function Transaction Construction

[0048] According to the suspicious function f extracted in 2.2.1.1 k , obtain its function signature S through Section 1.1 k .

[0049] Calculate S using the SHA-3 algorithmk The first four bytes of hash value get the function signature selector k k .

[0050] Get k through the mapping table M k The corresponding function parameter tuple V k .

[0051] Generate a random number that meets V k Types of parameters in The actual parameter value of the constraint and create a transaction tx through the ConFuzzius tool transaction building module k .

[0052] 2.2.1.3 Test case construction

[0053] The system obtains the transaction tx created in 2.2.1.2 k , and the suspicious function f extracted in 2.2.1.1 k .

[0054] According to the (f i :S read ) tuple to get the current suspicious function f k Read the state variable S k .

[0055] According to the (f i :S write ) tuple to obtain the state variable S k Function f for writing l .

[0056] Get the function f through Section 1.1 l The function signature S l .

[0057] Calculate S using the SHA-3 algorithm l The first four bytes of hash value get the function signature selector k l .

[0058] Get k through the mapping table M l The corresponding function parameter tuple V l .

[0059] Generate a random number that meets V l Types of parameters in The actual parameter value of the constraint and create a transaction tx through the ConFuzzius tool transaction building module l .

[0060] Use the head plug method to trade tx l Insert in transaction txk Header and form test cases This process is repeated until there is no function f l The final constructed test case

[0061] 2.2.1.4 Test Case Allocation

[0062] The system allocates the test cases generated in 2.2.1.3 to the fixed test case pool P fix middle.

[0063] 2.2.2 Random construction of test cases

[0064] 2.2.2.1 Random function acquisition

[0065] The system randomly selects function f from the ABI file. k .

[0066] In particular, the process continues to select l functions.

[0067] 2.2.2.2 Function Transaction Construction

[0068] Obtain the function f selected in Section 2.2.2.1 through Section 1.1 k The function signature S k .

[0069] Calculate S using the SHA-3 algorithm k The first four bytes of hash value get the function signature selector k k .

[0070] According to the mapping table M, get k k The corresponding function parameter tuple V k .

[0071] Generate a random number that meets V k Types of parameters in The actual parameter value of the constraint and create a transaction tx through the ConFuzzius tool transaction building module k .

[0072] 2.2.2.3 Test case construction

[0073] The system will construct the transaction tx in Section 2.2.2.2 k Build as a test case The value of the subscript i is the length l declared in Section 2.1.

[0074] 2.2.2.4 Test Case Allocation

[0075] The system allocates the test cases generated in 2.2.2.3 to the non-fixed test case pool P dyna In particular, the initial test case value Value i =0.

[0076] 3. Dynamic Analysis Phase of the Present Invention

[0077] 3.1 Vulnerability Oracle Definition

[0078] Vulnerability Oracle (VO) is an execution code that can analyze smart contracts, identify and detect possible security vulnerabilities. The definition of VO is as follows:

[0079] VO=[V1,V2,…,V h ]

[0080] Among them, V h Represents the scanning code of the hth vulnerability type. h For example, its input parameters include the current runtime instruction op cur , the previous runtime instruction op pre and bytecode path record rec. The VO implementation form of the present invention is similar to that of the ConFuzzius tool.

[0081] 3.2 Fixed test case pool P fix Vulnerability Detection

[0082] 3.2.1P fix Pool test case update

[0083] Fuzzer for a fixed test case pool P fix Test cases in Perform parameter update operations and use the ConFuzzius parameter mutation module to update all transaction tx k Perform parameter mutation and convert to tx k-new .Will Convert to

[0084] 3.2.2 Test Case Execution

[0085] In this phase, the fuzzer executes a fixed test case pool P using the ConFuzzius execution module. fix Each test case And record the bytecode path rec during execution 1 , Current running instructions and the previous runtime instruction

[0086] Bytecode path rec1 For the current test case The complete bytecode execution order.

[0087] Current running command For the current test case The bytecode being executed.

[0088] Previous runtime instruction For the current test case The last bytecode executed.

[0089] Specifically, the fuzzer will first execute the test case Get the bytecode path rec 1 , and then sequentially traverses the execution instructions during the vulnerability scanning phase.

[0090] 3.2.3 Vulnerability Scanning

[0091] According to the bytecode path rec obtained in Section 3.2.2 1 , Current running instructions and the previous runtime instruction It is used as an input parameter of the vulnerability oracle VO constructed by the present invention, and is executed to determine whether the current test case triggers a certain vulnerability.

[0092] 3.2.4P fix Pool test case removal

[0093] For a fixed test case pool P fix Test cases in Once a vulnerability is detected in Section 3.2.2, the test case From the fixed test case pool P fix Delete it.

[0094] 3.3 Non-fixed test case pool P dyna Vulnerability Detection

[0095] 3.3.1P dyna Pool test case update

[0096] Fuzzer for non-fixed test case pool P dyna Test cases in Perform parameter and transaction sequence update operations. For transaction sequence update operations:

[0097] Using the (fi:S generated in Section 1.4 read ) information and (f i :S write ) information. Any of 3.3.1.1 and 3.3.1.2 will be randomly selected to update the test case.

[0098] 3.3.1.1 Test case length increases

[0099] The system will randomly select test cases A transaction tx n , and get the transaction tx through the ConFuzzius tool n The corresponding function f n .

[0100] According to the (f i :S read ) tuple to get the current function f n Read the state variable S n .

[0101] According to the (f i :S write ) tuple to obtain the state variable S n Function f for writing m .

[0102] Get the function f through Section 1.1 m The function signature S m .

[0103] Calculate S using the SHA-3 algorithm m The first four bytes of hash value get the function signature selector k m .

[0104] Get k through the mapping table M m The corresponding function parameter tuple V m .

[0105] Generate a random number that meets V m Types of parameters in The actual parameter value of the constraint and create a transaction tx through the ConFuzzius tool transaction building module m .

[0106] tx m Head plugged into test case tx n Before, construct a test case of length k+1.

[0107] For parameter update operations, the ConFuzzius parameter mutation module is used to update all transaction tx k Perform parameter mutation and convert to tx k-new .

[0108] This process will eventually Convert to

[0109] 3.3.1.2 Test case length reduction

[0110] The system will randomly select test cases A transaction tx n .

[0111] The system will trade tx n From the test case Delete it.

[0112] The system updates the parameters of the test case. The parameter update operation uses the ConFuzzius parameter mutation module to update all transaction tx k Perform parameter mutation and convert to tx k-new .

[0113] This process will eventually Convert to

[0114] 3.3.2 Test Case Execution

[0115] In this phase, the fuzzer executes the non-fixed test case pool P using the ConFuzzius execution module. dyna Each test case And record the bytecode path rec during execution 2 , Current running instructions and the previous runtime instruction At the same time, the fuzzer is in the current test case Collect test cases during execution Branch coverage number B, number of key byte codes K and test cases The number of data dependencies contained is P. This information is used to calculate the value of each test case.

[0116] Bytecode path rec 2 For the current test case The complete bytecode execution order.

[0117] Current running command For the current test case The bytecode being executed.

[0118] Previous runtime instruction For the current test case The last bytecode executed.

[0119] The branch coverage number B is the current test case How many different branch statements are executed? Branch statements include if, else, while, for and other conditional judgment or loop statements.

[0120] The number of keyword byte codes K is the current test case The number of key byte codes included in the execution process. The key byte codes are shown in Table 1.

[0121] The data dependency logarithm P is the current test case The number of read-write pairs of each state variable in, that is, the number of times a state variable is defined and then used.

[0122] Specifically, the fuzzer will first execute the test case Get the bytecode path rec 2 , and then sequentially traverses the execution instructions during the vulnerability scanning phase.

[0123] 3.3.3 Vulnerability Scanning

[0124] According to the bytecode path rec obtained in Section 3.3.2 2 , Current running instructions and the previous runtime instruction As the input parameter of the vulnerability oracle VO constructed by the present invention, and judge the current test case by execution Whether some kind of vulnerability has been triggered.

[0125] 3.3.4 Calculation of test case value

[0126] 3.3.4.1 Test Case Value Formula Definition

[0127] The present invention is based on test cases The branch coverage number B, data dependency logarithm P and key byte code number K obtained during the execution process are used to calculate the test case The value is as shown in formula (3.1):

[0128]

[0129] Among them, Value i-new Representative test cases The value of B i-new Indicates the number of branches that the current test case breaks through; P i-new represents the logarithm of data dependency in the test case, K i-new It is the number of key bytecodes triggered during the execution of the test case; Count i-new Represents the number of transactions in the current test case. i-new , P i-new and K i-new Calculate the total value of the entire test case, and then average the total value based on the number of transactions in the current test case to get the final result Value i-new This is the test case The final value of .

[0130] 3.3.4.2 Calculation of test case value

[0131] The fuzzer obtains the branch coverage number B, the number of key byte codes K, and the current test case through Section 3.3.2 For the number of read and write pairs of state variables P, the fuzzer has a non-fixed test case pool P dyna Test cases in Calculate its value i-new .

[0132] 3.3.5 Test case replacement

[0133] The fuzzer obtains the non-fixed test case pool P in Section 3.3.4.2 dyna Test Cases Value i-new , and the value Value i-new With the old test case Value i Compare, if Value i-new >Valuei, the fuzzer will replace the old test cases For the test case after the current execution

[0134] Another object of the present invention is to propose a smart contract fuzz testing system, which mainly includes three modules:

[0135] Static processing module: This module obtains relevant information in the smart contract through static analysis and generates initial test cases to provide data support for subsequent dynamic analysis.

[0136] Pool module: This module is used to divide test cases into a non-fixed test case pool and a non-fixed test case pool. The two test case pools use different execution processes.

[0137] Dynamic analysis module: The fuzzer will determine the dependencies between bytecodes by analyzing the execution information of the current test case. The fuzzer determines whether there is a certain vulnerability in the current smart contract by performing this trajectory tracking. In addition, the fuzz testing system only performs parameter mutations on the test cases in the fixed test case pool to verify whether the test cases are useful, and performs double iterations of transaction sequences and parameters on the test cases in the non-fixed test case pool.

[0138] The essential features of the present invention are: 1. The present invention adopts a method that combines static and dynamic analysis, and uses the suspicious vulnerability code lines detected by static analysis as the end transactions of the test case construction to construct valuable test cases in reverse order, and does not optimize the transaction sequence in the fuzzification stage to ensure the structural integrity of the test case. 2. The present invention proposes a test case value calculation formula that is simple to calculate and has comprehensive coverage information, which measures the value judgment of the test case from a more comprehensive perspective and guides the test case optimization process. 3. By using the present invention, the length of the test case that triggers the vulnerability can be significantly reduced. Under the same environment, more test cases can be executed per unit time compared to existing smart contract fuzz testing tools. BRIEF DESCRIPTION OF THE DRAWINGS

[0139] Figure 1 The figure is a schematic diagram of the overall process of a smart contract vulnerability detection method and system of the present invention.

[0140] Figure 2 A schematic diagram of components of a test case of a smart contract vulnerability detection method and system of the present invention.

[0141] Figure 3 This is a schematic diagram of the value application process of a smart contract vulnerability detection method and system of the present invention. DETAILED DESCRIPTION

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

[0143] Example 1

[0144] The present invention proposes a smart contract fuzz testing method and system, such as Figure 1 As shown in the figure, it mainly includes three parts: static processing, pooling and dynamic analysis. The specific implementation of the solution is as follows:

[0145] 1. Static treatment stage of the present invention

[0146] First, the system performs static analysis on the smart contract input by the user, converts the smart contract source code into an ABI file through the solc tool, and uses the solc tool to obtain the public function signature based on the ABI file and build a function selector mapping table.

[0147] Secondly, the ABI file is converted into Slither Intermediate Representation (IR) through the Slither tool and the Slither tool is used on the Slither IR to obtain the dependency of each function on the contract state variables. The py-solc tool is used to count the number of keyword byte codes of each function in the contract.

[0148] Finally, run the Slither tool to detect suspicious vulnerability code lines in the current smart contract. Specifically, it includes the following:

[0149] 1.1 Obtaining ABI Files

[0150] During this processing phase, the solc tool is run to convert the smart contract into an ABI file.

[0151] Run the solc tool to obtain each contract function f in the ABI file i The function signature S i , where i represents the i-th function in the contract and its input parameter type Where j represents the jth parameter.

[0152] In particular, the system will automatically filter out functions in the ABI file that do not change the contract state, such as view functions, pure functions, etc., to ensure that fuzz testing is only performed on functions that change the contract state.

[0153] 1.2 Function selector mapping table construction

[0154] The system converts the function f obtained in Section 1.1 into i The function signature S i , S is converted into i The first four bytes are hashed to obtain the function selector k i .

[0155] The system takes the function input parameter type obtained in Section 1.1 Constructed as a parameter tuple V i ,in j represents the jth parameter type, 0≤j.

[0156] The system creates a function selector mapping table M, where M = {m1,m2,…,m i},m i By k i With V i The mapping relationship formed is m i ={k i :V i}.

[0157] 1.3 Contract Intermediate Representation Conversion

[0158] The system runs the Slither tool and converts the ABI file generated in Section 1.1 into Slither IR.

[0159] 1.4 Function Information Acquisition

[0160] The system calls the Slither API based on the Slither IR to obtain each function f i Read the state variable S read And construct a mapping relationship (f i :S read ).

[0161] The system calls the Slither API based on the Slither IR to obtain the state variables S defined by each function fi. write And construct a mapping relationship (f i :S write ).

[0162] The system calls the Slither API based on the Slither IR to obtain each function f i The line of code m～n Information and construct a mapping relationship (f i :l m～n )

[0163] In particular, state variables are global variables stored and managed in the contract.

[0164] 1.5 Obtaining the number of key word codes

[0165] The system uses the ABI file generated in Section 1.1 as the input of the py-solc tool to count the number of key bytecode instructions of each function fi in the smart contract.

[0166] The key bytecode instructions defined in the present invention are shown in Table 1. These key bytecodes serve as a reference for calculating the value of the test case during the dynamic execution process.

[0167] Table 1 Keyword Byte Code

[0168]

[0169]

[0170] 1.6 Obtaining Suspected Vulnerability Code Lines

[0171] Run the static analysis tool Slither to perform preliminary testing on the smart contract and detect suspicious vulnerability code lines in the contract that match the vulnerability description rules. c .

[0172] The system constructs a set of suspected vulnerability code lines Point.

[0173] The definition of the suspicious vulnerability code line set Point is as follows:

[0174] Point=(l1,l2,l3…lc ) (1.1)

[0175] Point refers to the set of smart contract code lines that are judged to have vulnerabilities during the static analysis phase. c Refers to the suspicious vulnerability code lines in the current contract, and c represents the number of code lines. In the actual execution process, the value range of c is: c≥0.

[0176] 2. The pooling stage of the present invention

[0177] The fuzzer creates a fixed test case pool P fix and a non-fixed test case pool P dyn The fuzzer finds suspicious functions through the suspected vulnerability code lines and builds test cases in reverse order, and distributes them in the fixed test case pool P. fix middle.

[0178] Fixed test case pool P fix The test cases in the above are valuable test cases identified in the static analysis phase, so their transaction sequences will not be optimized to prevent the structure of valuable test cases from being damaged;

[0179] The fuzzer randomly selects a function f from the ABI file. i , and the function f i Encoded as initial test cases, allocated to the non-fixed test case pool P dyn middle.

[0180] Non-fixed test case pool P dyn The test cases in are mainly used for optimization iteration to explore smart contract vulnerabilities that cannot be explored in the static analysis phase. Specifically include the following:

[0181] 2.1 Test case pool construction

[0182] The system first generates two sets of length l in memory (usually the empirical value of l is 10), which store the encoded test cases.

[0183] The two collections are initially defined as fixed test case pools Non-fixed test case pool in Represents the i-th test case in the j-th test case pool, and i=l, j=(1,2). When j=1, it represents the test case in the fixed test case pool, and when j=2, it represents the test case in the non-fixed test case pool.

[0184] 2.2 Test Case Construction

[0185] The components of a test case are Figure 2 shown.

[0186] 2.2.1 Reverse construction of suspected vulnerability code lines

[0187] The pseudo code for building a test case in reverse order is as follows:

[0188]

[0189]

[0190] 2.2.1.1 Obtaining suspicious functions

[0191] The system obtains the code line location where the suspected vulnerability is located by traversing Point c .

[0192] The system generates the function f through Section 1.4 i With the code line l m～n The mapping relationship (f i :l m～n ) Get the suspicious function f k .

[0193] In particular, the current phase ends when all suspected vulnerability code lines in Point are scanned.

[0194] 2.2.1.2 Function Transaction Construction

[0195] According to the suspicious function f extracted in 2.2.1.1 k , obtain its function signature S through Section 1.1 k .

[0196] Calculate S using the SHA-3 algorithm k The first four bytes of hash value get the function signature selector k k .

[0197] Get k through the mapping table M k The corresponding function parameter tuple V k .

[0198] Generate a random number that meets V k Types of parameters in The actual parameter value of the constraint and create a transaction tx through the ConFuzzius tool transaction building module k .

[0199] 2.2.1.3 Test case construction

[0200] The system obtains the transaction tx created in 2.2.1.2 k , and the suspicious function f extracted in 2.2.1.1 k .

[0201] According to the (f i :S read ) tuple to get the current suspicious function f k Read the state variable S k .

[0202] According to the (f i :S write ) tuple to obtain the state variable S k Function f for writing l .

[0203] Get the function f through Section 1.1 l The function signature S l .

[0204] Calculate S using the SHA-3 algorithm l The first four bytes of hash value get the function signature selector k l .

[0205] Get k through the mapping table M l The corresponding function parameter tuple V l .

[0206] Generate a random number that meets V l Types of parameters in The actual parameter value of the constraint and create a transaction tx through the ConFuzzius tool transaction building module l .

[0207] Use the head plug method to trade tx l Insert in transaction tx k Header and form test cases This process is repeated until there is no function f l The final constructed test case

[0208] 2.2.1.4 Test Case Allocation

[0209] The system allocates the test cases generated in 2.2.1.3 to the fixed test case pool P fix middle.

[0210] 2.2.2 Random construction of test cases

[0211] The pseudo code for randomly constructing test cases is as follows:

[0212]

[0213] 2.2.2.1 Random function acquisition

[0214] The system randomly selects function f from the ABI file. k .

[0215] In particular, the process continues to select l functions.

[0216] 2.2.2.2 Function Transaction Construction

[0217] Obtain the function f selected in Section 2.2.2.1 through Section 1.1 k The function signature S k .

[0218] Calculate S using the SHA-3 algorithm k The first four bytes of hash value get the function signature selector k k .

[0219] According to the mapping table M, get k k The corresponding function parameter tuple V k .

[0220] Generate a random number that meets V k Types of parameters in The actual parameter value of the constraint and create a transaction tx through the ConFuzzius tool transaction building module k .

[0221] 2.2.2.3 Test case construction

[0222] The system will construct the transaction tx in Section 2.2.2.2 k Build as a test case The value of the subscript i is the length l declared in Section 2.1.

[0223] 2.2.2.4 Test Case Allocation

[0224] The system allocates the test cases generated in 2.2.2.3 to the non-fixed test case pool P dyna In particular, the initial test case value Value i =0.

[0225] 3. Dynamic Analysis Phase of the Present Invention

[0226] 3.1 Vulnerability Oracle Definition

[0227] Vulnerability Oracle (VO) is an execution code that can analyze smart contracts, identify and detect possible security vulnerabilities. The definition of VO is as follows:

[0228] VO=[V1,V2,…,V h ]

[0229] Among them, V h Represents the scanning code of the hth vulnerability type. h For example, its input parameters include the current runtime instruction op cur , the previous runtime instruction op pre and bytecode path record rec. The VO implementation form of the present invention is similar to that of the ConFuzzius tool.

[0230] 3.2 Fixed test case pool P fix Vulnerability Detection

[0231] 3.2.1P fix Pool test case update

[0232] Fuzzer for a fixed test case pool P fix Test cases in Perform parameter update operations and use the ConFuzzius parameter mutation module to update all transaction tx k Perform parameter mutation and convert to tx k-new .Will Convert to

[0233] 3.2.2 Test Case Execution

[0234] In this phase, the fuzzer executes a fixed test case pool P using the ConFuzzius execution module. fix Each test case And record the bytecode path rec during execution 1 , Current running instructions and the previous runtime instruction

[0235] Bytecode path rec 1 For the current test case The complete bytecode execution order.

[0236] Current running command For the current test case The bytecode being executed.

[0237] Previous runtime instruction For the current test case The last bytecode executed.

[0238] Specifically, the fuzzer will first execute the test case Get the bytecode path rec 1 , and then sequentially traverses the execution instructions during the vulnerability scanning phase.

[0239] 3.2.3 Vulnerability Scanning

[0240] According to the bytecode path rec obtained in Section 3.2.2 1 , Current running instructions and the previous runtime instruction It is used as an input parameter of the vulnerability oracle VO constructed by the present invention, and is executed to determine whether the current test case triggers a certain vulnerability.

[0241] 3.2.4P fix Pool test case removal

[0242] For a fixed test case pool P fix Test cases in Once a vulnerability is detected in Section 3.2.2, the test case From the fixed test case pool P fix Delete it.

[0243] 3.3 Non-fixed test case pool P dyna Vulnerability Detection

[0244] 3.3.1P dyna Pool test case update

[0245] Fuzzer for non-fixed test case pool P dyna Test cases in Perform parameter and transaction sequence update operations. For transaction sequence update operations:

[0246] Using the (f generated in Section 1.4 i :S read ) information and (f i :S write ) information. Any of 3.3.1.1 and 3.3.1.2 will be randomly selected to update the test case.

[0247] 3.3.1.1 Test case length increases

[0248] The system will randomly select test cases A transaction tx n , and get the transaction tx through the ConFuzzius tool n The corresponding function f n .

[0249] According to the (f i :S read ) tuple to get the current function f n Read the state variable S n .

[0250] According to the (fi :S write ) tuple to obtain the state variable S n Function f for writing m .

[0251] Get the function f through Section 1.1 m The function signature S m .

[0252] Calculate S using the SHA-3 algorithm m The first four bytes of hash value get the function signature selector k m .

[0253] Get k through the mapping table M m The corresponding function parameter tuple V m .

[0254] Generate a random number that meets V m Types of parameters in The actual parameter value of the constraint and create a transaction tx through the ConFuzzius tool transaction building module m .

[0255] tx m Head plugged into test case tx n Before, construct a test case of length k+1.

[0256] For parameter update operations, the ConFuzzius parameter mutation module is used to update all transaction tx k Perform parameter mutation and convert to tx k-new .

[0257] This process will eventually Convert to

[0258] 3.3.1.2 Test case length reduction

[0259] The system will randomly select test cases A transaction tx n .

[0260] The system will trade tx n From the test case Delete it.

[0261] The system updates the parameters of the test case. The parameter update operation uses the ConFuzzius parameter mutation module to update all transaction tx k Perform parameter mutation and convert to tx k-new .

[0262] This process will eventually Convert to

[0263] 3.3.2 Test Case Execution

[0264] In this phase, the fuzzer executes the non-fixed test case pool P using the ConFuzzius execution module. dyna Each test case And record the bytecode path rec during execution 2 , Current running instructions and the previous runtime instruction At the same time, the fuzzer is in the current test case Collect test cases during execution Branch coverage number B, number of key byte codes K and test cases The number of data dependencies contained is P. This information is used to calculate the value of each test case.

[0265] Bytecode path rec 2 For the current test case The complete bytecode execution order.

[0266] Current running command For the current test case The bytecode being executed.

[0267] Previous runtime instruction For the current test case The last bytecode executed.

[0268] The branch coverage number B is the current test case How many different branch statements are executed? Branch statements include if, else, while, for and other conditional judgment or loop statements.

[0269] The number of keyword byte codes K is the current test case The number of key byte codes included in the execution process. The key byte codes are shown in Table 1.

[0270] The data dependency logarithm P is the current test case The number of read-write pairs of each state variable in, that is, the number of times a state variable is defined and then used.

[0271] Specifically, the fuzzer will first execute the test case Get the bytecode path rec 2 , and then sequentially traverses the execution instructions during the vulnerability scanning phase.

[0272] 3.3.3 Vulnerability Scanning

[0273] According to the bytecode path rec obtained in Section 3.3.2 2 , Current running instructions and the previous runtime instruction As the input parameter of the vulnerability oracle VO constructed by the present invention, and judge the current test case by execution Whether some kind of vulnerability has been triggered.

[0274] 3.3.4 Calculation of test case value

[0275] The value calculation application process consists of Figure 3 shown.

[0276] 3.3.4.1 Test Case Value Formula Definition

[0277] The present invention is based on test cases The branch coverage number B, data dependency logarithm P and key byte code number K obtained during the execution process are used to calculate the test case The value is as shown in formula (3.1):

[0278]

[0279] Among them, Value i-new Representative test cases The value of B i-new Indicates the number of branches that the current test case breaks through; P i-new represents the logarithm of data dependency in the test case, K i-new It is the number of key bytecodes triggered during the execution of the test case; Count i-new Represents the number of transactions in the current test case. i-new , P i-new and K i-new Calculate the total value of the entire test case, and then average the total value based on the number of transactions in the current test case to get the final result Value i-new This is the test case The final value of .

[0280] 3.3.4.2 Calculation of test case value

[0281] The fuzzer obtains the branch coverage number B, the number of key byte codes K, and the current test case through Section 3.3.2 For the number of read and write pairs of state variables P, the fuzzer has a non-fixed test case pool P dyna Test cases in Calculate its value i-new .

[0282] 3.3.5 Test case replacement

[0283] The fuzzer obtains the non-fixed test case pool P in Section 3.3.4.2 dyna Test Cases Value i-new , and the value Value i-new With the old test case Value i Compare, if Value i-new >Value i , the fuzzer will replace the old test case For the test case after the current execution

Claims

1. A smart contract vulnerability detection method, characterized in that: The following steps are involved: In the static processing stage, the smart contract is used as the input of the static processing stage, including: analyzing the data dependency facts and the number of key word code instructions of each function in the smart contract by static means; obtaining the suspected vulnerability code lines by running static analysis tools on the smart contract to be tested; the stage results generated in this stage are used for the allocation of different test cases in the pooling stage and the execution of different test case pools in the dynamic execution stage; In the pooling phase, different types of test case pools are constructed, and the test cases containing data flow dependency facts that are reverse-engineered from the suspected vulnerability code lines are assigned to the fixed test case pool. At the same time, test cases are constructed in a random manner and assigned to the non-fixed test case pool. In the dynamic analysis phase, the fuzz testing system dynamically executes test cases in two test case pools. In order to ensure the length of test cases in the fixed test case pool, the test cases in it are not optimized, and only the parameters of the test cases are mutated during the dynamic execution process; for the non-fixed test case pool, the optimization of test cases includes transaction sequence optimization and parameter mutation, and the optimization process of the test case pool is guided by the proposed test case value judgment formula with comprehensive coverage information; finally, the bytecode sequence related information is obtained by executing the test cases and analyzed to determine whether the vulnerability exists.

2. A smart contract vulnerability detection method according to claim 1, characterized in that: Static processing stage, including: 1.1 Obtaining ABI Files Convert the smart contract to an ABI file; Get each contract function f in the ABI file i The function signature S i , where i represents the i-th function in the contract and its input parameter type Where j represents the jth parameter; 1.4 Function Information Acquisition The system obtains each function f based on Slither IR i Read the state variable S read And construct a mapping relationship (f i :S read ); The system obtains each function f based on Slither IR i Defined state variable S write And construct a mapping relationship (f i :S write ); The system obtains each function f based on Slither IR i The line of code m～n Information and construct a mapping relationship (f i :l m～n ); 1.5 Obtaining the number of key word codes The system uses the ABI file generated in Section 1.1 as the input of the py-solc tool to count the functions f in the smart contract. i The number of key bytecode instructions; 1.6 Suspicious vulnerability code lines are obtained including: Perform preliminary testing on smart contracts to detect suspicious vulnerability code lines in the contract that match the vulnerability description rules. c ; The system builds a set of suspected vulnerability code lines Point; The definition of the suspicious vulnerability code line set Point is as follows: <h2 style=";text-align:left;direction:ltr">Point (l1,l2,l3…l)<h2 style=";text-align:left;direction:ltr"> c <h2 style=";text-align:left;direction:ltr"> (1.1) Point refers to the set of smart contract code lines that are judged to have vulnerabilities during the static analysis phase; c Refers to the suspicious vulnerability code lines in the current contract, c represents the number of code lines; in the actual execution process, the value range of c is: c≥0.

3. A smart contract vulnerability detection method according to claim 2, characterized in that: The pooling phase involves the construction of test case pools and test cases, including: Test case pool construction: 2.1 Test case pool construction The system generates two sets of length l in memory, which store the encoded test cases; The two collections are initially defined as fixed test case pools Non-fixed test case pool in represents the i-th test case in the j-th test case pool, and i=l, j=(1,2). When j=1, it represents the test case in the fixed test case pool. For example, when j=2, it represents the test cases in the non-fixed test case pool; Test case construction: 2.2 Test Case Construction 2.2.1 Reverse construction of suspected vulnerability code lines 2.2.1.1 Obtaining suspicious functions The system obtains the code line location where the suspected vulnerability is located by traversing Point c ; The system generates the function f through Section 1.4 i With the code line l m～n The mapping relationship (f i :l m～n ) Get the suspicious function f k ; 2.2.1.2 Function Transaction Construction According to the suspicious function f extracted in 2.2.1.1 k , get its function signature S k ; Calculate S using the SHA-3 algorithm k The first four bytes of hash value get the function signature selector k k ; Get k through the mapping table M k The corresponding function parameter tuple V k ; Generate a random number that meets V k Types of parameters in The actual parameter value of the constraint and create a transaction tx k ; 2.2.1.3 Test case construction The system obtains the transaction tx created in 2.2.1.2 k , and the suspicious function f extracted in 2.2.1.1 k ; According to the (f i :S read ) tuple to get the current suspicious function f k Read the state variable S k ; According to the (f i :S write ) tuple to obtain the state variable S k Function f for writing l ; System acquisition function f l The function signature S l ; Calculate S using the SHA-3 algorithm l The first four bytes of hash value get the function signature selector k l ; Get k through the mapping table M l The corresponding function parameter tuple V l ; Generate a random number that meets V l Types of parameters in The actual parameter value of the constraint and create a transaction tx l ; Use the head plug method to trade tx l Insert in transaction tx k Header and form test cases This process is repeated until there is no function f l ; Final constructed test case 2.2.2 Random construction of test cases 2.2.2.1 Random function acquisition The system randomly selects function f from the ABI file. k ; 2.2.2.2 Function Transaction Construction Get the function f selected in Section 2.2.2.1 k The function signature S k ; Calculate S using the SHA-3 algorithm k The first four bytes of hash value get the function signature selector k k ; According to the mapping table M, get k k The corresponding function parameter tuple V k ; Generate a random number that meets V k Types of parameters in The actual parameter value of the constraint and create a transaction tx k ; 2.2.2.3 Test case construction The system will construct the transaction tx in Section 2.2.2.2 k Build as a test case Test case assignment: 2.2.1.4 The system allocates the test cases generated in 2.2.1.3 to the fixed test case pool P fix middle; 2.2.2.4 The system allocates the test cases generated in 2.2.2.3 to the non-fixed test case pool P dyna In particular, the initial test case value Value i =0.

4. A smart contract vulnerability detection method according to claim 3, characterized in that: Updates and value calculations of test cases during the dynamic analysis phase include: Update the test cases in the fixed test case pool and the non-fixed test case pool to generate new rounds of test cases: 3.2.1P fix Pool test case update Fuzzer for a fixed test case pool P fix Test cases in Perform parameter update operations and update all transactions tx k Perform parameter mutation and convert to tx k-new ;Will Convert to 3.3.1P dyna Pool test case update Fuzzer for non-fixed test case pool P dyna Test cases in Perform parameter and transaction sequence update operations; for transaction sequence update operations: Using the (f generated in Section 1.4 i :S read ) information and (f i :S write ) information; will randomly select any of 3.3.1.1 and 3.3.1.2 to update the test case; 3.3.1.1 Test case length increases The system will randomly select test cases A transaction tx n , and get the transaction tx through the ConFuzzius tool n The corresponding function f n ; According to the (f i :S read ) tuple to get the current function f n Read the state variable S n ; According to the (f i :S write ) tuple to obtain the state variable S n Function f for writing m ; Get the function f through Section 1.1 m The function signature S m ; Calculate S using the SHA-3 algorithm m The first four bytes of hash value get the function signature selector k m ; Get k through the mapping table M m The corresponding function parameter tuple V m ; Generate a random number that meets V m Types of parameters in The actual parameter value of the constraint and create a transaction tx through the ConFuzzius tool transaction building module m ; tx m Head plugged into test case tx n Before, construct a test case of length k+1; For parameter update operations, the ConFuzzius parameter mutation module is used to update all transaction tx k Perform parameter mutation and convert to tx k-new ; This process will eventually Convert to 3.3.1.2 Test case length reduction The system will randomly select test cases A transaction tx n ; The system will trade tx n From the test case Delete from; The system updates the parameters of the test case. The parameter update operation uses the ConFuzzius parameter mutation module to update all transaction tx k Perform parameter mutation and convert to tx k-new ; This process will eventually Convert to 5. A smart contract vulnerability detection method according to claim 3, characterized in that: Test case execution and vulnerability detection during the dynamic analysis phase include: Execute the test cases in the fixed test case pool and the non-fixed test case pool, and determine whether the vulnerability is triggered by analyzing the bytecode sequence: 3.2.2 Test Case Execution The fuzzer executes a fixed pool of test cases P fix Each test case And record the bytecode path rec during execution 1 , Current running instructions and the previous runtime instruction Bytecode path rec 1 For the current test case Complete bytecode execution order; Current running command For the current test case The bytecode being executed; Previous runtime instruction For the current test case The last executed bytecode; 3.2.3 Vulnerability Scanning According to the bytecode path rec obtained in Section 3.2.2 1 , Current running instructions and the previous runtime instruction By analyzing rec 1 , and To determine whether the current test case triggers a certain vulnerability; 3.3.2 Test Case Execution In this phase, the fuzzer executes a non-fixed test case pool P dyna Each test case And record the bytecode path rec during execution 2 , Current running instructions and the previous runtime instruction At the same time, the fuzzer is in the current test case Collect test cases during execution Branch coverage number B, number of key byte codes K and test cases The number of data dependencies P included; this information is used to calculate the value of each test case; Bytecode path rec 2 For the current test case Complete bytecode execution order; Current running command For the current test case The bytecode being executed; Previous runtime instruction For the current test case The last executed bytecode; The branch coverage number B is the current test case How many different branch statements are executed, including conditional judgment or loop statements such as if, else, while, for, etc. 3.3.3 Vulnerability Scanning According to the bytecode path rec obtained in Section 3.3.2 2 , Current running instructions and the previous runtime instruction By analyzing rec 2 , and To determine the current test case Whether some kind of vulnerability has been triggered.

6. A smart contract vulnerability detection method according to claim 4, characterized in that: Value calculation, including: 3.3.4.1 Test Case Value Formula Definition The present invention is based on test cases The branch coverage number B, data dependency logarithm P and key byte code number K obtained during the execution process are used to calculate the test case The value is as shown in formula (3.1): Among them, Value i-new Representative test cases The value of B i-new Indicates the number of branches that the current test case breaks through; P i-new represents the logarithm of data dependency in the test case, K i-new It is the number of key bytecodes triggered during the execution of the test case; Count i-new Represents the number of transactions in the current test case; the fuzzer passes B i-new , P i-new and K i-new Calculate the total value of the entire test case, and then average the total value based on the number of transactions in the current test case to get the final result Value i-new This is the test case The final value of 3.3.4.2 Calculation of test case value The fuzzer obtains the branch coverage number B, the number of key byte codes K, and the current test case through Section 3.3.2 For the number of read and write pairs of state variables P, the fuzzer has a non-fixed test case pool P dyna Test cases in Calculate its value i-new .

Images