A Vulnerability Detection Method and Device for Smart Contracts on a Blockchain

Abstract

An embodiment of this specification provides a method for detecting vulnerabilities in smart contracts on a blockchain. The method includes: collecting a plurality of historical transactions that invoke several smart contracts on the blockchain to form an initial seed pool. Performing a mutation operation based on the seed transactions in the seed pool to obtain generated transactions. Performing checkpoint evaluation by executing the generated transactions, and adding the generated transactions that pass the evaluation to the seed pool, where the checkpoint evaluation is used to eliminate invalid transactions and / or identify transactions related to the transfer of asset tokens. Identifying a profit vulnerability of the several smart contracts according to the first asset state after the execution of the first transaction in the seed pool and the second asset state after the execution of the second transaction, where the first transaction is a historical transaction and the second transaction is a generated transaction related to the first transaction.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of software testing, and in particular, to a method and device for detecting vulnerabilities in smart contracts on a blockchain. Background Art

[0002] In today's blockchain environment, in order to be able to complete a variety of complex functions, smart contracts on the chain will cooperate and collaborate with each other. For example, financial smart contracts and exchange rate smart contracts call each other to obtain the latest asset value of financial products.

[0003] With the rapid development of decentralized applications (DApps), a series of smart contracts on the chain establish connections with each other and generate call relationships. For example, in order to implement a basic asset exchange function between two different asset tokens, it is necessary to integrate multiple smart contracts on the chain, introducing extremely complex function call relationships, increasing the possibility of smart contracts being attacked, and also bringing major challenges in terms of the security of smart contracts.

[0004] Therefore, while promoting the development of smart contracts, it has become particularly important to ensure the security of smart contract programs on the chain. Different from traditional vulnerabilities that can cause program crashes, attacks on smart contracts, or illegal exploitation of defects existing in smart contracts, often result in economic losses (by constructing seemingly normal transactions through calling smart contracts to obtain additional economic benefits, or causing losses to the economic benefits of others). This type of defect existing in smart contracts is called a profit-making vulnerability.

[0005] Therefore, it is hoped that there can be a solution that can quickly and effectively detect profit-making vulnerabilities in the highly complex smart contract calls on the chain through technical means. Summary of the Invention

[0006] One or more embodiments of this specification describe a method for detecting vulnerabilities in smart contracts on a blockchain. Based on fuzz testing, a feedback mechanism is introduced to screen out effective test seeds and drive the test program to efficiently detect profit-making vulnerabilities in smart contracts on the chain.

[0007] According to a first aspect, there is provided a method for detecting vulnerabilities in smart contracts on a blockchain, including:

[0008] Collect a plurality of historical transactions that call several smart contracts on the blockchain to form an initial seed pool.

[0009] Perform mutation operations on the seed transactions in the seed pool to obtain generated transactions.

[0010] By performing checkpoint evaluation on the generated transaction, the generated transaction that passes the evaluation is added to the seed pool as a seed transaction. The checkpoint evaluation is used to eliminate invalid transactions and / or identify transactions related to the transfer of asset tokens.

[0011] Identify the profit vulnerabilities of the several smart contracts according to the first asset state after the execution of the first transaction in the seed pool and the second asset state after the execution of the second transaction, where the first transaction is a historical transaction and the second transaction is a generated transaction related to the first transaction.

[0012] In one implementation, the checkpoint evaluation by performing the generated transaction includes:

[0013] Extract first trace information from the execution trace of the generated transaction, which records information related to path jumps.

[0014] Determine whether the generated transaction generates a new test path and whether it is rolled back by the program according to the first trace information.

[0015] If it generates a new test path and is not rolled back, determine that the generated transaction passes the evaluation.

[0016] In a scenario of the above implementation, the first trace information includes the first count value of the program counter corresponding to the execution jump-related instruction and the first destination of the jump. Determining whether the generated transaction generates a new test path includes:

[0017] If the global count storage set does not cover the first count value, determine that a new test path is generated and add the first count value to the global count storage set.

[0018] If the global count storage set has covered the first count value and the global destination storage set does not cover the first destination, determine that a new test path is generated and add the first destination to the global destination storage set.

[0019] According to one implementation, the checkpoint evaluation by performing the generated transaction includes:

[0020] Extract second trace information from the execution trace of the generated transaction, which records function call information related to token transfer.

[0021] Determine whether the generated transaction generates new asset token transfer information according to the second trace information.

[0022] If it generates new asset token transfer information, determine that the generated transaction passes the evaluation.

[0023] In a scenario of the above - mentioned embodiment, extracting second - track information from the execution track of the generated transaction includes:

[0024] Extract function - call instructions from the execution track, and determine from them the target instructions of the functions called as target functions related to token transfer and their target positions.

[0025] Read first - token transfer information from the target position in the storage space, including the starting point, target, and quantity of the current token transfer.

[0026] In a scenario of the above - mentioned embodiment, the operation codes of the function - call instructions include CALL and DELEGATECALL; the target functions include transfer and transferFrom.

[0027] In a scenario of the above - mentioned embodiment, determining whether the generated transaction generates new asset - token transfer information includes:

[0028] If the storage information at the target position in the global token - transfer storage set does not cover the first - token transfer information, determine that new asset - token transfer information is generated, and add the first - token transfer information to the global token - transfer storage set.

[0029] According to one embodiment, the first transaction is initiated by a first user, the second transaction is initiated by a second user, the first transaction and the second transaction are executed based on the same blockchain state, and identifying the profit - making vulnerabilities of the several smart contracts includes:

[0030] If the assets of the second user in the second - asset state are greater than the assets of the first user in the first - asset state, determine that there are profit - making vulnerabilities in the several smart contracts.

[0031] According to one embodiment, the first transaction is initiated by a first user and executed based on a first historical state; the second transaction is initiated by a second user and executed after simulating the execution of the first transaction in a test environment, and identifying the profit - making vulnerabilities of the several smart contracts includes:

[0032] If the assets of the first user in the second - asset state are less than the assets of the first user in the first - asset state, determine that there are profit - making vulnerabilities in the several smart contracts.

[0033] In a scenario of the above - mentioned embodiment, the second - asset state is obtained by the following method:

