Smart contract vulnerability detection method and device, medium and program product

Abstract

The embodiment of the invention provides an intelligent contract vulnerability detection method and device, a medium and a program product, and relates to the technical field of network security. The intelligent contract vulnerability detection method comprises the following steps: establishing a calling sequence pool of an intelligent contract; wherein each call sequence in the call sequence pool is used for indicating to call one or more test functions in sequence, and each test function in the one or more test functions is a function of which a function variable is assigned as a fuzzy test value in the smart contract; for each calling sequence in the calling sequence pool, performing a fuzzy test on the smart contract based on the calling sequence, and monitoring a running behavior and a running state of the smart contract; and under the condition that the running behavior and / or the running state are / is monitored to be abnormal, determining that a vulnerability exists. According to the embodiment of the invention, the technical effect of accurately detecting the vulnerability of the smart contract can be realized.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and more specifically, to a smart contract vulnerability detection method, device, medium, and program product. Background Technology

[0002] With the rapid development of blockchain technology, smart contracts are widely used in various fields such as decentralized finance (DeFi), non-fungible tokens (NFTs), games, and supply chains. A smart contract is an automated program deployed on a blockchain, possessing the characteristic of "code is law." Once deployed, it cannot be altered, therefore, its security and correctness requirements are extremely high.

[0003] Current mainstream smart contract vulnerability detection technologies primarily rely on static analysis methods, such as symbolic execution, abstract syntax tree analysis, and control flow / data flow graph analysis. While these methods can detect common vulnerabilities like integer overflow and reentrancy attacks, they still have the following limitations: 1. High false alarm rate: Static analysis often relies solely on code structure matching, making it difficult to determine whether a vulnerability is actually triggerable; 2. Severe underreporting: Static analysis cannot identify vulnerabilities that depend on runtime state, such as access control logic errors and composability attacks; 3. The lack of runtime behavior feedback mechanisms makes it impossible to dynamically verify and confirm potential vulnerabilities. Summary of the Invention

[0004] The purpose of this application is to provide a smart contract vulnerability detection method, device, medium, and program product to achieve the technical effect of accurately detecting smart contract vulnerabilities.

[0005] In a first aspect, embodiments of this application provide a smart contract vulnerability detection method, including: Establish a call sequence pool for smart contracts; wherein each call sequence in the call sequence pool is used to indicate the sequential invocation of one or more test functions, and each of the one or more test functions is a function in the smart contract whose function variable is assigned a fuzzy test value; For each call sequence in the call sequence pool, the smart contract is fuzz-tested based on the call sequence, and the running behavior and running status of the smart contract are monitored. If abnormalities are detected in the operational behavior and / or operational status, a vulnerability is identified.

[0006] In the above implementation process, by establishing a call sequence pool for smart contracts, fuzz testing is performed on the smart contracts for each call sequence in the pool, and the running behavior and running status of the smart contracts are monitored. If abnormal running behavior and / or running status are detected, a vulnerability is identified. Fuzz testing of smart contracts can be performed using batch call sequences, and potential vulnerabilities can be discovered by continuously monitoring the running behavior and running status of smart contracts during dynamic operation, thereby achieving accurate detection of smart contract vulnerabilities.

[0007] Furthermore, the establishment of the smart contract call sequence pool includes: Obtain the function call graph and test dataset of the smart contract; wherein, the function call graph is used to indicate the call relationship between various functions in the smart contract, and the test dataset includes the fuzzy test values ​​corresponding to the function variables of each function in the smart contract; Based on the function call graph and the test dataset, the call sequence pool is established.

[0008] In the above implementation process, by establishing a call sequence pool for smart contracts based on the function call graph and test dataset, it is possible to ensure that the call sequence pool for smart contracts is established completely and accurately.

[0009] Furthermore, obtaining the function call graph and test dataset of the smart contract includes: Compile the source code of the smart contract to obtain the application binary interface information of the smart contract; Extract the structural information of the smart contract from the source code and the application binary interface information; Based on the structural information, construct the function call graph and the test dataset.

[0010] In the above implementation process, the application binary interface information of the smart contract is obtained by compiling the source code of the smart contract. The structural information of the smart contract is extracted from the source code and the application binary interface information. Based on the structural information, the function call graph and test dataset are constructed, which can ensure that the function call graph and test dataset of the smart contract are constructed completely and accurately.

[0011] Furthermore, after extracting the structural information of the smart contract from the source code and the application binary interface information, the method further includes: The sensitive operation information in the structure information is marked; wherein, the sensitive operation information is structure information associated with a sensitive operation, and the sensitive operation includes one or more of asset transfer, status change and access control.

[0012] In the above implementation process, after extracting the structural information of the smart contract from the source code and application binary interface information, the structural information associated with sensitive operations, that is, the sensitive operation information, is marked. This can provide guidance for the subsequent establishment of the smart contract call sequence pool and ensure that the call sequence pool covers sensitive operations.

[0013] Further, establishing the call sequence pool based on the function call graph and the test dataset includes: Based on a predefined driving strategy, the call sequence pool is constructed according to the function call graph and the test dataset; wherein, the driving strategy includes any one or more of the following: a function priority-based driving strategy, a state dependency graph-based driving strategy, an account role-based driving strategy, and a path feedback-based driving strategy.

