Intelligent contract vulnerability detection method and system based on cross-contract control flow graph

Abstract

The invention relates to the technical field of electric data processing, in particular to an intelligent contract vulnerability detection method and system based on a cross-contract control flow graph. In order to solve the technical problem of high false alarm rate and missing report rate of the smart contract in the prior art, control flow diagrams of a plurality of smart contracts with a calling relationship are connected to generate a cross-contract control flow diagram, and different calling paths and interactions among the smart contracts are solved by constructing the cross-contract control flow diagram, so that the cross-contract control flow diagram is established. The execution logic and potential vulnerabilities of the smart contract can be captured more clearly; based on the execution logic of the smart contracts and the calling relation between the smart contracts in the cross-contract control flow graph, different vulnerability detection rules are designed for different vulnerabilities, vulnerability detection is performed on the smart contracts, and a vulnerability detection result is obtained; according to the vulnerability detection method, cross-contract vulnerabilities can be detected, the false alarm rate and the missing report rate are low, and the vulnerability detection accuracy is effectively improved.

Description

Technical Field

[0001] The present invention relates to the field of electrical data processing technology, and specifically to a smart contract vulnerability detection method and system based on a cross-contract control flow graph. Background Art

[0002] Although traditional software vulnerability detection methods have some effect on the security analysis of smart contracts, there are still many challenges due to the decentralized and immutable nature of smart contract code execution. On the one hand, the execution of smart contracts is based on the bytecode on the Ethereum Virtual Machine (EVM), which is quite different from the traditional software development environment and requires specialized analysis tools and techniques. On the other hand, the common concurrent execution and complex call chain structure in smart contracts make it difficult for automated vulnerability detection tools to accurately locate vulnerabilities, which leads to false positives and false negatives. The transaction order of smart contracts is not fixed, which increases the difficulty of detection tools to perform accurate analysis, especially when detecting vulnerabilities involving complex control flows.

[0003] In recent years, research on smart contract security testing has continued to emerge, and many smart contract vulnerability detection methods have been proposed, such as symbolic execution, fuzz testing, formal verification, deep learning, etc. However, these methods only generate control flow graphs for a single contract and ignore cross-contract calls, resulting in a high rate of false positives and negatives. Summary of the invention

[0004] The purpose of the present invention is to provide a smart contract vulnerability detection method and system based on a cross-contract control flow graph.

[0005] The technical solution of the present invention is as follows: A smart contract vulnerability detection method based on a cross-contract control flow graph includes the following operations: S1. Convert the bytecode of the smart contract into opcode, divide the opcode into basic blocks, connect the basic blocks to get the control flow graph according to the jump instructions and sequential execution; Based on the external call contract instruction in the control flow graph of the smart contract, obtain the calling contract as the target contract; connect the control flow graph of the smart contract with the control flow graph of the target contract and the control flow graph of the target contract externally calling the contract to obtain a cross-contract control flow graph; when connecting the control flow graphs, the basic block where the external call contract instruction in the control flow graph of the first smart contract is located is connected to the root basic block of the control flow graph of the second smart contract; the first smart contract externally calls the second smart contract; S2. Based on the execution logic of the smart contract and the calling relationship between smart contracts in the cross-contract control flow graph, the smart contract is tested for vulnerabilities to obtain vulnerability detection results.

[0006] In the cross-contract control flow graph, if there is an external call in the basic block of the current smart contract control flow graph, and the current smart contract state update occurs after the external call, then the current smart contract has a reentrancy vulnerability; If there is an external call in the basic block of the current smart contract control flow graph, and the corresponding target contract calls the current smart contract again through the callback function, the current smart contract has a reentrancy vulnerability.

[0007] In the cross-contract control flow graph, if there is an external call in the basic block of the current smart contract control flow graph, and the address of the corresponding target contract is not fixed, and there is malicious behavior against the current smart contract in the corresponding target contract, then the current smart contract has a delegate call vulnerability; malicious behavior includes tampering with contract storage and rewriting key contract variables.

[0008] In the cross-contract control flow graph, if there is a transfer operation after the selfdestruct operation in the basic block of the current smart contract control flow graph, and the transfer operation is not sent to a legal address, then the current smart contract has a self-destruct vulnerability; if there is an external call in the basic block of the current smart contract control flow graph, and there is a selfdestruct operation in the corresponding target contract, and the corresponding target contract calls the current smart contract again through a callback function, and the fund transfer is not sent to a legal address, then the current smart contract has a self-destruct vulnerability.

[0009] In the cross-contract control flow graph, if there is an infinite loop or a recursive call operation that cannot be terminated in the basic block of the current smart contract control flow graph, the current smart contract has a denial of service vulnerability; if there is an external call in the basic block of the current smart contract control flow graph, and it continuously fails to call the function in the corresponding target contract, and the corresponding target contract re-calls the current smart contract through the callback function, the current smart contract has a denial of service vulnerability.