[0034] Execute the generated third transaction to obtain a first intermediate state, and the third transaction is initiated by the second user.

[0035] Simulate and execute the first transaction based on the first intermediate state to obtain a second intermediate state.

[0036] Execute the second transaction based on the second intermediate state to obtain the second asset state.

[0037] According to one embodiment, the mutation operation based on the seed transactions in the seed pool includes:

[0038] Mutate the parameters included in any single seed transaction; or, perform combined mutation on two seed transactions.

[0039] According to one embodiment, the collecting of the multiple historical transactions that call several smart contracts on the blockchain further includes:

[0040] For any target historical transaction, obtain the block number and block timestamp of the block where the transaction is located, and store them in the seed pool corresponding to the target historical transaction for re - execution of the transaction.

[0041] According to one embodiment, the multiple historical transactions do not include invalid transactions, and the invalid transactions are transactions that trigger the revert operation.

[0042] According to a second aspect, there is provided a vulnerability detection device for smart contracts on a blockchain, including:

[0043] A collection module configured to collect multiple historical transactions that call several smart contracts on the blockchain to form an initial seed pool.

[0044] A seed mutation module configured to perform a mutation operation based on the seed transactions in the seed pool to obtain generated transactions.

[0045] A seed evaluation module configured to perform checkpoint evaluation by executing the generated transactions, and add the generated transactions that pass the evaluation to the seed pool as seed transactions. The checkpoint evaluation is used to eliminate invalid transactions and / or identify transactions related to the transfer of asset tokens.

[0046] An identification module configured to identify the profit - making vulnerabilities of the several smart contracts according to the first asset state after the execution of the first transaction in the seed pool and the second asset state after the execution of the second transaction, where the first transaction is a historical transaction and the second transaction is a generated transaction related to the first transaction.

[0047] According to a third aspect, there is provided a computer program product including computer programs / instructions, and when the computer programs / instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

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

[0049] In the method and apparatus provided in the embodiments of this specification, by introducing two modules responsible for evaluating the effectiveness of test seeds and identifying profitable transactions, on the one hand, invalid test seeds that cause fallback transactions can be eliminated in fuzz testing, improving the efficiency of fuzz testing; on the other hand, test seeds that generate asset token transfer transactions can be effectively identified, avoiding the problem of missed detections in fuzz testing that only focuses on code coverage; on the third hand, profitable vulnerabilities can be efficiently identified through dynamic differential analysis, solving the problem of low flexibility brought by using preset vulnerability oracles to identify profitable vulnerabilities, and improving the effectiveness of detecting profitable vulnerabilities in smart contracts. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] To more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention, and those of ordinary skill in the art can obtain other drawings based on these drawings without creative efforts.

[0051] Figure 1A Schematic diagram of an exemplary profitable vulnerability scenario disclosed in the embodiments of this specification;

[0052] Figure 1B Schematic diagram of an exemplary profitable vulnerability scenario disclosed in the embodiments of this specification;

[0053] Figure 1C Schematic diagram of an exemplary profitable vulnerability scenario disclosed in the embodiments of this specification;

[0054] Figure 2 Schematic diagram of the implementation architecture disclosed in the embodiments of this specification;

[0055] Figure 3 Flowchart of a method for detecting vulnerabilities in smart contracts on a blockchain provided according to the embodiments of this specification;

[0056] Figure 4 Schematic diagram of the seed pool initialization scenario provided according to the embodiments of this specification;

[0057] Figure 5A Pseudo-code of a checkpoint instrumentation provided according to the embodiments of this specification;

[0058] Figure 5B Pseudo-code of a checkpoint evaluation provided according to the embodiments of this specification;

[0059] Figure 5C A checkpoint insertion pseudocode provided according to an embodiment of this specification;

[0060] Figure 5D A checkpoint evaluation pseudocode provided according to an embodiment of this specification;

[0061] Figure 6 A schematic diagram of a vulnerability detection device for a smart contract on a blockchain according to an embodiment of this specification. Detailed implementation manners

[0062] The solutions provided by the embodiments of this specification will be described below with reference to the accompanying drawings.

[0063] As mentioned above, there are various profit-making behaviors on the blockchain, and attacks are launched on smart contracts using profit-making vulnerabilities. Compared with traditional vulnerabilities that can cause program crashes, attacks on smart contracts usually result in asset losses, so they are called profit-making behaviors. Profit-making behaviors obtain extra benefits through seemingly normal trading behaviors. Specifically, an adversary obtains extra improper benefits for himself or causes damage to the assets of other users by implementing profit-making behaviors (for example, submitting a carefully designed transaction call to a smart contract).

[0064] In fact, attacks that cause significant asset losses are usually caused by attacking the profit-making vulnerabilities of smart contracts on the chain. For example, in one case, a normal transaction in the asset token trading market involves the payment of appropriate handling fees. However, if there is incomplete access control in the smart contract, it will give the adversary the possibility of avoiding handling fees, posing a potential risk of significant losses to the project. In another case, a normal transaction needs to borrow money from an application and deposit sufficient collateral assets. However, due to insecure data dependencies in the smart contract, an adversary can conduct price manipulation attacks. By manipulating the value of the collateral assets, they can obtain more loans than in the normal situation through the collateral assets.

[0065] Two common cases of profit-making behaviors will be elaborated in detail below.