[0014] In the above implementation process, by predefining any one or more of the following driving strategies: function priority-based driving strategy, state dependency graph-based driving strategy, account role-based driving strategy, and path feedback-based driving strategy, a call sequence pool is constructed based on the predefined driving strategy, the function call graph, and the test dataset. This enriches the diversity of call sequences, improves the execution path coverage of subsequent fuzzing, and thus ensures the effective detection of common and unknown vulnerabilities in smart contracts.

[0015] Furthermore, before performing fuzz testing on the smart contract based on the call sequence for each call sequence in the call sequence pool, and monitoring the smart contract's execution behavior and status, the method further includes: Based on the bytecode of the smart contract, deploy the smart contract in a local test environment; wherein the bytecode is obtained by compiling the source code of the smart contract.

[0016] In the above implementation process, by deploying the smart contract in the local test environment based on the smart contract's bytecode, it is possible to directly perform fuzz testing on the smart contract in the local test environment to complete vulnerability detection, which helps to improve the efficiency of smart contract vulnerability detection.

[0017] Furthermore, the deployment tool for the smart contract includes the blockchain simulator Ganache.

[0018] In the above implementation process, by using the blockchain simulator Ganache to deploy smart contracts, the bytecode of smart contracts can be quickly deployed in the local test environment, which is conducive to further improving the efficiency of smart contract vulnerability detection.

[0019] Furthermore, the fuzzing test of the smart contract based on the call sequence includes: A fuzz test is performed on the smart contract based on the call sequence to obtain preliminary test results; If the preliminary test results meet the preset security conditions, the call sequence is mutated. The smart contract is then re-fuzz-tested based on the mutated call sequence.

[0020] In the above implementation process, the smart contract is fuzzed based on the call sequence to obtain preliminary test results. If the preliminary test results meet the preset security conditions, the call sequence is mutated, and the smart contract is fuzzed again based on the mutated call sequence. This allows for a second fuzz test on the smart contract if the vulnerability cannot be detected after the initial fuzzing test, thus achieving deep detection of smart contract vulnerabilities and effectively avoiding the problem of missed detection of smart contract vulnerabilities.

[0021] Furthermore, the method also includes: Based on the vulnerability information, a vulnerability report is generated for the vulnerability.

[0022] In the above implementation process, by generating a vulnerability report based on the vulnerability information after the existence of a vulnerability is identified, users can easily conduct further analysis later.

[0023] Secondly, embodiments of this application provide a smart contract vulnerability detection device, comprising: A call sequence pool establishment module is used to establish a call sequence pool for smart contracts; wherein, each call sequence in the call sequence pool is used to indicate the sequential invocation of one or more test functions, and each of the one or more test functions is a function in the smart contract whose function variable is assigned a fuzzy test value; The fuzzing module is used to perform fuzzing tests on the smart contract based on each call sequence in the call sequence pool, and to monitor the running behavior and running status of the smart contract. The vulnerability detection module is used to determine the existence of vulnerabilities when abnormal operating behavior and / or operating status are detected.

[0024] Thirdly, embodiments of this application provide an electronic device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor; when the processor executes the computer program, it implements the method described above.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium, the computer-readable storage medium including a stored computer program; wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the method described above.

[0026] Fifthly, embodiments of this application provide a computer program product, the computer program product including instructions, which, when executed by a computer, cause the computer to perform the method described above. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 A flowchart illustrating a smart contract vulnerability detection method provided in the first embodiment of this application; Figure 2 This is a schematic diagram of the structure of a smart contract vulnerability detection device provided in the second embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in the third embodiment of this application. Detailed Implementation

[0029] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0030] It should be noted that in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance. Furthermore, the step numbers in the text are only for the convenience of explaining the embodiments of this application and are not intended to limit the order in which the steps are performed.

[0031] With the rapid development of blockchain technology, smart contracts are widely used in various fields such as decentralized finance (DeFi), non-fungible tokens (NFTs), games, and supply chains. A smart contract is an automated program deployed on a blockchain, possessing the characteristic of "code is law." Once deployed, it cannot be altered, therefore, its security and correctness requirements are extremely high.

[0032] In related technologies, smart contract vulnerability detection techniques mainly rely on static analysis methods, such as symbolic execution, abstract syntax tree analysis, and control flow / data flow graph analysis. While these methods can detect common vulnerabilities such as integer overflow and reentrancy attacks, they still have the following drawbacks: 1. High false alarm rate: Static analysis often relies solely on code structure matching, making it difficult to determine whether a vulnerability is actually triggerable; 2. Severe underreporting: Static analysis cannot identify vulnerabilities that depend on runtime state, such as access control logic errors and composability attacks; 3. The lack of runtime behavior feedback mechanisms makes it impossible to dynamically verify and confirm potential vulnerabilities.

[0033] To address this, this application proposes a smart contract vulnerability detection method. By establishing a call sequence pool for smart contracts, fuzzing is performed on the smart contract based on each call sequence in the pool, and the running behavior and running status of the smart contract are monitored. If abnormal running behavior and / or running status are detected, a vulnerability is determined. This method can use batch call sequences to perform fuzzing on smart contracts and continuously monitor the running behavior and running status of smart contracts during dynamic operation to discover potential vulnerabilities, thereby achieving accurate detection of smart contract vulnerabilities.

[0034] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0035] The methods provided in this application can be executed by relevant terminal devices, and the following description uses a server as the execution subject.

