Smart Contract Vulnerability Detection Method and System Based on Cross-Contract Control Flow Graph

Abstract

The present invention relates to the technical field of electrical data processing, specifically a method and system for detecting vulnerabilities in smart contracts based on a cross-contract control flow graph. To solve the technical problem of high false positive and false negative rates in existing smart contract technologies, the present invention connects the control flow graphs of multiple smart contracts with call relationships to generate a cross-contract control flow graph, and solves the different call paths and interactions between smart contracts by constructing the cross-contract control flow graph, more clearly capturing the execution logic and potential vulnerabilities of smart contracts. And based on the execution logic of smart contracts and the call relationships between smart contracts in the cross-contract control flow graph, and for different vulnerabilities, different vulnerability detection rules are designed to detect vulnerabilities in smart contracts and obtain vulnerability detection results. Compared with other advanced existing vulnerability detection methods, it is found that the vulnerability detection method of the present invention can detect cross-contract vulnerabilities, with low false positive and false negative rates, effectively improving the accuracy of vulnerability detection.

Description

Technical Field

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

[0002] Although traditional software vulnerability detection methods have certain effects in the security analysis of intelligent contracts, due to the decentralized and immutable characteristics of the execution of intelligent contract code, there are still many challenges. On the one hand, the execution of intelligent contracts is based on 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 intelligent contracts make it difficult for automated vulnerability detection tools to accurately locate vulnerabilities, leading to false positives and false negatives. The transaction order of intelligent contracts is not fixed, which exacerbates the difficulty for detection tools to perform accurate analysis, especially when detecting vulnerabilities involving complex control flows.

[0003] In recent years, research on intelligent contract security detection has emerged continuously, and many intelligent 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 individual contracts and ignore cross-contract calls, resulting in high false positives and false negatives. Summary of the Invention

[0004] The purpose of the present invention is to provide an intelligent 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:

[0006] An intelligent contract vulnerability detection method based on a cross-contract control flow graph includes the following operations:

[0007] S1. Convert the bytecode of the intelligent contract into opcodes, divide the opcodes into basic blocks, and connect the basic blocks according to jump instructions and sequential execution to obtain a control flow graph;

[0008] Based on the external call contract instructions in the control flow graph of the intelligent contract, obtain the called contract as the target contract; connect the control flow graph of the intelligent contract, the control flow graph of the target contract, and the control flow graphs of the external call contracts of the target contract to obtain a cross-contract control flow graph; when connecting the control flow graphs, connect the basic block where the external call contract instruction is located in the control flow graph of the first intelligent contract to the root basic block of the control flow graph of the second intelligent contract; the first intelligent contract externally calls the second intelligent contract.

[0009] S2. Based on the execution logic of smart contracts and the call relationships between smart contracts in the cross - contract control flow graph, perform vulnerability detection on the smart contracts to obtain vulnerability detection results.

[0010] 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 re - entry vulnerability.

[0011] 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 re - entry vulnerability.

[0012] 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 are malicious behaviors in the corresponding target contract against the current smart contract, then the current smart contract has a delegatecall vulnerability; malicious behaviors include tampering with contract storage and rewriting key contract variables.

[0013] 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 legitimate address, then the current smart contract has a self - destruction 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 re - calls the current smart contract through a callback function, and the fund transfer is not sent to a legitimate address, then the current smart contract has a self - destruction vulnerability.

[0014] In the cross - contract control flow graph, if there is an infinite loop or an un - terminable recursive call operation in the basic block of the current smart contract control flow graph, then 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 the function in the corresponding target contract is continuously failed to be called, and the corresponding target contract re - calls the current smart contract through a callback function, then the current smart contract has a denial - of - service vulnerability.

[0015] In the cross - contract control flow graph, if there is a block.timestamp opcode 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 there is a block.timestamp opcode in the basic block of the control flow graph of the called 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.

