A method and device for detecting re-entrancy attacks against blockchain contracts

Abstract

The embodiments of this specification provide a method and device for detecting re-entrancy attacks against blockchain contracts. The method includes: obtaining a preset data stream existing in multiple smart contracts with external call behaviors on a target blockchain, where the preset data stream represents using the external input parameters of a function in a smart contract as the external call parameters of a function in the smart contract; determining, according to the preset data stream, the re-entrancy call paths existing between each of the multiple smart contracts, where the re-entrancy call path between a first contract and a second contract included in the multiple smart contracts at least includes the mutual calls between the first contract and the second contract; and the re-entrancy call path is used to determine the re-entrancy attack risk between each smart contract.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a method and apparatus for detecting re-entrancy attacks on blockchain contracts. Background Art

[0002] Blockchain is a new application mode of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. In a blockchain system, data blocks are combined into a chained data structure in a sequential connection manner according to the time sequence, and a distributed ledger that is immutable and unforgeable is guaranteed by cryptographic means. Due to the characteristics of decentralization, information immutability, and autonomy of the blockchain, the blockchain has received more and more attention and applications. A blockchain contract, or a smart contract, refers to computer code deployed on the blockchain that can automatically execute an agreement. Using blockchain contracts to implement established agreements or rules can improve the execution efficiency of the agreements or rules and can avoid subjective cheating behaviors during execution, and has a wide range of application scenarios. Summary of the Invention

[0003] Embodiments in this specification aim to provide a method and apparatus for detecting re-entrancy attacks on blockchain contracts. Through this method, based on the obtained data streams sent by potential attackers and attacked parties, a re-entrancy call path including two-way calls between the two can be determined, and the re-entrancy attack risk between each smart contract can be determined according to whether there is a re-entrancy call path, improving the accuracy of re-entrancy attack detection and solving the deficiencies of the prior art.

[0004] According to a first aspect, a method for detecting re-entrancy attacks on blockchain contracts is provided, including:

[0005] Obtain preset data streams existing in multiple smart contracts with external call behaviors on a target blockchain, where the preset data streams represent using the external input parameters of functions in the smart contract as the external call parameters of functions in the smart contract;

[0006] According to the preset data streams, determine the re-entrancy call paths existing between each of the multiple smart contracts, where the re-entrancy call path between a first contract and a second contract included in the multiple smart contracts at least includes the mutual calls between the first contract and the second contract; the re-entrancy call path is used to determine the re-entrancy attack risk between each of the smart contracts.

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

[0008] In a possible implementation, the mutual call between the first contract and the second contract includes: a first function in the first contract calls a second function in the second contract, and the second function calls a third function in the first contract, and the third function calls the second function.

[0009] In a possible implementation, a first function in the first contract calls a second function in the second contract, including: the first function indirectly calls the second function in the second contract by calling a function of another contract;

[0010] and / or

[0011] The third function calls the second function, including: the third function indirectly calls the second function by calling a function of another contract.

[0012] In a possible implementation, a first function in the first contract calls a second function in the second contract, and the second function calls a third function in the first contract, including:

[0013] The first function calls the second function by passing a first parameter to the second function in the second contract, and the first parameter indicates the address of the first contract; the second function accesses the first contract through the first parameter and calls the third function.

[0014] In a possible implementation, the mutual call between the first contract and the second contract includes: a first function in the first contract calls a second function in the second contract, and the second function calls a third function in an external object, the third function is implemented in the first contract and the third function implemented in the third function calls the second function.

[0015] In a possible implementation, the method further includes

[0016] Determine the attacking contract and the attacked contract among the multiple smart contracts according to the reentry call path.

[0017] According to a second aspect, there is provided a reentry attack detection device for blockchain contracts, the device includes:

[0018] An acquisition unit, configured to acquire a preset data stream existing in a plurality of smart contracts with external call behaviors on a target blockchain, and the preset data stream represents using the external input parameters of a function in the smart contract as the external call parameters of a function in the smart contract;

