A smart contract vulnerability detection method based on static profit analysis

Abstract

This paper discloses a smart contract vulnerability detection method based on static profit analysis. This method divides the logical behavior of smart contracts into two parts: profit and expenditure. By performing path-sensitive symbolic execution analysis on the contract under test, it attempts to find paths where there is no permission check on the caller, profit behavior occurs, the profitee is not checked, and the caller does not incur any cost. The code involved in this path is then determined to be vulnerable code. This method focuses on the overall semantic information of the contract code logic, and has a wide detection range, accurate detection results, and high recognition coverage.

Description

Technical Field

[0001] The present invention relates to the fields of smart contract security and static analysis, and in particular to a smart contract vulnerability detection method based on static profit analysis. Background Art

[0002] Blockchain technology is developing rapidly. Since the launch of Ethereum 2.0, smart contracts, as on-chain program code, have proven to be immutable once uploaded, facilitating the rapid development of decentralized finance. However, due to the complexity and difficulty of smart contract development, attacks exploiting vulnerabilities in smart contract code are common, causing significant losses to both users and project owners. The security of smart contracts on the blockchain is currently facing significant challenges.

[0003] To address these security issues, accurate and effective smart contract vulnerability detection methods are urgently needed. While currently common manual auditing methods can accurately and effectively identify code issues, they are labor-intensive and require a significant amount of domain expertise, making them incapable of detecting vulnerabilities across large numbers of contracts. Current static detection tools for automated vulnerability detection often focus solely on the suspected vulnerable code statements themselves, ignoring the logical semantics of the vulnerability code context. These tools also lack comprehensive and effective detection rules for existing vulnerability types. This results in high false positive rates and limited vulnerability detection capabilities. Summary of the Invention

[0004] In view of the shortcomings of existing smart contract static detection technology, the present invention provides a smart contract vulnerability detection method based on static profit analysis.

[0005] The core concept of this smart contract vulnerability detection method is that for every transaction invocation of a smart contract, if the caller is a non-privileged address, the called contract must ensure a balanced balance between revenue and expenditure. Therefore, if a non-privileged address only generates revenue without incurring any costs after completing a contract call, a code vulnerability is considered present. A vulnerability is defined as a program path that does not have caller permission checks, yet generates profit, has no corresponding caller expenditure, and does not perform checks on the beneficiary.

[0006] The purpose of the present invention is achieved through the following technical solutions:

[0007] A method for detecting smart contract vulnerabilities based on static profit analysis, comprising the following steps:

[0008] Step 1: Compile the smart contract written in Solidity into the Yul intermediate language using the solc compiler and convert it into a control flow graph;

[0009] Step 2: Perform path-sensitive symbolic execution analysis on the control flow graph. During the symbolic execution analysis, path information is collected to identify the following four types of behaviors: possible profit behaviors of the caller and the corresponding beneficiaries, possible expenditure behaviors of the caller, caller permission checks, and beneficiary checks.

[0010] Step 3: When the symbolic execution analysis reaches the end of each path, all collected information is combined to determine whether the path may have a vulnerability;

[0011] Step 4: After analyzing all possible paths or reaching the preset program running time, organize and output the vulnerability detection results.

[0012] Furthermore, the possible profit-making behaviors of the caller include profit-making behaviors brought about by internal ledger modifications, profit-making behaviors brought about by external contract calls based on EIP standards including ERC20, and profit-making behaviors brought about by native tokens.

[0013] Furthermore, the profit-making behavior brought about by the internal ledger modification includes: the token destruction behavior of the address controlled by the callee, the token destruction behavior of the transaction pool address, and the token minting behavior of the address controlled by the callee; the beneficiary of the profit-making behavior brought about by the internal ledger modification is the owner address variable of the modified internal ledger.

[0014] Furthermore, the profit behavior brought about by external contract calls based on EIP standards including ERC20 is the transfer behavior or authorization behavior to the address controlled by the callee, that is, searching for whether there is a transfer or approve function, and the first parameter of the corresponding function call is the address controlled by the callee; the beneficiary of the profit behavior brought about by external contract calls based on EIP standards including ERC20 is the first parameter variable of the function call, that is, the address variable being transferred or authorized.

[0015] Furthermore, the caller's possible spending behaviors include three categories: spending behaviors caused by internal ledger modifications, spending behaviors caused by external contract calls based on EIP standards including ERC20, and spending behaviors of the caller's native tokens.

