A reentrancy attack detection method and device for blockchain contracts

Abstract

The embodiments of this specification provide a reentrancy attack detection method and device for blockchain contracts, the method comprising: obtaining multiple bytecodes corresponding to multiple smart contracts on a target blockchain, determining multiple first smart contracts with external call behaviors among the multiple smart contracts according to the bytecodes, and determining a preset data flow existing in each of the first smart contracts, the preset data flow indicating that an external input parameter of a function in the first smart contract is used as an external call parameter of the function in the first smart contract; and determining a reentrancy attack relationship between each of the multiple first smart contracts according to the preset data flow.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and more particularly, to a method and device for detecting reentrancy attacks on blockchain contracts. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. In the blockchain system, data blocks are combined into a chain data structure in a sequential manner according to time order, and a distributed ledger that cannot be tampered with or forged is guaranteed by cryptography. Due to the characteristics of blockchain such as decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application. Blockchain contracts, or smart contracts, refer to computer codes deployed on blockchain that can automatically execute protocols. Using blockchain contracts to implement established protocols or rules can improve the execution efficiency of protocols or rules, and can avoid subjective cheating in execution, and has a wide range of application scenarios. Summary of the invention

[0003] The embodiments in this specification are intended to provide a method and device for detecting reentrancy attacks on blockchain contracts. Through this method, the data streams sent by both potential attackers and attacked parties can be checked, and the reentrancy attack can be determined based on the data stream, thereby improving the accuracy of the reentrancy attack check, significantly reducing the false alarm rate of the check, and solving the shortcomings of the prior art.

[0004] According to a first aspect, a reentrancy attack detection method for a blockchain contract is provided, comprising:

[0005] Acquire multiple bytecodes corresponding to multiple smart contracts on the target blockchain, determine multiple first smart contracts with external call behaviors among the multiple smart contracts according to the bytecodes, and determine a preset data flow existing in each of the first smart contracts, wherein the preset data flow indicates that an external input parameter of a function in the first smart contract is used as an external call parameter of a function in the first smart contract;

[0006] According to the preset data stream, a reentrancy attack relationship between each of the plurality of first smart contracts is determined.

[0007] In a possible implementation, the external calling behavior includes: calling one or more of functions in other contracts and calling variable objects passed in from the outside.

[0008] In a possible implementation, the plurality of first smart contracts include a first contract and a second contract;

[0009] Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the input parameters of the first function in the first contract as the call parameters of the second function of the second contract in the function body of the first function.

[0010] In a possible implementation, the plurality of first smart contracts include a first contract;

[0011] Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the input parameters of the first function in the first contract as the return value of the first function.

[0012] In a possible implementation, the plurality of first smart contracts include a first contract;

[0013] Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the input parameters of the first function in the first contract as the return value of the first function after data processing.

[0014] In a possible implementation, the plurality of first smart contracts include a first contract;

[0015] Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the input parameters of the first function in the first contract as the call objects in the first function.

[0016] In a possible implementation, the plurality of first smart contracts include a first contract and a second contract;

[0017] Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the return value of the second function of the second contract called by the first function in the first contract as the parameter for calling the external object.

[0018] In a possible implementation, the plurality of first smart contracts include a first contract and a second contract;

[0019] Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the return value of the second function of the second contract called by the first function in the first contract as the return value of the first function.

[0020] In a possible implementation, determining, according to the bytecode, a plurality of first smart contracts having external call behaviors among the plurality of smart contracts includes:

[0021] The bytecode is decompiled into an intermediate language representation, and multiple first smart contracts having external call behaviors among the multiple smart contracts are determined according to the intermediate language representation.

[0022] In a possible implementation, determining, according to the preset data stream, a reentrancy attack relationship between each of the plurality of first smart contracts includes:

[0023] According to the relationship between the preset data streams between the smart contracts, the reentrancy attack relationship between the first smart contracts in the multiple first smart contracts is determined.

[0024] In a possible implementation, determining, according to the preset data stream, a reentrancy attack relationship between each of the plurality of first smart contracts includes:

[0025] The pre-trained recognition model is input according to the preset data stream to obtain the reentrant attack relationship between the first smart contracts.

[0026] In a possible implementation, the method further includes determining, based on the reentrant attack relationships between the first smart contracts, the attacking contracts and the attacked contracts included in the multiple first smart contracts.