[0019] The detection unit is configured to determine, according to the preset data stream, the re - entry call paths existing between each of multiple smart contracts, where the re - entry call path between a first contract and a second contract included in the multiple smart contracts at least includes the mutual calls between the first contract and the second contract; the re - entry call path is used to determine the re - entry attack risk between each of the smart contracts.

[0020] According to a third aspect, there is provided a computer - readable storage medium, on which a computer program is stored. When the computer program is executed on a computer, the computer is made to execute the method described in the first aspect.

[0021] According to a fourth aspect, there is provided a computing device, including a memory and a processor. An executable code is stored in the memory, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0022] Using one or more of the methods, devices, computing devices, and storage media in the above - mentioned aspects, it is possible to determine, according to the obtained potential attacks and the data stream sent by both the attacked and the attacker, the re - entry call path including two - way calls between them, and determine the re - entry attack risk between each of the smart contracts according to whether there is a re - entry call path, further improving the accuracy of re - entry attack detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained according to these drawings.

[0024] Figure 1 Shows a blockchain architecture diagram;

[0025] Figure 2 Shows a re - entry attack detection scheme for blockchain contracts;

[0026] Figure 3 Shows a schematic diagram of a method for detecting re - entry attacks on blockchain contracts according to an embodiment of this specification;

[0027] Figure 4 Shows a flowchart of a method for detecting re - entry attacks on blockchain contracts according to an embodiment of this specification;

[0028] Figure 5 Shows a schematic diagram of a re - entry call path according to an embodiment of this specification;

[0029] Figure 6A schematic diagram showing an indirect call according to an embodiment of the present specification;

[0030] Figure 7 A schematic diagram showing the passing of a contract address parameter according to an embodiment of the present specification;

[0031] Figure 8 A schematic diagram showing another re - entry call path according to an embodiment of the present specification;

[0032] Figure 9 A schematic diagram showing the inspection of a re - entry call path according to an embodiment of the present specification;

[0033] Figure 10 A structural diagram of a re - entry attack detection device for a blockchain contract according to an embodiment of the present specification. Detailed implementation manners

[0034] Next, the solution provided in this invention manual will be described in conjunction with the accompanying drawings.

[0035] Figure 1 A blockchain architecture diagram is shown. As Figure 1 shown, the blockchain 100 contains, for example, 6 nodes. The connections between the nodes schematically represent P2P (Peer to Peer) connections. All - volume ledgers can be stored on these nodes, that is, the states of all blocks and all accounts are stored. Among them, each node in the blockchain generates the same state in the blockchain by executing the same transactions, and each node in the blockchain stores the same state database. It can be understood that Figure 1 although 6 nodes are shown in the blockchain in the figure, the embodiments of the present specification are not limited thereto, but may include other numbers of nodes. Specifically, the nodes contained in the blockchain can meet the requirements of Byzantine Fault Tolerance (BFT). The so - called Byzantine Fault Tolerance requirements can be understood as that Byzantine nodes can exist inside the blockchain, while the blockchain does not exhibit Byzantine behavior externally. Generally, in some Byzantine Fault Tolerance algorithms, it is required that the number of nodes is greater than 3f + 1, where f is the number of Byzantine nodes. For example, the Practical Byzantine Fault Tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).

[0036] Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. A transaction usually includes a sending field (From), a receiving field (To), and a data field (Data). Among them, in the case of a transfer transaction, the From field represents the account address that initiates the transaction (i.e., initiates the transfer task to another account), the To field represents the account address that receives the transaction (i.e., receives the transfer), and the Data field includes the transfer amount. In the case of a transaction invoking a smart contract in the blockchain, the From field represents the account address that initiates the transaction, the To field represents the account address of the contract invoked by the transaction, and the Data field includes data such as the function name in the invoked contract and the input parameters to the function, so as to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.

[0037] 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, in Ethereum, invoking a smart contract is to initiate a transaction pointing to the smart contract address, enabling each node in the Ethereum network to run the smart contract code distributively. It should be noted that in addition to being created by users, smart contracts can also be set by the system in the genesis block. Such contracts are generally called genesis contracts. Generally, some data structures, parameters, attributes, and methods of the blockchain network can be set in the genesis contract. In addition, an account with system administrator privileges can create or modify system-level contracts (referred to as system contracts for short).