[0066] In one case, as Figure 1AAs shown, an exemplary scenario of an attack exploiting a profit-making vulnerability is provided. In this scenario, the adversary obtains additional benefits for themselves by making transaction calls that are not expected by the smart contract developer, taking advantage of the profit-making vulnerability. Specifically, a user hopes to borrow a certain amount of asset tokens (named USDC) through an application called Unipound (represented as a contract on the blockchain). Under normal circumstances, the user only needs to call the borrow function of the smart contract Unipound (the transaction is identified as TX2 in the figure) to borrow the USDC asset tokens. As can be seen from the figure, when lending assets, the real-time price of the lent asset tokens will be queried in real-time (the getPrice function call identified as "STATICCALL" in TX2 in the figure), that is, when borrowing USDC asset tokens in the Unipound application, it depends on the real-time price of USDC asset tokens in Uniswap. At this time, in order to obtain additional benefits, the adversary may take advantage of this insecure dependency. Before the operation of borrowing USDC asset tokens, the adversary first increases the quantity of USDC asset tokens in the asset token trading market through an asset token swap transaction (identified as TX1 in the figure) (when the quantity of an asset token in the trading market increases, its price will decrease), thereby manipulating the price of USDC asset tokens. After that, when the adversary borrows USDC asset tokens through TX2, they can pay the same amount of funds but borrow more USDC asset tokens. Finally, the adversary restores the price of USDC asset tokens through an asset token exchange opposite to the previous swap transaction (identified as TX3 in the figure). After this series of operations, the adversary takes advantage of the insecure dependency in the smart contract and, with an equivalent investment of funds, obtains a quantity of asset tokens that exceeds what can be obtained through normal transactions, thus achieving the goal of obtaining additional benefits.

[0067] In another scenario, such as Figure 1BAs shown, an exemplary scenario of an attack exploiting a profit-making vulnerability is provided. In this scenario, the adversary, through additional smart contract transaction calls, exploits the profit-making vulnerability to cause other users to suffer asset losses. Specifically, a user attempts to purchase an NFT (Non-Fungible Token) asset token from a trading market called Opensea. Under normal circumstances, the user only needs to call the buy transaction function of the smart contract (identified as TX2 in the figure) to purchase the NFT asset token (NFT_ID in the figure). As can be seen from the figure, while the user is making the purchase, the real-time price of the purchased NFT asset token is queried in real time (the getPrice function call identified by "STATICCALL" in TX2 in the figure), and then the funds required to purchase the NFT asset token are transferred from the user's account to the account of the counterparty of the transaction at the queried price (the transfer function call identified by "CALL" in TX2 in the figure). However, when the adversary (who can be the counterparty of this purchase transaction) identifies the user's intention to purchase an NFT asset token, an additional transaction call (identified as TX1 in the figure) is initiated prior to the user's purchase transaction to increase the price of the target NFT asset token. As a result, when the user makes the purchase, the user will purchase the NFT asset token at a manipulated price and suffer additional asset losses.

[0068] It should be noted that the above is an example of the profit-making vulnerability of on-chain smart contracts. In real-world scenarios, the types of profit-making vulnerabilities are not limited to this. In other cases, profit-making vulnerabilities may also be triggered by re-entrancy attacks, unauthorized access, etc. These are not introduced one by one in the embodiments of this specification.

[0069] Through the above examples, it is not difficult to find that attacks against the profit-making vulnerabilities of on-chain smart contracts are usually intertwined with normal transaction calls, do not cause explicit program crashes, and can achieve the purpose of making a profit by making some additional normal transaction calls, with extremely strong concealment and relevance to the context transaction calls. To detect the profit-making vulnerabilities of on-chain smart contracts, a test method that can accurately restore the transaction call context needs to be designed.

[0070] Due to the characteristics of the profit-making vulnerabilities of on-chain smart contracts introduced above, it poses challenges to the methods for detecting profit-making vulnerabilities in the prior art.

[0071] In some existing technologies, off-chain methods are used to detect vulnerabilities in target smart contracts, that is, the target smart contract is deployed locally, and transactions are continuously sent to it to attempt to reproduce the vulnerabilities. However, profit-making vulnerabilities often result from logical errors in the mutual calls between multiple smart contracts on the chain. The off-chain method lacks a comprehensive simulation of the on-chain environment and cannot identify or reproduce the transaction call context related to profit-making vulnerabilities, making it impossible to detect profit-making vulnerabilities with complex transaction call relationships.

[0072] In some other existing technologies, since the profit-making vulnerabilities of smart contracts do not cause system downtime or program crashes like traditional vulnerabilities, and the profit-making behavior comes from the exploitation of logical vulnerabilities in smart contracts, predictions are made based on possible profit-making behaviors, and customized vulnerability oracles are preset in the tests to identify profit-making vulnerabilities. However, this method is difficult to identify profit-making behaviors in new models, affecting the effectiveness of profit-making vulnerability detection and having low flexibility.

[0073] There are also some existing technologies that, in the tests for detecting profit-making vulnerabilities, focus on fuzz testing untested transaction calls and no longer test the transaction calls that have been tested. However, in the tests of some transaction calls, due to the existence of security validations (such as parameter validity validation, permission validation, etc.), the function calls in the test transactions are rolled back because they do not conform to the validation rules, resulting in a large number of generated test transactions being marked as covered after only testing the shallow logic of the smart contract and no longer being tested in subsequent tests, and the core logic of the smart contract is not tested. In addition, some key functions must be repeatedly called in a specific context to trigger profit-making vulnerabilities. In this case, if a key function is marked as covered when it is first called and is no longer concerned in subsequent tests, the profit-making vulnerabilities cannot be effectively identified. Figure 1CAs shown, an exemplary scenario of an attack exploiting a profit-making vulnerability is provided. In this scenario, a user expects to conduct an exchange of asset tokens (as shown in the transaction call in the first row of the figure). After the user initiates this transaction call, the exchange of asset tokens will be implemented in the last two transaction calls (the transaction calls in the 11th and 12th rows of the figure), and the handling fee required for the exchange is obtained from the transaction call initiated by the user (as shown by the arrow in the figure). In this way, a logical vulnerability is generated in the transaction call context. An adversary can use some technical means to adjust the handling fee parameter to zero in the transaction call initiated by the user to avoid being charged. The negative result brought by such a profit-making vulnerability will not become apparent until the 11th row is tested. During this process, the key function is the transferFrom function, which is repeatedly called multiple times in the context of this transaction (for example, in the 4th, 9th, and 11th rows). Among them, only the transferFrom function call in the 11th row will trigger the profit-making vulnerability. If the test direction is determined solely by code coverage, when the transferFrom function is first called in the 4th row during testing, the test of this function will end, and subsequent calls to this key function will be ignored during testing, making it impossible to identify the profit-making vulnerability.