[0016] In a cross - contract control flow graph, if there are sstore or transfer operations in the basic blocks of the current smart contract control flow graph, and before the sstore or transfer operations, there are state updates or fund transfers in the current smart contract, and the call operation depends on the state update or fund transfer, then there is a transaction order - dependence vulnerability in the current smart contract; 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 conducts a fund transfer, then there is a transaction order - dependence vulnerability in the current smart contract.

[0017] 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, includes:

[0018] A cross - contract control flow graph generation module, which is used to convert the bytecode of a smart contract into opcodes, divide the opcodes 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 instructions in the control flow graph of the smart contract, obtain the called contract as the target contract; connect the control flow graph of the smart contract, the control flow graph of the target contract, and the control flow graph of the contracts externally called by the target contract to obtain a cross - contract control flow graph; when connecting the control flow graphs, 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 first smart contract externally calls the second smart contract.

[0019] A vulnerability detection result generation module, which is used to detect vulnerabilities in the smart contract based on the execution logic of the smart contract and the call relationship between smart contracts in the cross - contract control flow graph to obtain a vulnerability detection result.

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

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

[0022] The beneficial effects of the present invention are as follows:

[0023] A method for detecting vulnerabilities in smart contracts based on a cross - contract control flow graph provided by the present invention connects the control flow graphs of multiple smart contracts with call relationships to generate a cross - contract control flow graph. By constructing the cross - contract control flow graph, it solves the different call paths and interactions between smart contracts, and more clearly captures the execution logic and potential vulnerabilities of smart contracts. And based on the execution logic of smart contracts and the call relationships between smart contracts in the cross - contract control flow graph, different vulnerability detection rules are designed for different vulnerabilities to detect vulnerabilities in smart contracts and obtain vulnerability detection results. Comparing 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, effectively improving the accuracy of vulnerability detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] By reading the detailed description of the preferred embodiments below, the solutions and advantages of the present application will become clear to those of ordinary skill in the art. The drawings are only for the purpose of showing the preferred embodiments and are not considered to be a limitation of the present invention.

[0025] In the drawings:

[0026] Figure 1 is a schematic diagram of the vulnerability detection process in this embodiment;

[0027] Figure 2 is a comparison diagram of the detection effects of the method (abbreviated as CFGGuard) in this embodiment and the existing inspection methods. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0028] The following will describe the exemplary embodiments of the present disclosure in more detail with reference to the drawings.

[0029] This embodiment provides a method for detecting vulnerabilities in smart contracts based on a cross - contract control flow graph. Refer to Figure 1 , including the following operations:

[0030] S1. Convert the bytecode of the smart contract into opcodes, divide the opcodes into basic blocks, and connect the basic blocks according to jump instructions and sequential execution to obtain a control flow graph;

[0031] Based on the external call contract instructions in the control flow graph of the smart contract, obtain the called contract as the target contract; connect the control flow graph of the smart contract, the control flow graph of the target contract, and the control flow graph of the contracts externally called by the target contract to obtain a cross - contract control flow graph. When connecting the control flow graphs, connect the basic block where the external call contract instruction is located in the control flow graph of the first smart contract 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.

[0032] S2. Based on the execution logic of the smart contract and the call relationships between smart contracts in the cross-contract control flow graph, perform vulnerability detection on the smart contract to obtain the vulnerability detection result.

[0033] S1. Convert the bytecode of the smart contract into opcodes, divide the opcodes into basic blocks, execute according to the jump instructions and in sequence, and connect the basic blocks to obtain the control flow graph; based on the external call contract instructions in the control flow graph of the smart contract, obtain the called contract as the target contract; connect the control flow graph of the smart contract, the control flow graph of the target contract, and the control flow graph of the contracts externally called by the target contract to obtain the cross-contract control flow graph.

[0034] Connect the control flow graphs of multiple smart contracts with call relationships to generate a cross-contract control flow graph, which is convenient for further in-depth analysis of the complex call relationships of smart contracts and is beneficial to improving the accuracy of smart contract vulnerability detection.