[0038] In the scenario of deploying a contract, for example, Bob sends a transaction containing information for creating a smart contract (i.e., deploying a contract) to the blockchain as shown in Figure 1 The data field of this 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 this transaction is used to deploy a contract. After the nodes reach an agreement through the consensus mechanism, the contract address "0x6f8ae93..." of the contract is determined. Each node adds a contract account corresponding to the contract address of the smart contract to the state database, allocates the state storage corresponding to the contract account, and saves the contract code in the state storage of the contract, thus the contract is successfully created.

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

[0040] A reentrancy attack is an attack that takes advantage of the call mechanism to re-enter the contract multiple times during the contract execution process and execute malicious code, resulting in anomalies or financial losses in the contract. Specifically, when a contract calls an external contract during execution, the calling contract will be in a waiting state. At this time, if an attacker constructs a malicious external call request to re-enter the calling contract and execute malicious code, the attack can be achieved. Since the calling contract is in a waiting state, the attacker can execute the malicious code multiple times in a short period, resulting in anomalies or financial losses in the contract. Existing solutions for checking reentrancy attacks are mainly checking solutions for the attacked contract based on specific functions. Figure 2 Disclosed is a solution for checking reentrancy attacks on a blockchain contract. Taking Figure 1 the example shown, for example, by checking whether a specific function (such as the call.value function) is called in the contract to be checked, it is determined whether the contract to be checked is an attacked contract.

[0041] The call.value function can call itself back through other calls, and this feature poses a risk of being exploited for reentrancy attacks. For example, the call.value function in Contract A can trigger the fallback function in the called Contract B. If the attacker repeatedly calls the function in Contract A in the fallback function of Contract B, a reentrancy attack can be caused, resulting in losses of resources (such as tokens or fuel required for executing operations) in Contract A. Therefore, existing solutions for checking reentrancy attacks usually determine 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. Or, based on whether the call.value function is called in the contract to be checked and whether other specific operations are performed (such as whether a balance deduction operation is performed after calling the call.value function), it is determined whether the contract to be checked is an attacked contract.

[0042] However, the above solutions also have the following problems: First, the reentrancy attack essentially involves the data flow between the attacking contract and the attacked contract. However, the above solutions simply rely 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 is likely to cause a relatively high false positive rate of reentrancy attacks. Second, since reentrancy attacks initiated through other means than the specific functions relied on by the solution cannot be detected, the ability to detect reentrancy attacks is limited. For example, a reentrancy attack detection solution that mainly relies on checking the call.value() function call cannot detect reentrancy attacks implemented through standard token functions or complex reentrancy attacks caused by user-defined interface design problems. Third, the solution has a weak ability to expand the inspection scope. Especially for complex reentrancy attacks caused by user-defined interface design problems, since the defined interfaces of different users are often different, and there may not necessarily be a call to a typical specific function among them. Therefore, even if the types of specific functions are expanded, it is difficult to detect such reentrancy attacks.

[0043] To solve the above technical problems, the embodiments of this specification provide a method for detecting reentrancy attacks on blockchain contracts. Figure 3 A schematic diagram showing a method for detecting reentrancy attacks on blockchain contracts according to an embodiment of this specification. As Figure 3As shown, first, it is possible to obtain a preset data flow existing between smart contracts with external call behaviors, where the external input parameters of functions in the smart contracts are used as the external call parameters of functions in the smart contracts. Then, based on the obtained preset data flow, identify the reentry call paths between smart contracts, and determine whether there is a risk of reentry attack between different smart contracts according to the identified reentry call paths. This method has the following advantages: On the one hand, according to the obtained smart contracts and the data flow with the risk of reentry attack between smart contracts, identify the reentry call paths between smart contracts. Compared with the existing solution that simply checks the function call characteristics of the attacked contract party, this solution identifies the reentry call paths according to the data flows sent by both the potential attacker and the attacked party, improving the accuracy of reentry attack detection and significantly reducing the false positive rate of the detection. Second, by identifying the reentry call paths based on the data flows sent by both the attacker and the attacked party, various types of reentry attacks can be checked. For example, it includes reentry attacks implemented through call.value() function calls, reentry attacks implemented through standard token functions, and complex reentry attacks caused by user-defined interface design problems. Greatly improve the overall inspection ability for reentry attacks. Third, based on the data flow with the risk of reentry attack between the obtained smart contracts, detect the reentry call paths between contracts based on the mutual call pattern. This reentry call path more accurately matches the call pattern of the actual reentry attacks between contracts in the production scenario, further improving the efficiency and accuracy of reentry attack detection.