[0074] To solve the above problems, in the embodiments of this specification, a method and device for detecting vulnerabilities in smart contracts on a blockchain are proposed. By introducing two modules responsible for evaluating the effectiveness of test seeds and identifying profitable transactions, the detection efficiency of profit-making vulnerabilities in on-chain smart contracts can be improved. By using a dynamic differential analysis method, profitable vulnerabilities can be efficiently identified, solving the problem of low flexibility brought by identifying profitable vulnerabilities through preset vulnerability oracles, and improving the effectiveness of detecting profit-making vulnerabilities in smart contracts.

[0075] Figure 2 An implementation architecture disclosed in the embodiments of this specification is shown. In this embodiment, the detection of profit-making vulnerabilities in on-chain smart contracts is divided into three stages.

[0076] In stage 1, for multiple smart contracts to be detected, historical transactions that call these smart contracts are collected from blockchain nodes. In a specific scenario, the historical data on blockchain nodes is publicly queryable. The JSON-RPC API interface is used to initiate queries for historical transaction data from each blockchain node, collect the historical transaction data, and store it in JSON format. In addition, in this stage, the metadata of each historical transaction is also extracted, the execution trace is viewed, and the seed pool is initialized using the collected data.

[0077] In this way, a seed pool storing a number of historical transactions as test seeds is obtained. In stage 2, any one historical transaction is selected from the seed pool and mutated to obtain a generated transaction. The historical transaction and the generated transaction are respectively simulated and executed to obtain the corresponding asset states after the simulation execution is completed. The asset state corresponding to the historical transaction is marked as the first asset state in the figure, and the asset state corresponding to the generated transaction is marked as the second asset state in the figure. During the execution of the generated transaction, the execution trajectory is monitored, and according to the features included in the execution trajectory, the generated transaction is evaluated according to the screening rules, and the generated transaction passing the evaluation is added to the seed pool as a seed. The specific content of the screening rules will be elaborated in detail below.

[0078] By simulating and executing the historical transaction and the generated transaction, two corresponding asset states are obtained, and in stage 3, by performing differential analysis, the profit-making loopholes in the smart contract are identified.

[0079] The above outlines the technical concept in an exemplary embodiment of this specification. In Figure 3 Figure, a flowchart of a method for detecting vulnerabilities in a smart contract on a blockchain provided according to an embodiment of this specification is shown. It can be understood that this method can be executed by any device, equipment, platform, or device cluster with computing and processing capabilities. Refer to Figure 3 In this embodiment, the method at least includes the following steps: Step S301: Collect a plurality of historical transactions that call several smart contracts on the blockchain to form an initial seed pool. Step S303: Perform a mutation operation based on the seed transactions in the seed pool to obtain generated transactions. Step S305: Perform a checkpoint evaluation by executing the generated transactions, and add the generated transactions passing the evaluation to the seed pool as seed transactions. The checkpoint evaluation is used to eliminate invalid transactions and / or identify transactions related to the transfer of asset tokens. Step S307: Identify the profit-making loopholes in the several smart contracts according to the first asset state after the execution of the first transaction in the seed pool and the second asset state after the execution of the second transaction, where the first transaction is a historical transaction and the second transaction is a generated transaction related to the first transaction.

[0080] The specific execution manners of the above steps will be described in detail below with reference to the accompanying drawings.

[0081] In step S301, a plurality of historical transactions that call several smart contracts on the blockchain are collected to form an initial seed pool.

[0082] Figure 4It shows a schematic diagram of the seed pool initialization scenario provided according to an embodiment. It can be understood that in any node of the blockchain, each block that has been consensus-linked in the blockchain will be recorded, and some transactions that have been linked to the chain will be recorded in each block, which can be called historical transactions. Referring to the historical transaction part in the figure, it can be seen that the historical transactions on the blockchain can include the transaction tx0 executed under a certain blockchain state (taking the state S0 in the figure as an example). Among them, executing the transaction tx0 under the state S0 can change the blockchain state to S1. Each sequentially executed transaction tx i , changes the blockchain state from S i-1 to S i .

[0083] Sampling the real on-chain transactions recorded in the blockchain can obtain the collected historical transactions. In one embodiment, since the main concern is the profit-making vulnerabilities of smart contracts, only the transactions that call the target smart contract can be collected, without paying attention to ordinary transfer transactions, for example. The target smart contract can be all contracts on the chain or several smart contracts of interest.

[0084] According to one implementation, only the necessary transaction metadata is collected for historical transactions. Specifically, for any target historical transaction, information such as the block number and block timestamp of the block where the historical transaction occurred, as well as information data such as the transaction participant addresses and transaction body of this historical transaction are obtained. These data are stored in the seed pool corresponding to the target historical transaction for the re-execution of the transaction. In an example, referring to the transaction metadata part in the figure, for any historical transaction tx i , the participant addresses of this transaction (identified by From and To in the figure), the transaction body (identified by Data in the figure), and the block information corresponding to this transaction (identified by Env in the figure) are captured, including the block number (identified by BlockNumber) and the timestamp (identified by Timestamp). In other examples, the ABI interface information of the smart contract related to this historical transaction will also be analyzed. The ABI contains the function interface information exposed by the smart contract under test. Saving such information will help to call the functions of the smart contract according to the ABI interface information during the test execution of the transaction.

[0085] According to one implementation, during the process of collecting historical transactions, the execution trace information of each transaction is captured. Referring to the seed pool initialization part in the figure, taking the historical transaction tx i → S i+1 that generates the state migration as an example, the captured transaction tx i is exemplarily shown in the execution trace part outlined by the dotted line. iThe execution trace data, which contains a series of instructions parsed from bytecode. Each instruction includes data such as the program counter (PC) and opcode (e.g., operands). For example, in the first line of instructions, the value of the program counter is 0x5, the opcode is PUSH1, and the operand is 0X73. In addition, the asset tokens involved in the transaction will also be collected and saved. For example, in transaction tx i involves the conversion between WETH and USDC asset tokens, and this information will be collected (as shown in the asset token part outlined by the dashed line in the figure). Based on the blockchain state S i execute tx i transaction, generating a new state S i+1 , in this new state, the asset information of the initiator can be marked as V(From,S i+1 ), where From is the transaction initiator, corresponding to the transaction initiator (From) information in the transaction metadata described above.

