Method and apparatus for vulnerability detection for target applications

Abstract

The embodiment of the present specification provides a method and device for vulnerability detection of a target application, which is a decentralized application based on a block chain and supports resource exchange and transfer based on several types of tokens. The above method comprises: firstly, recording a transaction execution track involving a smart contract in an application execution process to form a call tree, the call tree containing transaction nodes and event nodes. Then, based on the call tree, extracting token transfer events and mining the roles involved in each transaction to determine target transfer actions occurring between a user and the target application, and each target transfer action forms a token flow. Then, the token flows for each type of token are merged, and the cumulative transfer-in amount and the cumulative transfer-out amount are determined based on the merged token flows. According to the cumulative transfer-in amount and the cumulative transfer-out amount, it is determined whether there is a token leakage vulnerability.

Description

Technical Field

[0001] This specification relates to one or more embodiments of blockchain-based decentralized applications, and more particularly to methods and apparatus for vulnerability detection of such decentralized applications. Background Technology

[0002] Blockchain and smart contracts have attracted significant attention from industry and academia. Many popular applications already utilize smart contracts on the blockchain, forming decentralized applications. Within these applications, some allow users to transfer and exchange resources based on tokens. However, as these applications develop, their security is also challenged. Attackers could exploit program flaws in smart contracts or functional bugs in the application to launch attacks and unjustifiably extract large amounts of resources that do not belong to them, thereby affecting the application's security and stability.

[0003] We hope there can be improved solutions to better detect vulnerabilities in these types of applications. Summary of the Invention

[0004] This specification describes one or more embodiments of a method and apparatus for vulnerability detection in decentralized applications, which can effectively detect token disclosure vulnerabilities in such applications and improve the security and stability of the applications.

[0005] According to the first aspect, a method for vulnerability detection of a target application is provided, wherein the target application is a decentralized application based on blockchain and supports resource exchange and transfer based on several types of tokens; the method includes:

[0006] The execution trajectory of smart contracts involved in the execution of the target application is recorded to form a call tree, which includes transaction nodes and event nodes; the directed edges between transaction nodes indicate that a parent transaction triggers a child transaction; the directed edges between a transaction node and an event node indicate that the event is emitted through the transaction.

[0007] Based on the call tree, token transfer events are extracted and the roles involved in each transaction are identified to determine the target transfer actions that occur between the user and the target application. Each target transfer action forms a token flow. The roles include user roles representing the user and application roles representing the target application.

[0008] The token flows for each type of token will be merged, and the cumulative inflow and outflow will be determined based on the merged token flows. Based on the cumulative inflow and outflow, it will be determined whether there is a token leakage vulnerability.

[0009] According to one implementation, the recording of the transaction execution trajectory is achieved by modifying the virtual machine deployed in the blockchain node for executing smart contracts.

[0010] Furthermore, modifications to the virtual machine may include at least one of the following:

[0011] Insert logging code into the function used to execute external transactions to record the external transactions;

[0012] Insert logging code into the call handler of the target function that generates the internal transaction to record the internal transaction;

[0013] Insert logging code into the virtual machine's Log operation to record events.

[0014] According to one implementation, based on the call tree, token transfer events are extracted and the roles involved in each transaction are identified to determine the target transfer action occurring between the user and the target application, specifically including:

[0015] Extract the target subtree from the call tree, traverse the target subtree, and determine the action corresponding to the token transfer event as the candidate transfer action; wherein, the root node of the target subtree is the transaction node that calls the proxy contract; the proxy contract is an external contract that the user can directly call in the target application;

[0016] The preset roles are passed along the call tree to determine the roles of each address involved in the call tree;

[0017] Based on the roles of each address, the target transfer action between the user and the target application is determined from the candidate transfer actions.

[0018] In a further embodiment, several types of tokens include a first type of token, which has a first token standard; in this case, traversing the target subtree and determining the action corresponding to the token transfer event as a candidate transfer action includes: using the first token standard, identifying a first event related to the transfer of the first type of token from the target subtree, replacing the event node corresponding to the first event with a token transfer node, and including the action corresponding to the node as a candidate transfer action.

[0019] In one embodiment, the plurality of token types include a second type of token, which is a token that can be directly transferred between users through external transactions; in this case, traversing the target subtree and determining the action corresponding to the token transfer event as a candidate transfer action includes: retrieving token transfer information from the first transaction of the target subtree, inserting a token transfer node into the transaction node corresponding to the first transaction, and classifying the action corresponding to the node as a candidate token transfer action.

[0020] According to one embodiment, the aforementioned method of passing preset roles along the call tree to determine the roles of each address involved in the call tree specifically includes: setting the initiator of an external transaction as a user role, setting the proxy contract as an application role, and passing roles along the call tree in a predetermined manner. The role passing includes, for internal transactions, if the callee is not marked with a role, assigning the caller's role to the callee.

[0021] In a specific example, the target transfer action is recorded as a data tuple, which includes the block height of the transaction that triggered the action, the position of the transaction in the block, the number of tokens transferred, the type of tokens transferred, and the action type; the action type is selected from deposit action or withdrawal action.

