A smart contract vulnerability detection method and device

Abstract

The present invention discloses a vulnerability detection method and device for smart contracts. The method comprises: collecting historical call functions, blockchain states and corresponding associated addresses in historical transactions of smart contracts on a blockchain by responding to vulnerability detection requests; performing fuzzy testing according to the associated addresses to obtain multiple callable functions, sequentially associating the historical call functions and each callable function, and constructing multiple update transaction sequences; mutating the update transaction sequences respectively to generate mutated transaction sequences; executing the update transaction sequence and the mutated transaction sequence respectively under the same blockchain state, and judging whether a vulnerability occurs in the smart contract according to whether the blockchain states after execution are the same, thereby effectively improving the high false positive rate or high false negative rate of vulnerability detection and improving the security of vulnerability detection of smart contracts.

Description

Technical Field

[0001] The present invention relates to the field of vulnerability detection technology, and in particular to a method and device for detecting vulnerabilities in smart contracts. Background Art

[0002] As blockchain technology matures, the blockchain platform Ethereum first introduced smart contracts as a Turing-complete program that can automate blockchain transactions to achieve complex functions. With the development of blockchain technology, the application of smart contracts is becoming more and more extensive.

[0003] Smart contracts are compiled and deployed on the blockchain and cannot be modified after deployment. If there are vulnerabilities in the smart contract, the contract will be in a state of permanent attack, causing serious security issues.

[0004] To this end, existing technologies usually perform vulnerability detection on smart contracts through static analysis or fuzz testing. However, since vulnerability detection technology based on static analysis cannot accurately restore the program state information of the contract at runtime, existing methods usually try to consider all possible situations. This method usually introduces unreachable program paths, resulting in a high false positive rate. Existing fuzz testing methods rely on expert knowledge to summarize known attack patterns when detecting vulnerabilities, which may result in a high number of missed reports and fail to detect new attack patterns, resulting in reduced security of vulnerability detection in smart contracts. Summary of the invention

[0005] The present invention provides a method and device for vulnerability detection of smart contracts, which solves the technical problem that static analysis and fuzzy testing methods in the prior art easily lead to high false positive rate or high missed negative rate of vulnerability detection, resulting in reduced security of vulnerability detection of smart contracts.

[0006] The present invention provides a smart contract vulnerability detection method, comprising:

[0007] Respond to vulnerability detection requests, collect the blockchain status, historical call functions and corresponding associated addresses of smart contracts on the blockchain;

[0008] Perform fuzz testing according to the associated address to obtain multiple callable functions, and associate the historical call functions to construct multiple update transaction sequences;

[0009] mutating the update transaction sequence to generate a mutated transaction sequence;

[0010] The update transaction sequence and the mutated transaction sequence are respectively executed under the blockchain state, and whether a vulnerability occurs in the smart contract is determined according to the blockchain state after execution.

[0011] Optionally, the step of responding to the vulnerability detection request and collecting the blockchain status, historical call functions and corresponding associated addresses of the smart contract on the blockchain includes:

[0012] Respond to vulnerability detection requests, collect historical transactions of smart contracts on the blockchain and replay them to obtain blockchain status and historical call functions;

[0013] Traversing the specific bytecodes in the historical call function, and extracting address information associated with the specific bytecodes as associated addresses;

[0014] The blockchain state includes a pre-transaction state and a post-transaction state.

[0015] Optionally, the associated address includes an external account address and a contract address; the step of performing fuzz testing according to the associated address to obtain multiple callable functions, associating the historical call functions, and constructing multiple update transaction sequences includes:

[0016] Extract the corresponding target smart contract according to the contract address;

[0017] Perform fuzz testing on the target smart contract according to the parameter variables corresponding to the historical call function and the external account address to determine multiple initial functions;

[0018] Deleting a specific type of function from the multiple initial functions to obtain multiple callable functions;

[0019] The historical calling functions and the callable functions are respectively associated, and a plurality of update transaction sequences are constructed in combination with the blockchain state.

[0020] Optionally, the step of performing fuzz testing on the target smart contract according to the parameter variables corresponding to the historical call function and the external account address to determine multiple initial functions includes:

[0021] Parse the target smart contract to determine the required parameter type;

[0022] Query the parameter value with the same type as the required parameter and the latest timestamp from the parameter variable corresponding to the historical call function;