[0036] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a smart contract vulnerability detection method according to the first embodiment of this application. The smart contract vulnerability detection method includes steps S101-S103: S101. Establish a call sequence pool for the smart contract; wherein, each call sequence in the call sequence pool is used to indicate the sequential invocation of one or more test functions, and each of the one or more test functions is a function in the smart contract whose function variable is assigned a fuzzy test value.

[0037] As an example, based on actual business needs, a smart contract is selected, and a call sequence pool for the smart contract is established. Each call sequence in the call sequence pool is used to indicate the sequential invocation of one or more test functions. Each of the one or more test functions is a function in the smart contract whose function variable is assigned a fuzzy test value.

[0038] In practical applications, the program structure of a smart contract can be analyzed to determine the individual functions within the contract and the calling relationships between them. For each function's function variable, one or more fuzzy test values ​​are identified. The function variable is then assigned one of these fuzzy test values, resulting in one or more test functions for that function. Based on the calling relationships between these functions, all the obtained test functions are combined and sorted to obtain multiple calling sequences, thus establishing a calling sequence pool.

[0039] S102. For each call sequence in the call sequence pool, perform fuzz testing on the smart contract based on the call sequence, and monitor the smart contract's running behavior and running status.

[0040] As an example, after establishing a pool of call sequences for smart contracts, each call sequence is selected from the pool, and a fuzz test is performed on the smart contract based on the call sequence. During the fuzz test, the running behavior and running status of the smart contract are monitored in real time.

[0041] It's important to note that the execution behavior of a smart contract refers to the series of calculations, logical judgments, and state changes performed by the smart contract based on its current running state and according to the call sequence; it is a dynamic execution process. The running state of a smart contract refers to all the data stored on the blockchain at the moment of its execution. This data is typically stored in the smart contract's state variables and is a static snapshot of the data.

[0042] For example, the behavior and state of a smart contract include changes in the function call stack, changes in asset balance, changes in state variables, and gas usage.

[0043] S103. If abnormal operating behavior and / or operating status are detected, a vulnerability is identified.

[0044] As an example, if abnormal behavior and / or abnormal running status are detected, the smart contract is considered to be abnormal in this operation, and a vulnerability is determined to exist.

[0045] It should be noted that abnormal operation behavior and / or abnormal operation status mainly include the following situations: abnormal operation behavior; abnormal operation status; abnormal operation behavior and abnormal operation status.

[0046] In practical applications, the execution behavior of a smart contract can be matched against a number of predefined abnormal behaviors. If the smart contract's execution behavior matches any of these abnormal behaviors, its execution behavior is determined to be abnormal; otherwise, its execution behavior is determined to be normal. Similarly, the execution state of a smart contract can be matched against a number of predefined abnormal states. If the smart contract's execution state matches any of these abnormal states, its execution state is determined to be abnormal; otherwise, its execution state is determined to be normal. For example, these abnormal behaviors and states include, but are not limited to, re-entrant call stack detection, unexpected fund transfers / locking, abnormal gas consumption, and illegal modification of state variables.

[0047] In practical applications, once a vulnerability is identified, it is possible to continue recording vulnerability information such as suspicious inputs, function call paths, transaction information, and account status during the current execution of the smart contract.

[0048] This application embodiment establishes a call sequence pool for smart contracts. For each call sequence in the call sequence pool, fuzz testing is performed on the smart contract based on the call sequence, and the running behavior and running status of the smart contract are monitored. If abnormal running behavior and / or running status are detected, a vulnerability is determined. It can use batch call sequences to perform fuzz testing on smart contracts, and continuously monitor the running behavior and running status of smart contracts during dynamic operation to discover potential vulnerabilities, thereby achieving accurate detection of smart contract vulnerabilities.

[0049] In an optional embodiment, establishing a call sequence pool for a smart contract includes: obtaining a function call graph and a test dataset of the smart contract; wherein the function call graph is used to indicate the call relationships between various functions in the smart contract, and the test dataset includes fuzzy test values ​​corresponding to the function variables of various functions in the smart contract; and establishing a call sequence pool based on the function call graph and the test dataset.

[0050] As an example, based on actual business needs, a smart contract is selected, and the function call graph and test dataset of the smart contract are obtained. The function call graph is used to indicate the call relationship between various functions in the smart contract, and the test dataset includes the fuzzy test values ​​corresponding to the function variables of various functions in the smart contract.

[0051] In practical applications, for a selected smart contract, a function call graph and test dataset can be generated based on the application binary interface (ABI) information of the smart contract.

[0052] After obtaining the function call graph and test dataset of the smart contract, a call sequence pool for the smart contract is established based on the function call graph and test dataset.

[0053] In practical applications, the function call graph of a smart contract can be used to determine the individual functions within the contract and the call relationships between them. Based on the smart contract's test dataset, fuzzy test values ​​are determined for the function variables of each function. Each function variable in the smart contract corresponds to one or more fuzzy test values. For each function variable in the smart contract, one or more fuzzy test values ​​are determined, and the function variable is assigned to each of these fuzzy test values, resulting in one or more test functions for that function. Based on the call relationships between the functions, all the obtained test functions are combined and sorted to obtain multiple call sequences, thereby establishing a call sequence pool.

[0054] This application embodiment establishes a smart contract call sequence pool based on the function call graph and test dataset of the smart contract, which ensures the complete and accurate establishment of the smart contract call sequence pool.