[0086] Collect multiple historical transactions that call several smart contracts from the blockchain, perform data collection according to the above rules, and regard each historical transaction as a seed transaction and deposit it into the seed pool to complete the initialization of the seed pool.

[0087] In one implementation, among the multiple historical transactions collected, invalid transactions are not included. The invalid transaction is a transaction that triggers the revert operation. That is, in the transaction trace of the captured transaction, if there is an instruction with the revert opcode, it means that the transaction is rejected by the smart contract for some reason, resulting in a function call revert operation. Such transactions will not be effectively utilized in subsequent profit vulnerability detection, so such historical transactions can be not collected.

[0088] After the initialization of the seed pool is completed, in step S303, perform a mutation operation based on the seed transactions in the seed pool to obtain generated transactions.

[0089] In one implementation, the mutation operation is to mutate the parameters included in any single seed transaction in the seed pool to obtain generated transactions.

[0090] In another implementation, the mutation operation is to perform combined mutation on two or more seed transactions in the seed pool to obtain generated transactions. According to a specific scenario, perform combined mutation on the seed transactions based on the havoc method.

[0091] Next, in step S305, checkpoint evaluation is performed by executing the generated transaction, and the generated transaction that passes the evaluation is added to the seed pool as a seed transaction. The checkpoint evaluation is used to eliminate invalid transactions and / or identify transactions related to the transfer of asset tokens.

[0092] To avoid excessive exploration of useless code / generated transactions and increase the diversity of seed transactions in the seed pool, during the execution of the generated transaction, waypoint evaluation is performed. On the one hand, invalid transactions are eliminated, and the generated transactions that produce invalid transactions will not be added to the seed pool as seed transactions. On the other hand, transactions related to the transfer of asset tokens generated during the execution of the generated transaction are identified, and based on this, it is determined whether the generated transaction can be added to the seed pool as a seed transaction.

[0093] Generally speaking, the checkpoint evaluation includes two parts of operations. The first part is to instrument the monitored opcodes for the currently simulated generated transaction and count the instrumentations hit during the current simulation execution. During the simulation execution, it can be executed based on the starting state of the original historical transaction corresponding to the generated transaction. For example, if the current generated transaction tx is mutated from the historical transaction tx0 in, for example, Figure 4 then the block information corresponding to the historical transaction tx0 can be obtained, and then the blockchain state S0 when tx0 is executed can be obtained from the blockchain node, and the generated transaction tx is executed based on the state S0. Alternatively, the generated transaction can also be executed in a specified state of interest. The second part is to determine whether the currently simulated generated transaction has produced a new execution trace, whether it has been rolled back, or whether it involves a new transfer of asset tokens based on the instrumentation hit statistics of the current simulation execution and the global hit statistics (i.e., the instrumentation hit statistics during the entire profit vulnerability detection process), so as to make the checkpoint evaluation result. Next, the checkpoint evaluation method will be further introduced in combination with embodiments and drawings.

[0094] According to one implementation, to avoid possible excessive exploration of useless code / generated transactions, the validity of the generated transaction is judged. Specifically, first trace information is extracted from the execution trace of the generated transaction, which records information related to path jumps. According to the first trace information, it is determined whether the generated transaction produces a new test path and whether it is rolled back by the program. If it produces a new test path and is not rolled back, it is determined that the generated transaction passes the evaluation, and the generated transaction is added to the seed pool as a seed transaction.

[0095] Among them, first trajectory information is extracted from the execution trace of the generated transaction, that is, including instrumenting the opcodes that generate path jumps to obtain path jump-related information as the first trajectory information. Typically, the instrumented opcodes that generate path jumps may include JUMP and JUMPI. Correspondingly, the obtained first trajectory information may include the first count value of the program counter corresponding to the execution of the above-mentioned jump-related instructions, and the first destination of the jump. According to this information, it can be determined whether the generated transaction generates a new test path.

[0096] Specifically, if the global count storage set does not cover the first count value, it is determined that a new test path is generated, and the first count value is added to the global count storage set. If the global count storage set already covers the first count value, but the global destination storage set does not cover the first destination, it can also be determined that a new test path is generated. At this time, the first destination can be added to the global destination storage set.

[0097] In addition, it is also necessary to determine whether the generated transaction generates a rollback, which can be determined based on whether there is an opcode or instruction indicating a rollback in its trajectory information. For example, if there is an instruction with the opcode of revert, it means that this generated transaction is rejected by the smart contract for some reason and a rollback operation occurs. If such generated transactions are added to the seed pool as seed transactions and mutated and continuously tested and executed based on this transaction in subsequent tests, they will continuously be rejected by the smart contract for the same reason, resulting in a waste of resources and reducing the efficiency of detecting profit-making vulnerabilities.

[0098] Take Figure 5A the shown pseudocode as an example, a checkpoint instrumentation according to an embodiment is provided. In the simulated execution of the generated transaction, the execution trace data of the generated transaction (the variable trace shown in the figure) is collected. The opcode of each instruction in the execution trace data is detected (the for loop in lines 1 - 7 shown in the figure). If the instruction contains path jump-related information, that is, the opcode is one of JUMP and JUMPI (the judgment shown in line 2 of the code in the figure), then the count value (the first count value) of the program counter (PC) of this instruction is stored in the count storage set (Br local ) in this simulated execution, as shown in line 3 of the code in the figure; in addition, through the instruction stack, the destination (the first destination) pointed to by the jump contained in this instruction is stored in the destination storage set (C local ) in this simulated execution, as shown in line 5 of the code in the figure.

[0099] Next, take Figure 5BTaking the shown pseudocode as an example, a checkpoint evaluation method in this embodiment is provided. After each generated transaction simulation execution is completed, the collected count storage set and destination storage set are respectively compared with the global count storage set (Br) and global destination storage set (C). Different from the count storage set and destination storage set, the global count storage set and global destination storage set store the program counters of the instructions related to path jumps that have been executed and the information of the jump destination pointers during the overall process of this profit vulnerability detection. Refer to Figure 5B , this section of pseudocode will output the checkpoint evaluation result (is_waypoint), where true represents passing the evaluation and false represents failing the evaluation. During the checkpoint evaluation process, each program counter and jump destination pointer will be judged, as shown in the for loop from line 2 to line 10.