[0010] In the cross-contract control flow graph, if the basic block of the control flow graph of the current smart contract contains the block.timestamp opcode and there is a random number generation operation, then the current smart contract has a timestamp dependency vulnerability; if there is an external call in the basic block of the control flow graph of the current smart contract, and the basic block of the control flow graph in the corresponding target contract contains the block.timestamp opcode, and the operation of the current smart contract depends on the return value of the corresponding target contract, then the current smart contract has a timestamp dependency vulnerability.

[0011] In the cross-contract control flow graph, if there is an sstore or transfer operation in the basic block of the current smart contract control flow graph, and before the sstore or transfer operation, the current smart contract updates the state or transfers funds, and the call operation depends on the state update or fund transfer, then the current smart contract has a transaction order dependency vulnerability; if the current smart contract first executes the sstore instruction to update the state and then calls the corresponding target contract, or the current smart contract first calls the corresponding target contract and then transfers funds, then the current smart contract has a transaction order dependency vulnerability.

[0012] A smart contract vulnerability detection system based on a cross-contract control flow graph is used to implement the above-mentioned smart contract vulnerability detection method based on a cross-contract control flow graph, comprising: The cross-contract control flow graph generation module is used to convert the bytecode of the smart contract into an opcode, divide the opcode into basic blocks, and connect the basic blocks to obtain a control flow graph according to jump instructions and sequential execution; based on the external call contract instruction in the control flow graph of the smart contract, obtain the calling contract as the target contract; connect the control flow graph of the smart contract with the control flow graph of the target contract and the control flow graph of the target contract externally calling the contract to obtain a cross-contract control flow graph; when connecting the control flow graph, the basic block where the external call contract instruction in the control flow graph of the first smart contract is located is connected to the root basic block of the control flow graph of the second smart contract; the first smart contract externally calls the second smart contract; The vulnerability detection result generation module is used to perform vulnerability detection on smart contracts based on the execution logic of smart contracts and the calling relationship between smart contracts in the cross-contract control flow graph to obtain vulnerability detection results.

[0013] A smart contract vulnerability detection method and device based on a cross-contract control flow graph includes a processor and a memory, wherein the processor implements the above-mentioned smart contract vulnerability detection method based on a cross-contract control flow graph when executing a computer program stored in the memory.

[0014] A computer-readable storage medium is used to store a computer program, wherein the computer program, when executed by a processor, implements the above-mentioned smart contract vulnerability detection method based on a cross-contract control flow graph.

[0015] The beneficial effects of the present invention are: The present invention provides a smart contract vulnerability detection method based on a cross-contract control flow graph, which connects the control flow graphs of multiple smart contracts with calling relationships to generate a cross-contract control flow graph, and solves different calling paths and interactions between smart contracts by constructing a cross-contract control flow graph, so as to more clearly capture the execution logic and potential vulnerabilities of the smart contract; and based on the execution logic of the smart contract and the calling relationship between the smart contracts in the cross-contract control flow graph, different vulnerability detection rules are designed for different vulnerabilities, and vulnerability detection is performed on the smart contract to obtain vulnerability detection results. Compared with other advanced existing vulnerability tools, it is found that the vulnerability detection method of the present invention can detect cross-contract vulnerabilities with low false positive rate and false negative rate, which effectively improves the accuracy of vulnerability detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] By reading the detailed description of the preferred embodiment below, the scheme and advantages of the present application will become clear to those skilled in the art. The accompanying drawings are only for the purpose of illustrating the preferred embodiment and are not to be considered as limiting the present invention.

[0017] In the attached picture: Figure 1 Schematic diagram of vulnerability detection process in this embodiment; Figure 2 : is a comparison chart of the detection effect of the method of this embodiment (abbreviated as CFGGuard) and the existing inspection method in the embodiment. DETAILED DESCRIPTION

[0018] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings.

[0019] This embodiment provides a smart contract vulnerability detection method based on a cross-contract control flow graph, see Figure 1 , including the following operations: S1. Convert the bytecode of the smart contract into opcode, divide the opcode into basic blocks, connect the basic blocks to get the control flow graph according to the jump instructions and sequential execution; Based on the external call contract instruction in the control flow graph of the smart contract, obtain the calling contract as the target contract; connect the control flow graph of the smart contract with the control flow graph of the target contract and the control flow graph of the target contract externally calling the contract to obtain a cross-contract control flow graph; when connecting the control flow graphs, the basic block where the external call contract instruction in the control flow graph of the first smart contract is located is connected to the root basic block of the control flow graph of the second smart contract; the first smart contract externally calls the second smart contract; S2. Based on the execution logic of the smart contract and the calling relationship between smart contracts in the cross-contract control flow graph, the smart contract is tested for vulnerabilities to obtain vulnerability detection results.

[0020] S1. Convert the bytecode of the smart contract into operation code, divide the operation code into basic blocks, connect the basic blocks according to jump instructions and sequential execution to obtain a control flow graph; based on the external call contract instruction in the control flow graph of the smart contract, obtain the calling contract as the target contract; connect the control flow graph of the smart contract with the control flow graph of the target contract and the control flow graph of the external call contract of the target contract to obtain a cross-contract control flow graph.