[0035] First, convert the bytecode of the smart contract into opcodes, divide the opcodes into basic blocks, execute according to the jump instructions and in sequence, and connect the basic blocks to obtain the control flow graph. Specifically, the input is EVM bytecode, which is low-level code composed of a series of bytes, where each byte or group of bytes represents a specific opcode or related parameter; by parsing the bytecode byte by byte, the instruction stream of the contract can be generated; after parsing the EVM bytecode, use the tool solc to disassemble the bytecode into EVM assembly instructions to generate a sequence of opcodes, 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 a smart contract, each node represents a segment of operations in the bytecode or a segment of logic in a high-level function; the edges between nodes represent the jumps of the execution flow. For example, function calls, conditional branches, loop jumps, etc. When constructing the control flow graph, connect these basic blocks, execute according to the jump instructions and in sequence, establish the edges between the basic blocks, and form the structure of the control flow graph.

[0036] Table 1 shows the core code for constructing the control flow graph of a single smart contract. In Table 1, "functions" represents the set of all functions in the smart contract, which is used to create nodes for each function. "functioncalls" represents the call relationships between functions and is a mapping structure. Each entry records the other functions called by a certain function when it is the caller. In Table 1, lines 3 - 5 create a corresponding node for each function and add it to the control flow graph. Then, edges for each pair of function call relationships are added to the control flow graph. For each (caller, callees) pair in the "functioncalls" function, "caller" represents the caller function, and "callees" is the list of functions called by "caller". First, obtain the node "callerNode" of the caller "caller". Then, traverse each called function "callee" in "callees" and obtain the node "calleeNode" of "callee". 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.

[0037] Table 1 Construction Code for the Control Flow Graph of a Single Smart Contract

[0038]

[0039] Then, based on the external call contract instructions in the control flow graph of the smart contract, obtain the called contract as the target contract. Specifically, obtain the external call instructions (call instruction or delegatecall) in the basic blocks of the control flow graph of the smart contract, mark the corresponding basic blocks as external call nodes, and record the target address, function selector, and parameters called by the external call nodes; trace the instruction path of sload or calculate the target address, express the target address as a symbolic variable, solve its possible values, and once the target address is parsed, obtain the called contract as the target contract.

[0040] Finally, 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 contracts externally called by the target contract, and so on to connect the control flow graphs of smart contracts with call relationships to obtain a cross - contract control flow graph.

[0041] When connecting the control flow graphs, connect the basic block where the external call contract instruction is located in the control flow graph of the first smart contract with the root basic block (the root node of the control flow graph and also the basic block of the program execution entry) of the control flow graph of the second smart contract; the first smart contract externally calls the second smart contract.

[0042] Table 2 records the generated code for the cross - contract control flow graph. In Table 2, a new control flow graph object is created in line 2 to store the call relationships of each function and external contracts. In lines 3 - 5, the external call mapping is traversed, and in each iteration, a caller (i.e., the function that calls an external contract) and its corresponding externalContracts (the list of called external contracts) are obtained. A node is created for the caller function, and the node type is specified as "function", then the node representing the function is created. The callerNode is added to the control flow graph. In lines 6 - 8, the external contract nodes are traversed, the external contract nodes are added to the control flow graph, and an edge is added from the calling function callerNode to the external contract node externalNode, and the type of the edge is "external call", indicating 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 relationships between them.

[0043] Table 2 Cross - contract control flow graph construction code for multiple smart contracts

[0044]

[0045] In addition, to simplify the cross - contract control flow graph and improve the subsequent calculation efficiency; when there are circular calls between smart contracts in the cross - contract control flow graph, it will cause multiple duplicate paths to be generated in the control flow graph. If the conditions of two paths are exactly the same and do not affect the execution result at this time, then only one of the duplicate paths in the cross - contract control flow graph is retained. At the same time, for the part of the cross - contract control flow graph that has a loop, the loop path is folded into a single node (basic block).