[0100] Among them, if the first count value included in the first trace information is not covered in the global count storage set (shown in line 3 of the figure), it proves that a new test path is generated during the simulation execution of this generated transaction. In this case, this generated transaction passes the checkpoint evaluation (shown in line 4 of the figure), and the first count value is stored in the global count storage set (shown in line 5 of the figure). If the first count value is already covered in the global count storage set, then the first destination pointed to by the jump included in this instruction needs to be judged. If the first destination is not covered in the global destination storage set and this instruction has not been rolled back (shown in line 6 of the figure), it proves that a new destination jump is generated during the simulation execution of this generated transaction, which is also regarded as generating a new test path. In this case, this generated transaction passes the checkpoint evaluation (shown in line 7 of the figure), and the first destination is stored in the global destination storage set (shown in line 8 of the figure).

[0101] According to another implementation manner, the checkpoint evaluation further includes judging the correlation between the generated transaction and the asset token transfer. Specifically, second trace information is extracted from the execution trace of executing the generated transaction, which records function call information related to token transfer. According to the second trace information, it is determined whether the generated transaction generates new asset token transfer information. If it generates new asset token transfer information, it is determined that this generated transaction passes the evaluation, and this generated transaction is added to the seed pool as a seed transaction.

[0102] In a scenario of the above implementation manner, during the process of extracting the second trajectory information, key attention is paid to the instructions containing functions related to token transfer, and relevant information on token circulation is collected. Specifically, in the execution trajectory, stubs are inserted for the operation codes related to function calls, so as to extract function call instructions, and from them, target instructions whose called functions are target functions related to token transfer are screened out, and the target positions where the target instructions are located are determined. The first token circulation information is read from the target position in the storage space, which includes the starting point, target, and quantity of the current token transfer. In typical contract compilation languages, the operation codes related to function calls can include: CALL, DELEGATECALL; the target functions related to token transfer include: transfer function, transferFrom function.

[0103] In this scenario, if the storage information at the target position in the global token circulation storage set does not cover the first token circulation information, it is determined that new asset token circulation information is generated, and the first token circulation information is added to the global token circulation storage set.

[0104] Take Figure 5C the pseudo-code shown as an example to provide a checkpoint stubbing according to an embodiment. In the simulated execution of generating a transaction, execution trajectory data (the variable trace shown in the figure) is collected. The operation code of each instruction in the execution trajectory data is detected (the for loop in lines 2 - 7 shown in the figure). If the instruction contains a function call instruction, that is, the operation code is one of CALL, DELEGATECALL (the judgment shown in line 3 of the code in the figure), and the function called by the function call instruction is a target function related to token transfer, such as the transfer function or the transferFrom function, or the call value of the function call is not zero, it is determined that new asset token circulation has occurred. The target position (PC) of the target instruction is collected, and the first token circulation information (token flow ) is read from the storage space (Memory&Stack), and the first token circulation information is stored in the token circulation storage set (F local ) of this simulated execution, as shown in line 5 of the code in the figure.

[0105] Next, take Figure 5D the pseudo-code shown as an example to provide a checkpoint evaluation method in this embodiment. After the simulated execution of each generated transaction is completed, the collected token circulation storage set is compared with the global token circulation storage set (F). The global token circulation storage set stores the transaction context information related to asset token circulation that has been executed during the overall process of this profit-making vulnerability detection. Refer to Figure 5D, this piece of pseudocode will output the checkpoint evaluation result (is_waypoint), where true indicates passing the evaluation and false indicates failing the evaluation. During the checkpoint evaluation process, each transaction related to the transfer of asset tokens will be judged, as shown in the for loop from line 2 to line 7.

[0106] Among them, if the storage information at the target location (represented by i in the figure) in the global token transfer storage set does not cover the first token transfer information (shown in line 3 of the figure), it proves that new asset token transfers have occurred during the simulated execution of this generated transaction. In this case, this generated transaction passes the checkpoint evaluation (shown in line 4 of the figure), and the first token transfer information is added to the global token transfer storage set (shown in line 5 of the figure).

[0107] One or more of the above embodiments describe a method for checkpoint evaluation during the simulated execution of generated transactions. Through checkpoint evaluation, it is possible to avoid adding invalid generated transactions as seed transactions to the seed pool, thereby avoiding excessive exploration of useless code / generated transactions. Moreover, by paying attention to the token transfer information, the seed transactions in the seed pool can provide a richer execution context for token transfer-related functions, increasing the mining depth.

[0108] It should be understood that the above steps S303 and S305 can be repeatedly executed, continuously selecting seed transactions from the seed pool as the mutation basis to generate new generated transactions, and performing checkpoint evaluation on them. The generated transactions that pass the evaluation are added to the seed pool as the basis for subsequent mutations. In this way, a large number of generated transactions will be gradually added and accumulated in the seed pool. Together with the original historical transactions, these generated transactions serve as the basis for detecting profit-making vulnerabilities.

[0109] Specifically, as mentioned above, by executing the execution traces generated by historical transactions and generated transactions, the asset states corresponding before and after execution can be obtained. In the next step, through differential analysis, based on the comparison of the asset states of historical transactions and generated transactions, the profit-making vulnerabilities in the smart contract will be identified.

[0110] In step S307, according to the first asset state after the execution of the first transaction in the seed pool and the second asset state after the execution of the second transaction, identify the profit-making vulnerabilities of the several smart contracts, where the first transaction is a historical transaction and the second transaction is a generated transaction related to the first transaction.

[0111] As described above, in an attack against a profit-making vulnerability in a smart contract, an adversary obtains additional benefits for himself by performing transaction calls that are not expected by the smart contract developer, or causes other users to suffer asset losses by performing additional smart contract transaction calls.

[0112] According to one implementation, the first transaction is initiated by a first user, the second transaction is initiated by a second user, and the first transaction and the second transaction are executed based on the same blockchain state. If the assets of the second user in the second asset state are greater than the assets of the first user in the first asset state, it is determined that there is a profit-making vulnerability in the several smart contracts.