[0021] The control flow graphs of multiple smart contracts with calling relationships are connected to generate a cross-contract control flow graph, which facilitates a more in-depth analysis of the complex calling relationships of smart contracts and helps improve the accuracy of smart contract vulnerability detection.

[0022] First, the bytecode of the smart contract is converted into opcode, and the opcode is divided into basic blocks. According to jump instructions and sequential execution, the basic blocks are connected to obtain a control flow graph. Specifically, the input is EVM bytecode, which is a low-level code consisting of a series of bytes, where each byte or a group of bytes represents a specific opcode (opcode) or related parameters; by parsing the bytecode byte by byte, the instruction stream of the contract can be generated; after parsing the EVM bytecode, the tool solc is used to disassemble the bytecode into EVM assembly instructions, generate an opcode sequence, and then divide these opcodes into basic blocks to find the starting and ending points of each basic block; each node in the control flow graph represents a basic block, that is, an instruction sequence without branches; for smart contracts, each node represents a section of operation in the bytecode, or a section of logic in a high-level function; the edges between nodes represent the jump of the execution flow. For example, function calls, conditional branches, loop jumps, etc. When building a control flow graph, these basic blocks are connected, and according to jump instructions and sequential execution, the edges between basic blocks are established to form the structure of the control flow graph.

[0023] Table 1 shows the core code for constructing a control flow graph for a single smart contract in this embodiment. In Table 1, functions represents the set of all functions in the smart contract, which is used to create a node for each function. functioncalls represents the calling relationship between functions and is a mapping structure. Each entry records other functions called by a function when it is a caller. In Table 1, lines 3-5 create a corresponding node for each function and add it to the control flow graph. Then add the edges of each pair of function call relationships in the control flow graph. For each (caller, callees) pair in the functioncalls function, caller represents the caller function, and callees is a list of functions called by the caller. First, get the callerNode node of the caller caller. Then traverse each called function callee in callees and get the callee node calleeNode. Create an edge representing "internal call" between callerNode and calleeNode through line 10. Finally, return the constructed control flow graph, which contains the nodes of all functions in a contract and the call edges between functions.

[0024] Table 1 Single smart contract control flow graph construction code

[0025] Then, based on the external call contract instruction in the control flow graph of the smart contract, the calling contract is obtained as the target contract. Specifically, the external call instruction (call instruction or delegatecall) in the basic block of the control flow graph of the smart contract is obtained, the corresponding basic block is marked as an external call node, and the target address, function selector and parameters called by the external call node are recorded; the instruction path of sload or calculation target address is tracked, the target address is expressed as a symbolic variable, and its possible value is solved. Once the target address is resolved, the calling contract is obtained as the target contract.

[0026] Finally, the control flow graph of the smart contract is connected with the control flow graph of the target contract and the control flow graph of the target contract's external calling contract. Similarly, the control flow graphs of the smart contracts containing calling relationships are connected to obtain a cross-contract control flow graph.

[0027] When connecting the control flow graph, the basic block where the external call contract instruction is located in the control flow graph of the first smart contract is connected to the root basic block of the control flow graph of the second smart contract (the root node of the control flow graph, which is also the basic block of the program execution entry); the first smart contract externally calls the second smart contract.

[0028] Table 2 records the generated code of the cross-contract control flow graph. In Table 2, line 2 creates a new control flow graph object to store the calling relationship between each function and the external contract. Lines 3-5 traverse the external call mapping, and obtain a caller (i.e., the function that calls the external contract) and its corresponding externalContracts (the list of external contracts called) in each iteration. Create a node for the caller function, specify the node type as "function", and then create a node representing the function. Add callerNode to the control flow graph. Lines 6-8 traverse the external contract node, add the external contract node to the control flow graph, and add an edge from the calling function callerNode to the external contract node externalNode. The edge type is "external call", indicating that this is an external contract call relationship. Finally, the constructed control flow graph is returned, which contains all function nodes, external contract nodes, and the external call relationship between them.

[0029] Table 2 Construction code of cross-contract control flow graph of multiple smart contracts

[0030] In addition, to simplify the cross-contract control flow graph and improve the subsequent computing efficiency; when there are circular calls between smart contracts in the cross-contract control flow graph, multiple repeated paths will be generated in the control flow graph. If the conditions of the two paths are exactly the same and do not affect the execution result, one of the repeated paths in the cross-contract control flow graph will be retained. At the same time, for the part of the cross-contract control flow graph where there is a loop, the loop path is collapsed into a single node (basic block).

[0031] S2. Based on the execution logic of the smart contract and the calling relationship between smart contracts in the cross-contract control flow graph, the smart contract is tested for vulnerabilities to obtain vulnerability detection results.

[0032] Based on the execution logic of the smart contract and the calling relationship between smart contracts in the cross-contract control flow graph, different vulnerability detection rules are designed for different vulnerabilities, and vulnerability detection is performed on the smart contract to obtain vulnerability detection results.

[0033] Detection of reentrancy vulnerabilities in smart contracts.