[0046] S2. Based on the execution logic of smart contracts and the call relationships between smart contracts in the cross - contract control flow graph, perform vulnerability detection on smart contracts to obtain the vulnerability detection results.

[0047] Based on the execution logic of smart contracts and the call relationships between smart contracts in the cross - contract control flow graph, and for different vulnerabilities, design different vulnerability detection rules to perform vulnerability detection on smart contracts to obtain the vulnerability detection results.

[0048] For the detection of re - entry vulnerabilities in smart contracts.

[0049] In this embodiment, it is set 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 state update occurs after the external call, then there is a re - entry vulnerability in the current smart contract; 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 there is a re - entry vulnerability in the current smart contract.

[0050] Specifically, to detect re - entry vulnerabilities using the cross - contract control flow graph, it is necessary to analyze the behavior of the contract by combining the function - level and cross - contract interaction levels.

[0051] On the one hand, in the analysis of a single smart contract in the cross - contract control flow graph, analyze the control flow graph of each smart contract in the cross - contract control flow graph, traverse each basic block, identify whether there is an external call in the function (such as operation codes like call, delegatecall, etc.) 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 the call operation code or the delegatecall operation code) and the current smart contract state update occurs after the external call (the sstore operation code for state storage is after the call operation code or the delegatecall operation code), then there is a re - entry vulnerability in the current smart contract.

[0052] On the other hand, in the analysis of multiple smart contracts in the cross - contract control flow graph, by tracking the call operation code or the delegatecall operation code in the current smart contract control flow graph, record the external call target contract and the function logic, and check whether the external contract re - calls the current smart contract through a 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 re - calls the current smart contract through a callback function, then there is a re - entry vulnerability in the current smart contract. In addition, during the process of finding loops in the cross - contract control flow graph through depth - first search, if the current smart contract externally calls a target contract, the target contract externally calls another contract, and the other contract re - calls the current smart contract through a callback function, then there is a re - entry vulnerability in the current smart contract.

[0053] Regarding the detection of delegate call vulnerabilities in smart contracts.

[0054] 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 are malicious behaviors in the corresponding target contract against the current smart contract, then there is a delegate call vulnerability in the current smart contract; malicious behaviors include tampering with contract storage and rewriting key contract variables.

[0055] Specifically, in the cross - contract control flow graph, traverse the basic blocks of each function in each smart contract control flow graph to check if there is a `delegatecall` opcode. If the `delegatecall` opcode exists in a basic block, then there is an external call in the current smart contract. Locate the call node of the `delegatecall` opcode, obtain the corresponding target contract, record its parameters (target contract address and call data), and check if the function address of the corresponding target contract is fixed (the address information can be read from function parameters or storage variables). If the address of the corresponding target contract is not fixed and is untrusted, obtain the call edge containing the `delegatecall` opcode in the cross - contract control flow graph, record the current smart contract, the target contract, and the data passed during the call, and check the code logic of the target contract to confirm if there are malicious behaviors in the target contract. If there are malicious behaviors in the target contract against the current smart contract, such as tampering with storage or rewriting critical variables, and the target contract is untrusted, then the current smart contract has a delegate call vulnerability. Additionally, in the cross - contract control flow graph, perform a depth - first traversal of the delegate call path to trace other contract logics that may be affected after the execution of the `delegatecall` opcode. If the current smart contract calls a target contract, the target contract calls other contracts, the addresses of these other contracts are not fixed and untrusted, and these other contracts call back the current smart contract through the `delegatecall` opcode, forming a circular call, and there are operations in the call path to the current smart contract that allow dynamic injection of malicious code (i.e., there are malicious behaviors against the current smart contract), then the current smart contract has a delegate call vulnerability.

[0056] For the detection of self - destruction vulnerabilities in smart contracts.

[0057] 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 legitimate address, then the current smart contract has a self - destruction 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 redeems the current smart contract through a callback function, and the fund transfer is not sent to a legitimate address, then the current smart contract has a self - destruction vulnerability.