[0113] Specifically, the first transaction, as a historical transaction, is initiated by a user and is executed based on the blockchain state S pre After execution, the new blockchain state is S post , and the first transaction can be expressed as tx = (user, S pre , S post ). The second transaction is a generated transaction, initiated by an adversary, and is executed based on the same blockchain state S pre After execution, a new blockchain state S' post is generated, and the second transaction can be expressed as tx0 = (adversary, S pre , S' post ). The assets owned by the user after the execution of the first transaction as a historical transaction are expressed as V(user, S post ), which is the normal assets that the user can obtain in the historical transaction. The assets owned by the adversary after the execution of the generated transaction are expressed as V(adversary, S' post ), which is the assets that the adversary can obtain after executing the constructed second transaction. When V(adversary, S' post ) > V(user, S post ), it means that, under the same blockchain state, more asset returns can be obtained by executing the constructed transaction than in a normal transaction, that is, the adversary obtains additional benefits for himself by performing transaction calls that are not expected by the smart contract developer. Therefore, it can be determined that there is a profit-making vulnerability in the smart contract.

[0114] According to another embodiment, the first transaction as a historical transaction is initiated by the first user (an ordinary honest user) and executed based on the first historical state; the constructed second transaction is initiated by the second user (the adversary) and executed after simulating the execution of the first transaction in a test environment. If the second assets of the first user in the second asset state are less than the first assets of the first user in the first asset state, it is determined that there is a profit vulnerability in the several smart contracts. That is to say, if after executing the first transaction of the honest user in the constructed environment (test environment) and then executing the second transaction constructed by the adversary, the assets of the honest user (the second assets) are reduced compared to the assets in the normal state (the first assets), it indicates that the funds of the honest user are damaged and there is a profit vulnerability in the smart contract.

[0115] In a specific scenario, the execution effect of the constructed second transaction also requires the auxiliary execution of another generated transaction, that is, the third transaction. That is, first execute the generated third transaction to obtain the first intermediate state, and the third transaction is also initiated by the second user. Then, based on the first intermediate state, simulate the execution of the first transaction to obtain the second intermediate state. Next, based on the second intermediate state, execute the second transaction to obtain the second asset state.

[0116] Specifically, the first transaction is still denoted as tx, and its real historical execution trace in the blockchain is tx=(user,S pre ,S post ). Assume that the adversary initiates the third transaction tx0, and after executing this third transaction in the blockchain state S0, the first intermediate state S1 is generated. The execution of this third transaction can be expressed as tx0=(adversary,S0,S1). Then, based on the blockchain state S1, simulate the execution of the first transaction initiated by the user (user) to obtain the new blockchain state S2, that is, the second intermediate state. The simulated execution of the first transaction can be expressed as tx=(user,S1,S2). Next, based on the blockchain state S2, execute the second transaction tx1 initiated by the adversary again to generate the new blockchain state S3. The execution of this transaction is expressed as tx1=(adversary,S2,S3). That is to say, the above three transactions constitute a complete transaction context: tx0→tx→tx1, assuming that the user executes the first transaction on the intermediate state constructed by the adversary.

[0117] It can be understood that under normal circumstances, the assets owned by the user after the execution of the first transaction are denoted as V(user,S post) This is the normal assets owned by the user in historical transactions. The assets owned by the user after the adversary executes the generated transaction are denoted as V(user, S3), which is the assets owned by the user in the transaction context constructed by the adversary. When V(user, S post ) > V(user, S3), it means that the adversary constructs an execution environment in an intermediate state by executing the constructed transaction. When the user executes the historical transaction in this constructed state, the user will obtain less asset returns than in a normal transaction. That is, the adversary causes other users to suffer asset losses by implementing additional smart contract transaction calls. Therefore, it can be determined that there is a profit-making vulnerability in the smart contract.

[0118] Through the above differential analysis method, the execution status of a large number of seed transactions in the seed pool can be analyzed. Specifically, the asset status of the executed historical transactions and the generated transactions can be compared, and according to the above criteria, the profit-making vulnerabilities of the smart contract can be identified.

[0119] It should be noted that during the detection of profit-making vulnerabilities, the identity of the transaction initiator (the adversary or the user) is often difficult to determine. In some scenarios, from the perspective of the adversary, the captured asset change is a positive return, while from the perspective of the user, it is a negative return. Therefore, the identification of profit-making vulnerabilities is only related to the relative change relationship of assets in a specific scenario and has nothing to do with the positive or negative direction of asset changes.

[0120] In this specification, the "first" in terms such as the first transaction and the first intermediate state, and the corresponding "second", "third", "fourth" (if any) in the text are only for the convenience of distinction and description and do not have any restrictive meaning.

[0121] The above content describes specific embodiments of this specification, and other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be executed in a different order from that in the embodiments, and the desired results can still be achieved. Additionally, the processes depicted in the drawings do not necessarily need to be executed in the specific order or continuous order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0122] Figure 6 FIG. is a schematic diagram of a vulnerability detection device for a smart contract on a blockchain according to an embodiment of this specification. The system 600 is deployed in a computing device, and the computing device can be implemented by any device, equipment, platform, device cluster, etc. with computing and processing capabilities. This system embodiment corresponds to Figure 3 the method embodiment shown. The system 600 includes:

[0123] The collection module 601 is configured to collect multiple historical transactions that call several smart contracts on the blockchain to form an initial seed pool.

[0124] The seed mutation module 602 is configured to perform a mutation operation based on the seed transactions in the seed pool to obtain generated transactions.

[0125] The seed evaluation module 603 is configured to perform checkpoint evaluation by executing the generated transactions, and add the generated transactions that pass the evaluation to the seed pool as seed transactions. The checkpoint evaluation is used to eliminate invalid transactions and / or identify transactions related to the transfer of asset tokens.

[0126] The identification module 604 is configured to identify the profit loopholes of the several smart contracts according to the first asset state after the execution of the first transaction in the seed pool and the second asset state after the execution of the second transaction, where the first transaction is a historical transaction and the second transaction is a generated transaction related to the first transaction.