[0022] According to one embodiment, the above method further includes: using information of a preset type of token and the roles involved in each transaction to mine a preset relationship between users; accordingly, determining the cumulative inflow and cumulative outflow includes: merging the token flow of a single user to obtain the merged token flow of that user; at a single operation point of the merged token flow, searching for related users who have the preset relationship with that user, grouping them into a group, and calculating the cumulative deposit and cumulative withdrawal of all users in the group.

[0023] Furthermore, in one embodiment, the preset type token is used to record the user's staking share, and when the user performs a deposit / withdrawal operation, the target application mints / destroys the preset type token; the mining of preset relationships between users includes one or more of the following:

[0024] In response to a first user invoking a proxy contract, the preset type token is transferred to the target application, and the preset type token is minted for a second user, recording that the first user and the second user have the preset relationship;

[0025] In response to a third user transferring the preset type token to a fourth user, the system records that the third user and the fourth user have the preset relationship.

[0026] According to one embodiment, several types of tokens are multiple types of tokens; the token streams for each type of token are merged, including: converting each type of token into a preset uniform value unit based on a pre-built conversion table, and merging the token streams of different tokens into a single stream based on the uniform value unit.

[0027] In one embodiment, determining whether a token leakage vulnerability exists based on the cumulative inflow and cumulative outflow includes: at each action, calculating the actual return rate corresponding to the action based on the ratio of the cumulative outflow to the cumulative inflow before the action is executed; from the actual return rates corresponding to multiple actions of multiple users, determining multiple return rates that are less than a preset threshold T, calculating the average and standard deviation of the multiple return rates, and determining a standard return rate based on the average and standard deviation; and identifying actions with actual return rates greater than the standard return rate as abnormal actions that lead to token leakage.

[0028] According to the second aspect, an apparatus for vulnerability detection of a target application is provided, wherein the target application is a decentralized application based on blockchain and supports resource exchange and transfer based on several types of tokens; the apparatus includes:

[0029] The recording unit is configured to record the transaction execution trajectory of smart contracts involved in the execution of the target application, forming a call tree. The call tree includes transaction nodes and event nodes. The directed edges between transaction nodes indicate that a parent transaction triggers a child transaction. The directed edges between a transaction node and an event node indicate that the event is emitted through the transaction.

[0030] The extraction unit is configured to extract token transfer events and mine the roles involved in each transaction based on the call tree, thereby determining the target transfer actions that occur between the user and the target application, and each target transfer action forms a token flow; wherein the roles include user roles representing the user and application roles representing the target application;

[0031] The detection unit is configured to merge the token flows for each type of token, determine the cumulative inflow and cumulative outflow based on the merged token flows, and determine whether there is a token leakage vulnerability based on the cumulative inflow and cumulative outflow.

[0032] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0033] According to a fourth aspect, a computing device is provided, 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 method of the first aspect.

[0034] In the embodiments described in this specification, the vulnerability detection scheme consists of three stages. It acquires transaction data from the blockchain upon which the DeApp is based and outputs token leakage vulnerabilities and corresponding attackers. The first stage records the DeApp's execution trajectory by replaying these transactions. The second stage extracts token transfer events and mines the roles (users or applications) of related addresses and the relationships between users, generating a token flow for the user. The third stage merges the token flow and performs anomaly detection to reveal token leakage vulnerabilities and corresponding attackers. Through this method, token leakage vulnerabilities in the target application can be detected efficiently and accurately. Attached Figure Description

[0035] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is a schematic diagram of a blockchain architecture;

[0037] Figure 2 This diagram illustrates the token transfer process during an attack transaction targeting a DeApp.

[0038] Figure 3 The code for the transfer function of the LP token is shown;

[0039] Figure 4 A schematic diagram illustrating the framework of a vulnerability detection scheme according to one embodiment is shown;

[0040] Figure 5 A flowchart illustrating an application vulnerability detection method according to one embodiment is shown.

[0041] Figure 6 A schematic diagram of the call tree is shown;

[0042] Figure 7 This illustrates multiple save modes for the target application in one example;

[0043] Figure 8 This illustrates the process of determining the token flow based on the call tree;

[0044] Figure 9 A schematic diagram of the structure of a detection device according to one embodiment is shown. Detailed Implementation

[0045] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0046] Decentralized applications are proposed based on blockchain architecture. For example... Figure 1 The image shown is a schematic diagram of a blockchain architecture. Figure 1 The blockchain architecture diagram shown depicts multiple nodes, such as node 1 and nodes 2 through 6. The lines connecting the nodes schematically represent peer-to-peer connections. These nodes can store the entire ledger, that is, the state of all blocks and all accounts. Each node in the blockchain can generate the same state by executing the same transaction, and each node can store the same state database, also known as the world state.

[0047] In the blockchain field, a transaction refers to a unit of task executed and recorded within the blockchain. A transaction typically includes a From field, a To field, and a Data field. Specifically, in the case of a transfer transaction, the From field represents the account address initiating the transaction (i.e., initiating a transfer task to another account), the To field represents the account address receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount. In the case of a transaction calling a smart contract on the blockchain, the From field represents the account address initiating the transaction, the To field represents the account address of the contract called by the transaction, and the Data field includes the function name in the called contract and the parameters passed to that function, which is used to retrieve and execute the function's code from the blockchain during transaction execution.