[0044] The detailed process of this method will be further elaborated below. Figure 4 The flowchart showing a method for detecting reentry attacks on blockchain contracts according to an embodiment of this specification is shown. As Figure 4 described, this method at least includes the following steps:

[0045] Step S401, obtain the preset data flow existing in multiple smart contracts with external call behaviors on the target blockchain, where the preset data flow represents using the external input parameters of functions in the smart contracts as the external call parameters of functions in the smart contracts;

[0046] Step S403, according to the preset data flow, determine the reentry call paths existing between each of the multiple smart contracts, where the reentry call path between the first contract and the second contract included in the multiple smart contracts at least includes the mutual calls between the first contract and the second contract; the reentry call path is used to determine the risk of reentry attack between each of the smart contracts.

[0047] First, in step S401, obtain the preset data streams existing in multiple smart contracts with external call behaviors on the target blockchain. In different embodiments, the target blockchain may be a blockchain for different specific businesses or specific purposes. In different embodiments, the target blockchain may also be different specific types of blockchains that support the deployment or invocation of smart contracts, and this specification does not limit this. In one embodiment, the target blockchain may be, for example, the Ethereum blockchain. 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 invoking functions in other contracts and invoking variable objects passed in externally.

[0048] In this step, the preset data stream may represent using the external input parameters of the functions in the smart contract as the external call parameters of the functions in the smart contract. In different embodiments, the specific manner of obtaining the preset data may be different. For example, in one embodiment, multiple bytecodes corresponding to the smart contracts deployed on the target blockchain may be obtained, and based on the bytecodes, the smart contracts with external call behaviors among the deployed smart contracts may be determined. Generally, a smart contract needs to be compiled by a compiler before it can run on a blockchain virtual machine (VM), and the compilation result of the smart contract may be referred to as bytecodes. That is to say, usually, the bytecode form is often used to check the actually deployed smart contracts. Therefore, the bytecodes of the smart contracts deployed on the target blockchain can be obtained, and based on this, the smart contracts with external call behaviors among the deployed smart contracts can be determined. In a specific embodiment, the bytecodes may also be decompiled into an intermediate language representation (Intermediate Representation, IR), and based on the intermediate language representation, the smart contracts with external calls among the multiple smart contracts may be determined. By this means, the complexity of re-entrancy attack checking can be reduced, and the efficiency of re-entrancy attack checking can be improved. In another embodiment, after the smart contracts with external call behaviors, based on the intermediate language representations of these smart contracts, the preset data streams in these smart contracts may be determined.

[0049] In different embodiments, the specific representation form of the obtained preset data stream may be different. For example, in one embodiment, the preset data stream may be specifically represented in the following form: taking the input parameters of the first function in the first contract among multiple smart contracts as the call parameters for calling the second function in the second contract among the multiple smart contracts in the function body of the first function. In another embodiment, the preset data stream may be specifically represented in the following form: taking the input parameters of the first function in the first contract as the return value of the first function. In yet another embodiment, the preset data stream may be specifically represented in the following form: taking the input parameters of the first function in the first contract as the call object in the first function. In still another embodiment, the preset data stream may be specifically represented in the following form: taking the return value of the second function called by the first function in the first contract for calling the second contract as the parameter for calling an external object. In yet another embodiment, the preset data stream may be specifically represented in the following form: taking the return value of the second function called by the first function in the first contract for calling the second contract as the return value of the first function.