[0034] This embodiment is arranged that, in a cross-contract control flow graph, if there is an external call in the basic block of the current smart contract control flow graph, and the current smart contract state update occurs after the external call, then the current smart contract has a reentrancy vulnerability; if there is an external call in the basic block of the current smart contract control flow graph, and the corresponding target contract re-calls the current smart contract through a callback function, then the current smart contract has a reentrancy vulnerability.

[0035] Specifically, to detect reentrancy vulnerabilities using cross-contract control flow graphs, it is necessary to analyze the behavior of the contract at both the function level and the cross-contract interaction level.

[0036] On the one hand, in the analysis of a single smart contract in a cross-contract control flow graph, the control flow graph of each smart contract in the cross-contract control flow graph is analyzed, each basic block is traversed, and it is identified whether there are external calls in the function (such as call, delegatecall and other opcodes) and whether the state update occurs after the external call. If there is an external call in the current smart contract control flow graph (the function contains a call opcode or a delegatecall opcode), and the current smart contract state update occurs after the external call (the sstore opcode used for state storage is after the call opcode or the delegatecall opcode), then the current smart contract has a reentrancy vulnerability.

[0037] On the other hand, in the analysis of multiple smart contracts in the cross-contract control flow graph, by tracking the call opcode or delegatecall opcode in the current smart contract control flow graph, recording the external call target contract and function logic, check whether the external contract calls the current smart contract again through the callback function (such as fallback); if there is an external call in the basic block of the current smart contract control flow graph, and the corresponding target contract calls the current smart contract again through the callback function, then the current smart contract has a reentrancy vulnerability. In addition, in the process of finding loops in the cross-contract control flow graph through depth-first search, if the current smart contract externally calls the target contract, the target contract externally calls other contracts, and other contracts call the current smart contract again through the callback function, then the current smart contract has a reentrancy vulnerability.

[0038] Detection of delegate call vulnerabilities in smart contracts.

[0039] If there is an external call in the basic block of the current smart contract control flow graph, and the address of the corresponding target contract is not fixed, and there is malicious behavior against the current smart contract in the corresponding target contract, then the current smart contract has a delegated call vulnerability; malicious behavior includes tampering with contract storage and rewriting key contract variables.

[0040] Specifically, in the cross-contract control flow graph, traverse the basic block of each function of each smart contract control flow graph, check whether there is a delegatecall opcode, if there is a delegatecall opcode in the basic block, the current smart contract has an external call, locate the call node of the delegatecall opcode, obtain the corresponding target contract, record its parameters (target contract address and call data), check whether the corresponding target contract function address is fixed (the address information can be read from the function parameters and storage variables); if the address of the corresponding target contract is not fixed and unreliable, obtain the call edge containing the delegatecall opcode in the cross-contract control flow graph, record the current smart contract, target contract, and the data passed during the call, and check the code logic of the target contract to confirm whether the target contract has malicious behavior. If there is malicious behavior against the current smart contract in the corresponding target contract, such as tampering with storage, rewriting key variables, etc., and the target contract is not trusted, then the current smart contract has a delegate call vulnerability. In addition, in the cross-contract control flow graph, the delegate call path is traversed depth-first to track other contract logics that may be affected after the delegatecall opcode is executed. If the current smart contract calls the target contract, and the target contract calls other contracts, the addresses of other contracts are not fixed and unreliable, and other contracts call back the current smart contract through the delegatecall opcode, forming a circular call, and there are operations in the path of calling the current smart contract that allow dynamic injection of malicious code (that is, there is malicious behavior against the current smart contract), then the current smart contract has a delegate call vulnerability.

[0041] Detection of self-destruct vulnerabilities in smart contracts.

[0042] If there is a transfer operation after the selfdestruct operation in the basic block of the current smart contract control flow graph, and the transfer operation is not sent to a legal address, the current smart contract has a self-destruct vulnerability. If there is an external call in the basic block of the current smart contract control flow graph, and there is a selfdestruct operation in the corresponding target contract, and the corresponding target contract calls the current smart contract again through the callback function, and the fund transfer is not sent to a legal address, the current smart contract has a self-destruct vulnerability.

[0043] Specifically, in the cross-contract control flow graph, on the one hand, for the control flow graph of a single smart contract, analyze the control flow graph of each single smart contract, check whether there is a selfdestruct opcode in the basic block, if there is, further determine whether there is a transfer or similar transfer operation after the selfdestruct operation, and determine whether the fund transfer is sent to a legal address; if there is a transfer operation after the selfdestruct operation, and the transfer operation is not sent to a legal address, then the current smart contract has a self-destruct vulnerability. On the other hand, in the analysis of multiple smart contracts in the cross-contract control flow graph, analyze the cross-contract call path, especially whether the contract destruction operation involves an external contract call; if the current smart contract calls the target contract, and there is a selfdestruct operation in the target contract, check whether the corresponding target contract calls the current smart contract again through the callback function, and check whether there is an unsafe fund transfer path (whether the fund transfer is sent to a legal address). If the target contract calls the current smart contract again through the callback function, and the fund transfer is not sent to a legal address, then the current smart contract has a self-destruct vulnerability.

[0044] Detection of denial of service vulnerabilities in smart contracts.