[0055] In an optional embodiment, obtaining the function call graph and test dataset of the smart contract includes: compiling the source code of the smart contract to obtain the application binary interface information of the smart contract; extracting the structural information of the smart contract from the source code and the application binary interface information; and constructing the function call graph and test dataset based on the structural information.

[0056] As an example, a smart contract is selected based on actual business needs.

[0057] First, for the selected smart contract, obtain the source code of the smart contract, compile the source code of the smart contract, and obtain the ABI interface information of the smart contract.

[0058] In practical applications, the source code of a smart contract can be obtained by reading a file.

[0059] In practical applications, compilers such as solc, hardhat, or foundry can be used to compile the source code of smart contracts.

[0060] Next, the structural information of the smart contract is extracted from the source code and application binary interface information of the smart contract.

[0061] Understandably, the structural information of a smart contract is used to characterize the program structure of the smart contract.

[0062] In practical applications, the structural information of smart contracts includes function names, parameters, state variables, decorators, and external calling functions (such as the call function and the delegatecall function).

[0063] Finally, based on the structural information of the smart contract, a function call graph and a test dataset are constructed.

[0064] In practical applications, the calling relationships between various functions in a smart contract can be determined based on the contract's structural information, and a function call graph can be constructed based on these relationships.

[0065] In practical applications, based on the structural information of the smart contract, the function variables of each function in the smart contract can be determined. Heuristic methods can then be used to construct one or more fuzzy test values ​​corresponding to the function variables of each function in the smart contract, thereby building a test dataset. For example, using heuristic methods (setting boundary values, extreme values, zero values, and negative values, etc.), test addresses can be automatically found for address-type function variables, such as attacker account addresses, smart contract addresses, and 0x0 addresses, and these found test addresses can be used as the fuzzy test values ​​corresponding to address-type function variables. Similarly, the values ​​of uint-type function variables can be mutated to obtain new function variable values, such as 0, -1, 1, the maximum value of uint256, and the value obtained by subtracting 1 from the maximum value of uint256, and these new function variable values ​​can be used as the fuzzy test values ​​corresponding to uint-type function variables. Likewise, the values ​​of string-type function variables can be mutated to obtain new function variable values, such as empty strings, long strings, and specific encodings such as UTF-8 and UTF-16, and these new function variable values ​​can be used as the fuzzy test values ​​corresponding to string-type function variables.

[0066] This application embodiment obtains the application binary interface information of the smart contract by compiling the source code of the smart contract, extracts the structural information of the smart contract from the source code and the application binary interface information, and constructs a function call graph and test dataset based on the structural information, which can ensure the complete and accurate construction of the function call graph and test dataset of the smart contract.

[0067] In an optional embodiment, after extracting the structure information of the smart contract from the source code and application binary interface information, the method further includes: marking sensitive operation information in the structure information; wherein, the sensitive operation information is structure information associated with sensitive operations, and the sensitive operations include one or more of asset transfer, state change and access control.

[0068] As an example, after extracting the structural information of the smart contract from the source code and application binary interface information of the smart contract, the system continues to identify and mark the structural information associated with sensitive operations from the extracted structural information, namely sensitive operation information. The sensitive operations include one or more of asset transfer, state change and access control.

[0069] By marking sensitive operation information in the structure of smart contracts, guidance can be provided for the subsequent creation of a pool of call sequences for smart contracts.

[0070] This application embodiment extracts the structural information of the smart contract from the source code and application binary interface information, and marks the structural information associated with sensitive operations, i.e., sensitive operation information, to provide guidance for the subsequent establishment of the smart contract call sequence pool and ensure that the call sequence pool covers sensitive operations.

[0071] In an optional embodiment, the step of establishing a call sequence pool based on the function call graph and the test dataset includes: constructing a call sequence pool based on a predefined driving strategy, according to the function call graph and the test dataset; wherein the driving strategy includes any one or more of the following: a function priority-based driving strategy, a state dependency graph-based driving strategy, an account role-based driving strategy, and a path feedback-based driving strategy.

[0072] As an example, one or more of the following are predefined: function priority-based driving strategy, state dependency graph-based driving strategy, account role-based driving strategy, and path feedback-based driving strategy.

[0073] It should be noted that the function priority-based driving strategy is a strategy that combines and sorts all the test functions based on the priority of each function in the smart contract and the calling relationship between the functions.

[0074] In practical applications, for each function in a smart contract, a weight or level can be set according to the function's characteristics. For example, state modification functions involving state changes such as transfers, deposits, withdrawals, and updates have a higher weight, event triggering functions, and relay call functions such as call and delegatecall functions have a higher level, and pure view functions have a lower weight. The priority of a function is determined according to its weight or level, and functions with higher priority are called first.

[0075] The state dependency graph-based driving strategy is a strategy that combines and sorts all the test functions based on the state dependency graphs of each function in the smart contract and the calling relationships between the functions.

[0076] In practical applications, for each function in a smart contract, a state dependency graph can be constructed based on the dependency relationship between the function and the target function associated with it. For example, if function A writes variable x and function B reads variable x, then function A should be called first and then function B should be called. This ensures that the call sequence can enter a valid state, avoids meaningless reverts, and improves the effectiveness of testing.

[0077] The account role-based driving strategy is a strategy that combines and sorts all the test functions based on the account roles that call the functions in the smart contract and the calling relationships between the functions.