[0048] Blockchain provides the functionality of smart contracts. A smart contract on the blockchain is a contract that can be triggered and executed by transactions within the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract on the blockchain involves initiating a transaction pointing to the smart contract's address, causing each node in the blockchain to run the smart contract code in a distributed manner. It should be noted that besides users creating smart contracts, the system can also set smart contracts in the genesis block. These contracts are generally called genesis contracts. Typically, genesis contracts can set some blockchain data structures, parameters, attributes, and methods. Furthermore, accounts with system administrator privileges can create or modify system-level contracts (referred to as system contracts). These system contracts can be used to add data structures for different business operations to the blockchain.

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

[0050] In scenarios where contracts are invoked, for example, Bob sends a transaction to invoke a smart contract, such as... Figure 1 In the blockchain shown, the `from` field of this transaction is the address of the account of the transaction initiator (i.e., Bob), the `to` field "0x6f8ae93…" represents the address of the smart contract being invoked, and the `data` field of the transaction includes the method and parameters for invoking the smart contract. After consensus is reached on this transaction in the blockchain, each node in the blockchain can execute the transaction, thereby executing the contract separately, and updating the state database based on the execution of the contract. To obtain the same world state, the same virtual machine, such as the EVM (Ethereum Virtual Machine), is deployed on each node of the blockchain to execute the deployed smart contracts.

[0051] As can be seen above, in a blockchain, both users and smart contracts are identified by addresses. There is no formal difference between user addresses and contract addresses. The account address representing a user is called an external account.

[0052] Since smart contracts are essentially program code that can be written and deployed to implement certain logic, decentralized applications (DeApps) built on blockchain can utilize smart contracts to realize their functions. Generally, transactions involved in the operation of a DeApp can be divided into two types: external transactions and internal transactions. External transactions are initiated by external accounts (users), while internal transactions are initiated by smart contracts. External transactions can derive or trigger multi-layered internal transactions that depend on a tree structure. Correspondingly, the smart contracts involved in a DeApp can be divided into proxy contracts and internal contracts. Proxy contracts are user-facing contracts that can be directly invoked by users through external transactions. After a proxy contract is invoked, its execution can trigger invocation of internal contracts (or background contracts). In addition, during the execution of smart contracts, predetermined events can be triggered to record specific behaviors.

[0053] Decentralized Applications (DeApps) can leverage smart contracts to provide increasingly rich functionality. Many DeApps offer various tokens, allowing users to exchange and transfer resources using these tokens. Resources can take various forms, including physical resources (funds, tickets), virtual or network resources (data traffic, cloud storage space, etc.), and user benefits (e.g., membership duration). A token can be considered an identifier of a resource, indicating its quantity or share. Some DeApps offer multiple different types of tokens. Different types of tokens can indicate the same type of resource or identify different types of resources. Typically, different types of tokens can be converted to each other at a certain "exchange rate."

[0054] Due to the complexity of DeApp functionality, some applications are vulnerable to token disclosure vulnerabilities. Such vulnerabilities refer to situations where untrusted users can perform token disclosure actions that abnormally withdraw / acquire resources from the DeApp in excess of a reasonable amount (e.g., far exceeding the deposited amount) or a reasonable proportion (e.g., far exceeding the normal return ratio).

[0055] Token disclosure vulnerabilities involve many characteristics.

[0056] Figure 2 This diagram illustrates token transfers during an attack on a DeApp. In the diagram, black nodes represent the attacker's and their malicious contract's addresses. Gray nodes represent internal contracts within the DeApp application. Hollow nodes represent addresses outside the attacker and the DeApp application. Edges of varying depths indicate the use of different types of tokens for transfers. As can be seen from the diagram, the transfer paths and flows in the transaction are complex, with only some paths related to the DeApp application and the user.

[0057] As mentioned earlier, some DeApp applications support the deposit, withdrawal, and exchange of various types of tokens, such as... Figure 2 The image shows edges of varying depths. For example, a DeApp might allow users to deposit token A and withdraw token B via token exchange. Furthermore, some DeApps allow users to deposit resources in token form within the app and earn rewards, so it's normal for users to withdraw more resources than they initially deposited. These complexities present challenges for token leakage detection.

[0058] Detecting token leakage vulnerabilities often requires analyzing the root cause of the leak. However, because DeApp applications provide various services based on complex smart contracts, the root causes of token leakage are also complex. Some vulnerabilities are caused by common program weaknesses inherent in the smart contracts themselves, such as integer overflow and reentrancy.