[0045] If there is an infinite loop or a recursive call operation that cannot be terminated in the basic block of the current smart contract control flow graph, the current smart contract has a denial of service vulnerability; if there is an external call in the basic block of the current smart contract control flow graph, and it continuously fails to call the function in the corresponding target contract, and the corresponding target contract re-calls the current smart contract through the callback function, the current smart contract has a denial of service vulnerability.

[0046] Specifically, in the cross-contract control flow graph, on the one hand, for the control flow graph of a single smart contract, check whether there is a code segment in the control flow graph of each smart contract that may cause high gas consumption, that is, check whether there is an infinite loop or a recursive call that cannot be terminated in the basic block; if there is, it means that there is an operation that consumes a lot of gas. Excessive gas consumption may cause the contract to fail, thereby causing a contract denial of service vulnerability, and the current smart contract has a denial of service vulnerability. On the other hand, in the analysis of multiple smart contracts in the cross-contract control flow graph, check whether the smart contract depends on an external contract. If the external contract does not respond for a long time when called, it will block the current contract. In the cross-contract control flow graph, analyze the interdependence between contracts, especially when there is an external call in the basic block of the current smart contract control flow graph, and the function in the corresponding target contract is continuously failed to call or cannot be called, and the corresponding target contract re-calls the current smart contract through the callback function, resulting in a recursive call. When interacting across contracts, contract A may be called back by contract B, and contract B calls back contract A, resulting in resource waste or deadlock.

[0047] Detection of timestamp dependency vulnerabilities in smart contracts.

[0048] If the block.timestamp opcode exists in the basic block of the control flow graph of the current smart contract and there is a random number generation operation, then the current smart contract has a timestamp dependency vulnerability; if there is an external call in the basic block of the control flow graph of the current smart contract, and the block.timestamp opcode exists in the basic block of the control flow graph in the corresponding target contract, and the operation of the current smart contract depends on the return value of the corresponding target contract, then the current smart contract has a timestamp dependency vulnerability.

[0049] Specifically, in the cross-contract control flow graph, on the one hand, for the control flow graph of a single smart contract, analyze the control flow graph of each function to find out whether there is a block.timestamp opcode (which can be determined by paying attention to conditional judgment operations, such as if, require, etc.). They may determine the execution path based on the timestamp. If the block.timestamp opcode exists in the basic block and there is a random number generation operation, then the current smart contract has a timestamp dependency vulnerability. On the other hand, in the analysis of multiple smart contracts in the cross-contract control flow graph, if the smart contract depends on the behavior of external contracts (such as calling external contracts and relying on their timestamps), it is necessary to check whether these calls will be maliciously manipulated, resulting in unsafe timestamp use; if the current smart contract calls the target contract, and the execution of the target contract depends on the timestamp (such as the existence of the block.timestamp opcode), it is necessary to determine whether the current smart contract is affected by the operation of the target contract. If the operation of the current smart contract depends on the return value of the corresponding target contract, for example, the current smart contract performs certain operations (such as status updates, fund transfers, etc.) after the target contract is executed, the execution result of the target contract may be affected by the timestamp problem, and the behavior of the current smart contract will also be affected, resulting in a timestamp dependency vulnerability. In this case, the current smart contract has a timestamp dependency vulnerability.

[0050] Detection of transaction order dependency vulnerabilities in smart contracts.

[0051] If there is an sstore or transfer operation in the basic block of the current smart contract control flow graph, and before the sstore or transfer operation, the current smart contract updates its status or transfers funds, and the call operation depends on the status update, then the current smart contract has a transaction order dependency vulnerability; if the current smart contract first executes the sstore instruction to update the status and then calls the corresponding target contract, or the current smart contract first calls the corresponding target contract and then transfers funds, then the current smart contract has a transaction order dependency vulnerability.

[0052] Specifically, on the one hand, for the control flow graph of a single smart contract, check whether there is logic that depends on the transaction order in each smart contract function, traverse the basic blocks in the control flow graph of each smart contract, and check whether the basic block contains the opcode sstore that affects the contract state. If an sstore or transfer operation is executed in a basic block, and a state update or fund transfer has occurred before the call, and the subsequent call operation depends on these state updates, then the current smart contract has a transaction order dependency vulnerability. Secondly, if contract A executes the sstore instruction to update the state before calling contract B, or contract A calls contract B first and then transfers funds, then the attacker can control the transaction order to affect the execution result of contract A, resulting in a transaction order dependency vulnerability. On the other hand, in the analysis of multiple smart contracts in the cross-contract control flow graph, it is necessary to detect whether the call of a smart contract depends on the transaction order; if the current smart contract updates a certain state before calling the contract target contract, or performs operations such as fund transfer after calling the target contract, that is, if the current smart contract first executes the sstore instruction to update the state and then calls the corresponding target contract, or the current smart contract first calls the corresponding target contract and then transfers funds, it may cause a transaction order dependency vulnerability. The current smart contract has a transaction order dependency vulnerability. In checking the cross-contract interaction path, especially between multiple contracts in the contract call chain, it is necessary to check whether the wrong state change or fund transfer is caused by the call order. This can be achieved by checking state modification (such as sstore), transfer (such as transfer) and callback (such as fallback) and other operations. If there is an incorrect state change or fund transfer caused by the call order, the smart contract has a transaction order dependency vulnerability.