[0016] Furthermore, the caller's spending behavior caused by the internal ledger modification includes: the contract under test reducing the spending behavior of the "_allowances" storage variable authorized to the caller, and the contract under test reducing the spending behavior of any storage variable under the caller's name except "_allowances".

[0017] Furthermore, the caller's spending behavior caused by external contract calls based on EIP standards including ERC20 includes the test contract calling the transferFrom / safeTransferFrom function with the first parameter being the caller's external function call behavior, and through the previous and next ledger checks, that is, using the balanceOf external call or address(this).balance to check the token balance including ERC20 or the native token balance, and compare them to determine the behavior of increasing the balance of this contract.

[0018] Furthermore, when the symbolic execution analysis encounters a conditional branch, the caller permission check behavior and the variable check behavior are identified in combination with the actual branch path selection of the current symbolic execution analysis; the variable check behavior is matched with the beneficiary information recorded in the profit behavior, thereby identifying the beneficiary check behavior;

[0019] The caller's permissions are checked when the conditional branch meets the following two conditions:

[0020] (1) This conditional branch means that the caller compares the contract's built-in data, which includes storage type data, constant type data, and immutable type data;

[0021] (2) The value selected by the conditional branch in the current execution path represents that the conditional branch restricts the caller to the contract's built-in value range;

[0022] The variable is checked when the following two conditions are met in the conditional branch:

[0023] (1) This conditional branch means comparing the variable with the contract's built-in data, which includes storage type data, constant type data, and immutable type data;

[0024] (2) The value selected by the conditional branch in the current execution path indicates that the conditional branch restricts the variable to the contract’s built-in value range.

[0025] Furthermore, the step three includes the following sub-steps:

[0026] (3.1) Determine whether the path ends with revert. If so, it means that the path cannot be successfully executed and the path analysis ends; otherwise, continue to execute (3.2);

[0027] (3.2) Is there a caller permission check in the path? If so, it is considered that there is no vulnerability and the path analysis ends. Otherwise, continue to (3.3);

[0028] (3.3) Traverse and analyze each caller profit behavior collected in step 2 to determine whether it is a "token destruction behavior of the transaction pool address". If so, directly execute (3.4); otherwise, determine whether there is a profit check behavior corresponding to the profit behavior in the path. If so, exclude the profit behavior; otherwise, continue to execute (3.4);

[0029] (3.4) Determine whether there is an expenditure behavior required for the profit-making behavior in the current execution path. If so, it is considered that there is no vulnerability and the profit-making behavior is excluded; otherwise, it is considered that there is a vulnerability in the path, and the profit point brought by the vulnerability is the code corresponding to the profit-making behavior. Record the vulnerability detection results.

[0030] A smart contract vulnerability detection device based on static profit analysis includes one or more processors for implementing a smart contract vulnerability detection method based on static profit analysis.

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

[0032] The smart contract vulnerability detection method of this invention is based on the static analysis of smart contracts. It uses path-sensitive symbolic execution to simulate possible contract execution paths and identify program execution paths that allow the caller to profit without performing any permission checks and without incurring any expenditures. This detection method aligns with the business semantics of smart contracts and can more effectively identify contract code vulnerabilities with high accuracy and coverage. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 This is an overall flow chart of the smart contract vulnerability detection method based on static profit analysis according to an embodiment of the present invention.

[0034] Figure 2 It is a flowchart that determines whether there is a vulnerability in the path at the end of the path.

[0035] Figure 3 Schematic diagram of a smart contract vulnerability detection device based on static profit analysis in an embodiment. DETAILED DESCRIPTION

[0036] The present invention will be described in detail below with reference to the accompanying drawings and preferred embodiments, and the purpose and effects of the present invention will become more apparent. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0037] As one of the implementation methods, Figure 1 As shown, the smart contract vulnerability detection method based on static profit analysis of this embodiment includes the following steps:

[0038] Step 1: Use the solc compiler to compile the smart contract written in Solidity into the Yul intermediate language and convert it into a control flow graph.

[0039] Step 2: Perform path-sensitive symbolic execution analysis on the control flow graph (CFG). During the symbolic execution analysis, collect path information and identify the following four types of behaviors: the caller's possible profit-making behavior and the corresponding beneficiary, the caller's possible expenditure behavior, the caller's permission check behavior, and the beneficiary check behavior.

[0040] (2.1) The caller's possible profit-making behavior and the corresponding beneficiaries

[0041] The caller's possible profit-making behaviors include: profit-making behaviors brought about by internal ledger modifications, profit-making behaviors brought about by external contract calls based on EIP standards including ERC20, and profit-making behaviors brought about by native tokens.