[0058] 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 it exists, 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 legitimate address; if there is a transfer operation after the selfdestruct operation and the transfer operation is not sent to a legitimate address, then the current smart contract has a self - destruction 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 a target contract and there is a selfdestruct operation in the target contract, check whether the corresponding target contract redeems the current smart contract through a callback function, and check whether there is an insecure fund transfer path (whether the fund transfer is sent to a legitimate address). If the target contract redeems the current smart contract through a callback function and the fund transfer is not sent to a legitimate address, then the current smart contract has a self - destruction vulnerability.

[0059] For the detection of denial - of - service vulnerabilities in smart contracts.

[0060] If there is an infinite loop or an un - terminable recursive call operation in the basic block of the control flow graph of the current smart contract, then the current smart contract has a denial - of - service vulnerability; if there is an external call in the basic block of the control flow graph of the current smart contract, and the corresponding function in the target contract is continuously called and fails, and the corresponding target contract redeems the current smart contract through a callback function, then the current smart contract has a denial - of - service vulnerability.

[0061] 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 an un - terminable recursive call in the basic block; if it exists, it means that there is an operation that consumes a large amount of gas. Consuming too much gas may cause the contract to fail, resulting in a contract denial - of - service vulnerability, then 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 during the call, it will block the current contract. In the cross - contract control flow graph, analyze the mutual dependence relationship between contracts, especially when there is an external call in the basic block of the control flow graph of the current smart contract, and the corresponding function in the target contract is continuously called and fails or cannot be called, and the corresponding target contract redeems the current smart contract through a callback function, resulting in a recursive call. During cross - contract interaction, contract A may be called back by contract B, and contract B calls back contract A again, causing resource waste or deadlock.

[0062] Detection of timestamp dependence vulnerabilities in smart contracts.

[0063] If there is a block.timestamp opcode 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 dependence vulnerability; if there is an external call in the basic block of the control flow graph of the current smart contract and there is a block.timestamp opcode in the basic block of the control flow graph of the called 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 dependence vulnerability.

[0064] 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 whether there is a block.timestamp opcode (which can be found by paying attention to conditional judgment operations such as if, require, etc.), which may determine the execution path based on the timestamp. If there is a block.timestamp opcode in the basic block and there is a random number generation operation, then the current smart contract has a timestamp dependence vulnerability. On the other hand, in the analysis of multiple smart contracts in the cross-contract control flow graph, analyze whether the behavior of the smart contract depends on the behavior of external contracts (such as calling an external contract and depending on its timestamp), and check whether these calls can be maliciously manipulated, resulting in insecure use of timestamps; if the current smart contract calls a target contract and the execution of the target contract depends on the timestamp (such as there is a block.timestamp opcode), then 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 state update, fund transfer, etc.) after the execution of the target contract, then 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 dependence vulnerability, then the current smart contract has a timestamp dependence vulnerability.

[0065] Detection of transaction order dependence vulnerabilities in smart contracts.

[0066] If there is an sstore or transfer operation in the basic block of the control flow graph of the current smart contract, and before the sstore or transfer operation, there is a state update or fund transfer in the current smart contract and the call operation depends on the state update, then the current smart contract has a transaction order dependence 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 conducts a fund transfer, then the current smart contract has a transaction order dependence vulnerability.

[0067] 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 within 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 there is a transaction order dependency vulnerability in the current smart contract. Secondly, if contract A first executes the sstore instruction to update the state and then calls contract B, or contract A first calls contract B and then makes a fund transfer, 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 certain smart contract depends on the transaction order; if the current smart contract updates a certain state before calling the target contract, or makes 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 makes a fund transfer, it may lead to a transaction order dependency vulnerability, and there is a transaction order dependency vulnerability in the current smart contract. In checking the cross-contract interaction path, especially among multiple contracts in the contract call chain, it is necessary to check whether there are incorrect state changes or fund transfers due to the call order, which can be achieved by checking operations such as state modification (such as sstore), transfer (such as transfer), and callback (such as fallback). If there are incorrect state changes or fund transfers due to the call order, then there is a transaction order dependency vulnerability in the smart contract.