[0023] The external account address is used as the initiator of the target smart contract, and fuzz testing is performed in combination with the parameter value to determine multiple initial functions.

[0024] Optionally, the method further comprises:

[0025] If there is no parameter value of the same type as the required parameter in the parameter variable corresponding to the historical call function, a preset random number generator is used to generate a new parameter value of the same type as the required parameter.

[0026] Optionally, the step of mutating the update transaction sequence to generate a mutated transaction sequence includes:

[0027] Exchanging the execution order of the historical calling function and the callable function in the update transaction sequence to generate a first variant transaction sequence;

[0028] The callable function in the update transaction sequence is inserted into the corresponding historical call function to generate a second variant transaction sequence.

[0029] Optionally, the step of inserting the callable function in the update transaction sequence into the corresponding historical call function to generate a second variant transaction sequence includes:

[0030] Traversing the bytecodes in the historical calling function, and matching the corresponding internal calling function according to the bytecodes;

[0031] The callable function in the update transaction sequence is inserted into the internal call function to generate a second variant transaction sequence.

[0032] Optionally, the step of respectively executing the update transaction sequence and the mutated transaction sequence under the blockchain state, and judging whether the smart contract has a vulnerability according to the blockchain state after execution includes:

[0033] Execute the update transaction sequence and the mutated transaction sequence respectively in the blockchain state to generate two sets of post-execution blockchain states;

[0034] If the two groups of blockchain states after execution are the same, it is determined that there is no vulnerability in the smart contract;

[0035] If the two groups of blockchain states after execution are different, it is determined that a vulnerability exists in the smart contract.

[0036] Optionally, the method further comprises:

[0037] Adjusting the block timestamp and / or block difficulty in the original block information of the blockchain according to a preset gradient to obtain updated block information;

[0038] Executing the historical call function under the original block information and the updated block information respectively to generate two sets of modified blockchain states;

[0039] If the two groups of modified blockchain states are the same, it is determined that there is no vulnerability in the smart contract;

[0040] If the two sets of modified blockchain states are different, it is determined that a vulnerability exists in the smart contract.

[0041] The present invention also provides a smart contract vulnerability detection device, comprising:

[0042] The historical information collection module is used to respond to vulnerability detection requests and collect the blockchain status, historical call functions and corresponding associated addresses of smart contracts on the blockchain;

[0043] A transaction sequence generation module, used to perform fuzz testing according to the associated address, obtain multiple callable functions, and associate the historical call functions to construct multiple update transaction sequences;

[0044] A sequence mutation module, used to mutate the update transaction sequence to generate a mutated transaction sequence;

[0045] The vulnerability detection module is used to respectively execute the update transaction sequence and the mutated transaction sequence under the blockchain state, and determine whether the smart contract has a vulnerability according to the blockchain state after execution.

[0046] It can be seen from the above technical solutions that the present invention has the following advantages:

[0047] The present invention collects historical call functions, blockchain states and corresponding associated addresses in historical transactions of smart contracts on the blockchain by responding to vulnerability detection requests; performs fuzzy testing according to the associated addresses to obtain multiple callable functions, sequentially associates the historical call functions and each callable function, and constructs multiple update transaction sequences; mutates the update transaction sequences respectively to generate mutated transaction sequences; executes the update transaction sequence and the mutated transaction sequence respectively under the same blockchain state, and determines whether a vulnerability occurs in the smart contract according to whether the blockchain states after execution are the same, thereby effectively improving the high false positive rate or high false negative rate of vulnerability detection and improving the security of vulnerability detection of smart contracts. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0049] Figure 1 A flowchart of a method for detecting a vulnerability in a smart contract provided in the first embodiment of the present invention;

[0050] Figure 2A flowchart of a method for detecting a vulnerability in a smart contract provided in Embodiment 2 of the present invention;

[0051] Figure 3 The following is a flowchart showing an execution flow of a vulnerability detection method for a smart contract in an embodiment of the present invention;

[0052] Figure 4 This is a structural block diagram of a smart contract vulnerability detection device provided in Example 3 of the present invention. DETAILED DESCRIPTION

[0053] The embodiments of the present invention provide a method and device for vulnerability detection of smart contracts, which are used to solve the technical problem that the static analysis and fuzzy testing methods in the prior art easily lead to a high false positive rate or a high missed negative rate in vulnerability detection, resulting in reduced security of vulnerability detection of smart contracts.