[0027] In a possible implementation, a plurality of key-value pairs are pre-saved in the multimodal retrieval database, wherein the keys in the key-value pairs are used to save features of pre-acquired information of a first modality, and the values ​​in the key-value pairs are used to save relevant information of the same modality as the information of the first modality, as well as relevant information of a modality different from the information of the first modality.

[0028] According to a second aspect, a reentrancy attack detection device for a blockchain contract is provided, the device comprising:

[0029] An acquisition unit is configured to acquire multiple bytecodes corresponding to multiple smart contracts on the target blockchain, determine multiple first smart contracts with external call behaviors among the multiple smart contracts according to the bytecodes, and determine a preset data flow existing in each of the first smart contracts, wherein the preset data flow indicates that an external input parameter of a function in the first smart contract is used as an external call parameter of a function in the first smart contract;

[0030] The detection unit is configured to determine, based on the preset data stream, a reentrancy attack relationship between each of the multiple first smart contracts.

[0031] According to a third aspect, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed in a computer, the computer is caused to execute the method described in the first aspect.

[0032] According to a fourth aspect, a computing device is provided, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0033] By utilizing one or more of the methods, apparatuses, computing devices, and storage media in the above aspects, the data streams sent by both the potential attacker and the attacked party can be checked, and reentrancy attacks can be determined based on the data streams, thereby improving the accuracy of reentrancy attack checks and significantly reducing the false alarm rate of the checks. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0035] Figure 1 A blockchain architecture diagram is shown;

[0036] Figure 2 A reentrancy attack detection scheme for blockchain contracts is shown;

[0037] Figure 3 A schematic diagram showing a reentry attack detection method for a blockchain contract according to an embodiment of this specification;

[0038] Figure 4 A flowchart of a reentry attack detection method for a blockchain contract according to an embodiment of this specification is shown;

[0039] Figure 5 A schematic diagram showing a first preset data stream form according to an embodiment of this specification;

[0040] Figure 6 A schematic diagram showing a second preset data stream form according to an embodiment of this specification;

[0041] Figure 7 A schematic diagram showing a third preset data stream form according to an embodiment of this specification;

[0042] Figure 8 A schematic diagram showing a fourth preset data stream form according to an embodiment of this specification;

[0043] Fig. 9 A schematic diagram showing a fifth preset data stream form according to an embodiment of this specification;

[0044] Fig.10 A structural diagram of a reentry attack detection device for blockchain contracts according to an embodiment of this specification is shown. DETAILED DESCRIPTION

[0045] The solution provided in this invention book will be described below in conjunction with the accompanying drawings.

[0046] Figure 1 A diagram of a blockchain architecture is shown. Figure 1 As shown, the blockchain 100 includes, for example, 6 nodes. The lines between the nodes schematically represent P2P (Peer to Peer) connections. These nodes can store the full amount of ledgers, that is, store the status of all blocks and all accounts. Among them, each node in the blockchain generates the same state in the blockchain by executing the same transaction, and each node in the blockchain stores the same state database. It can be understood that Figure 1 Although it is shown that the blockchain includes 6 nodes, the embodiments of this specification are not limited to this, but may include other numbers of nodes. Specifically, the nodes included in the blockchain can meet the Byzantine Fault Tolerance (BFT) requirements. The Byzantine Fault Tolerance requirement can be understood as Byzantine nodes can exist inside the blockchain, but the blockchain does not reflect Byzantine behavior to the outside. In general, some Byzantine fault tolerance algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).

[0047] Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. Transactions usually include a send field (From), a receive field (To), and a data field (Data). Among them, in the case where the transaction is a transfer transaction, the From field indicates the account address that initiates the transaction (i.e., initiates a transfer task to another account), the To field indicates the account address that receives the transaction (i.e., receives the transfer), and the Data field includes the transfer amount. In the case where the transaction calls a smart contract in the blockchain, the From field indicates the account address that initiates the transaction, the To field indicates the account address of the contract called by the exchange, and the Data field includes the function name in the calling contract, and the incoming parameters of the function, etc., which are used to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.