[0059] Besides the weaknesses of smart contracts, some token leakage vulnerabilities are rooted in functional errors. For example, a DeApp uses LP tokens to represent a user's staked share. When a user deposits resources, the DeApp mints or generates LP tokens; when a user withdraws resources, the DeApp destroys LP tokens. LP tokens can be transferred. Figure 3 The code for the LP token transfer function is shown. As shown, an incorrectly implemented transfer function (line 2) leads to a token leakage vulnerability. Assume the variable `_from` (line 3) equals the variable `_to` (line 4). In this case, since the balance `_from` (line 19) will be overwritten by the balance `_to` (line 23), the balance `_to` will eventually be updated to the balance `_to` plus `_value` (line 23), while the user's balance is not reduced. Therefore, an attacker can exploit this vulnerability by first staking resources to obtain X LP tokens, then transferring those X LP tokens to themselves. Thus, the attacker can hold 2X LP tokens and use those 2X LP tokens to extract twice the initial resources from the DeApp application.

[0060] In addition, various other functional errors have also led to token leaks. For example, when a user deposits resources, the DeApp application may not check whether the token has been successfully transferred, or the application may not be able to verify whether the address where the token was deposited is correct. Overall, the various issues leading to token leaks (including smart contract weaknesses and functional errors) pose a significant challenge to protecting DeApp applications from attacks.

[0061] While existing detection tools have demonstrated superior performance in detecting smart contract weaknesses, functional errors are a more common cause of token leakage vulnerabilities. As DeApps become increasingly feature-rich and complex, these functional errors are difficult to systematically resolve, limiting the ability of existing tools to detect token leakage vulnerabilities.

[0062] In view of this, a new vulnerability detection scheme is proposed in the embodiments of this specification. Figure 4 This diagram illustrates a framework of a vulnerability detection scheme according to one embodiment. Figure 4 As shown, this detection scheme consists of three stages: acquiring transaction data from the blockchain on which the DeApp is based, and outputting token leakage vulnerabilities and corresponding attackers. The first stage records the DeApp's execution trajectory by replaying these transactions. The second stage extracts token transfer events and mines the roles (users or applications) of related addresses and the relationships between users, generating a user token flow. The third stage merges the token flows and performs anomaly detection to reveal token leakage vulnerabilities and corresponding attackers.

[0063] The above testing process is described in detail below.

[0064] Figure 5 This diagram illustrates a method for application vulnerability detection according to one embodiment. It is understood that this method targets blockchain-based decentralized applications (DeApps) that support resource exchange and transfer based on several types of tokens. For ease of description, this type of application, which is the target of the analysis, will be referred to as the target application. Figure 5 The process can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities. The executing entity can be a node in the blockchain system, or it can be located outside the blockchain but have the ability to obtain relevant data from the blockchain node.

[0065] like Figure 5 As shown, according to the method flow, firstly in step S51, the transaction execution trajectory involving smart contracts during the execution of the target application is recorded, and a call tree is formed based on the trajectory.

[0066] Specifically, the trace here mainly refers to the transaction execution logs involving smart contracts during the target application's runtime. In particular, an external transaction sent to a smart contract (whose To field points to the smart contract's address) may trigger multiple internal transactions that call other smart contracts. Based on the execution relationships of these transactions, the above trace can be arranged into a Call Flow Tree (CFT), or call tree, as shown below. Figure 6 As shown in part (1).

[0067] As shown in the diagram, there are two types of nodes in a Call Tree CFT: transaction nodes and event nodes. Transaction nodes include outer transactions (e.g., 0) and inner transactions (e.g., 1), where a directed edge between two transaction nodes indicates that a parent transaction triggered an inner transaction as a child transaction. Each transaction node includes the addresses of the caller and callee of the transaction, as well as the data carried by the transaction. This data may include the called function and parameters, the transaction value, and the call type (i.e., call, CALLCODE, DELEGATECALL, STATICALL, and CREATE). Each event node contains the address of the initiator and event data. Directed edges between transaction nodes and event nodes indicate that an event was issued in the transaction. The Call Tree CFT can serve as the basis for subsequent token transfer extraction and other in-depth analysis.

[0068] The recording of the aforementioned execution trajectory can be achieved by modifying the virtual machine (e.g., EVM) deployed in the node for executing smart contracts. Specifically, to extract the execution logs of external transactions, logging code can be inserted into the function used to execute external transactions (in a specific blockchain system, this function is ApplyMessage()). To record the execution of internal transactions, logging code can be inserted into the call handlers of the functions call, CALLCODE, DELEGATECALL, STATICALL, and CREATE, since internal transactions can only be generated through these functions. Through this logging code, the execution of transactions and their triggering relationships can be recorded.

[0069] To log events, logging code can be inserted into the EVM's Log operation. Alternatively, in one embodiment, a call stack can be maintained to identify the corresponding transaction that triggered the event. Specifically, when a call handler is triggered, the corresponding transaction is pushed onto the call stack. When the handler returns, the top transaction of the call stack is popped. Thus, by examining the top of the call stack, it can be determined which transaction an event belongs to.

[0070] By using the above methods, the execution trajectory of transactions is recorded, forming a call tree (CFT).

[0071] Next, in step 52, based on the above call tree, token transfer events are extracted and the roles involved in each transaction are mined to determine the target transfer action that occurred between the user and the target application.

[0072] It's important to understand that detecting token leaks focuses on token transfer behavior between users and the target application. However, as mentioned earlier, target applications typically consist of multiple smart contracts supporting various business functions, making token transfer paths within the application highly complex (e.g., Figure 2 (As shown), this makes extracting token transfers between users and applications challenging.