[0078] In practical applications, multiple account roles can be constructed, such as owner, attacker, user, and random. Based on the calling relationships between various functions, the execution paths of various account roles can be simulated to perform behaviors such as permission bypass, reentrancy attack, and flash loan attack, thereby generating multiple call sequences.

[0079] The path feedback-based driving strategy is to use path feedback tools, such as EVM trace, to monitor the executed and unexecuted paths of smart contracts, and then combine and sort all the test functions based on the unexecuted paths of the smart contract and the call relationships between the functions.

[0080] In practical applications, the input parameters of the target function on the unexecuted path of the smart contract can be adjusted first based on the unexecuted path of the smart contract. Then, multiple call sequences can be generated based on the call relationship between the functions to improve path coverage and reduce problems such as false positives and false negatives.

[0081] After obtaining the function call graph and test dataset of the smart contract, a call sequence pool is constructed based on the predefined driving strategy and the function call graph and test dataset.

[0082] This application embodiment predefines one or more of the following driving strategies: function priority-based driving strategy, state dependency graph-based driving strategy, account role-based driving strategy, and path feedback-based driving strategy. Based on the predefined driving strategy, a call sequence pool is constructed according to the function call graph and test dataset. This enriches the diversity of call sequences, improves the execution path coverage of subsequent fuzzing, and thus ensures effective detection of common and unknown vulnerabilities in smart contracts.

[0083] In an optional embodiment, before performing fuzz testing on the smart contract based on the call sequence for each call sequence in the call sequence pool and monitoring the smart contract's running behavior and running status, the method further includes: deploying the smart contract in a local test environment based on the smart contract's bytecode; wherein the bytecode is obtained by compiling the smart contract's source code.

[0084] As an example, the bytecode of the smart contract is obtained by compiling the source code of the smart contract. Based on the bytecode, the smart contract is deployed in a local test environment.

[0085] By deploying smart contracts in a local testing environment based on their bytecode, vulnerability detection can be performed directly on the smart contract in the local testing environment without connecting to a real test network or mainnet.

[0086] This application embodiment deploys the smart contract in a local testing environment based on the smart contract's bytecode, enabling fuzz testing of the smart contract directly in the local testing environment to complete vulnerability detection, which helps improve the efficiency of smart contract vulnerability detection.

[0087] In an optional embodiment, the deployment tool for smart contracts includes the blockchain simulator Ganache.

[0088] As an example, the blockchain simulator Ganache provides a local Ethereum blockchain environment, allowing users to operate without connecting to a real test network or mainnet. Upon startup, Ganache provides 10 virtual accounts simulating different users, such as deployers, attackers, and victims, and simultaneously starts a JSON-RPC service. The access link is [link missing]. http: / / 127.0.0.1: 8545。 Each of the 10 virtual accounts has 100 ETH by default, facilitating rapid deployment and testing of smart contracts. JSON-RPC (JSON Remote Procedure Call) is a data exchange protocol based on JSON format, used for remote calls between clients and servers.

[0089] After obtaining the bytecode of the smart contract, the blockchain simulator Ganache is used to deploy the smart contract in a local test environment based on the bytecode.

[0090] This application embodiment uses the blockchain simulator Ganache to deploy smart contracts, which enables the rapid deployment of smart contract bytecode in a local testing environment, thus improving the efficiency of smart contract vulnerability detection.

[0091] In an optional embodiment, the step of performing fuzz testing on the smart contract based on the call sequence includes: performing fuzz testing on the smart contract based on the call sequence to obtain preliminary test results; if the preliminary test results meet preset security conditions, performing mutation processing on the call sequence; and performing fuzz testing on the smart contract again based on the mutated call sequence.

[0092] As an example, for each call sequence in the call sequence pool, a fuzz test is performed on the smart contract based on the call sequence to obtain preliminary test results, and it is determined whether the preliminary test results meet the preset security conditions.

[0093] In practical applications, each call sequence in the call sequence pool can be traversed in descending order of function priority. Transaction requests can be sent to the smart contract via the JSON-RPC protocol, and preliminary test results returned by the smart contract can be received.