[0050] Then, after obtaining the preset data stream, in step S403, according to the preset data stream obtained in step S401, the re - entry call paths existing between each of the multiple smart contracts can be determined. Specifically, the re - entry call path between the first contract and the second contract included in the multiple smart contracts may at least include the mutual calls between the first contract and the 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.

[0051] In different embodiments, the specific manner of the mutual calls between the first contract and the second contract may be different. In one embodiment, the mutual calls between the first contract and the second contract may be in the following manner: the first function in the first contract calls the second function in the second contract, and the second function calls the third function in the first contract, and the third function calls the second function. Figure 5 Shows a schematic diagram of a re - entry call path according to an embodiment of this specification. As Figure 5As shown, for example, the first function of the first contract calls the second function in the second contract, the second function also calls the third function in the first contract, and the third function also calls the second function. This re-entrancy call path between the first contract and the second contract makes the first contract at risk of a re-entrancy attack on the second contract. Therefore, by identifying this re-entrancy call path, the re-entrancy attack risk existing in the first contract and the second contract can be determined, as well as the attacking contract and the attacked contract in the first contract and the second contract. It should be noted that since the data stream obtained in step S401 represents the external input parameters of the functions in the smart contract as the external call parameters of the functions in the smart contract. Therefore, if not otherwise specified, the function calls between different contracts described in this step are all function calls by passing parameters.

[0052] In a specific embodiment, the first function can indirectly call the second function in the second contract by calling the function of another contract. Figure 6 FIG. shows a schematic diagram of an indirect call according to an embodiment of the present specification. As Figure 6 shown, for example, the first function of the first contract calls the other function in the other contract, and the other function calls the second function in the second contract. Or, the other function can also indirectly call the second function in the second contract through the other function in another contract. Similarly, in another specific embodiment, the third function can also indirectly call the second function by calling the function of another contract. By detecting the indirect call, it is convenient to help identify the deep re-entrancy attack risk in the non-direct call relationship. In an example, if the out-degree represents the interval level of the indirect call, the contract with the largest out-degree from the first function, or in other words, the contract with the deepest indirect call relationship, can be detected for the risk of being used in a re-entrancy attack, greatly improving the ability to identify the re-entrancy attack risk.

[0053] In another specific embodiment, the first function in the first contract calls the second function in the second contract, and the second function calls the third function in the first contract. It can be specifically implemented in the following way: the first function calls the second function by passing the first parameter to the second function in the second contract, and the first parameter indicates the address of the first contract; the second function accesses the first contract through the first parameter and calls the third function. Figure 7 FIG. shows a schematic diagram of passing the contract address parameter according to an embodiment of the present specification. As Figure 7 shown, for example, the first function in the first contract calls the second function in the second contract by passing the parameter p1 to the second function, and p1 represents the address of the first contract. The second function accesses the first contract through p1 and calls its third function. In this way, the first contract can control the second function to call its own function, that is, the second function can call the third function in the first contract.

[0054] In another embodiment, the mutual call between the first contract and the second contract can also be implemented in the following manner: a first function in the first contract calls a second function in the second contract, and the second function calls a third function in an external object. The third function is implemented in the first contract, and the third function implemented in the first contract calls the second function. Figure 8 A schematic diagram showing another reentry call path according to an embodiment of the present specification. As Figure 8 shown, as Figure 8 shown, for example, a first function of a first contract calls a second function in a second contract, and the second function calls a third function in an external object p. The third function is also implemented in the first contract, and the third function implemented in the first contract also calls the second function. In this way, it is not necessary to detect whether the external object p is the first contract. Then, since the third function exists both in the external object p and in the first contract, and the third function in the first contract calls the second function. Therefore, in the case where the external object p is actually the first contract, this reentry call path between the first contract and the second contract makes the first contract also have the risk of launching a reentry attack on the second contract. Therefore, it is also possible to determine the reentry attack risk existing between the first contract and the second contract by identifying this reentry call path. And since the external call object does not need to be detected, the complexity of reentry attack detection can be reduced.