[0053] In order to verify the effect of the detection method of this embodiment (hereinafter referred to as CFGGuard), the following experiment was conducted.

[0054] The experiment demonstrated its performance from three research questions: Question 1: What is the success rate of CFGGuard when analyzing real smart contracts compiled with different versions of the Solidity compiler? Question 2: Can CFGGuard efficiently detect the six vulnerabilities mentioned above? Question 3: Compared with other detection tools, can CFGGuard detect reentrancy vulnerabilities, delegate call vulnerabilities, self-destruction vulnerabilities, denial of service vulnerabilities, timestamp dependency vulnerabilities, and transaction order dependency vulnerabilities more accurately? Preliminary preparation for the experiment. All experiments were conducted on JDK8.0, and CFGGuard was run using IntelliJ IDEA, version 2022.1.4, for writing and debugging Java code. IntelliJ IDEA provides support for plug-ins such as Java bytecode analysis and control flow graph generation, which facilitates the development and testing process. CFGGuard is compared with the three vulnerability detection tools in Table 3, all of which use control flow graphs to detect smart contract vulnerabilities and operate on Ethereum bytecode. CFGGuard is compared with these three vulnerability detection tools to verify the effectiveness of CFGGuard in contract analysis and vulnerability detection accuracy. Table 3 shows the four tools required for the experiment and the corresponding types of vulnerabilities detected. RE, DDC, SD, DoS, TD, and TOD represent reentrancy vulnerabilities, delegate call vulnerabilities, self-destruction vulnerabilities, denial of service vulnerabilities, timestamp dependency vulnerabilities, and transaction order dependency vulnerabilities, respectively.

[0055] Table 3 Inputs of the tools required for the experiment and the types of vulnerabilities that can be detected

[0056] Datasets. In the experiment, CFGGuard was evaluated using three datasets. The first dataset is 1,000 different versions of smart contracts from Ethereum, between versions 0.4.0 and 0.8.0, to verify the effectiveness of CFGGuard in analyzing smart contracts. The second dataset is used for a comprehensive evaluation of CFGGuard. 100 manually labeled Ethereum smart contracts, which contain all the vulnerabilities that need to be tested, are run on CFGGuard to calculate relevant performance parameters. The third dataset contains 200 Ethereum smart contracts, which are used to compare the accuracy of CFGGuard and the other four tools in detecting smart contract vulnerabilities.

[0057] Evaluation parameters. Seven main evaluation indicators were obtained for the experimental results, including True Positive (TP), True Negative (TN), False Positive (FP), False Negative (FN), Precision (P), Recall (R), and F1 score (F). These indicators are used to comprehensively evaluate the performance of CFGGuard for vulnerability detection. Based on these metrics, Precision (Precision, Pre), Recall (R), and F1 score (F1Score, F) are calculated. These evaluation indicators are calculated by the following three equations: Pre = TP / (TP+FP), R = TP / (TP+FN), F = (2×Pre×R) / (Pre+R).

[0058] Success rate (response to question 1). First, a comparison was made in terms of the success rate of parsing smart contracts. The tools were run on dataset 1 and the successful executions and non-empty control flow graphs given in the output were counted. CFGGuard was able to analyze 996 smart contracts with a success rate of 99.6%. The success rate is defined as the ratio between the smart contracts analyzed without critical errors and the size of the dataset. Figure 2 As shown in the figure, Mythril is able to analyze almost all smart contracts (991 out of 1,000). Mythril's high success rate is due to its mature analysis framework, but its relatively long running time may limit the processing efficiency of large-scale data sets. It is followed by Oyente with 878 smart contracts. Octopus reached an error state on many smart contracts and only calculated 504 smart contracts. Therefore, CFGGuard significantly shortens the running time while maintaining a high success rate. This makes CFGGuard have greater application potential in large-scale contract analysis and real-time detection scenarios.

[0059] Effectiveness (response to question 2). The experiment tested CFGGuard on the second dataset. Table 4 provides the number of vulnerabilities detected by CFGGuard, including the number of TP, TN, FP, and FN. The corresponding precision (P), recall (R), and F1 score (F) are also calculated. RE, DDC, SD, DoS, TD, and TOD represent reentrancy vulnerability, delegate call vulnerability, self-destruct vulnerability, denial of service vulnerability, timestamp dependency vulnerability, and transaction order dependency vulnerability, respectively.

[0060] Table 4 CFGGuard detection results

[0061] Comparison with other existing methods (response to question 3). In the experiment, CFGGuard was compared with three other existing vulnerability detection tools. To ensure a fair comparison, Octopus, Oyente, and Mythril, which can detect vulnerabilities at the bytecode level and by building control flow graphs, were selected as benchmark tools. Comparing the experimental results in Table 4 with those in Table 5, Table 6, and Table 7, it can be seen that CFGGuard has a higher accuracy and F1 score in detecting vulnerabilities.