[0048] The blockchain can provide the function of smart contracts. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. For example, calling a smart contract in Ethereum is to initiate a transaction pointing to the smart contract address, so that each node in the Ethereum network runs the smart contract code in a distributed manner. It should be noted that in addition to being able to create smart contracts by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a genesis contract. Generally, some blockchain network data structures, parameters, properties and methods can be set in the genesis contract. In addition, accounts with system administrator privileges can create system-level contracts or modify system-level contracts (referred to as system contracts).

[0049] In the scenario of deploying a contract, for example, Bob sends a transaction containing information about creating a smart contract (i.e. deploying a contract) to Figure 1 In the blockchain shown, the data field of the transaction includes the code of the contract to be created (such as bytecode or machine code), and the to field of the transaction is empty to indicate that the transaction is used to deploy the contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93..." of the contract is determined, and each node adds a contract account corresponding to the contract address of the smart contract in the state database, allocates the state storage corresponding to the contract account, and saves the contract code in the state storage of the contract, so that the contract is successfully created.

[0050] In the scenario of calling a contract, for example, Bob sends a transaction for calling a smart contract to Figure 1 In the blockchain shown, the from field of the transaction is the address of the account of the transaction initiator (i.e. Bob), the "0x6f8ae93..." in the to field represents the address of the smart contract being called, and the data field of the transaction includes the method and parameters for calling the smart contract. After the transaction is reached in the blockchain, each node in the blockchain can execute the transaction separately, thereby executing the contract separately, and updating the status database based on the execution of the contract.

[0051] Reentrancy attack is an attack that uses the calling mechanism to re-enter the contract multiple times during the contract execution and execute malicious code, causing contract anomalies or financial losses. Specifically, when a contract calls an external contract during execution, the caller contract will be in a waiting state. At this time, if the attacker constructs a malicious external call request, re-enters the caller contract and executes malicious code, the attack can be achieved. Since the caller contract is in a waiting state, the attacker can execute malicious code multiple times in a short period of time, causing contract anomalies or financial losses. Existing solutions for checking reentrancy attacks are mainly based on checking solutions for specific functions against the attacked contract. Figure 2 A reentrancy attack detection scheme for blockchain contracts is shown. Figure 1 As shown in the example, for example, by checking whether a specific function (such as call.value function) is called in the contract to be checked, it is determined whether the contract to be checked is an attacked contract. The call.value function can call back itself by calling other calls, and this feature is in danger of being used for reentrancy attacks. For example, the call.value function in the A contract can trigger the fallback function (fallback) in the called B contract. If the attacker repeatedly calls the function in the A contract in the fallback function (fallback) of the B contract, a reentrancy attack can be caused, causing the resources in the A contract (for example, tokens, or the fuel required to perform the operation) to be lost. Therefore, the existing reentrancy attack check scheme usually determines whether the contract to be checked is an attacked contract based on, for example, whether the call.value function is called in the contract to be checked. Alternatively, it is determined whether the contract to be checked is an attacked contract based on whether the call.value function is called in the contract to be checked and whether other specific operations are performed (for example, whether the balance deduction operation is performed after calling the call.value function).

[0052] However, the above scheme also has the following problems: First, the reentrancy attack essentially involves the data flow between the attacking contract and the attacked contract. The above scheme simply relies on the function call characteristics of the attacked contract party (for example, calling a specific function) for inspection, and cannot identify the data flow between the two parties, which easily causes the problem of a high false alarm rate of reentrancy attacks. Second, since it is impossible to detect reentrancy attacks initiated by other means other than the specific function that the scheme relies on, the ability to check reentrancy attacks is limited. For example, a reentrancy attack inspection scheme that mainly relies on checking the call.value() function call cannot detect reentrancy attacks implemented by, for example, standard token functions, or complex reentrancy attacks caused by user-defined interface design problems. Third, the expansion capability of the scheme inspection scope is weak, especially for complex reentrancy attacks caused by user-defined interface design problems, because the defined interfaces of different users are often different, and there may not be calls to typical specific functions. Therefore, even if the types of specific functions are expanded, it is difficult to check this type of reentrancy attack.