[0042] (2.1.1) Profitable activities resulting from internal ledger modifications, including: token destruction of addresses controlled by the callee, token destruction of transaction pool addresses, and token minting of addresses controlled by the callee.

[0043] The beneficiary of the profit behavior brought about by the modification of the internal ledger is the owner address variable of the modified internal ledger.

[0044] Although the token destruction behavior here does not make any profit for the address of the destroyed token, it is actually an indirect profit behavior for the caller. In the detection rules, the address of the destroyed token is set as the beneficiary here.

[0045] (2.1.2) Profitable behavior resulting from external contract calls based on EIP standards including ERC20

[0046] This behavior is a transfer or authorization to an address controlled by the callee. This means searching for a transfer or approve function where the first argument to the function call is the address controlled by the callee. The beneficiary of this behavior is the first argument variable of the function call, i.e., the address variable being transferred or authorized.

[0047] (2.1.3) Profitability of Native Tokens

[0048] This action is to transfer the native token to the address controlled by the callee. The beneficiary of this action is the address variable that receives the native token transfer.

[0049] The "address controlled by the callee" in (2.1) above means: the address directly derived from the calldata parameter variable when calling an external function, or the new variable obtained by calculating the calldata parameter.

[0050] (2.2) Possible spending behavior of the caller (i.e. msg.sender)

[0051] This behavior includes three categories: caller spending behavior caused by internal ledger modifications, caller spending behavior caused by external contract calls based on EIP standards including ERC20, and caller native token spending behavior.

[0052] (2.2.1) Caller spending behavior caused by internal ledger modification

[0053] Depending on the storage variable being modified, two modification behaviors are identified:

[0054] 1. The contract under test reduces the spending behavior of authorizing the caller's "_allowances" storage variable;

[0055] 2. The contract under test reduces the spending behavior of any storage variables under the caller's name except "_allowances".

[0056] (2.2.2) Caller spending behavior caused by external contract calls based on EIP standards including ERC20

[0057] This includes the contract under test calling the transferFrom / safeTransferFrom function, with the first parameter being the caller's external function call behavior, as well as checking the previous and next ledgers, that is, using the balanceOf external call or address(this).balance to check the balance of tokens including ERC20 or native tokens, and comparing them to determine the behavior of increasing the balance of this contract.

[0058] (2.2.3) Native Token Spending Behavior

[0059] That is, the code behavior of the contract under test using msg.value (msg.value represents the number of native tokens received by the contract under test in the current transaction. In this method, it means that in this program path, the contract under test requires the caller to pay the native token).

[0060] (2.3) Caller permission check behavior

[0061] When symbolic execution analysis encounters a conditional branch, it combines the actual branch path selection of the current symbolic execution analysis with the condition of the conditional branch to identify the caller permission check behavior. Specifically:

[0062] There is a behavior where the caller's permissions are checked, which requires the conditional branch to meet the following two points:

[0063] (a) This conditional branch means that the caller (msg.sender) is compared with the contract's built-in data, which includes storage type data, constant type data, and immutable type data.

[0064] (b) The value selected by the conditional branch in the current execution path indicates that the conditional branch restricts the caller to the contract's built-in value range.

[0065] For example, assuming that the owner variable is the owner address of this contract, which is the storage address variable within the contract, for the if (msg.sender == owner) judgment, when the if conditional branch takes the false branch, the check does not restrict the caller's value to the contract's built-in range. For the if conditional branch takes the true branch, the check restricts the caller's value to the contract's built-in range.

[0066] If both of the above points are met, it is considered that the caller permissions on this path are checked and there is a caller permission check behavior.

[0067] (2.4) Profit-seeker inspection behavior

[0068] To collect profit-seeker checks, all variable checks must be collected during path analysis. Specifically, when symbolic execution analysis encounters a conditional branch, variable checks are identified based on the actual branch path selection during the current symbolic execution analysis and the conditional branch conditions. For a variable to be checked during the current analysis path, the following two conditions must be met:

[0069] (a) This conditional branch means comparing the variable with the contract's built-in data, which includes storage type data, constant type data, and immutable type data.

[0070] (b) The value selected by the conditional branch in the current execution path indicates that the conditional branch restricts the variable to the contract’s built-in value range.

[0071] If both of the above conditions are met, the variable is checked. For checked variables, if the variable is calculated by keccak256, abi.encode, or abi.encodePacked, the components of keccak256, abi.encode, or abi.encodePacked are also checked.