[0094] In practical applications, security conditions can be set based on the normal behavior and state of smart contracts when there are no vulnerabilities or anomalies, to obtain preset security conditions, such as normal transaction execution state, state variables meeting expectations (e.g., after the transfer function is executed, the transferor's balance decreases, the receiver's balance increases, and the total amount remains unchanged), function return values ​​meeting expectations (e.g., after the getBalance(address) is called, the return value is consistent with the account's actual holdings, such as add(1,2) returning 3), and access control meeting expectations (e.g., when a non-administrator calls an administrator function, although a revert is triggered, because the smart contract is designed to make this behavior legal, this rollback is an expected rollback and also belongs to the expected result).

[0095] If the initial test results meet the preset security conditions, the fuzz test values ​​in the call sequence are mutated to obtain a mutated call sequence, and the smart contract is fuzz tested again based on the mutated call sequence. If the initial test results do not meet the preset security conditions, the use of the call sequence is terminated.

[0096] In practical applications, dynamic feedback information, such as execution path coverage and abnormal paths, can be used to mutate the fuzz test values ​​in the call sequence, resulting in a mutated call sequence. For example, given the original call sequence data as shown below, if the smart contract returns a preliminary test result that meets the preset security conditions, then the second fuzz test can use "-1" instead of "1": { "contract": "TEST", "function": "approve", "priority": 1.0, "args": ["0x...", "1"] / / UINT8_MAX }".

[0097] Once the call sequence pool has been traversed, the fuzzing test on the smart contract ends.

[0098] This application embodiment performs fuzz testing on smart contracts based on call sequences to obtain preliminary test results. If the preliminary test results meet preset security conditions, the call sequences are mutated, and the smart contracts are fuzz tested again based on the mutated call sequences. This allows for a second fuzz test on the smart contracts even if the initial fuzz test fails to detect vulnerabilities, thus achieving deep detection of smart contract vulnerabilities and effectively avoiding the problem of missed detection of smart contract vulnerabilities.

[0099] In an optional embodiment, the method further includes step S104: S104. Generate a vulnerability report based on the vulnerability information.

[0100] As an example, after a vulnerability is identified, the vulnerability information can be recorded and analyzed to determine the vulnerability type, transaction sequence, and trigger path, and a detailed report containing this information can be generated to obtain a vulnerability report.

[0101] This application embodiment, by generating a vulnerability report based on the vulnerability information after a vulnerability is identified, facilitates further analysis by the user.

[0102] To more clearly illustrate the smart contract vulnerability detection method provided in the first embodiment of this application, taking a reentrancy vulnerability as an example, the specific process of applying the smart contract vulnerability detection method will be described.

[0103] The VulnerableBank contract is a bank account model that simulates deposit, withdrawal, transfer, and retrieval operations. The source code of the contract is shown below: pragma solidity ^ 0.8 .0; contract VulnerableBank { mapping(address =>uint256) public balances; function deposit() public payable { balances[msg.sender] += msg.value; } function withdraw(uint256 amount) public { require(balances[msg.sender]>= amount, "Insufficient"); (bool ok, ) = msg.sender.call { value: amount }(""); require(ok, "Transfer failed"); balances[msg.sender] -= amount; } function transfer(address to, uint256 amount) public { require(to != address(0), "invalid recipient"); require(balances[msg.sender]>= amount, "Insufficient balance"); balances[msg.sender] -= amount; balances[to] += amount; } function get (address user) public view returns(uint256) { return balances[user]; } receive() external payable {} }".

[0104] 1. Compile the source code of the contract using the command-line tool solc to obtain the bytecode and ABI interface information of the contract.

[0105] 2. Parse and extract the contract's structural information from the source code and ABI interface information, including: 1. Function names: deposit(), withdraw(uint256), transfer(address, uint256), get(), and receive(); 2. Parameters: amount uint256, address to, and address user; 3. State variable: balances; 4. External function call: msg.sender.call{value: amount}("").

[0106] 3. Construct the function call graph of the contract based on its structural information, and mark the call function within the withdraw function. The function call graph is shown below: "deposit() → withdraw()" withdraw() → deposit() … …”

[0107] 4. Based on the structural information of the contract, construct a fuzzing test dataset. For the uint256 amount parameter, construct fuzzing test values ​​such as 0, 1 wei, balance, balance + 1, UINT256_MAX, etc.; for the address to parameter, construct fuzzing test values ​​such as empty address, long address (0x...), empty address, etc.

[0108] 5. Use the Ganache-cli tool to deploy the bytecode of the contract in a local test environment.

[0109] 6. Based on a function priority-driven strategy, it was determined that in this contract, the `attack` function is a reentrancy vulnerability testing function, and it indirectly calls the `call` function (i.e., the previously marked function) through the `withdraw` function, thus having the highest priority of 1.0; followed by the `deposit`, `withdraw`, and `transfer` functions, with relatively high priorities of 0.6; and finally, the `get` function, with the lowest priority of 0.2. A call sequence pool was established based on the function call graph and the test dataset. { "id":"seed-1", "sequence":[ {"contract":"VulnerableBank","function":"deposit","args":[],"value":"1","caller":"0xUser"}, {"contract":"VulnerableBank","function":"withdraw","args":["1"],"value":"0","caller":"0xUser"} ], "tags":["medium-risk"], "priority":0.6 } { "id":"seed-2", "sequence":[ {"contract":"VulnerableBank","function":"withdraw","args":["1"],"value":"0","caller":"0xUser"} {"contract":"VulnerableBank","function":"deposit","args":[],"value":"1","caller":"0xUser"}, ], "tags":["medium-risk"], "priority":0.6 } { "id":"seed-3", "sequence":[ {"contract":"VulnerableBank","function":"get","args":[],"value":"0","caller":"0xUser"} ], "tags":["common"], "priority":0.2 } { "id":"attack-1", "sequence":[ {"contract":"Attacker","function":"attack","args":[],"value":"1","caller":"0xAttacker"} ], "tags":["reentrancy","high-risk"], "priority": 1.0 } … …”

[0110] The Attack contract is a reentrancy vulnerability testing contract, and its code is as follows: `pragma solidity ^0.8.0;` interface IVuln { function deposit() external payable; functionwithdraw(uint256) external;} contract Attacker { IVuln public vuln; address owner; constructor(address _v) { vuln = IVuln(_v); owner = msg.sender;} function attack() external payable { require(msg.value>= 1e18); vuln.deposit{value: msg.value}(); vuln.withdraw(msg.value); } receive() external payable { if (address(vuln).balance>= 1e18) { vuln.withdraw(1e18); / / reenter } else { payable(owner).transfer(address(this).balance); } } }".

[0111] 7. Select call sequences from the call sequence pool according to function priority for fuzz testing. Send transactions to the contract via JSON-RPC protocol, analyze the preliminary test results returned by the contract. If the preliminary test results meet expectations, optimize the fuzz test values ​​in the current call sequence and re-fuzz test based on the mutated call sequence. { "id":"seed-1", "sequence":[ {"contract":"VulnerableBank","function":"deposit","args":[],"value":"1","caller":"0xUser"}, {"contract":"VulnerableBank","function":"withdraw","args":["-1"],"value":"0","caller":"0xUser"} ], "tags":["common"], "priority": 0.2 }".

[0112] The fuzz test ends when all call sequences in the call sequence pool have been traversed.

[0113] 8. Monitor the running behavior and status of smart contracts in real time, detect changes in the balance state variable, track whether there are callback calls (reentrant) from msg.sender, and whether changes in balances[attacker] are reduced multiple times in a single transaction, resulting in repeated withdrawals of the balance.

[0114] 9. If, during a single withdraw call, the fallback function of msg.sender initiates another withdraw (i.e., a repeated entry of withdraw occurs within the same external call stack), it is considered a re-entry; or if balances[attacker] is observed to be reduced to below expectations multiple times in multiple transactions (the balance decreases multiple times but update only occurs once), re-entry is suspected.

[0115] 10. Record abnormal results and output vulnerability reports.

[0116] Please refer to Figure 2 , Figure 2This is a schematic diagram of a smart contract vulnerability detection device provided in the second embodiment of this application. The second embodiment of this application provides a smart contract vulnerability detection device, including: a call sequence pool establishment module 201, used to establish a call sequence pool for smart contracts; wherein each call sequence in the call sequence pool is used to indicate the sequential invocation of one or more test functions, and each of the one or more test functions is a function in the smart contract whose function variable is assigned a fuzz test value; a fuzz testing module 202, used to perform fuzz testing on the smart contract based on each call sequence in the call sequence pool, and monitor the running behavior and running state of the smart contract; and a vulnerability detection module 203, used to determine the existence of a vulnerability when abnormal running behavior and / or running state are detected.

[0117] In an optional embodiment, establishing a call sequence pool for a smart contract includes: obtaining a function call graph and a test dataset of the smart contract; wherein the function call graph is used to indicate the call relationships between various functions in the smart contract, and the test dataset includes fuzzy test values ​​corresponding to the function variables of various functions in the smart contract; and establishing a call sequence pool based on the function call graph and the test dataset.

[0118] In an optional embodiment, obtaining the function call graph and test dataset of the smart contract includes: compiling the source code of the smart contract to obtain the application binary interface information of the smart contract; extracting the structural information of the smart contract from the source code and the application binary interface information; and constructing the function call graph and test dataset based on the structural information.

[0119] In an optional embodiment, the sequence pool establishment module 201 is further configured to mark sensitive operation information in the structure information after extracting the structure information of the smart contract from the source code and application binary interface information; wherein, the sensitive operation information is structure information associated with a sensitive operation, and the sensitive operation includes one or more of asset transfer, state change and access control.

[0120] In an optional embodiment, the step of establishing a call sequence pool based on the function call graph and the test dataset includes: constructing a call sequence pool based on a predefined driving strategy, according to the function call graph and the test dataset; wherein the driving strategy includes any one or more of the following: a function priority-based driving strategy, a state dependency graph-based driving strategy, an account role-based driving strategy, and a path feedback-based driving strategy.

[0121] In an optional embodiment, the fuzzing module 202 is further configured to deploy the smart contract in a local test environment based on the bytecode of the smart contract before performing fuzz testing on the smart contract based on the call sequence for each call sequence in the call sequence pool and monitoring the running behavior and running status of the smart contract; wherein the bytecode is obtained by compiling the source code of the smart contract.

[0122] In an optional embodiment, the deployment tool for smart contracts includes the blockchain simulator Ganache.

[0123] In an optional embodiment, the step of performing fuzz testing on the smart contract based on the call sequence includes: performing fuzz testing on the smart contract based on the call sequence to obtain preliminary test results; if the preliminary test results meet preset security conditions, performing mutation processing on the call sequence; and performing fuzz testing on the smart contract again based on the mutated call sequence.

[0124] In an optional embodiment, the vulnerability detection module 203 is also used to generate a vulnerability report based on the vulnerability information of the vulnerability.

[0125] The specific implementation process of the functions and roles of each module in the above-mentioned device can be found in the implementation process of the corresponding steps in the method described in the first embodiment of this application, and will not be repeated here.

[0126] Please refer to Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in the third embodiment of this application. The third embodiment of this application provides an electronic device 30, including a processor 301, a memory 302, and a computer program stored in the memory 302 and configured to be executed by the processor 301; when the processor 301 executes the computer program, it implements the method described in the first embodiment of this application and can achieve the same beneficial effects.

[0127] When the processor 301 reads a computer program from the memory 302 via the bus 303 and executes the computer program, it can implement any of the methods described in the first embodiment of this application.

[0128] Processor 301 can process digital signals and may include various computing architectures. For example, it may be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 301 may be a microprocessor.

[0129] The memory 302 can be used to store instructions executed by the processor 301 or data related to the execution of instructions. These instructions and / or data may include code for implementing some or all of the functions of one or more modules described in the embodiments of this application. The processor 301 of this disclosure embodiment can be used to execute instructions in the memory 302 to implement the method described in the first embodiment of this application. The memory 302 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memories well known to those skilled in the art.

[0130] The fourth embodiment of this application provides a computer-readable storage medium, which includes a stored computer program; wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to perform the method described in the first embodiment of this application, and can achieve the same beneficial effects.

[0131] The method described in the first embodiment of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the various embodiments of this application are executed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, a core network device, an OAM (Open Application Model), or other programmable devices.

[0132] The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions may be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium may be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; or an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0133] The fifth embodiment of this application provides a computer program product, which includes instructions that, when executed by a computer, cause the computer to perform the method described in the first embodiment of this application and achieve the same beneficial effects.