[0127] According to an embodiment of another aspect, the present specification also provides a computer program product, including a computer program / instructions, which when executed by a processor, implement the steps of the foregoing method. Figure 3 The steps of the method.

[0128] According to an embodiment of yet another aspect, the present specification also provides a computing device, including a memory and a processor, characterized in that the memory stores executable code, and when the processor executes the executable code, it implements the steps of the foregoing method. Figure 3 The steps of the method.

[0129] Those skilled in the art should be able to realize that in the above one or more examples, the functions described in the embodiments of the present invention can be implemented by hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0130] The specific embodiments described above further elaborate on the objectives, technical solutions, and beneficial effects of the embodiments of the present invention. It should be understood that the above is only the specific embodiments of the embodiments of the present invention and is not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the present invention shall be included in the protection scope of the present invention.

Claims

1. A vulnerability detection method for smart contracts on a blockchain, comprising: Collecting a plurality of historical transactions that invoke several smart contracts on the blockchain to form an initial seed pool; Performing mutation operations on the seed transactions in the seed pool to obtain generated transactions; Performing checkpoint evaluation by executing the generated transactions, and adding the generated transactions that pass the evaluation to the seed pool as seed transactions, where the checkpoint evaluation is used to eliminate invalid transactions and / or identify transactions related to the transfer of asset tokens; Identifying profit vulnerabilities of the several smart contracts according to the first asset state after the execution of the first transaction in the seed pool and the second asset state after the execution of the second transaction, where the first transaction is a historical transaction and the second transaction is a generated transaction related to the first transaction.

2. The method according to claim 1, wherein The performing checkpoint evaluation by executing the generated transactions includes: Extracting first trace information from the execution trace of executing the generated transaction, which records information related to path jumps; Determining whether the generated transaction generates a new test path and whether it is rolled back by the program according to the first trace information; If it generates a new test path and is not rolled back, determining that the generated transaction passes the evaluation.

3. The method according to claim 2, wherein The first trace information includes the first count value of the program counter corresponding to the execution jump-related instruction and the first destination of the jump; Determining whether the generated transaction generates a new test path includes: If the global count storage set does not cover the first count value, determining that a new test path is generated and adding the first count value to the global count storage set; If the global count storage set has covered the first count value and the global destination storage set does not cover the first destination, determining that a new test path is generated and adding the first destination to the global destination storage set.

4. The method according to claim 1, wherein, The performing checkpoint evaluation by executing the generated transactions includes: Extracting second trace information from the execution trace of executing the generated transaction, which records function call information related to token transfer; Determining whether the generated transaction generates new asset token transfer information according to the second trace information; If it generates new asset token transfer information, determining that the generated transaction passes the evaluation.

5. The method according to claim 4, wherein Extracting second trace information from the execution trace of executing the generated transaction includes: Extracting function call instructions from the execution trace and determining the target instructions and their target positions where the called functions are target functions related to token transfer; Reading first token transfer information from the target position in the storage space, including the starting point, target, and quantity of the current token transfer.

6. The method according to claim 5, wherein The operation codes of the function call instructions include CALL, DELEGATECALL; the target functions include transfer, transferFrom.

7. The method according to claim 5, wherein Determining whether the generated transaction generates new asset token transfer information includes: If the storage information at the target position in the global token transfer storage set does not cover the first token transfer information, determining that new asset token transfer information is generated and adding the first token transfer information to the global token transfer storage set.

8. The method according to claim 1, wherein, The first transaction is initiated by a first user, and the second transaction is initiated by a second user. The first transaction and the second transaction are executed based on the same blockchain state. Identifying the profit-making vulnerabilities of the several smart contracts includes: If the assets of the second user in the second asset state are greater than the assets of the first user in the first asset state, it is determined that there are profit-making vulnerabilities in the several smart contracts.

9. The method according to claim 1, wherein, The first transaction is initiated by a first user and executed based on a first historical state; the second transaction is initiated by a second user and executed after simulating the execution of the first transaction in a test environment. Identifying the profit-making vulnerabilities of the several smart contracts includes: If the assets of the first user in the second asset state are less than the assets of the first user in the first asset state, it is determined that there are profit-making vulnerabilities in the several smart contracts.

10. The method according to claim 9, wherein, The second asset state is obtained by the following method: Executing a generated third transaction to obtain a first intermediate state, where the third transaction is initiated by the second user; Based on the first intermediate state, simulating the execution of the first transaction to obtain a second intermediate state; Based on the second intermediate state, executing the second transaction to obtain the second asset state.

11. The method according to claim 1, wherein The performing mutation operations based on the seed transactions in the seed pool includes: Mutating the parameters included in any single seed transaction; or, performing combined mutation on two seed transactions.

12. The method according to claim 1, wherein, The collecting of the multiple historical transactions that invoke several smart contracts on the blockchain further includes: For any target historical transaction, obtaining the block number and block timestamp of the block where the transaction is located, and storing them in the seed pool corresponding to the target historical transaction for re-execution of the transaction.

13. The method according to claim 1, wherein The multiple historical transactions do not include invalid transactions, and the invalid transactions are transactions that trigger the revert operation.

14. A vulnerability detection device for smart contracts on a blockchain, comprising: A collection module configured to collect multiple historical transactions that invoke several smart contracts on the blockchain to form an initial seed pool; A seed mutation module configured to perform mutation operations based on the seed transactions in the seed pool to obtain generated transactions; A seed evaluation module configured to perform checkpoint evaluation by executing the generated transactions, and adding the generated transactions that pass the evaluation to the seed pool as seed transactions. The checkpoint evaluation is used to eliminate invalid transactions and / or identify transactions related to the transfer of asset tokens; An identification module configured to identify the profit-making vulnerabilities of the several smart contracts according to the first asset state after the execution of the first transaction in the seed pool and the second asset state after the execution of the second transaction, where the first transaction is a historical transaction and the second transaction is a generated transaction related to the first transaction.

15. A computer program product, comprising computer programs / instructions, which when executed by a processor implement the steps of the method according to any one of claims 1-13.

16. A computing device, comprising a memory and a processor, characterized in that, An executable code is stored in the memory, and when the processor executes the executable code, it implements the method according to any one of claims 1-13.

Images