[0054] In order to make the purpose, features and advantages of the present invention more obvious and easy to understand, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described below are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0055] See also Figure 1 , Figure 1 A flowchart of the steps of a smart contract vulnerability detection method provided in Example 1 of the present invention.

[0056] The present invention provides a method for detecting a vulnerability in a smart contract, comprising the following steps:

[0057] Step 101, responding to the vulnerability detection request, collecting the blockchain status, historical call functions and corresponding associated addresses of the smart contract on the blockchain;

[0058] Smart contracts are contracts in the form of computer programs that can automatically execute and perform specific tasks. They are based on blockchain technology and record and verify the execution of contract terms in a transparent, secure and tamper-proof manner. Smart contracts usually consist of multiple code modules that can define contract terms, execution conditions and the blockchain state after execution.

[0059] Blockchain is a decentralized distributed database technology that uses cryptography and consensus algorithms to ensure data synchronization and consistency among all participants on the network. In a blockchain, all data is divided into small pieces (called "blocks"), each of which contains a record of one or more transactions and some metadata, such as a timestamp and the hash value of the previous block.

[0060] In an embodiment of the present invention, by responding to a vulnerability test request, the smart contract to be tested is located, the historical transactions of the smart contract on the blockchain and the historical call functions called by it are collected, and the historical call functions are re-executed to obtain the blockchain status before and after the execution.

[0061] At the same time, the associated addresses involved in the execution of the historical transaction function are collected.

[0062] It should be noted that blockchain status information can be represented by triples, for example <addr,<key,value> >, where addr refers to the on-chain address corresponding to the state.<key,value> It is a key-value pair, where key is the key and value is the value, which is also a state variable. Each on-chain address has many state variables. The associated address can include but is not limited to external account addresses and addresses of other smart contracts (i.e. contract addresses). The external account address is a wallet account controlled by the user, while the contract address is an independent smart contract deployed on the Ethereum network.

[0063] Step 102, perform fuzz testing according to the associated address, obtain multiple callable functions, associate historical call functions, and construct multiple update transaction sequences;

[0064] After obtaining the associated address, the corresponding target smart contract can be matched according to the associated address, based on performing fuzz testing on the target smart contract, or extracting multiple callable functions based on its ABI information, and associating the historical transaction function with each callable function in the order of execution to form multiple update transaction sequences.

[0065] Among them, the associated address can be a contract address. The contract address is associated with the target smart contract. Fuzz testing on it can obtain multiple external transaction calls, thereby extracting multiple callable functions to construct multiple update transaction sequences.

[0066] Step 103, mutating the update transaction sequence to generate a mutated transaction sequence;

[0067] In this embodiment, after a plurality of update transaction sequences are obtained, each update transaction sequence may be mutated respectively to generate a mutated transaction sequence according to different mutation strategies.

[0068] It should be noted that mutation strategies may include but are not limited to transaction reordering, transaction insertion, and block information update.

[0069] Step 104, respectively execute the update transaction sequence and the mutated transaction sequence in the blockchain state, and determine whether there is a vulnerability in the smart contract according to the blockchain state after execution.

[0070] In an embodiment, each update transaction sequence and the corresponding variant transaction sequence can be executed separately under the same blockchain state to determine whether the post-execution blockchain states obtained after executing the update transaction sequence and the variant transaction sequence are different. If they are different, it is determined that a vulnerability exists in the smart contract; if they are the same, it is determined that no vulnerability exists in the smart contract.

[0071] In an embodiment of the present invention, in response to a vulnerability detection request, historical call functions, blockchain states, and corresponding associated addresses in historical transactions of a smart contract on a blockchain are collected; fuzz testing is performed according to the associated addresses to obtain a plurality of callable functions, and the historical call functions and each callable function are associated in sequence to construct a plurality of update transaction sequences; the update transaction sequences are mutated to generate mutated transaction sequences; the update transaction sequence and the mutated transaction sequence are respectively executed under the same blockchain state, and whether a vulnerability occurs in the smart contract is determined based on whether the blockchain states after execution are the same, thereby effectively improving the high false alarm rate or high missed alarm rate of vulnerability detection and improving the security of vulnerability detection of smart contracts.

