A smart contract reentrancy defect detection method based on dynamic execution information analysis

Abstract

The present invention relates to a reentry defect detection method for Ethereum smart contracts based on dynamic execution information analysis, the method comprising the following steps: step 1) preprocessing the contract to be tested; step 2) constructing an attack contract; step 3) deploying the contract to be tested and the attack contract; step 4) randomly generating executable transactions; step 5) collecting dynamic execution information; step 6) analyzing the dynamic execution information and detecting harmful reentry; step 7) repeating step 4)-step 6), if harmful reentry is detected, the contract has a reentry defect, if the execution time executionTime is greater than the test time limit t, the contract is safe. The technical solution improves the automation degree of reentry defect detection, the technical solution has high accuracy, low false alarm rate, and high code coverage.

Description

Technical Field

[0001] The present invention relates to a detection method, and in particular to a smart contract reentry defect detection method based on dynamic execution information analysis, which belongs to the field of smart contract defect detection in blockchain systems. Background Art

[0002] Blockchain technology has attracted attention from all walks of life due to its characteristics of decentralization, persistence, anonymity and auditability. It has been applied to various scenarios such as digital currency and voting, solving the problem of over-reliance on trusted third parties in the field of digital transactions. Ethereum is one of the most widely used blockchain platforms today. It supports developers to write smart contracts for various purposes. However, due to the characteristics of the Ethereum virtual machine and the complexity of the Solidity language used to write smart contracts, there are often defects in smart contracts. Reentrancy defects are one of the most complex and serious defects. The DAO incident caused a loss of more than 60 million US dollars and forced Ethereum to hard fork.

[0003] At present, the existing reentrancy defect detection methods mainly include: pattern matching, symbolic execution, taint analysis, formal verification, etc. The pattern matching method uses an abstract syntax tree to extract contract source code information, stores the syntax and semantic information of the contract source code in intermediate forms such as XML and OWL, uses the corresponding query statement to construct a defect pattern, and searches for reentrancy defects in the source code. However, the code representation of reentrancy defects is very complex, and the defect pattern constructed manually is difficult to cover all possibilities, and the false alarm rate is high. The symbolic execution method uses symbols instead of variables to simulate the execution of contracts and explore all possible execution paths of contracts to find reentrancy defects. This method faces two major problems: path explosion and path reachability analysis. Most existing tools do not consider path reachability, so the false alarm rate is high. Taint analysis uses the method of tainting key data to determine whether the data has been repeatedly modified, so as to determine whether there is a reentrancy defect. However, most existing tools perform taint analysis by reproducing existing transactions on the public chain or manually sending transactions on the test chain, which makes it difficult to automatically detect reentrancy defects for contracts that are not on the chain. Formal verification methods use mathematical models to verify the characteristics of contracts, which is difficult, and the modeling process is difficult to automate, requiring a lot of manpower. Therefore, there is an urgent need for an automated smart contract reentrancy defect detection method with a low false positive rate. Summary of the invention

[0004] The present invention aims at the problems existing in the prior art and provides an Ethereum smart contract reentry defect detection method based on dynamic execution information analysis. The technical solution uses dynamic execution information analysis to detect reentry defects of contracts written in Solidity language under the Ethereum platform, automatically generates executable transactions, records dynamic execution information, and constructs a contract call chain to discover reentry. After discovering reentry, the dynamic execution information is further analyzed to determine whether the reentry is harmful, thereby detecting contract reentry defects.

[0005] In order to achieve the above object, the technical solution of the present invention is as follows: a method for detecting reentrancy defects in Ethereum smart contracts based on dynamic execution information analysis, the method comprising the following steps:

[0006] Step 1) Preprocess the contract to be tested;

[0007] Compile the contract to be tested and obtain its bytecode and binary interface information ABI. Analyze the binary interface information and obtain the function prototype FunctionPrototype of each function of the contract to be tested i , construct the candidate function FunctionCandidate based on the function prototype i ={Function_name i ,Function_selector i ,Function_parameters i}, where Function_name i is the function name, Function_selector i Function_parameters is the function selector i is the set of parameter types required by the function. The calculation formula of the function selector is:

[0008] Function_selector=bytes4(keccak256(functionPrototype))