[0072] After obtaining the variable inspection behavior information of the path, it is matched with the beneficiary information recorded in step (2.1) to collect the beneficiary inspection behavior information.

[0073] Step 3: When the symbolic execution analysis encounters the end of each path, all the collected information is combined to determine whether the path may have a vulnerability, as follows: Figure 2 As shown, this is achieved through the following sub-steps:

[0074] (3.1) Determine whether the path ends with revert. If so, it means that the path cannot be successfully executed and the path analysis ends; otherwise, continue to execute (3.2);

[0075] (3.2) Is there a caller permission check in the path? If so, it is considered that there is no vulnerability and the path analysis ends. Otherwise, continue to (3.3);

[0076] (3.3) Traverse and analyze each caller profit behavior collected in step 2 to determine whether it is a "token destruction behavior of the transaction pool address". If so, directly execute (3.4); otherwise, determine whether there is a profit check behavior corresponding to the profit behavior in the path. If so, exclude the profit behavior; otherwise, continue to execute (3.4);

[0077] (3.4) Determine whether there is an expenditure behavior required for the profit-making behavior in the current execution path. If so, it is considered that there is no vulnerability and the profit-making behavior is excluded; otherwise, it is considered that there is a vulnerability in the path, and the profit point brought by the vulnerability is the code corresponding to the profit-making behavior. Record the vulnerability detection results.

[0078] Step 4: After analyzing all possible paths or reaching the preset program running time, organize and output the vulnerability detection results.

[0079] On the other hand, corresponding to the aforementioned embodiment of the smart contract vulnerability detection method based on static profit analysis, the present invention also provides an embodiment of a smart contract vulnerability detection device based on static profit analysis.

[0080] See also Figure 3An embodiment of the present invention provides a smart contract vulnerability detection device based on static profit analysis, including one or more processors for implementing the smart contract vulnerability detection method based on static profit analysis in the above embodiment.

[0081] The embodiment of the smart contract vulnerability detection device based on static profit analysis of the present invention can be applied to any device with data processing capabilities, and the device with data processing capabilities can be a device or apparatus such as a computer. The device embodiment can be implemented through software, or through hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of any device with data processing capabilities in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory for execution. From the hardware level, if Figure 3 The figure shows a hardware structure diagram of any device with data processing capability where the smart contract vulnerability detection device based on static profit analysis of the present invention is located. Figure 3 In addition to the processor, memory, network interface, and non-volatile memory shown, any device with data processing capabilities in which the apparatus in the embodiment is located may also include other hardware, generally based on the actual functions of the device with data processing capabilities, which will not be described in detail.

[0082] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0083] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present invention. A person of ordinary skill in the art can understand and implement the present invention without inventive work.

[0084] An embodiment of the present invention also provides a computer-readable storage medium having a program stored thereon. When the program is executed by a processor, the general image target detection method based on the self-attention mechanism in the above embodiment is implemented.

[0085] The computer-readable storage medium may be an internal storage unit of any device with data processing capabilities described in any of the aforementioned embodiments, such as a hard disk or memory. The computer-readable storage medium may also be an external storage device, such as a plug-in hard disk, a smart memory card (SmartMedia card, SMC), an SD card, a flash card, etc. equipped on the device. Furthermore, the computer-readable storage medium may also include both an internal storage unit of any device with data processing capabilities and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by any device with data processing capabilities, and may also be used to temporarily store data that has been output or is to be output.

[0086] Those skilled in the art will understand that the foregoing descriptions are merely preferred embodiments of the invention and are not intended to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, those skilled in the art will still be able to modify the technical solutions described in the foregoing examples or substitute equivalents for some of the technical features therein. Any modifications, equivalent substitutions, etc. made within the spirit and principles of the invention shall be included within the scope of protection of the invention.

Claims

1. A smart contract vulnerability detection method based on static profit analysis, characterized in that: The following steps are involved: Step 1: Compile the smart contract written in Solidity into the Yul intermediate language using the solc compiler and convert it into a control flow graph; Step 2: Perform path-sensitive symbolic execution analysis on the control flow graph. During the symbolic execution analysis, path information is collected to identify the following four types of behaviors: possible profit behaviors of the caller and the corresponding beneficiaries, possible expenditure behaviors of the caller, caller permission checks, and beneficiary checks. Step 3: When the symbolic execution analysis reaches the end of each path, all collected information is combined to determine whether the path may have a vulnerability; Step 4: After analyzing all possible paths or reaching the preset program running time, organize and output the vulnerability detection results.