[0062] Table 5 shows the detection results of Mythril, which marks half of the smart contracts as having reentrancy vulnerabilities. However, when reviewing the contracts marked as reentrancy vulnerabilities by Mythril, it was found that Mythril could not distinguish the semantics of external call functions such as call(), transfer(), and send() when analyzing the contracts at the bytecode level. It marked any state change after an external call as a potential reentrancy vulnerability, which resulted in a large number of false positives.

[0063] Table 6 shows the detection results of the Oyente tool. Oyente has an F1 value of 30.8%, 31.2%, and 16.2% in detecting reentrancy vulnerabilities, timestamp dependency vulnerabilities, and transaction order dependency vulnerabilities, respectively, while CFGGuard has an F1 value of 100.0%, 89.8%, and 87.8% for the corresponding vulnerabilities, respectively. In the detection of timestamp dependency vulnerabilities, Oyente has a large number of false negatives, which may be caused by the path explosion problem. In the detection of transaction order dependency vulnerabilities, there are high false positives and false negatives, which is because Oyente marks any contract with two different ether flows as a transaction order dependency vulnerability. This loose standard does not consider the logic of fund flow in actual scenarios. For example, in some contracts, the owner's operation of withdrawing the balance or specifying the amount does not result in actual fund loss, but it may still be misjudged as a TOD vulnerability, resulting in false positives. In addition, Oyente only focuses on the change in the amount of the transfer and ignores the recipient information. For example, if the change in the transaction order affects the recipient, but the tool fails to detect this, it may lead to false negatives.

[0064] Table 7 shows the results of running Octopus on the third dataset. The results show that there are a lot of false positives, especially in detecting transaction denial of service vulnerabilities. This is because Octopus may mistake some normal function calls as DoS vulnerabilities. For example, when a contract performs transfer operations multiple times through the send() or transfer() functions, Octopus may mistakenly believe that these actions will cause blocking or service interruption, and thus mark them as DoS vulnerabilities. Octopus mainly focuses on the send() function when detecting DoS, but tends to ignore the potential impact of the transfer() function. Because the transfer() function may also cause service interruption due to the blocking operation of the receiving contract, failure to cover this will result in missed reports.

[0065] Table 5 Mythril detection results

[0066] Table 6 Oyente test results

[0067] Table 7 Octopus test results

[0068] This embodiment also provides a smart contract vulnerability detection system based on a cross-contract control flow graph, which is used to implement the above-mentioned smart contract vulnerability detection method based on a cross-contract control flow graph, including: The cross-contract control flow graph generation module is used to convert the bytecode of the smart contract into an opcode, divide the opcode into basic blocks, and connect the basic blocks to obtain a control flow graph according to jump instructions and sequential execution; based on the external call contract instruction in the control flow graph of the smart contract, obtain the calling contract as the target contract; connect the control flow graph of the smart contract with the control flow graph of the target contract and the control flow graph of the target contract externally calling the contract to obtain a cross-contract control flow graph; when connecting the control flow graph, the basic block where the external call contract instruction in the control flow graph of the first smart contract is located is connected to the root basic block of the control flow graph of the second smart contract; the first smart contract externally calls the second smart contract; The vulnerability detection result generation module is used to perform vulnerability detection on smart contracts based on the execution logic of smart contracts and the calling relationship between smart contracts in the cross-contract control flow graph to obtain vulnerability detection results.

[0069] This embodiment also provides a smart contract vulnerability detection method and device based on a cross-contract control flow graph, including a processor and a memory, wherein the processor implements the above-mentioned smart contract vulnerability detection method based on a cross-contract control flow graph when executing a computer program stored in the memory.

[0070] This embodiment also provides a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the above-mentioned smart contract vulnerability detection method based on a cross-contract control flow graph.

[0071] The present embodiment provides a smart contract vulnerability detection method based on a cross-contract control flow graph, which connects the control flow graphs of multiple smart contracts with calling relationships to generate a cross-contract control flow graph, and solves different calling paths and interactions between smart contracts by constructing a cross-contract control flow graph, so as to more clearly capture the execution logic and potential vulnerabilities of the smart contract; and based on the execution logic of the smart contract and the calling relationship between the smart contracts in the cross-contract control flow graph, different vulnerability detection rules are designed for different vulnerabilities, and vulnerability detection is performed on the smart contract to obtain vulnerability detection results. Compared with other advanced existing vulnerability tools, it is found that the vulnerability detection method of the present invention can detect cross-contract vulnerabilities with low false positive rate and missed negative rate, which effectively improves the accuracy of vulnerability detection.

Claims

1. A smart contract vulnerability detection method based on a cross-contract control flow graph, characterized in that: The following operations are included: S1. Convert the bytecode of the smart contract into opcode, divide the opcode into basic blocks, connect the basic blocks to get the control flow graph according to the jump instructions and sequential execution; Based on the external call contract instruction in the control flow graph of the smart contract, obtain the calling contract as the target contract; connect the control flow graph of the smart contract with the control flow graph of the target contract and the control flow graph of the target contract externally calling the contract to obtain a cross-contract control flow graph; when connecting the control flow graphs, the basic block where the external call contract instruction in the control flow graph of the first smart contract is located is connected to the root basic block of the control flow graph of the second smart contract; the first smart contract externally calls the second smart contract; S2. Based on the execution logic of the smart contract and the calling relationship between smart contracts in the cross-contract control flow graph, the smart contract is tested for vulnerabilities to obtain vulnerability detection results.