[0053] In order to solve the above technical problems, the embodiments of this specification provide a reentrancy attack detection method for blockchain contracts. Figure 3 A schematic diagram of a reentry attack detection method for a blockchain contract according to an embodiment of this specification is shown. Figure 3 As shown, first, the intermediate language representation (IR) of the blockchain contract can be obtained by decompilation according to the bytecode of multiple blockchain contracts. Then, according to the intermediate language representation, the preset data stream between the smart contracts with external call behavior is identified, and the external input parameters of the function in the smart contract are used as the external call parameters of the function in the smart contract. Then, according to the identified preset data stream, the reentrancy attack relationship between multiple blockchain contracts is determined. This method has the following advantages: on the one hand, by identifying the data stream with reentrancy attack risk between the smart contract and the smart contract, the reusable attack relationship between the smart contracts is judged. Compared with the existing scheme that simply checks the function call characteristics of the attacked contract party, this scheme checks the data streams sent by both the potential attack and the attacked parties, and determines the reentrancy attack according to the data stream, which improves the accuracy of the reentrancy attack check and significantly reduces the false alarm rate of the check. Second, by checking the data streams sent by the attack and the attacked parties, multiple types of reentrancy attacks can be checked. For example, it includes reentrancy attacks implemented through call.value() function calls, reentrancy attacks implemented through standard token functions, and complex reentrancy attacks caused by user-defined interface design issues. The overall inspection capability for reentrancy attacks is greatly improved.

[0054] The detailed process of this method is further explained below. Figure 4 A flowchart of a reentry attack detection method for a blockchain contract according to an embodiment of this specification is shown. Figure 4 Said method at least comprises the following steps:

[0055] Step S401, obtaining multiple bytecodes corresponding to multiple smart contracts on the target blockchain, determining multiple first smart contracts with external call behaviors among the multiple smart contracts according to the bytecodes, and determining a preset data flow existing in each of the first smart contracts, wherein the preset data flow indicates that an external input parameter of a function in the first smart contract is used as an external call parameter of a function in the first smart contract;

[0056] Step S403: determining a reentrancy attack relationship between each of the multiple first smart contracts according to the preset data flow.

[0057] First, in step S401, multiple bytecodes corresponding to multiple smart contracts on the target blockchain are obtained, and multiple first smart contracts with external call behaviors among the multiple smart contracts are determined according to the bytecodes. In different embodiments, the target blockchain can be a blockchain for different specific businesses or specific purposes. In different embodiments, the target blockchain can also be a blockchain of different specific types that supports the deployment or calling of smart contracts, which is not limited in this specification. In one embodiment, the target blockchain can be, for example, the Ethereum blockchain.

[0058] Usually, smart contracts need to be compiled by a compiler before they can run on a blockchain virtual machine (VM), and the compilation result of a smart contract can be called bytecodes. That is to say, smart contracts that can usually be used to check actual deployment are often in the form of bytecodes. Therefore, in this step, multiple bytecodes corresponding to multiple smart contracts on the target blockchain can be obtained, and multiple first smart contracts with external call behaviors in the multiple smart contracts can be determined based on the bytecodes. In different embodiments, the types of external call behaviors in multiple smart contracts may be different. In one embodiment, the external call behavior may include one or more of calling functions in other contracts and calling variable objects passed in from the outside.

[0059] In different embodiments, the specific method of determining multiple first smart contracts may be different. Since the parsing complexity of the intermediate language representation (IR) is usually lower than the parsing complexity of the bytecode. Therefore, in one embodiment, the bytecode can be decompiled into an intermediate language representation (IR), and multiple first smart contracts with external call behaviors in the multiple smart contracts are determined according to the intermediate language representation. In the above manner, the complexity of the reentrancy attack check can be reduced and the efficiency of the reentrancy attack check can be improved.

[0060] After determining multiple first smart contracts, the preset data streams existing in each first smart contract can be determined, and the preset data stream indicates that the external input parameters of the function in the first smart contract are used as the external call parameters of the function in the first smart contract. In different embodiments, the specific form of using the external input parameters of the function in the smart contract as the external call parameters of the function in the smart contract in the preset data stream may be different. In one embodiment, multiple smart contracts may include, for example, a first contract and a second contract. In different specific embodiments, the first contract and the second contract may be different specific contracts, and this specification does not limit this. In this embodiment, the preset data stream can be specifically expressed in the following form: using the input parameters of the first function in the first contract as the call parameters of the second function of the second contract in the function body of the first function. Figure 5 FIG. 1 is a schematic diagram showing a first preset data stream form according to an embodiment of this specification. Figure 5 As shown, for example, the first function of the first contract uses the input parameter p1 it receives as a calling parameter for calling the second function of the second contract.