2. The method for detecting smart contract vulnerabilities based on static profit analysis according to claim 1, characterized in that: The possible profit-making behaviors of the caller include profit-making behaviors brought about by internal ledger modifications, profit-making behaviors brought about by external contract calls based on EIP standards including ERC20, and profit-making behaviors brought about by native tokens.

3. The method for detecting smart contract vulnerabilities based on static profit analysis according to claim 2, characterized in that: The profit-making behaviors brought about by the internal ledger modification include: destroying tokens of the address controlled by the callee, destroying tokens of the transaction pool address, and minting tokens of the address controlled by the callee; the beneficiary of the profit-making behaviors brought about by the internal ledger modification is the owner address variable of the modified internal ledger.

4. The method for detecting smart contract vulnerabilities based on static profit analysis according to claim 2, characterized in that: The profit behavior brought about by external contract calls based on EIP standards including ERC20 is the transfer behavior or authorization behavior to the address controlled by the callee. That is, the search is carried out to see whether there is a transfer or approve function, and the first parameter of the corresponding function call is the address controlled by the callee. The profit behavior brought about by external contract calls based on EIP standards including ERC20 is the first parameter variable of the function call, that is, the address variable being transferred or authorized.

5. The method for detecting smart contract vulnerabilities based on static profit analysis according to claim 1, characterized in that: The caller's possible spending behaviors include three categories: spending behaviors caused by internal ledger modifications, spending behaviors caused by external contract calls based on EIP standards including ERC20, and spending behaviors of the caller's native tokens.

6. The method for detecting smart contract vulnerabilities based on static profit analysis according to claim 5, characterized in that: The caller's spending behavior caused by internal ledger modification includes: the contract under test reducing the spending behavior of the "_allowances" storage variable authorized to the caller, and the contract under test reducing the spending behavior of any storage variable under the caller's name except "_allowances".

7. The method for detecting smart contract vulnerabilities based on static profit analysis according to claim 5, characterized in that: Caller spending behavior caused by external contract calls based on EIP standards including ERC20, including the test contract calling the transferFrom / safeTransferFrom function with the caller as the first parameter, and through the previous and next ledger checks, that is, using the balanceOf external call or address(this).balance to check the balance of tokens including ERC20 or native tokens, and compare them to determine the behavior of increasing the balance of this contract.

8. The method for detecting smart contract vulnerabilities based on static profit analysis according to claim 1, characterized in that: When the symbolic execution analysis encounters a conditional branch, the caller permission check behavior and variable check behavior are identified based on the actual branch path selection of the current symbolic execution analysis; Matching the variable checking behavior with the profit-maker information recorded in the profit-making behavior to identify the profit-maker checking behavior; The caller's permissions are checked when the conditional branch meets the following two conditions: (1) This conditional branch means that the caller compares the contract's built-in data, which includes storage type data, constant type data, and immutable type data; (2) The value selected by the conditional branch in the current execution path represents that the conditional branch restricts the caller to the contract's built-in value range; The variable is checked when the following two conditions are met in the conditional branch: (1) This conditional branch means comparing the variable with the contract's built-in data, which includes storage type data, constant type data, and immutable type data; (2) The value selected by the conditional branch in the current execution path indicates that the conditional branch restricts the variable to the contract's built-in value range.

9. The method for detecting smart contract vulnerabilities based on static profit analysis according to claim 1, characterized in that: The step three includes the following sub-steps: (3.1) Determine whether the path ends with revert. If so, it means that the path cannot be successfully executed and the path analysis ends; otherwise, continue to execute (3.2); (3.2) Is there a caller permission check in the path? If so, it is considered that there is no vulnerability and the path analysis ends. Otherwise, continue to (3.3); (3.3) Traverse and analyze each caller profit behavior collected in step 2 to determine whether it is a "token destruction behavior of the transaction pool address". If so, directly execute (3.4); otherwise, determine whether there is a profit check behavior corresponding to the profit behavior in the path. If so, exclude the profit behavior; otherwise, continue to execute (3.4); (3.4) Determine whether there is any expenditure behavior required for the profit-making behavior in the current execution path. If so, it is considered that there is no vulnerability and the profit-making behavior is excluded. Otherwise, it is considered that there is a vulnerability in the path, and the profit point brought by the vulnerability is the code corresponding to the profit-making behavior. Record the vulnerability detection results.

10. A smart contract vulnerability detection device based on static profit analysis, characterized in that: The method comprises one or more processors for implementing the smart contract vulnerability detection method based on static profit analysis as described in any one of claims 1 to 9.

Images