[0073] For ease of understanding, in this article, the act of a user transferring tokens within the target application is referred to as a deposit action, while the instance where the target application transfers tokens to the user is defined as a withdrawal action. For example, a token exchange may include both deposit and withdrawal actions.

[0074] To extract deposit and withdrawal actions, it is necessary to accurately locate the token transfer between the user and the target application, and identify the exact token transferred by the user. However, the target application has multiple deposit and withdrawal methods, which makes the extraction of these actions difficult.

[0075] Figure 7This illustrates multiple storage modes for the target application in one example. Figure 7 The target application in the example provides at least three storage modes. Figure 7 Part (1) of the example is the most straightforward deposit action, where user A directly calls the proxy contract and transfers the token to that contract. In this case, the exact token transfer is easily traced. However, sometimes token transfers between users and target applications are more complex. Figure 7 In the deposit mode (2), user A invokes the proxy contract, and the token is transferred from user A to the vault contract, which is an internal contract responsible for handling the allocation of resources in the target application. In this case, it is necessary to distinguish this internal contract from other related contracts in the target application in order to perform subsequent extraction actions. Figure 7 In the deposit mode (3) of the application, user A invokes a proxy contract, and tokens are transferred from user B to that proxy contract. This function is similar to direct debit in a payment application. In this case, the invoker—user A—and the depositor (user B) are separate, which means that there is a specific relationship between user A and user B. User A can withdraw tokens or resources from the target application based on deposited resources belonging to user B. Therefore, it is necessary to identify users and discover their relationships when withdrawing deposits (withdrawals) for more accurate analysis.

[0076] In addition to token transfers between users and target applications, there are other token transfers between users or within target applications, which can also interfere with vulnerability detection.

[0077] Considering the various complexities mentioned above, in step 52, the call tree is analyzed. First, token transfer events are extracted, and then the roles involved in each transaction are mined to determine the role relationship information, thereby obtaining the target token transfer that occurs between the user and the target application, thus forming the token flow.

[0078] Figure 8 The process of determining the token flow based on the call tree is shown, which is a sub-step of step 52.

[0079] like Figure 8 As shown, in step S521, token transfer events are first extracted from the above call tree to obtain alternative transfer actions.

[0080] To extract token transfer information related to the aforementioned target transfer actions, irrelevant subtrees can be excluded from the complete call tree, retaining only the relevant target subtrees. The root node of the target subtree is the transaction (external transaction) of the proxy contract that calls the target application. Then, alternative transfer actions can be determined by traversing the target subtree.

[0081] Specifically, the target subtree related to the transfer of the target token is first identified. To avoid interference and improve extraction efficiency, in one embodiment, only the subtree of the proxy contract calling the target application is retained, while irrelevant subtrees are pruned. For example... Figure 6 As shown in section (2), assuming transaction 2 is an external transaction that calls the proxy contract, then irrelevant subtrees 1 and 3 can be pruned, retaining the relevant target subtree 2. In the illustration, the target subtree retains the initial root node 0 to align with the original diagram for clarity. Furthermore, it should be noted that although only one target subtree is shown in the diagram, there may actually be multiple relevant target subtrees in the entire call tree CFT, and these target subtrees will be retained for subsequent analysis.

[0082] After pruning irrelevant subtrees, token transfer events can be extracted from the remaining target subtrees to obtain alternative transfer actions. Here, the alternative transfer actions need to be determined based on the type of token provided by the target application, the standards / specifications that the token meets, or its characteristics.

[0083] For example, in one scenario, the target application provides Type I and Type II tokens. For Type I token transfers, the Type I token standard can be used to identify all events related to the transfer, and these event nodes are replaced with token transfer nodes that record the details of the transfer (e.g., "Address A transfers X units of Y tokens to Address B"). Assume that Type II tokens are tokens that can be directly transferred between users via external transactions. For Type II token transfers, token transfer information can be retrieved from the transactions in the target subtree, and a new token transfer node is inserted into the corresponding transaction node. Next, the token transfer node is promoted to a child node of the transaction node that invoked the proxy contract. For example, in... Figure 6 In part (3), event nodes 7 and 8 involving Type I token transfers are replaced with token transfer nodes 7 and 8 (shown as black circles in the diagram), and they are promoted to child nodes of transaction node 2. In addition, a node 9 involving Type II token transfers is inserted. The token transfer actions corresponding to these token transfer nodes are all considered as alternative transfer actions.

[0084] In step S522, role mining is performed, that is, the role of each address involved in the aforementioned call tree is determined. Roles include user roles representing users and application roles representing target applications.

[0085] According to one implementation, role mining is heuristically performed by parsing the call flow in the call tree. Specifically, the initiator of an external transaction is set as a user role, and the proxy contract is set as an application role. When an internal transaction is triggered, if the callee is not marked with any role, the caller's role is assigned to the callee; that is, the callee is marked with the same role as the caller. For example, initially, the caller of transaction 0 is a user role, and transaction 2 calls the proxy contract, so the callee of transaction 2 is an application role. Through role passing, the callees of transactions 0, 1, and 3 are assigned user roles, and the callees of transactions 5 and 6 are assigned application roles.