[0134] The methods described in the first embodiment of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, in the form of a computer program product. A computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the various embodiments of this application are performed, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, a core network device, an OAM (Open Application Model), or other programmable devices.

[0135] Computer programs or instructions can be stored in or transferred from one computer-readable storage medium to another. For example, a computer program or instructions can be transferred from one website, computer, server, or data center to another via wired or wireless means. A computer-readable storage medium can be any usable medium that a computer can access, or a data storage device such as a server or data center that integrates one or more usable media. Usable media can be magnetic media, such as floppy disks, hard disks, and magnetic tapes; optical media, such as digital video discs; or semiconductor media, such as solid-state drives. The computer-readable storage medium can be volatile or non-volatile, or may include both types.

[0136] In summary, this application provides a smart contract vulnerability detection method, device, medium, and program product. The smart contract vulnerability detection method includes: establishing a call sequence pool for smart contracts; wherein each call sequence in the call sequence pool is used to indicate the sequential invocation of one or more test functions, and each of the one or more test functions is a function in the smart contract whose function variable is assigned a fuzz test value; for each call sequence in the call sequence pool, performing fuzz testing on the smart contract based on the call sequence, and monitoring the running behavior and running state of the smart contract; and determining the existence of a vulnerability when abnormal running behavior and / or running state are detected. This application, by establishing a call sequence pool for smart contracts, performing fuzz testing on the smart contract based on each call sequence in the call sequence pool, and monitoring the running behavior and running state of the smart contract, determines the existence of a vulnerability when abnormal running behavior and / or running state are detected. It can use batch call sequences to perform fuzz testing on smart contracts, and continuously monitor the running behavior and running state of the smart contract during dynamic operation to discover potential vulnerabilities, thereby achieving accurate detection of smart contract vulnerabilities.