[0072] See also Figure 2 , Figure 2 A flowchart of the steps of a smart contract vulnerability detection method provided in Example 2 of the present invention.

[0073] The present invention provides a method for detecting a vulnerability in a smart contract, comprising the following steps:

[0074] Step 201, responding to the vulnerability detection request, collecting the blockchain status, historical call functions and corresponding associated addresses of the smart contract on the blockchain;

[0075] Optionally, step 201 may include the following sub-steps:

[0076] Respond to vulnerability detection requests, collect historical transactions of smart contracts on the blockchain and replay them to obtain blockchain status and historical call functions;

[0077] Traverse the specific bytecodes in the historical calling function and extract the address information associated with the specific bytecode as the associated address.

[0078] The blockchain status includes the pre-transaction status and the post-transaction status. For example, the pre-transaction status information is <addr,<key0,value0> >, after replaying the historical transaction on EVM, that is, after executing the historical call function, if the corresponding state (i.e. value) is modified by the transaction corresponding to the function, the post-transaction state will be collected as <addr,<key1,value1> >.

[0079] EVM (Ethereum Virtual Machine) is one of the core components of the Ethereum blockchain platform and the operating environment of Ethereum smart contracts. On a technical level, EVM is a stack-based virtual machine that allows developers to write smart contracts on the Ethereum platform and execute them on the blockchain. The code executed by EVM is based on smart contracts written in Ethereum's Solidity programming language, which are compiled into a bytecode format that can be recognized by EVM.

[0080] Historical transactions include smart contract transactions, and their structure usually includes the following parts: transaction sender, transaction receiver, transaction amount, transaction ID, transaction timestamp, etc. The transaction also includes information such as contract address and contract method. It is actually executing a contract call. A smart contract is a piece of automatically executed code that can process and verify transaction data and automatically perform corresponding operations according to conditions.

[0081] In an embodiment of the present invention, historical transactions of smart contracts on the blockchain can be obtained, and the historical transactions can be replayed on the EVM to re-execute the historical transactions to obtain the blockchain status and historical call functions, and the two are used to construct historical transaction information.

[0082] At the same time, in addition to the historical call functions and blockchain status, the addresses involved in each historical transaction are also collected. These addresses are usually highly correlated with the corresponding transactions. Therefore, by traversing the specific bytecodes of the historical call functions during execution, including but not limited to CALL, CALLCODE, DELEGATECALL, STATICCALL and other operation codes, the address information associated with the above specific bytecodes can be extracted to obtain the associated address.

[0083] It should be noted that the associated address can usually include two types of addresses: external account addresses and addresses of other smart contracts (i.e. contract addresses). External account addresses are wallet accounts controlled by users, while contract addresses are independent smart contracts deployed on the Ethereum network.

[0084] Optionally, the associated address includes an external account address and a contract address.

[0085] Step 202, extract the corresponding target smart contract according to the contract address;

[0086] Although the state of a smart contract can be changed by many external function calls, in order to narrow the scope of exploration, the present invention generates a transaction sequence based on previously collected contract addresses because the functions in these contract addresses are more likely to trigger vulnerabilities.

[0087] To this end, you can first extract the corresponding target smart contract from the contract address to obtain the data extraction basis for subsequent callable functions.

[0088] Step 203, perform fuzz testing on the target smart contract according to the parameter variables and external account addresses corresponding to the historical call functions, and determine multiple initial functions;

[0089] Optionally, step 203 may include the following sub-steps:

[0090] Parse the target smart contract and determine the required parameter type;

[0091] Query the parameter variable corresponding to the historical call function for the parameter value with the same type as the required parameter and the latest timestamp;

[0092] Using the external account address as the initiator of the target smart contract, fuzz testing is performed in combination with parameter values ​​to determine multiple initial functions.

[0093] During the replay of historical transactions, the specific parameter values, parameter types and timestamps of the parameter variables corresponding to various historical call functions can be recorded. At the same time, the associated addresses also include external account addresses, including the external account addresses in the current transaction, the external account addresses collected in the historical information collection module, and randomly generated external account addresses.