[0086] Furthermore, further analysis can be performed to fine-tune and refine the roles of addresses. Specifically, if a token transfer at a given address is associated with many addresses in historical transactions, we consider that address as an application role. If a user role invokes a proxy contract through a transaction, the relevant parameters in the transaction's data field can be parsed. If the specific address 'add' in the address type parameter is not tagged with a role, then that address 'add' is tagged as a user role. In this way, the roles of each address in the CFT can be obtained, serving as the basis for subsequent analysis.

[0087] It's important to note that trusted addresses (e.g., the creator of the proxy contract) need to be excluded from the user group to avoid interference from privileged addresses. Specifically, the creator of the proxy contract can be set as a trusted address. When a trusted address invokes the proxy contract, the address type parameter in the transaction is treated as a trusted address, not a user role.

[0088] Next, in step S523, user relationships are mined using information from a preset type of token and the aforementioned role information.

[0089] As mentioned earlier, some DeApp applications allow users to extract resources based on tokens deposited by other users. This step is designed for such applications and is optional.

[0090] Specifically, some DeApps offer Type III tokens to record a user's staked amount. When a user deposits a token, the application mints or generates this Type III token; when a user withdraws a token, the application destroys it. In some specific applications, Type III tokens are specifically called LP tokens. The creation / destruction of LP tokens can be represented as a token transfer from / to a specific address (e.g., address 0x0). Figure 6As shown in section (4), assuming token transfer event 7 involves LP tokens, token transfer node 7 can be converted into an LM node to represent the minting of LP tokens. However, the use of LP tokens introduces new detection barriers because users can transfer their staked shares to others. For example, according to Figure 7 In pattern (3), user B deposits resources into the target application, resulting in the minting of LP tokens for user A. User A can then extract the resources by destroying the LP tokens. In this case, without information about the relationship between user A and user B, it is possible to mistakenly attribute the token leak to user A. Furthermore, some DeApp applications achieve this functionality by maintaining a world state store, making detection and analysis more complex.

[0091] Therefore, in one embodiment, LP token information and user role information are used to establish relationships between users for more accurate detection. Based on LP tokens, the minting of LP tokens in the subtree associated with deposit (withdrawal) actions can be used to determine relationships between users. For example, if user A invokes a proxy contract to transfer tokens to the target application, and LP tokens are minted for user B, a relationship can be established and recorded between user A and user B. Furthermore, since LP tokens can be transferred between users, LP token transfers can be collected to establish relationships between users. For example, if user A transfers LP tokens to user B, the relationship between user A and user B can be recorded. Additionally, based on mined user roles, relationships between the caller of the proxy contract and the user who transfers (or receives) tokens to the target application can be recorded. For example, in... Figure 7 In pattern (3), the relationship between the caller (user A) and user B can be recorded.

[0092] In one example, the mined user relationships can be represented as follows:

[0093] rel={(userA,userB,blocki,txj)

[0094] This means that user A established a pre-defined relationship with user B through transaction txj in block i.

[0095] Furthermore, in step S524, based on the roles of the aforementioned addresses, the target transfer action between the user and the target application is determined from the candidate transfer actions.

[0096] Specifically, by determining the roles of each address in the call tree, the target transfer action occurring between the user and the target application can be accurately identified, and a token flow can be generated accordingly, for example... Figure 6(4) Token transfer node 8 corresponds to the target transfer action, which is used to form the token flow. It can be understood that there may be multiple target token transfers in the relevant target subtree. For each specific target token transfer, a tuple can be generated to represent the token sender's (deposit or withdrawal) action. This tuple can be represented as:

[0097] action=(block,tx,amount,token,type) (1)

[0098] Where "block" is the block height of the transaction that triggered the user's action, "tx" is the transaction's position within the block, "amount" is the number of tokens, "token" is the type of token being transferred, and "type" is the action type (deposit or withdrawal). A series of these actions can constitute a token flow.

[0099] By grouping each action according to the user, we can obtain the token flow corresponding to each user.

[0100] Back Figure 5 Based on the information obtained in step S52, vulnerability detection step S53 can be executed, in which the token flows for each type of token are merged, the cumulative inflow and cumulative outflow are determined based on the merged token flows, and the existence of a token leakage vulnerability is determined based on the cumulative inflow and cumulative outflow.

[0101] It's important to understand that some DeApps support multiple tokens, which can potentially interfere with the calculation of return rates. For example, a user might deposit token A but withdraw token B, making direct comparisons of token quantities impossible. Therefore, in this embodiment, different types of token streams are merged to calculate the correct return rate.

[0102] However, in some blockchain systems and DeApps, the values ​​of various token types differ significantly, and the amount of resources they represent changes over time. Therefore, in one embodiment, a method is proposed to unify token values. Specifically, a special unified unit of value, such as WETH, can be defined or used to calculate token values. To this end, a conversion table, also known as an "exchange rate table," is pre-constructed based on certain standards between WETH and other tokens. Based on the exchange rate table, the values ​​of other tokens can be calculated using WETH, and token flows from different tokens can be merged into a single flow. In this way, a merged token flow can be obtained for subsequent testing. In particular, if a token flow contains only one token, it can be directly considered a merged flow without converting it to WETH.

[0103] Based on the merged token flow, a return rate can be calculated, and token leakage can be detected by detecting abnormal return rates. Specifically, the return rate can be defined as the ratio of the cumulative amount transferred out to the cumulative amount deposited for the token-related resources. In one example, the cumulative deposits (Deposits), cumulative withdrawals (Withdrawls), and return rate (rate) are defined as follows:

[0104] Deposits=∑action.amount type=deposit

[0105] Withdrawls=∑action.amount type=withdrawal

[0106]

[0107] As can be seen, the cumulative deposit amount is the sum of the amounts involved in each deposit action (which may involve "exchange rate" conversion), the cumulative withdrawal amount is the sum of the amounts involved in each withdrawal action, and each deposit / withdrawal action is, for example, the target token transfer action recorded by the tuple in equation (1).

[0108] For each user, their merged token stream can be traversed, and the corresponding return rate can be calculated at each operation. For each operation in the token stream, related users can be recursively searched first and grouped together. Then, the cumulative deposits (Deposits) and cumulative withdrawals (Withdrawls) of all users in that group before the operation are calculated, and the return rate is further calculated based on this.

[0109] The calculated return rate is divided into three cases: 1) The return rate is less than or equal to 1, which is normal and can be ignored for vulnerability detection; 2) The return rate is infinity (∞), which can be directly reported as a token leak because the user withdrew the token but did not deposit it; 3) The return rate is not ∞ but greater than 1, which needs to be collected to further determine whether the return rate is abnormal.