[0009] Add candidate functions to the function candidate pool FunctionCandidatePool.

[0010] Step 2) Build the attack contract;

[0011] Reentrancy refers to the process in which, during the execution of a transaction, contract A makes an external call to a function in contract B, and contract B in turn calls a function in contract A.

[0012] Build an attack contract Agent. The Agent has the following functions: the Agent calls the function modified by payable in the contract to be tested and transfers money, the Agent calls any function in testedContract, and the Agent re-enters any function of the contract to be tested through the fallback function.

[0013] Step 3) Deploy the contract to be tested and the attack contract;

[0014] Send a transaction, deploy the contract to be tested and the attack contract to the test chain, and obtain the contract address testedContractAddr and the attack contract address AgentAddr;

[0015] Step 4) Randomly generate executable transactions;

[0016] Randomly select a candidate function FunctionCandidate from the candidate pool FunctionCandidatePool i and FunctionCandidate j (i and j can be equal), respectively as the first call target first and the reentrancy target reentrancy, according to the parameter type Function_parameters in the candidate function FunctionCandidate, randomly generate a legal parameter value paraValue to form an executable transaction.

[0017] Step 5) Collect dynamic execution information;

[0018] Get the dynamic execution information stepInfo of each step of the executable transaction generated in step 4) in the Ethereum virtual machine i ={opcode,stack,storage,callerAddr,calleeAddr}, where opcode is the instruction executed by EVM, stack is the variable value in the current stack, storage is the variable value in the current storage, callerAddr is the initiator address of the call, and calleeAddr is the target address of the call.

[0019] Step 6) Detect harmful reentry;

[0020] According to the callerAddr and calleeAddr information obtained in step 5), the contract call chain callList is constructed, where the node represents the address of the contract on the test chain and the edge represents the call relationship. If the contract address to be tested appears twice in the contract call chain, reentry occurs. If reentry occurs, determine whether a transfer operation is performed after reentry or the variable value of the same address in storage is modified multiple times. If the above operations occur, reentry is harmful, otherwise it is safe.

[0021] Step 7) Repeat steps 4) to 6). If harmful reentrancy is detected, the contract has a reentrancy defect. If the execution time executionTime is greater than the test time limit t, the contract is safe.

[0022] As an improvement of the present invention, the detection of harmful reentry in step 6) comprises the following steps:

[0023] (1) Based on the callerAddr and calleeAddr information obtained in step 5), the contract call chain callList is constructed, where the node represents the address of the contract on the test chain, and the edge represents the call relationship. Based on callList, it is determined whether reentry occurs. The details are as follows:

[0024] 1) Get callerAddr and calleeAddr of stepInfo from the execution log;

[0025] 2) Determine whether the contract call chain callList is empty. If callList is empty, execute step 3), otherwise execute step 4);

[0026] 3) Add callerAddr and calleeAddr to callList, and return to step 1);

[0027] 4) Determine whether callerAddr is the same as the address stored in the tail node of the callList chain. If so, execute step 5); otherwise, execute step 6);

[0028] 5) Add calleeAddr to callList and execute step 7)

[0029] 6) Delete the tail node of the chain and return to 2) to continue execution;

[0030] 7) Determine whether the contract address to be tested appears twice in the chain. If so, reentry is detected, otherwise return to step 1)

[0031] (2) When reentry is detected, determine whether a transfer operation is performed or the variable value of the same address in the storage is modified multiple times after the reentry. If the above operations occur, the reentry is harmful, otherwise it is safe. The specific judgment basis is as follows:

[0032] 1) Transfer operation: stepInfo i In stepInfo i .opcode=CALL,stepInfo i .stack[2]>0;

[0033] 2) Modify the variable value of the same address in storage multiple times: stepInfo i .opcode=stepInfo j .opcode=SSTORE,stepInfo i .stack[0] = stepInfo j .stack[0],i≠j.