[0094] In an embodiment of the present invention, after locating the corresponding target smart contract through the contract address, the target smart contract can be parsed to determine its required parameter type. After determining the required parameter type, the parameter value with the same required parameter type and the latest timestamp can be queried from the parameter variable corresponding to the historical call function. The external account address can be used as the initiator of the transaction call to which the target smart contract belongs, and the transaction in the target smart contract can be fuzzy tested in combination with the parameter value to determine the multiple initial functions called by the target smart contract during execution.

[0095] Step 204, deleting a specific type of function from the multiple initial functions to obtain multiple callable functions;

[0096] Step 205, respectively associate the historical call function and each callable function, and build multiple update transaction sequences in combination with the blockchain state;

[0097] In an embodiment of the present invention, the ABI information of the associated address contract can be read to extract multiple initial functions corresponding to the ABI information. To further save resources, specific types of functions such as pure and view functions can be deleted from them, because these two types of functions cannot modify the state variables of the smart contract, thereby obtaining multiple callable functions. After obtaining multiple callable functions, the historical call functions and each callable function are respectively associated in the order of execution, and multiple update transaction sequences are constructed in combination with the blockchain state.

[0098] In a specific implementation, after fuzz testing the smart contract, multiple callable functions can be extracted, and the present invention associates them with the callable functions on a related address and forms an update transaction sequence. For example, given a historical transaction and ten external transaction calls constructed from another associated smart contract, the present invention generates ten unique transaction sequences.

[0099] It is worth mentioning that, at the same time, the present invention collects the parameter types of each function call to improve the effectiveness of the generated transactions.

[0100] Step 206, mutating the update transaction sequence to generate a mutated transaction sequence;

[0101] In the embodiment of the present invention, all mutation strategies are mutated for each generated update transaction sequence, wherein each mutation transaction sequence may include multiple, such as a first mutation transaction sequence and a second mutation transaction sequence, corresponding to different mutation strategies respectively.

[0102] In an example of the present invention, step 206 may include the following sub-steps S11-S12:

[0103] S11, exchanging the execution order of the historical calling functions and the callable functions in the update transaction sequence to generate a first variant transaction sequence;

[0104] In the embodiment of the present invention, in order to determine whether there is a state dependency relationship between the historical calling function and the callable function, the execution order of the update transaction sequence constructed by the association between them may be mutated.

[0105] In the update transaction sequence, the historical call function is executed first, and then the callable function is executed. At this time, the execution order of the historical call function and the callable function can be exchanged to generate the first variant transaction sequence.

[0106] S12, inserting the callable function in the update transaction sequence into the corresponding historical call function to generate a second variant transaction sequence;

[0107] Further, step S12 may include the following sub-steps:

[0108] Traverse the bytecodes in the historical call functions and match the corresponding internal call functions according to the bytecodes;

[0109] The callable function in the update transaction sequence is inserted into the internal call function to generate a second mutated transaction sequence.

[0110] In the embodiment of the present invention, in addition to reordering the update transaction sequence, transaction insertion mutation may also be performed to determine whether there is a state inconsistency vulnerability caused by control flow hijacking.

[0111] At this time, the bytecodes in the historical call functions can be traversed to match the corresponding call instructions and corresponding addresses according to the bytecodes, thereby matching the corresponding internal call functions, that is, internal transactions. Then, the callable function is inserted before the end of the internal transaction, thereby generating a second variant transaction sequence.

[0112] Among them, the internal call function, also known as the internal transaction, refers to another function call initiated within the contract during the execution of the smart contract transaction. This function is called the internal call function.

[0113] Step 207, respectively execute the update transaction sequence and the mutated transaction sequence in the blockchain state, and determine whether there is a vulnerability in the smart contract according to the blockchain state after execution.

[0114] Further, step 207 may include the following sub-steps:

[0115] Execute the update transaction sequence and the mutation transaction sequence respectively on the blockchain state to generate two sets of blockchain states after execution;

[0116] If the blockchain states are the same after the two groups are executed, it is determined that there is no vulnerability in the smart contract;

[0117] If the blockchain states after the two groups are executed are different, it is determined that there is a vulnerability in the smart contract.

[0118] Optionally, the method further comprises:

[0119] Adjust the block timestamp and / or block difficulty in the original block information of the blockchain according to a preset gradient to obtain updated block information;

[0120] Execute the historical call function under the original block information and the updated block information respectively to generate two sets of modified blockchain states;

[0121] If the blockchain states after the two groups of modifications are the same, it is determined that there is no vulnerability in the smart contract;