[0055] Next, in a specific embodiment, the detection process of the reentry call path will be further specifically described. Figure 9 A schematic diagram showing the inspection of the reentry call path according to an embodiment of the present specification. As Figure 9 shown, for example, the function bar() in the contract from calls the function foo() in the contract target. Since the call parameter passed by the function bar() when calling foo() is the address of this contract (i.e., the address of the contract from, address(this)), and the function foo() calls the function hook() in the contract from through the input parameter v1 (i.e., the address of the contract from) in its function body. And the function hook() in the contract from also calls the function foo() in the contract target. Therefore, a situation as Figure 5The re - entry call path between the first contract and the second contract as shown. Therefore, contract from has the risk of launching a re - entry attack on contract target. Due to the data flow that constitutes this re - entry call path, it can all be the preset data flow obtained in step S401, that is, it can all have the property of using the external input parameters of the contract function as the external call parameters of the contract function. For example, function bar() calls function foo() in contract target, that is, takes the input parameter v2 of function bar() as the call parameter for calling function foo(). Another example is that function hook() calls function foo() in contract target, and also takes the input parameter v2 of function hook() as the call parameter for calling function foo(). The other data flows that constitute the re - entry call path are similar and will not be elaborated one by one here. Therefore, based on the preset data flow obtained in step S401, it is possible to identify, for example Figure 5 , Figure 8 the re - entry call paths of contract mutual calls as shown.

[0056] In addition, in one embodiment, the re - entry call path can be used to determine the re - entry attack risk between the various smart contracts. For example, based on whether there is a re - entry call path between different smart contracts, it can be determined whether there is a re - entry attack risk between different smart contracts. For example, in Figure 5 the example shown, based on Figure 5 the re - entry call path existing between the first contract and the second contract in Figure 5 , it can be determined that there is a re - entry attack risk between the first contract and the second contract in Figure 8 . In Figure 8 the example shown, based on Figure 8 the re - entry call path existing between the first contract and the second contract in

[0057] According to an embodiment of another aspect, a re - entry attack detection device for blockchain contracts is also provided. Figure 10 shows the structural diagram of a device for obtaining multi - modal features according to an embodiment of this specification. As Figure 10 shown, the device 1000 includes:

[0058] An acquisition unit 1001, configured to acquire the preset data flow existing in multiple smart contracts with external call behaviors on the target blockchain, where the preset data flow represents using the external input parameters of the functions in the smart contract as the external call parameters of the functions in the smart contract;

[0059] The detection unit 1002 is configured to determine, according to the preset data stream, the re - entry call paths existing between each of the multiple smart contracts, where the re - entry call paths between a first contract and a second contract included in the multiple smart contracts at least include the mutual calls between the first contract and the second contract; the re - entry call paths are used to determine the re - entry attack risks between the respective smart contracts.

[0060] Another aspect of the embodiments of this specification provides a computer - readable storage medium, on which a computer program is stored. When the computer program is executed on a computer, the computer is made to execute any one of the above - mentioned methods.

[0061] Another aspect of the embodiments of this specification provides a computing device, including a memory and a processor. An executable code is stored in the memory. When the processor executes the executable code, any one of the above - mentioned methods is implemented.

[0062] It should be understood that the descriptions such as "first" and "second" in this article are only used to distinguish similar concepts for the simplicity of description and do not have other limiting effects.

[0063] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flowcharts, based on conventional or non - creative means, there may be more or fewer operation steps. The step sequences listed in the embodiments are only one way among the execution sequences of numerous steps and do not represent the only execution sequence. When an actual device or terminal product executes, it can be executed in the method sequence shown in the embodiments or the drawings or executed in parallel (for example, in an environment of parallel processors or multi - threaded processing, or even in a distributed data - processing environment). The term "comprising", "including" or any other variant thereof is intended to cover non - exclusive inclusion, so that a process, method, product or device including a series of elements not only includes those elements but also includes other elements not explicitly listed, or further includes elements inherent to such a process, method, product or device. Without further limitation, it does not exclude the existence of additional identical or equivalent elements in the process, method, product or device including the said elements.