[0034] Compared with the prior art, the present invention has the following advantages: 1) This technical solution improves the automation level of reentrancy defect detection. In this method, the deployment of the contract to be tested, the random generation and execution of transactions, and the collection and analysis of dynamic execution information are all completed automatically by the program. Compared with the previous taint analysis and formal verification methods, the automation level of detection is greatly improved and the labor cost is reduced; 2) This technical solution has high accuracy and low false alarm rate. This method divides reentrancy defect detection into two steps: discovering reentry and judging whether reentry is harmful. It screens out legal and purposeful reentry and reduces false alarms. In addition, this method analyzes whether harmful reentry occurs based on dynamic execution information. Once discovered, the reentry defect can be triggered, and there is no problem of unreachable paths. Compared with symbolic execution, the accuracy is greatly improved and the false alarm rate is reduced. And based on the analysis of dynamic information such as opcode, compared with traditional source code-based pattern matching, there is no need to consider the complexity of source code writing, which greatly reduces the difficulty of feature extraction and improves the accuracy; 3) This solution has high code coverage. This method uses dynamic execution information analysis. All functions in the contract to be tested are in the candidate pool, and the generation of parameter values ​​also adopts a completely random strategy. If the time limit of a test is long enough, all possible execution paths can be covered, so the code coverage rate is high. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 is a flow chart of the present invention;

[0036] Figure 2 It is the code diagram of the contract to be tested;

[0037] Figure 3 It is the attack contract code diagram;

[0038] Figure 4 It is the candidate pool of the contract to be tested;

[0039] Figure 5 It is the dynamic information of one step execution;

[0040] Figure 6 It is the contract call chain;

[0041] Figure 7 It is to judge the execution record of harmful reentry. DETAILED DESCRIPTION

[0042] In order to deepen the understanding of the present invention, the present embodiment is described in detail below with reference to the accompanying drawings.

[0043] Example 1: See Figure 1 , a method for detecting reentrancy defects in Ethereum smart contracts based on dynamic execution information analysis, the method comprising the following steps:

[0044] Step 1) Preprocess the contract to be tested;

[0045] Compile the contract to be tested and obtain its bytecode and binary interface information ABI. Analyze the binary interface information and obtain the function prototype FunctionPrototype of each function of the contract to be tested i , construct the candidate function FunctionCandidate based on the function prototype i ={Function_name i , Function_selector i , Function_parameters i}, where Function_name i is the function name, Function_selector i Function_parameters is the function selector i is the set of parameter types required by the function. The calculation formula of the function selector is:

[0046] Function_selector=bytes4(keccak256(functlonPrototype))

[0047] Add candidate functions to the function candidate pool FunctionCandidatePool.

[0048] Step 2) Build the attack contract;

[0049] Build an attack contract Agent. The Agent has the following functions: the Agent calls the function modified by payable in the contract to be tested and transfers money, the Agent calls any function in testedContract, and the Agent re-enters any function of the contract to be tested through the fallback function.

[0050] Step 3) Deploy the contract to be tested and the attack contract;

[0051] Send a transaction, deploy the contract to be tested and the attack contract to the test chain, and obtain the contract address testedContractAddr and the attack contract address AgentAddr;

[0052] Step 4) Randomly generate executable transactions;

[0053] Randomly select a candidate function FunctionCandidate from the candidate pool FunctionCandidatePool i and FunctionCandidate j (i and j can be equal), respectively as the first call target first and the reentrancy target reentrancy, according to the parameter type Function_parameters in the candidate function FunctionCandidate, randomly generate a legal parameter value paraValue to form an executable transaction.

[0054] Step 5) Collect dynamic execution information;

[0055] Get the dynamic execution information stepInfo of each step of the executable transaction generated in step 4) in the Ethereum virtual machine i ={opcode, stack, storage, callerAddr, calleeAddr}, where opcode is the instruction executed by the EVM, stack is the variable value in the current stack, storage is the variable value in the current storage, callerAddr is the initiator address of the call, and calleeAddr is the target address of the call.

[0056] Step 6) Detect harmful reentry;

[0057] According to the callerAddr and calleeAddr information obtained in step 5), the contract call chain callList is constructed, where the node represents the address of the contract on the test chain and the edge represents the call relationship. If the contract address to be tested appears twice in the contract call chain, reentry occurs. If reentry occurs, determine whether a transfer operation is performed after reentry or the variable value of the same address in storage is modified multiple times. If the above operations occur, reentry is harmful, otherwise it is safe.

[0058] Step 7) Repeat steps 4) to 6). If harmful reentrancy is detected, the contract has a reentrancy defect. If the execution time executionTime is greater than the test time limit t, the contract is safe.