[0122] If the blockchain states after the two sets of modifications are different, it is determined that there is a vulnerability in the smart contract.

[0123] In an embodiment of the present invention, in order to determine whether a historical calling function has a dependency on block information, the execution environment to which the historical calling function belongs may be modified, that is, the original block information to which the historical calling function belongs may be adjusted.

[0124] Among them, the way to adjust the block information includes but is not limited to adjusting the block timestamp and / or block difficulty according to a certain preset gradient.

[0125] The historical call function is executed under the original block information and the updated block information respectively to generate two sets of modified blockchain states; if the two sets of modified blockchain states are the same, it is determined that the smart contract has no loopholes; if the two sets of modified blockchain states are different, it is determined that the smart contract has loopholes.

[0126] See also Figure 3 , Figure 3 The following is a flowchart showing an execution flow of a vulnerability detection method for a smart contract in an embodiment of the present invention.

[0127] Taking the mutation strategy as reordering as an example, in the historical information collection module, the present invention first collects the on-chain historical transaction information of the smart contract to be tested. Then, the present invention re-executes all transactions and records the blockchain status information before and after the execution of the transaction. In the transaction sequence generation module, the present invention generates a transaction sequence based on the previously collected information. Specifically, the present invention first selects one of the transactions from the historical transactions, and generates another transaction based on the execution information of the transaction, and pieced together to obtain a transaction sequence (a total of two transactions). In the transaction sequence mutation module, the present invention mutates the transaction sequence obtained in the previous step according to the three predefined mutation rules, and obtains a new transaction sequence. The two transaction sequences before and after the mutation are referred to as peer transaction sequence pairs. The present invention determines whether there is a state inconsistency vulnerability by executing the peer transaction sequence pair and observing the consistency of the execution results of the two transaction sequences. If two transactions from different callers have no state dependency, the final smart contract state of the original transaction sequence and the mutated transaction sequence should be exactly the same.

[0128] In an embodiment of the present invention, in response to a vulnerability detection request, historical call functions, blockchain states, and corresponding associated addresses in historical transactions of a smart contract on a blockchain are collected; fuzz testing is performed according to the associated addresses to obtain a plurality of callable functions, and the historical call functions and each callable function are associated in sequence to construct a plurality of update transaction sequences; the update transaction sequences are mutated to generate mutated transaction sequences; the update transaction sequence and the mutated transaction sequence are respectively executed under the same blockchain state, and whether a vulnerability occurs in the smart contract is determined based on whether the blockchain states after execution are the same, thereby effectively improving the high false alarm rate or high missed alarm rate of vulnerability detection and improving the security of vulnerability detection of smart contracts.

[0129] See also Figure 4 , Figure 4 A structural block diagram of a smart contract vulnerability detection device according to a third embodiment of the present invention is shown.

[0130] The present invention also provides a smart contract vulnerability detection device, comprising:

[0131] The historical information collection module 301 is used to respond to the vulnerability detection request and collect the blockchain status, historical call functions and corresponding associated addresses of the smart contract on the blockchain;

[0132] The transaction sequence generation module 302 is used to perform fuzzy testing according to the associated address, obtain multiple callable functions, associate historical call functions, and construct multiple update transaction sequences;

[0133] A sequence mutation module 303, used to mutate the update transaction sequence to generate a mutated transaction sequence;

[0134] The vulnerability detection module 304 is used to execute the update transaction sequence and the mutated transaction sequence respectively under the blockchain state, and determine whether there is a vulnerability in the smart contract according to the blockchain state after execution.

[0135] Optionally, the historical information collection module 301 is specifically used for:

[0136] Respond to vulnerability detection requests, collect historical transactions of smart contracts on the blockchain and replay them to obtain blockchain status and historical call functions;

[0137] Traverse the specific bytecodes in the historical call function and extract the address information associated with the specific bytecode as the associated address;

[0138] Among them, the blockchain state includes the pre-transaction state and the post-transaction state.

[0139] Optionally, the associated address includes an external account address and a contract address; the transaction sequence generation module 302 includes:

[0140] The contract extraction submodule is used to extract the corresponding target smart contract according to the contract address;

[0141] The initial function determination submodule is used to perform fuzz testing on the target smart contract and determine multiple initial functions based on the parameter variables and external account addresses corresponding to the historical call functions;