[0110] Specifically, a threshold can be set, for example, T = 5. Return rates below this threshold T are included, and their average (ave) and standard deviation (std) are calculated. Then, a standard return rate is determined based on this average and standard deviation. For example, this standard return rate can be set as rate = ave + 5 * std. Therefore, if the actual return rate is greater than this standard return rate (rate), token leakage can be considered identified. In this way, anomalies caused by attackers can be effectively detected.

[0111] When the above-mentioned token leakage is detected, the user who issued the corresponding action will be identified as an attacker, and the detection results will be reported.

[0112] Reviewing the above process, it can be seen that the solution in the embodiments of this specification is not limited to specific functions of a particular application, but rather detects token leakage vulnerabilities by tracing the transaction execution process to locate the token transfer that occurs between the user and the application. This solution is applicable to a variety of DeApp applications and provides more accurate detection results.

[0113] According to another embodiment, an apparatus for vulnerability detection of a target application is provided, the target application being a blockchain-based decentralized application that supports resource exchange and transfer based on several types of tokens. Figure 9 The diagram illustrates the structure of a detection device according to one embodiment. This device can be deployed in any device, platform, or device cluster with data storage, computing, and processing capabilities. Specifically, the detection device can be deployed within a node of a blockchain system, or it can be deployed in a device outside the blockchain, but it has the ability to obtain relevant data from the blockchain node. Figure 9 As shown, the detection device 900 includes:

[0114] The recording unit 910 is configured to record the transaction execution trajectory of smart contracts involved in the execution of the target application, forming a call tree. The call tree includes transaction nodes and event nodes. The directed edges between transaction nodes indicate that a parent transaction triggers a child transaction. The directed edges between a transaction node and an event node indicate that the event is emitted through the transaction.

[0115] Extraction unit 920 is configured to extract token transfer events and mine the roles involved in each transaction based on the call tree, thereby determining the target transfer actions that occur between the user and the target application, and each target transfer action forms a token flow; wherein the roles include user roles representing the user and application roles representing the target application.

[0116] The detection unit 930 is configured to merge the token streams for each type of token, determine the cumulative inflow and cumulative outflow based on the merged token streams, and determine whether there is a token leakage vulnerability based on the cumulative inflow and cumulative outflow.

[0117] The implementation methods of each unit in the above device can be referred to the previous examples. Figure 5 The above device can accurately and effectively detect token disclosure vulnerabilities in target applications.

[0118] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figure 5 The method described.

[0119] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figure 5 The method described.

[0120] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0121] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for vulnerability detection of a target application, wherein the target application is a blockchain-based decentralized application that supports resource exchange and transfer based on several types of tokens; the method includes: The execution trajectory of smart contracts involved in the execution of the target application is recorded to form a call tree, which includes transaction nodes and event nodes; the directed edges between transaction nodes indicate that a parent transaction triggers a child transaction; the directed edges between a transaction node and an event node indicate that the event is emitted through the transaction. Based on the call tree, token transfer events are extracted and the roles involved in each transaction are identified, thereby determining the target transfer actions that occur between the user and the target application, and each target transfer action forms a token flow; The roles mentioned include user roles representing users and application roles representing the target application; The token flows for each type of token will be merged, and the cumulative inflow and outflow will be determined based on the merged token flows. Based on the cumulative inflow and outflow, it will be determined whether there is a token leakage vulnerability.

2. The method according to claim 1, wherein, The recording of the transaction execution trajectory is achieved by modifying the virtual machine deployed in the blockchain node for executing smart contracts.