[0059] Specific embodiment: refer to Figure 1-Figure 7, a smart contract reentrancy defect detection method based on dynamic execution information analysis, the method comprising the following steps:

[0060] The contract to be tested is Figure 2 The DAO contract shown.

[0061] Step 1) Preprocess the contract to be tested;

[0062] Compile the contract to be tested and obtain its bytecode and binary interface information ABI. Analyze the binary interface information and obtain the function prototype functionPrototype of each function of the contract to be tested i , the results are as follows:

[0063] functionPrototype donate =donate(address);

[0064] functionPrototype withdraw =withdraw(uint256);

[0065] Construct a candidate function Function_candidate based on the function prototype i ={Function_name i , Function_selector i , Function_parameters i}, where Function_name i is the function name, Function_selector i Function_parameters is the function selector i is the set of parameter types required by the function. The calculation formula of the function selector is:

[0066] Function_selector=bytes4(keccaak256(functionPrototype));

[0067] The function selector evaluates to the following:

[0068] Function_selector donate =bytes4(keccak256(functionPrototype donate ))=00362a95

[0069] Function_selector withdraw=bytes4(keccak256(functionPrototype withdraw ))=2e1a7d4d

[0070] The candidate functions constructed are as follows:

[0071] Function_candidate1={Function_name1:{donate},Function_selector1:{00362a95},Function_parameter1:{address}}

[0072] Function_candidate2={Function_name2:{withdraw},Function_selector2:{2e1a7d4d},Function_parameter2:{uint}}

[0073] The candidate pool FunctionCandidatePool is as follows Figure 4 shown.

[0074] Step 2) Build the attack contract;

[0075] Construct the attack contract Agent as follows Figure 3 As shown in the figure, the Agent calls the function modified with payable in the contract under test through the callPayable function and transfers money. The Agent calls any function in testedContract through the attack function. The Agent re-enters any function of the contract under test through the fallback function.

[0076] Step 3) Deploy the contract to be tested and the attack contract;

[0077] Send a transaction, deploy the contract to be tested and the attack contract to the test chain, obtain the address of the contract to be tested and the address of the attack contract, the results are as follows:

[0078] testedContractAddr=0x95423402D61eEFe885E74B30A05673C6af4da571

[0079] AgentAddr=0xed82f158F6c2426dD1ca8B2557faf988946D4e0A

[0080] Step 4) Randomly generate executable transactions;

[0081] Randomly select a candidate function FunctionCandidate from the candidate pool FunctionCandidatePool i and FunctionCandidate j (i and j can be equal), respectively as the first call target first and the reentrancy target reentrancy, the results are as follows:

[0082] first=candidate2

[0083] reentrancy=candidate2

[0084] According to the parameter type Function_parameters in the candidate function FunctionCandidate, the parameter value paraValue is randomly generated to form an executable transaction. The result of randomly generating paraValue is as follows:

[0085] paraValue first =1

[0086] paraValue reentrancy =123

[0087] Step 5) Collect dynamic execution information;

[0088] Get the dynamic execution information stepInfo of each step of the executable transaction generated in step 4) in the Ethereum virtual machine i ={opcode,stack,storage,callerAddr,calleeAddr}. Figure 5 An instance of dynamic execution information for a step execution, where:

[0089] opcode=EQ

[0090] stack={0xf8b2cb4f,0xf8b2cb4f,0xdb0fb107}

[0091] storage=null

[0092] callerAddr=0x95423402D61eEFe885E74B30A05673C6af4da571

[0093] calleeAddr=0xed82f158F6c2426dD1ca8B2557faf988946D4e0A

[0094] Step 6) Detect harmful reentry;

[0095] Based on the callerAddr and calleeAddr information obtained in step 5), the contract call chain callList is constructed, where the node represents the address of the contract on the test chain and the edge represents the call relationship. The callList constructed in this example is as follows Figure 6 As shown in the figure, testedContractAddr appears twice, indicating that reentry has occurred.

[0096] Analyze the dynamic execution information after reentry occurs to determine whether the reentry is harmful. Figure 7 The dynamic execution information shown, where opcode = CALL, stack[2] = 0x7b>0, performs a transfer operation, and determines that reentry is harmful.