[0142] A callable function determination submodule is used to delete a specific type of function from multiple initial functions to obtain multiple callable functions;

[0143] The function combination submodule is used to associate historical call functions and each callable function respectively, and build multiple update transaction sequences in combination with the blockchain status.

[0144] Optionally, the initial function determination submodule is specifically used for:

[0145] Parse the target smart contract and determine the required parameter type;

[0146] Query the parameter variable corresponding to the historical call function for the parameter value with the same type as the required parameter and the latest timestamp;

[0147] Using the external account address as the initiator of the target smart contract, fuzz testing is performed in combination with parameter values ​​to determine multiple initial functions.

[0148] Optionally, the transaction sequence generation module 302 further includes:

[0149] The random parameter generation submodule is used to use a preset random number generator to generate a new parameter value of the same type as the required parameter if there is no parameter value of the same type as the required parameter in the parameter variable corresponding to the historical call function.

[0150] Optionally, the sequence variation module 303 includes:

[0151] A first mutation submodule, used to exchange the execution order of the historical call function and the callable function in the update transaction sequence to generate a first mutation transaction sequence;

[0152] The second mutation submodule is used to insert the callable function in the update transaction sequence into the corresponding historical call function to generate a second mutation transaction sequence.

[0153] Optionally, the second mutation submodule is specifically used for:

[0154] Traverse the bytecodes in the historical call functions and match the corresponding internal call functions according to the bytecodes;

[0155] The callable function in the update transaction sequence is inserted into the internal call function to generate a second mutated transaction sequence.

[0156] Optionally, the vulnerability detection module 304 is specifically used for:

[0157] Execute the update transaction sequence and the mutation transaction sequence respectively on the blockchain state to generate two sets of blockchain states after execution;

[0158] If the blockchain states are the same after the two groups are executed, it is determined that there is no vulnerability in the smart contract;

[0159] If the blockchain states after the two groups are executed are different, it is determined that there is a vulnerability in the smart contract.

[0160] Optionally, the device further comprises:

[0161] A block information update module, used to adjust the block timestamp and / or block difficulty in the original block information of the blockchain according to a preset gradient to obtain updated block information;

[0162] The function execution module is used to execute the historical call function under the original block information and the updated block information respectively, and generate two sets of modified blockchain states;

[0163] The first determination module is used to determine that there is no vulnerability in the smart contract if the two groups of modified blockchain states are the same;

[0164] The second determination module is used to determine that a vulnerability exists in the smart contract if the two groups of modified blockchain states are different.

[0165] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices, modules and sub-modules can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0166] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0167] 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 on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0168] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for detecting vulnerabilities in smart contracts, characterized in that: include: Respond to vulnerability detection requests, collect the blockchain status, historical call functions and corresponding associated addresses of smart contracts on the blockchain; Perform fuzz testing according to the associated address to obtain multiple callable functions, and associate the historical call functions to construct multiple update transaction sequences; mutating the update transaction sequence to generate a mutated transaction sequence; Execute the update transaction sequence and the mutated transaction sequence respectively under the blockchain state, and determine whether the smart contract has a vulnerability according to the blockchain state after execution; The step of responding to the vulnerability detection request and collecting the blockchain status, historical call functions and corresponding associated addresses of the smart contract on the blockchain includes: Respond to vulnerability detection requests, collect historical transactions of smart contracts on the blockchain and replay them to obtain blockchain status and historical call functions; Traversing the specific bytecodes in the historical call function, and extracting address information associated with the specific bytecodes as associated addresses; Wherein, the blockchain state includes a pre-transaction state and a post-transaction state; The associated address includes an external account address and a contract address; the step of performing fuzz testing according to the associated address to obtain multiple callable functions, and associating the historical call functions to construct multiple update transaction sequences includes: Extract the corresponding target smart contract according to the contract address; Perform fuzz testing on the target smart contract according to the parameter variables corresponding to the historical call function and the external account address to determine multiple initial functions; Deleting a specific type of function from the multiple initial functions to obtain multiple callable functions; Respectively associating the historical call function with each of the callable functions, and building a plurality of update transaction sequences in combination with the blockchain state; The step of mutating the update transaction sequence to generate a mutated transaction sequence includes: Exchanging the execution order of the historical calling function and the callable function in the update transaction sequence to generate a first variant transaction sequence; Inserting the callable function in the update transaction sequence into the corresponding historical call function to generate a second variant transaction sequence; The step of respectively executing the update transaction sequence and the mutated transaction sequence under the blockchain state, and judging whether the smart contract has a vulnerability according to the blockchain state after execution, comprises: Execute the update transaction sequence and the mutated transaction sequence respectively in the blockchain state to generate two sets of post-execution blockchain states; If the two groups of blockchain states after execution are the same, it is determined that there is no vulnerability in the smart contract; If the two groups of blockchain states after execution are different, it is determined that a vulnerability exists in the smart contract.