2. According to claim 1, the smart contract vulnerability detection method based on the cross-contract control flow graph is characterized in that: In the cross-contract control flow graph, If there is an external call in the basic block of the current smart contract control flow graph, and the current smart contract status update occurs after the external call, then the current smart contract has a reentrancy vulnerability; If there is an external call in the basic block of the current smart contract control flow graph, and the corresponding target contract calls the current smart contract again through the callback function, the current smart contract has a reentrancy vulnerability.

3. The smart contract vulnerability detection method based on cross-contract control flow graph according to claim 1 is characterized in that: In the cross-contract control flow graph, If there is an external call in the basic block of the current smart contract control flow graph, and the address of the corresponding target contract is not fixed, and there is malicious behavior against the current smart contract in the corresponding target contract, then the current smart contract has a delegated call vulnerability; malicious behavior includes tampering with contract storage and rewriting key contract variables.

4. The smart contract vulnerability detection method based on cross-contract control flow graph according to claim 1 is characterized in that: In the cross-contract control flow graph, If there is a transfer operation after the selfdestruct operation in the basic block of the current smart contract control flow graph, and the transfer operation is not sent to a valid address, then the current smart contract has a self-destruct vulnerability; If there is an external call in the basic block of the current smart contract control flow graph, and there is a selfdestruct operation in the corresponding target contract, and the corresponding target contract calls the current smart contract again through the callback function, and the fund transfer is not sent to the legal address, then the current smart contract has a self-destruct vulnerability.

5. The method for detecting smart contract vulnerabilities based on cross-contract control flow graphs according to claim 1 is characterized in that: In the cross-contract control flow graph, If there is an infinite loop or a recursive call operation that cannot be terminated in the basic block of the current smart contract control flow graph, the current smart contract has a denial of service vulnerability; If there are external calls in the basic blocks of the current smart contract control flow graph, and the calls to the functions in the corresponding target contract continue to fail, and the corresponding target contract calls the current smart contract again through the callback function, then the current smart contract has a denial of service vulnerability.

6. The smart contract vulnerability detection method based on cross-contract control flow graph according to claim 1 is characterized in that: In the cross-contract control flow graph, If the block.timestamp opcode exists in the basic block of the control flow graph of the current smart contract and there is a random number generation operation, then the current smart contract has a timestamp dependency vulnerability; If there is an external call in the basic block of the control flow graph of the current smart contract, and the block.timestamp opcode exists in the basic block of the control flow graph in the corresponding target contract, and the operation of the current smart contract depends on the return value of the corresponding target contract, then the current smart contract has a timestamp dependency vulnerability.

7. The smart contract vulnerability detection method based on cross-contract control flow graph according to claim 1 is characterized in that: In the cross-contract control flow graph, If there is an sstore or transfer operation in the basic block of the current smart contract control flow graph, and before the sstore or transfer operation, the current smart contract has a state update or fund transfer, and the call operation depends on the state update or fund transfer, then the current smart contract has a transaction order dependency vulnerability; If the current smart contract first executes the sstore instruction to update the status and then calls the corresponding target contract, or the current smart contract first calls the corresponding target contract and then transfers funds, the current smart contract has a transaction order dependency vulnerability.

8. A smart contract vulnerability detection system based on a cross-contract control flow graph, used to implement the smart contract vulnerability detection method based on a cross-contract control flow graph according to claim 1, characterized in that: include: The cross-contract control flow graph generation module is used to convert the bytecode of the smart contract into an opcode, divide the opcode into basic blocks, and connect the basic blocks to obtain a control flow graph according to jump instructions and sequential execution; based on the external call contract instruction in the control flow graph of the smart contract, obtain the calling contract as the target contract; connect the control flow graph of the smart contract with the control flow graph of the target contract and the control flow graph of the target contract externally calling the contract to obtain a cross-contract control flow graph; when connecting the control flow graph, the basic block where the external call contract instruction in the control flow graph of the first smart contract is located is connected to the root basic block of the control flow graph of the second smart contract; the first smart contract externally calls the second smart contract; The vulnerability detection result generation module is used to perform vulnerability detection on smart contracts based on the execution logic of smart contracts and the calling relationship between smart contracts in the cross-contract control flow graph to obtain vulnerability detection results.

9. A smart contract vulnerability detection method and device based on a cross-contract control flow graph, characterized in that: It includes a processor and a memory, wherein when the processor executes the computer program stored in the memory, it implements the smart contract vulnerability detection method based on the cross-contract control flow graph as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein when the computer program is executed by a processor, it implements the smart contract vulnerability detection method based on a cross-contract control flow graph as described in any one of claims 1 to 7.

Images