[0097] Step 7) Harmful reentrancy is found and the contract has a reentrancy defect.

[0098] It should be noted that the above embodiments are not intended to limit the protection scope of the present invention, and equivalent changes or substitutions made on the basis of the above technical solutions all fall within the protection scope of the claims of the present invention.

Claims

1. A method for detecting reentrancy defects in Ethereum smart contracts based on dynamic execution information analysis, characterized in that: The method comprises the following steps: Step 1) Preprocess the contract to be tested; Step 2) Build the attack contract; Step 3) Deploy the contract to be tested and the attack contract; Step 4) Randomly generate executable transactions; Step 5) Collect dynamic execution information of test cases; Step 6) Detect harmful reentry; Step 7) Repeat steps 4) to 6). If harmful reentrancy is detected, the contract has a reentrancy defect. If the execution time executionTime> the test time limit t, the contract is safe. Among them, step 1) preprocesses the contract to be tested; specifically, compile the contract to be tested, obtain its bytecode Bytecode and binary interface information ABI, analyze the binary interface information, and obtain the function prototype FunctionPrototype of each function of the contract to be tested i , construct the candidate function FunctionCandidate based on the function prototype i ={Function_name i ,Function_selector i ,Function_parameters i }, where Function_name i is the function name, Function_selector i Function_parameters is the function selector i is the set of parameter types required by the function. The calculation formula of the function selector is: Function_selector=bytes4(keccak256(functionPrototype)) Add candidate functions to the function candidate pool FunctionCandidatePool, Step 2) Build an attack contract; specifically, build an attack contract Agent, which has the following functions: Agent calls the function modified by payable in the contract to be tested and transfers money, Agent calls any function in testedContract, Agent re-enters any function of the contract to be tested through the fallback function, Step 3) Deploy the contract to be tested and the attack contract; specifically, send a transaction, deploy the contract to be tested and the attack contract to the test chain, obtain the address of the contract to be tested, testedContractAddr, and the address of the attack contract, AgentAddr, Step 4) Randomly generate executable transactions; specifically, randomly select the candidate function FunctionCandidate in the candidate pool FunctionCandidatePool i and FunctionCandidate j , as the first call target first and the reentrancy target reentrancy, respectively, according to the parameter type Function_parameters in the candidate function FunctionCandidate, randomly generate a legal parameter value paraValue to form an executable transaction, Step 5) Collect dynamic execution information; specifically, obtain the dynamic execution information stepInfo of each step of the executable transaction generated in step 4) in the Ethereum virtual machine i ={opcode,stack,storage,callerAddr,calleeAddr}, where opcode is the instruction executed by EVM, stack is the variable value in the current stack, storage is the variable value in the current storage, callerAddr is the initiator address of the call, and calleeAddr is the target address of the call. Step 6) Detect harmful reentry; the details are as follows, (1) Based on the callerAddr and calleeAddr information obtained in step 5), the contract call chain callList is constructed, where the node represents the address of the contract on the test chain, and the edge represents the call relationship. Based on callList, it is determined whether reentry occurs, as follows: 1) Get callerAddr and calleeAddr of stepInfo from the execution log; 2) Determine whether the contract call chain callList is empty. If callList is empty, execute step 3), otherwise execute step 4) 3) Add callerAddr and calleeAddr to callList, and return to step 1) 4) Determine whether callerAddr is the same as the address stored in the tail node of the callList chain. If so, execute step 5); otherwise, execute step 6); 5) Add calleeAddr to callList and execute step 7) 6) Delete the tail node of the chain and return to step 2) to continue execution 7) Determine whether the contract address to be tested appears twice in the chain. If so, reentry is detected, otherwise return to step 1) (2) When reentry is detected, determine whether a transfer operation is performed or the variable value of the same address in the storage is modified multiple times after the reentry. If the above operations occur, the reentry is harmful, otherwise it is safe. The specific judgment basis is as follows: 1) Transfer operation: stepInfo i In stepInfo i .opcode=CALL,stepInfo i .stack[2]>0; 2) Modify the variable value of the same address in storage multiple times: stepInfo i .opcode=stepInfo j .opcode=SSTORE,stepInfo i .stack[0] = stepInfo j .stack[0],i≠j.

Images