[0061] In another embodiment, the first contract may be included in the plurality of smart contracts. The preset data flow may be specifically expressed in the following form: the input parameter of the first function in the first contract is used as the return value of the first function. In a specific embodiment, the input parameter of the first function in the first contract may be used as the return value of the first function after data processing. Figure 6 FIG. 2 is a schematic diagram showing a second preset data stream form according to an embodiment of this specification. Figure 6 As shown, for example, the first function of the first contract processes the external input parameter p1 it receives through data processing OP(p1) to obtain a processing result p2, and uses p2 as the return value of the first function. In one example, the return value can be returned to the external caller of the first function.

[0062] In another embodiment, the plurality of smart contracts may include the first contract. The preset data flow may be specifically expressed in the following form: the input parameter of the first function in the first contract is used as the calling object in the first function. Figure 7 FIG. 2 is a schematic diagram showing a third preset data stream form according to an embodiment of this specification. Figure 7 As shown, for example, the first function of the first contract receives an external input parameter p1, p1 is an external object, and the external object is called in the first function. In one example, for example, the method p.xx() in the external object p1 is called.

[0063] In another embodiment, the plurality of smart contracts may include a first contract and a second contract. The preset data flow may be specifically expressed in the following form: the return value of the second function of the second contract called in the first function of the first contract is used as a parameter for calling the external object. Figure 8 FIG. 4 is a schematic diagram showing a fourth preset data stream form according to an embodiment of this specification. Figure 8 As shown, for example, the first function of the first contract calls the second function of the second contract, and accepts the return value p1 of the second function, and uses p1 as a parameter for calling the external object c. In one example, for example, the parameter of the method c.xx() of the external object c is called.

[0064] In another embodiment, the plurality of smart contracts may include a first contract and a second contract. The preset data flow may be specifically expressed in the following form: the return value of the second function of the second contract called in the first function of the first contract is used as the return value of the first function. Fig. 9 FIG. 5 is a schematic diagram showing a fifth preset data stream form according to an embodiment of this specification. Fig. 9 As shown, for example, the first function of the first contract calls the second function of the second contract, and accepts the return value p1 of the second function, and uses p1 as the return value of the first function. In one example, the return value can be returned to the external caller of the first function.

[0065] Then, after determining the preset data flows existing in each first smart contract, in step S403, the reentrancy attack relationship between each smart contract in the plurality of first smart contracts may be determined according to the preset data flows.

[0066] In different embodiments, the specific manner of determining the reentrant attack relationship between each smart contract may be different. In one embodiment, for example, the reentrant attack relationship between each of the first smart contracts in the plurality of first smart contracts may be determined based on the relationship between the preset data streams existing between the smart contracts. In different specific embodiments, the reentrant attack relationship between each smart contract may be determined based on the specific relationship between the preset data streams in different specific representations identified between different smart contracts, and this specification does not limit this. In another embodiment, a pre-trained recognition model may be input based on the preset data stream to obtain the reentrant attack relationship between each smart contract. In a specific embodiment, the recognition model may be pre-trained, for example, based on the preset data stream extracted from the historical data of the smart contract, and the historical recognition results of the reentrant attack. In different specific embodiments, the recognition model may be based on different specific types of neural network models, and this specification does not limit this. In a specific embodiment, for example, it may be based on one of a convolutional neural network (CNN), a recursive neural network (RNN), and a Transformer model.

[0067] In addition, after determining the reentrant attack relationship between each smart contract. In one embodiment, the offensive contracts and attacked contracts included in the plurality of first smart contracts can also be determined based on the reentrant attack relationship between each first smart contract. Identifying the offensive contract and the attacked contract can, for example, provide a basis for further taking preventive measures against the offensive contract and taking protective measures against the attacked contract.

[0068] According to yet another embodiment, a reentrancy attack detection device for a blockchain contract is also provided. Fig.10 A structural diagram of a device for acquiring multimodal features according to an embodiment of this specification is shown, such as Fig.10 As shown, the device 1000 includes:

[0069] The acquisition unit 1001 is configured to acquire multiple bytecodes corresponding to multiple smart contracts on the target blockchain, determine multiple first smart contracts with external call behaviors among the multiple smart contracts according to the bytecodes, and determine a preset data flow existing in each of the first smart contracts, wherein the preset data flow indicates that an external input parameter of a function in the first smart contract is used as an external call parameter of a function in the first smart contract;

[0070] The detection unit 1002 is configured to determine, according to the preset data stream, a reentrancy attack relationship between each of the multiple first smart contracts.

[0071] Another aspect of the embodiments of the present specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute any one of the above methods.

[0072] On the other hand, the embodiments of the present specification provide a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, any one of the above methods is implemented.

[0073] It should be understood that the descriptions such as “first” and “second” in this article are only used to distinguish similar concepts for the sake of simplicity of description and do not have any other limiting effect.

[0074] Although one or more embodiments of the present specification provide method operation steps as described in the embodiments or flow charts, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent a unique execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "include", "comprise" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements.

[0075] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. 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. For example, 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.

[0076] Those skilled in the art should be aware that one or more embodiments of the present specification may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0077] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0078] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0079] The above description is only an example of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in the scope of the claims.

Claims

1. A reentrancy attack detection method for blockchain contracts, comprising: Acquire multiple bytecodes corresponding to multiple smart contracts on the target blockchain, determine multiple first smart contracts with external call behaviors among the multiple smart contracts according to the bytecodes, and determine a preset data flow existing in each of the first smart contracts, wherein the preset data flow indicates that an external input parameter of a function in the first smart contract is used as an external call parameter of a function in the first smart contract; The preset data streams existing in each first smart contract are input into the recognition model to obtain the reentrancy attack relationship between each first smart contract. The recognition model is pre-trained by the preset data streams extracted from the historical data of the smart contract and the historical recognition results for the reentrancy attack.

2. The method according to claim 1, wherein: The external calling behavior includes: calling functions in other contracts, calling variable objects passed in from the outside, or one or more of the above.

3. The method according to claim 1, wherein: The plurality of first smart contracts include a first contract and a second contract; Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the input parameters of the first function in the first contract as the call parameters of the second function of the second contract in the function body of the first function.

4. The method according to claim 1, wherein: The plurality of first smart contracts include a first contract; Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the input parameters of the first function in the first contract as the return value of the first function.

5. The method according to claim 4, wherein: The plurality of first smart contracts include a first contract; Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the input parameters of the first function in the first contract as the return value of the first function after data processing.

6. The method according to claim 1, wherein: The plurality of first smart contracts include a first contract; Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the input parameters of the first function in the first contract as the call object in the first function.

7. The method according to claim 1, wherein: The plurality of first smart contracts include a first contract and a second contract; Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the return value of the second function of the second contract called by the first function in the first contract as the parameter for calling the external object.

8. The method according to claim 1, wherein: The plurality of first smart contracts include a first contract and a second contract; Using the external input parameters of the function in the first smart contract as the external call parameters of the function in the first smart contract includes: using the return value of the second function of the second contract called by the first function in the first contract as the return value of the first function.

9. The method according to claim 1, wherein: Determining, according to the bytecode, a plurality of first smart contracts having external call behaviors among the plurality of smart contracts, including: The bytecode is decompiled into an intermediate language representation, and multiple first smart contracts having external call behaviors among the multiple smart contracts are determined according to the intermediate language representation.

10. The method according to claim 1 further includes determining the attacking contracts and attacked contracts included in the multiple first smart contracts based on the reentrant attack relationship between the first smart contracts.

11. A reentry attack detection device for a blockchain contract, the device comprising: An acquisition unit is configured to acquire multiple bytecodes corresponding to multiple smart contracts on the target blockchain, determine multiple first smart contracts with external call behaviors among the multiple smart contracts according to the bytecodes, and determine a preset data flow existing in each of the first smart contracts, wherein the preset data flow indicates that an external input parameter of a function in the first smart contract is used as an external call parameter of a function in the first smart contract; The detection unit is configured to input the preset data streams existing in each first smart contract into the recognition model to obtain the reentrancy attack relationship between each first smart contract, and the recognition model is pre-trained by the preset data stream extracted from the historical data of the smart contract and the historical recognition results for the reentrancy attack.

12. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 10.

13. A computing device, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 10 is implemented.

Images