[0068] To verify the effectiveness of the detection method in this embodiment (hereinafter referred to as CFGGuard), the following experiments were conducted.

[0069] The experiments 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 types of vulnerabilities? Question 3: Compared with other detection tools, can CFGGuard more accurately detect reentrancy vulnerabilities, delegatecall vulnerabilities, self-destruction vulnerabilities, denial-of-service vulnerabilities, timestamp dependency vulnerabilities, and transaction order dependency vulnerabilities?

[0070] Preparations before the experiment. All experiments were conducted in JDK 8.0, and CFGGuard was run using IntelliJ IDEA, version 2022.1.4, for writing and debugging Java code. IntelliJ IDEA provides support for plugins such as Java bytecode analysis and control flow graph generation, facilitating the development and testing processes. CFGGuard was compared with the three vulnerability detection tools in Table 3, all of which used control flow graphs to detect smart contract vulnerabilities and operated on Ethereum bytecode. CFGGuard was 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 vulnerability types detected. RE, DDC, SD, DoS, TD, and TOD represent re-entrancy vulnerability, delegate call vulnerability, self-destruction vulnerability, denial-of-service vulnerability, timestamp dependency vulnerability, and transaction order dependency vulnerability, respectively.

[0071] Table 3 Input of tools required for the experiment and detectable vulnerability types

[0072]

[0073] Datasets. In the experiment, CFGGuard was evaluated using three datasets. The first dataset was 1000 different versions of smart contracts from Ethereum, between versions 0.4.0 - 0.8.0, to verify the effectiveness of CFGGuard in analyzing smart contracts. The second dataset was used for a comprehensive evaluation of CFGGuard. 100 manually labeled Ethereum smart contracts containing all the vulnerabilities to be tested were run on CFGGuard to calculate relevant performance parameters. The third dataset contained 200 Ethereum smart contracts for comparing the accuracy of CFGGuard and four other tools in detecting smart contract vulnerabilities.

[0074] Evaluation Parameters. Seven main evaluation metrics 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 metrics were used to comprehensively evaluate the performance of CFGGuard for vulnerability detection. Based on these metrics, Precision (Pre), Recall (R), and F1-score (F1Score, F) were calculated, and these evaluation metrics were calculated by the following three equations: Pre = TP / (TP+FP), R = TP / (TP+FN), and F = (2×Pre×R) / (Pre+R).

[0075] Success Rate (Response to Question 1). First, a comparison was made in terms of the success rate of parsing smart contracts. These tools were run on Dataset 1, and the number of successfully executed and non-empty control flow graphs given in the output was counted. CFGGuard was able to analyze 996 smart contracts with a success rate of 99.6%. The success rate was defined as the ratio between the number of smart contracts analyzed without critical errors and the size of the dataset. As Figure 2 shown, Mythril was able to analyze almost all smart contracts (991 out of 1000). The high success rate of Mythril benefited from its mature analysis framework, but its running time was relatively long, which might limit the processing efficiency for large-scale datasets. Followed by Oyente with 878 smart contracts. Octopus reached an error state for many smart contracts and only counted 504 smart contracts. Therefore, CFGGuard significantly shortened 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.

[0076] 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) were also calculated. RE, DDC, SD, DoS, TD, TOD represent Reentrancy vulnerability, Delegated Call vulnerability, Self-Destruction vulnerability, Denial of Service vulnerability, Timestamp Dependency vulnerability, and Transaction Order Dependency vulnerability respectively.

[0077] Table 4 Detection Results of CFGGuard

[0078]

[0079] Comparison with other existing methods (reply to Question 3). In the experiment, CFGGuard was compared with three other existing vulnerability detection tools. To ensure the fairness of the comparison, tools Octopus, Oyente, and Mythril that can detect at the bytecode level and detect vulnerabilities by constructing control flow graphs were selected as the benchmark tools. By comparing the experimental results in Table 4 with those in Tables 5, 6, and 7, it can be seen that CFGGuard has a high precision and F1 score in detecting vulnerabilities.

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