[0064] For the convenience of description, when describing the above device, it is divided into various modules according to functions for separate description. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same or multiple software and / or hardware, or the modules implementing the same function can be realized by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and 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 displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces, and the indirect coupling or communication connection of the device or unit can be in electrical, mechanical or other forms.

[0065] Those skilled in the art should be able to realize that one or more embodiments of this specification can be provided as a method, system or computer program product. Therefore, one or more embodiments of this specification can take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of this specification can 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.

[0066] One or more embodiments of this specification can 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 can also be practiced in a distributed computing environment, where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0067] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other, and the key point of each embodiment is to illustrate 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 refer to the description of the method embodiment. In the description of this specification, the description of reference terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic expression of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, 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.

[0068] The above is only the embodiment of one or more embodiments of this specification, and is not used to limit one or more embodiments of this specification. For those skilled in the art, one or more embodiments of this specification can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included within the scope of the claims.

Claims

1. A method for detecting re - entry attacks against blockchain contracts, comprising: Obtaining a preset data flow existing in multiple smart contracts with external call behaviors on a target blockchain, where the preset data flow represents using the external input parameters of a function in the smart contract as the external call parameters of the function in the smart contract; Determining, according to the preset data flow, the re - entry call paths existing between each of the multiple smart contracts, where the re - entry call path between a first contract and a second contract among the multiple smart contracts at least includes the mutual calls between the first contract and the second contract; the mutual calls between the first contract and the second contract include: a first function in the first contract calls a second function in the second contract, and the second function calls a third function in the first contract, and the third function calls the second function; or includes: a first function in the first contract calls a second function in the second contract, and the second function calls a third function in an external object, and the third function is implemented in the first contract and the third function implemented in the third function calls the second function; Determining, according to the re - entry call path existing between the first contract and the second contract, that there is a risk of re - entry attack between the first contract and the second contract.

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

3. The method according to claim 1, wherein, The first function in the first contract calls the second function in the second contract, including: the first function indirectly calls the second function in the second contract by calling a function of other contracts; and / or, The third function calls the second function, including: the third function indirectly calls the second function by calling a function of other contracts.

4. The method according to claim 1, wherein The first function in the first contract calls the second function in the second contract, and the second function calls the third function in the first contract, including: The first function calls the second function by passing a first parameter to the second function in the second contract, where the first parameter indicates the address of the first contract; the second function accesses the first contract through the first parameter and calls the third function.

5. The method according to claim 1, further comprising, Determining, according to the re - entry call path, the aggressive contract and the attacked contract among the multiple smart contracts.

6. A device for detecting re - entry attacks against blockchain contracts, the device comprising: An obtaining unit configured to obtain a preset data flow existing in multiple smart contracts with external call behaviors on a target blockchain, where the preset data flow represents using the external input parameters of a function in the smart contract as the external call parameters of the function in the smart contract; The detection unit is configured to determine, according to the preset data stream, the reentry call paths existing between each of the multiple smart contracts, where the reentry call path between a first contract and a second contract included in the multiple smart contracts at least includes the mutual calls between the first contract and the second contract; the mutual calls between the first contract and the second contract include: a first function in the first contract calls a second function in the second contract, and the second function calls a third function in the first contract, and the third function calls the second function; or includes: a first function in the first contract calls the second function in the second contract, and the second function calls a third function in an external object, the third function is implemented in the first contract and the third function implemented in the third function calls the second function; the detection unit is further configured to determine, according to the reentry call path existing between the first contract and the second contract, that there is a risk of reentry attack between the first contract and the second contract.

7. A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed in a computer, the computer is made to execute the method according to any one of claims 1-5.

8. A computing device, including a memory and a processor, where an executable code is stored in the memory, and when the processor executes the executable code, the method according to any one of claims 1-5 is implemented.

Images