3. The method of claim 2, wherein the modification of the virtual machine includes at least one of the following: Insert logging code into the function used to execute external transactions to record the external transactions; Insert logging code into the call handler of the target function that generates the internal transaction to record the internal transaction; Insert logging code into the virtual machine's Log operation to record events.

4. The method according to claim 1, wherein, Based on the call tree, token transfer events are extracted and the roles involved in each transaction are identified to determine the target transfer actions occurring between the user and the target application, including: Extract the target subtree from the call tree, traverse the target subtree, and determine the action corresponding to the token transfer event as the candidate transfer action; wherein, the root node of the target subtree is the transaction node that calls the proxy contract; the proxy contract is an external contract that the user can directly call in the target application; The preset roles are passed along the call tree to determine the roles of each address involved in the call tree; Based on the roles of each address, the target transfer action between the user and the target application is determined from the candidate transfer actions.

5. The method according to claim 4, wherein, The several types of tokens include a first type of token, which has a first token standard; traversing the target subtree, determining the actions corresponding to the token transfer event as candidate transfer actions, including: Using the first token standard, identify the first event related to the transfer of the first type of token from the target subtree, replace the event node corresponding to the first event with the token transfer node, and classify the action corresponding to the node into the candidate transfer action.

6. The method according to claim 4, wherein, The aforementioned types of tokens include a second type of token, which is a token that can be directly transferred between users through external transactions; traversing the target subtree, determining the actions corresponding to the token transfer event as candidate transfer actions, including: Token transfer information is retrieved from the first transaction of the target subtree. A token transfer node is inserted into the transaction node corresponding to the first transaction, and the action corresponding to the node is included in the candidate token transfer action.

7. The method according to claim 4, wherein, The preset roles are passed along the call tree to determine the roles of each address involved in the call tree, including: The initiator of the external transaction is set as a user role, and the proxy contract is set as an application role. Roles are passed along the call tree in a predetermined manner. The role passing includes, for internal transactions, assigning the caller's role to the callee if the callee is not marked with a role.

8. The method according to claim 1, wherein, The target transfer action record is a data tuple, which includes the block height of the transaction that triggered the action, the position of the transaction in the block, the number of tokens transferred, the type of tokens transferred, and the action type; the action type is selected from deposit action or withdrawal action.

9. The method according to claim 1, further comprising: By utilizing information about preset type tokens and the roles involved in each transaction, preset relationships between users can be identified. The process of merging the token flows for each type of token, and determining the cumulative inflow and cumulative outflow based on the merged token flows, includes: Merge the token streams of a single user to obtain the merged token stream of that user; At a single operation in the merged token flow, search for related users who have the preset relationship with the user, group them together, and calculate the cumulative deposits and withdrawals of all users in the group.

10. The method according to claim 9, wherein, The preset type token is used to record the user's staked share, and when the user performs a deposit / withdrawal operation, the target application mints / destroys the preset type token; the mining of preset relationships between users includes one or more of the following: In response to a first user invoking a proxy contract, the preset type token is transferred to the target application, and the preset type token is minted for a second user, recording that the first user and the second user have the preset relationship; In response to a third user transferring the preset type token to a fourth user, the system records that the third user and the fourth user have the preset relationship.

11. The method according to claim 1, wherein, Several types of tokens are combined into multiple types of tokens; the token flows for each type of token will be merged, including: Based on a pre-built conversion table, all types of tokens are converted into a preset unified value unit, and the token flows of different tokens are merged into a single flow based on this unified value unit.

12. The method according to claim 1, wherein, Based on the cumulative inflow and outflow, determine whether a token disclosure vulnerability exists, including: At each action, the actual return rate corresponding to that action is calculated based on the ratio of the cumulative outflow to the cumulative inflow before the action was executed. From the actual return rates corresponding to multiple actions of multiple users, determine multiple return rates that are less than a preset threshold T, calculate the average and standard deviation of these multiple return rates, and determine the standard return rate based on the average and standard deviation. Actions where the actual return rate is greater than the standard return rate are identified as abnormal actions that lead to token leakage.

13. An apparatus for vulnerability detection of a target application, wherein the target application is a blockchain-based decentralized application that supports resource exchange and transfer based on several types of tokens; the apparatus comprises: The recording unit is configured to record the transaction execution trajectory of smart contracts involved in the execution of the target application, forming a call tree. The call tree includes transaction nodes and event nodes. The directed edges between transaction nodes indicate that a parent transaction triggers a child transaction. The directed edges between a transaction node and an event node indicate that the event is emitted through the transaction. The extraction unit is configured to extract token transfer events and mine the roles involved in each transaction based on the call tree, thereby determining the target transfer actions that occur between the user and the target application, and each target transfer action forms a token flow; The roles mentioned include user roles representing users and application roles representing the target application; The detection unit is configured to merge the token flows for each type of token, determine the cumulative inflow and cumulative outflow based on the merged token flows, and determine whether there is a token leakage vulnerability based on the cumulative inflow and cumulative outflow.

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

15. A computing device, comprising a memory and a processor, characterized in that, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-12.

Images