[0081] Table 6 presents the detection results of the Oyente tool. The F1 values of Oyente in detecting reentrancy vulnerabilities, timestamp dependency vulnerabilities, and transaction order dependency vulnerabilities are 30.8%, 31.2%, and 16.2% respectively, while the F1 values of CFGGuard for the corresponding vulnerabilities are 100.0%, 89.8%, and 87.8% respectively. In the detection of timestamp dependency vulnerabilities, Oyente has a large number of missed detections, which may be caused by the problem of path explosion. In the detection of transaction order dependency vulnerabilities, there are relatively high false positives and missed detections because Oyente marks any contract with two different Ether flows as having a transaction order dependency vulnerability. This loose standard does not consider the fund flow logic in the actual scenario. For example, in some contracts, the operation of the owner withdrawing the balance or a specified amount does not result in actual fund losses but may still be misjudged as a TOD vulnerability, leading to false positives. In addition, Oyente only focuses on the change in the transferred amount 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 missed detections.

[0082] Table 7 shows the results of running Octopus on the third dataset. The results show a large number of false positives, especially in detecting transaction denial-of-service vulnerabilities. This is because Octopus may misclassify some normal function calls as DoS vulnerabilities. For example, when a contract performs multiple transfer operations through the send() or transfer() functions, Octopus may mistakenly think 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 it is easy to ignore the potential impact of the transfer() function. Because the transfer() function may also cause service interruption due to blocking operations in the receiving contract, and the failure to cover this will lead to missed reports.

[0083] Table 5 Detection Results of Mythril

[0084]

[0085] Table 6 Detection Results of Oyente

[0086]

[0087] Table 7 Detection Results of Octopus

[0088]

[0089] This embodiment also provides a smart contract vulnerability detection system based on a cross-contract control flow graph for implementing the above-mentioned smart contract vulnerability detection method based on a cross-contract control flow graph, including:

[0090] A cross-contract control flow graph generation module, which is used to convert the bytecode of a smart contract into opcodes, divide the opcodes into basic blocks, and connect the basic blocks according to jump instructions and sequential execution to obtain a control flow graph; based on the external call contract instructions in the control flow graph of the smart contract, obtain the called contract as the target contract; connect the control flow graph of the smart contract, the control flow graph of the target contract, and the control flow graph of the contracts externally called by the target contract to obtain a cross-contract control flow graph; when connecting the control flow graphs, connect the basic block where the external call contract instruction is located in the control flow graph of the first smart contract 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;

[0091] A vulnerability detection result generation module, which is used to perform vulnerability detection on the smart contract based on the execution logic of the smart contract and the call relationship between smart contracts in the cross-contract control flow graph to obtain vulnerability detection results.

[0092] This embodiment also provides a device for detecting vulnerabilities in smart contracts based on a cross-contract control flow graph, including a processor and a memory. When the processor executes the computer program stored in the memory, the above-mentioned method for detecting vulnerabilities in smart contracts based on a cross-contract control flow graph is implemented.

[0093] This embodiment also provides a computer-readable storage medium for storing a computer program. When the computer program is executed by a processor, the above-mentioned method for detecting vulnerabilities in smart contracts based on a cross-contract control flow graph is implemented.

[0094] A method for detecting vulnerabilities in smart contracts based on a cross-contract control flow graph provided in this embodiment connects the control flow graphs of multiple smart contracts with call relationships to generate a cross-contract control flow graph, and solves different call paths and interactions between smart contracts by constructing the cross-contract control flow graph, more clearly capturing the execution logic and potential vulnerabilities of smart contracts; and based on the execution logic of smart contracts and the call relationships between smart contracts in the cross-contract control flow graph, different vulnerability detection rules are designed for different vulnerabilities to detect vulnerabilities in smart contracts and obtain vulnerability detection results. Comparing 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, effectively improving 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