[0137] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0138] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0139] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0140] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for detecting smart contract vulnerabilities, characterized in that, include: Establish a call sequence pool for smart contracts; wherein each call sequence in the call sequence pool is used to indicate the sequential invocation of one or more test functions, and each of the one or more test functions is a function in the smart contract whose function variable is assigned a fuzzy test value; For each call sequence in the call sequence pool, the smart contract is fuzz-tested based on the call sequence, and the running behavior and running status of the smart contract are monitored. If abnormalities are detected in the operational behavior and / or operational status, a vulnerability is identified.

2. The method according to claim 1, characterized in that, The pool of call sequences for establishing smart contracts includes: Obtain the function call graph and test dataset of the smart contract; wherein, the function call graph is used to indicate the call relationship between various functions in the smart contract, and the test dataset includes the fuzzy test values ​​corresponding to the function variables of each function in the smart contract; Based on the function call graph and the test dataset, the call sequence pool is established.

3. The method according to claim 2, characterized in that, The process of obtaining the function call graph and test dataset of the smart contract includes: Compile the source code of the smart contract to obtain the application binary interface information of the smart contract; Extract the structural information of the smart contract from the source code and the application binary interface information; Based on the structural information, construct the function call graph and the test dataset.

4. The method according to claim 3, characterized in that, After extracting the structural information of the smart contract from the source code and the application binary interface information, the method further includes: The sensitive operation information in the structure information is marked; wherein, the sensitive operation information is structure information associated with a sensitive operation, and the sensitive operation includes one or more of asset transfer, status change and access control.

5. The method according to claim 2, characterized in that, The step of establishing the call sequence pool based on the function call graph and the test dataset includes: Based on a predefined driving strategy, the call sequence pool is constructed according to the function call graph and the test dataset; wherein, the driving strategy includes any one or more of the following: a function priority-based driving strategy, a state dependency graph-based driving strategy, an account role-based driving strategy, and a path feedback-based driving strategy.

6. The method according to claim 1, characterized in that, Before performing fuzz testing on the smart contract based on the call sequence for each call sequence in the call sequence pool, and monitoring the smart contract's execution behavior and status, the method further includes: Based on the bytecode of the smart contract, deploy the smart contract in a local test environment; wherein the bytecode is obtained by compiling the source code of the smart contract.

7. The method according to claim 6, characterized in that, The deployment tools for the smart contracts include the blockchain simulator Ganache.

8. The method according to claim 1, characterized in that, The fuzzing test of the smart contract based on the call sequence includes: A fuzz test is performed on the smart contract based on the call sequence to obtain preliminary test results; If the preliminary test results meet the preset security conditions, the call sequence is mutated. The smart contract is then re-fuzz-tested based on the mutated call sequence.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: Based on the vulnerability information, a vulnerability report is generated for the vulnerability.

10. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor; when the processor executes the computer program, it implements the method according to any one of claims 1 to 9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program; wherein, when the computer program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 9.

12. A computer program product, characterized in that, The computer program product includes instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 9.

Images