2. The method according to claim 1, characterized in that The step of performing fuzz testing on the target smart contract according to the parameter variables corresponding to the historical call function and the external account address to determine multiple initial functions includes: Parse the target smart contract to determine the required parameter type; Query the parameter value with the same type as the required parameter and the latest timestamp from the parameter variable corresponding to the historical call function; The external account address is used as the initiator of the target smart contract, and fuzz testing is performed in combination with the parameter value to determine multiple initial functions.

3. The method according to claim 2, characterized in that The method further comprises: If there is no parameter value of the same type as the required parameter in the parameter variable corresponding to the historical call function, a preset random number generator is used to generate a new parameter value of the same type as the required parameter.

4. The method according to claim 1, characterized in that: The step of inserting the callable function in the update transaction sequence into the corresponding historical call function to generate a second variant transaction sequence includes: Traversing the bytecodes in the historical calling function, and matching the corresponding internal calling function according to the bytecodes; The callable function in the update transaction sequence is inserted into the internal call function to generate a second variant transaction sequence.

5. The method according to claim 1, characterized in that The method further comprises: Adjusting the block timestamp and / or block difficulty in the original block information of the blockchain according to a preset gradient to obtain updated block information; Executing the historical call function under the original block information and the updated block information respectively to generate two sets of modified blockchain states; If the two groups of modified blockchain states are the same, it is determined that there is no vulnerability in the smart contract; If the two sets of modified blockchain states are different, it is determined that a vulnerability exists in the smart contract.

6. A smart contract vulnerability detection device, characterized in that: include: The historical information collection module is used to respond to vulnerability detection requests and collect the blockchain status, historical call functions and corresponding associated addresses of smart contracts on the blockchain; A transaction sequence generation module, used to perform fuzz testing according to the associated address, obtain multiple callable functions, and associate the historical call functions to construct multiple update transaction sequences; A sequence mutation module, used to mutate the update transaction sequence to generate a mutated transaction sequence; A vulnerability detection module, used to respectively execute the update transaction sequence and the mutated transaction sequence under the blockchain state, and determine whether the smart contract has a vulnerability according to the blockchain state after execution; The historical information collection module is specifically used for: Respond to vulnerability detection requests, collect historical transactions of smart contracts on the blockchain and replay them to obtain blockchain status and historical call functions; Traversing the specific bytecodes in the historical call function, and extracting address information associated with the specific bytecodes as associated addresses; Wherein, the blockchain state includes a pre-transaction state and a post-transaction state; The associated address includes an external account address and a contract address; the transaction sequence generation module includes: The contract extraction submodule is used to extract the corresponding target smart contract according to the contract address; An initial function determination submodule, used to perform fuzz testing on the target smart contract according to the parameter variables corresponding to the historical call function and the external account address, and determine multiple initial functions; A callable function determination submodule, used to delete a specific type of function from the plurality of initial functions to obtain a plurality of callable functions; A function combining submodule, used to respectively associate the historical call function with each of the callable functions, and construct multiple update transaction sequences in combination with the blockchain state; The sequence variation module comprises: A first mutation submodule, used for exchanging the execution order of the historical calling function and the callable function in the update transaction sequence to generate a first mutation transaction sequence; A second mutation submodule, used for inserting the callable function in the update transaction sequence into the corresponding historical call function to generate a second mutation transaction sequence; The vulnerability detection module is specifically used for: Execute the update transaction sequence and the mutated transaction sequence respectively in the blockchain state to generate two sets of post-execution blockchain states; If the two groups of blockchain states after execution are the same, it is determined that there is no vulnerability in the smart contract; If the two groups of blockchain states after execution are different, it is determined that a vulnerability exists in the smart contract.

Images