Vulnerability detection method and device, computer device and readable storage medium

Abstract

The embodiment of the application provides a vulnerability detection method and device, computer equipment and a readable storage medium, and belongs to the technical field of blockchains. A to-be-detected source code of a to-be-detected smart contract is acquired; an abstract syntax tree corresponding to the to-be-detected source code is obtained by analyzing the syntax structure of the to-be-detected source code; a control flow graph of the to-be-detected smart contract is acquired, and the completion of the calling relationship of the control flow graph is performed according to the abstract syntax tree, so that a cross-contract control flow graph is obtained; a global state dependency graph is constructed based on the dependency relationship of each statement node in the cross-contract control flow graph; and vulnerability stain analysis is performed on the to-be-detected smart contract based on the global state dependency graph, so that a vulnerability detection result of the to-be-detected smart contract is obtained. In this way, the comprehensiveness and accuracy of vulnerability detection can be improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a vulnerability detection method, apparatus, computer device, and readable storage medium. Background Technology

[0002] A smart contract is a decentralized, event-driven, distributed execution and verification program that consists of a set of code (contract functions) and data (contract state) and runs on a blockchain. As business scenarios on the blockchain become increasingly diverse, contract logic also becomes more complex, potentially leading to reentrancy attacks, integer overflow vulnerabilities, denial-of-service attacks, and timestamp dependency vulnerabilities in smart contracts.

[0003] Therefore, in order to ensure data security, prevent malicious attacks, and improve the reliability of contracts, it is necessary to detect vulnerabilities in smart contracts.

[0004] In related technologies, intermediate language or pattern matching is usually used to detect vulnerabilities in smart contracts. Although the detection speed is relatively fast, actual attacks often involve complex contract code logic and semantics. Relying solely on pattern matching to detect vulnerabilities will lead to incomplete and inaccurate detection. Summary of the Invention

[0005] The main objective of this application is to provide a vulnerability detection method, apparatus, computer device, and readable storage medium that can improve the comprehensiveness and accuracy of vulnerability detection.

[0006] To achieve the above objectives, a first aspect of this application proposes a vulnerability detection method, the method comprising:

[0007] Obtain the source code of the smart contract to be tested;

[0008] The syntax structure of the source code under test is parsed to obtain the abstract syntax tree corresponding to the source code under test.

[0009] Obtain the control flow graph of the smart contract under test, and complete the call relationship of the control flow graph according to the abstract syntax tree to obtain the cross-contract control flow graph;

[0010] Based on the dependency relationships of each statement node in the cross-contract control flow graph, a global state dependency graph is constructed.

[0011] Based on the global state dependency graph, vulnerability and taint analysis is performed on the smart contract under test to obtain the vulnerability detection results of the smart contract under test.

[0012] Accordingly, a second aspect of this application provides a vulnerability detection device, the device comprising:

[0013] The acquisition module is used to acquire the source code of the smart contract to be tested.

[0014] The parsing module is used to parse the syntax structure of the source code under test and obtain the abstract syntax tree corresponding to the source code under test.

[0015] The completion module is used to obtain the control flow graph of the smart contract under test, and complete the call relationship of the control flow graph according to the abstract syntax tree to obtain a cross-contract control flow graph.

[0016] The construction module is used to construct a global state dependency graph based on the dependency relationships of each statement node in the cross-contract control flow graph;

[0017] The analysis module is used to perform vulnerability and taint analysis on the smart contract under test based on the global state dependency graph, and obtain the vulnerability detection results of the smart contract under test.

[0018] In some implementations, the analysis module is further configured to:

[0019] Based on the global state dependency graph, determine at least one vulnerability feature of the smart contract under test;

[0020] For each of the aforementioned vulnerability characteristics, a corresponding taint analysis rule is matched, and multiple key code nodes are extracted from the global state dependency graph based on the taint analysis rule;

[0021] Based on the aforementioned multiple key code nodes, vulnerability analysis is performed to obtain the vulnerability detection results of the smart contract under test.

[0022] In some implementations, the analysis module is further configured to:

[0023] Based on the taint analysis rules, the taint sources and taint aggregation points corresponding to the vulnerability characteristics are determined from the global state dependency graph.

[0024] Based on the taint source and the taint aggregation point, the propagation path of taint information is determined from the global state dependency graph;

[0025] Extract multiple key code nodes corresponding to the propagation path.

[0026] In some implementations, the analysis module is further configured to:

[0027] The analysis results are obtained by analyzing the statement sequence and variable assignments of each key code node.

[0028] Obtain preset vulnerability conditions, and perform vulnerability detection on the analysis results of each key code node according to the preset vulnerability conditions to obtain the vulnerability detection results of the smart contract under test.

[0029] In some implementations, the completion module is further used for:

[0030] Based on the abstract syntax tree, the target node in the source code under test that contains cross-contract calls is determined, and the target node is marked.

[0031] Based on the marked target node, determine the first smart contract invoked across contracts by the target node;

[0032] Obtain the first control flow graph of the first smart contract, and connect the target nodes with the control flow graph of the first control flow graph and the control flow graph of the smart contract under test to obtain a cross-contract control flow graph.

[0033] In some embodiments, the vulnerability detection device further includes an update module for:

[0034] Based on the abstract syntax tree, determine the function names and variable names of each statement node in the cross-contract control flow diagram;

[0035] Inject the function name and the variable name into the cross-contract control flow graph to obtain the updated cross-contract control flow graph.

[0036] In some implementations, the dependencies include data dependencies and control dependencies; the building module is further configured to:

[0037] Based on the cross-contract control flow graph, data flow detection is performed on each statement node to obtain the detection results;

[0038] When the detection result indicates that any two of the statement nodes have the data dependency relationship, the data dependency relationship is marked in the cross-contract control flow graph to obtain a global state dependency graph; or, when the detection result indicates that any two of the statement nodes have the control dependency relationship, the control dependency relationship is marked in the cross-contract control flow graph to obtain a global state dependency graph.

[0039] Accordingly, a third aspect of the present application provides a computer device, the computer device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the vulnerability detection method described in any one of the embodiments of the first aspect of the present application.

[0040] Accordingly, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the vulnerability detection method described in any one of the embodiments of the first aspect of the present application.

[0041] This application embodiment obtains the source code of the smart contract under test; parses the syntax structure of the source code to obtain the corresponding abstract syntax tree; obtains the control flow graph of the smart contract under test, and completes the call relationships of the control flow graph according to the abstract syntax tree to obtain a cross-contract control flow graph; constructs a global state dependency graph based on the dependency relationships of each statement node in the cross-contract control flow graph; and performs vulnerability and taint analysis on the smart contract under test based on the global state dependency graph to obtain the vulnerability detection results of the smart contract under test. In this way, the call relationships of the smart contract under test can be completed, that is, the cross-contract relationships can be completed, taking into account the collaborative effects between multiple smart contracts, thereby achieving a more comprehensive and accurate analysis of the smart contract under test. Furthermore, by considering the dependency relationships of each statement node, the propagation of vulnerabilities and taints in the contract can be analyzed, further improving the comprehensiveness and accuracy of the detection of the smart contract under test. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the architecture of the vulnerability detection system provided in the embodiments of this application;

[0043] Figure 2 This is a flowchart of the vulnerability detection method provided in the embodiments of this application;

[0044] Figure 3 This is a flowchart of generating a cross-contract control flow graph provided in an embodiment of this application;

[0045] Figure 4 This is a flowchart of generating a global state dependency graph provided in an embodiment of this application;

[0046] Figure 5 This is a flowchart of vulnerability detection based on matching corresponding taint analysis rules according to vulnerability characteristics, provided in an embodiment of this application.

[0047] Figure 6 This is a general flowchart of the vulnerability detection method provided in the embodiments of this application;

[0048] Figure 7 This is a schematic diagram of the functional modules of the vulnerability detection device provided in the embodiments of this application;

[0049] Figure 8 This is a schematic diagram of the hardware structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0052] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0053] A smart contract is a decentralized, event-driven, distributed execution and verification program that consists of a set of code (contract functions) and data (contract state) and runs on a blockchain. As business scenarios on the blockchain become increasingly diverse, contract logic also becomes more complex, potentially leading to reentrancy attacks, integer overflow vulnerabilities, denial-of-service attacks, and timestamp dependency vulnerabilities in smart contracts.

[0054] Therefore, in order to ensure data security, prevent malicious attacks, and improve the reliability of contracts, it is necessary to detect vulnerabilities in smart contracts.

[0055] In related technologies, intermediate language or pattern matching is usually used to detect vulnerabilities in smart contracts. Although the detection speed is relatively fast, actual attacks often involve complex contract code logic and semantics. Relying solely on pattern matching to detect vulnerabilities will lead to incomplete and inaccurate detection.

[0056] Based on this, embodiments of this application provide a vulnerability detection method, apparatus, computer device, and readable storage medium, which can improve the comprehensiveness and accuracy of vulnerability detection.

[0057] The vulnerability detection method, apparatus, computer equipment, and readable storage medium provided in this application are specifically described through the following embodiments. First, the vulnerability detection system in the embodiments of this application is described.

[0058] Please refer to Figure 1 In some implementations, embodiments of this application provide a vulnerability detection system. Specifically, the vulnerability detection system includes a client 11 and a server 12.

[0059] For example, client 11 can be a personal computer, mobile device, or dedicated testing device with adequate processing power, memory, and storage space. Client 11 can provide a user-friendly interface that allows users to input or upload the source code of the smart contract to be tested. Furthermore, client 11 can perform preliminary parsing of the smart contract source code, such as syntax checking, to ensure the basic parsability and integrity of the source code, and encrypt and securely transmit the processed data (such as the source code) to server 12.

[0060] Specifically, server 12 can be configured as a high-performance server cluster, including multi-core processors and high-speed storage systems, to support data-intensive processing tasks. Server 12 can also be a cloud server or a dedicated security testing server. Server 12 can perform in-depth syntactic structure parsing on the smart contract source code sent by client 11, generate an abstract syntax tree, and based on the abstract syntax tree, generate and improve the control flow graph of the smart contract, including cross-contract control flow graphs. Furthermore, server 12 can use the control flow graph to construct a global state dependency graph, perform taint analysis based on these graphs, and identify potential security vulnerabilities. The vulnerability detection results are then processed and fed back to client 11, which may also include detailed vulnerability information and remediation suggestions.

[0061] The vulnerability detection method in this application can be illustrated through the following embodiments.

[0062] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user will be obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent will the necessary user-related data for the normal operation of the embodiments of this application be obtained.

[0063] In this embodiment, the description will focus on the vulnerability detection device, which can be integrated into a computer device. See also... Figure 2 , Figure 2 This is a flowchart illustrating the steps of a vulnerability detection method provided in this application embodiment. Taking the vulnerability detection device specifically integrated into a terminal or server as an example, the specific process when the processor on the terminal or server executes the program instructions corresponding to the vulnerability detection method is as follows:

[0064] Step 101: Obtain the source code of the smart contract to be tested.

[0065] In some implementations, since smart contracts often involve data interaction or other important business logic, vulnerabilities in the smart contract code may lead to financial losses, data leaks, or other security issues. Therefore, in order to ensure the secure, reliable, and efficient operation of smart contracts, the source code of the smart contract under test can be obtained to facilitate subsequent vulnerability detection of the smart contract.

[0066] The smart contract to be tested can be either not yet deployed on the blockchain, or it can be deployed but require periodic security checks. Smart contracts can be written in high-level programming languages ​​and contain a set of rules and conditions that are automatically executed on the blockchain when specific conditions are met.

[0067] The source code to be tested is called the source code, which can be the original code that encodes the smart contract to be tested, defining all the logic and functions of the smart contract to be tested.

[0068] For example, the source code of the smart contract to be tested can be obtained from blockchain explorers, code repositories, smart contract deployment tools, and other channels.

[0069] By using the above methods, the source code of the smart contract under test can be obtained, which will facilitate subsequent analysis of the syntax structure of the source code and thus enable vulnerability detection of the smart contract under test.

[0070] Step 102: Parse the syntax structure of the source code to be tested to obtain the abstract syntax tree corresponding to the source code to be tested.

[0071] In some implementations, in order to better understand the logic of the smart contract under test and discover and fix potential vulnerabilities, the syntax structure of the source code under test can be parsed to generate an abstract syntax tree that retains the syntax structure information of the source code under test, thereby facilitating subsequent code analysis.

[0072] An Abstract Syntax Tree (AST) is a tree-like data structure used to represent the abstract syntax structure of the source code of a smart contract under test. It is easier to analyze and process than the source code itself. Each node in the AST represents a construct in the source code, such as a function declaration, variable declaration, or expression. Each node can also include related metadata to improve the readability of the AST and facilitate subsequent analysis.

[0073] For example, a compiler can perform lexical analysis, decomposing the source code under test into a series of lexical units. A lexical unit is the smallest identifiable part of the source code under test, such as keywords, identifiers, and literals. After lexical analysis, the compiler enters the syntax analysis phase. In the syntax analysis phase, the compiler confirms whether the syntax structure of the source code under test conforms to the language rules and generates corresponding AST nodes. The compiler continuously creates nodes during the syntax analysis process and organizes these nodes into a tree structure.

[0074] Understandably, each node can be used to represent a syntactic construct in the source code under test. For example, an if statement will generate an abstract syntax tree node containing a conditional expression and a then clause.

[0075] Furthermore, in addition to the structural information of the source code under test, extra metadata can be added to the abstract syntax tree (AST) to capture more syntax, data, and control information. The metadata added to the nodes of the AST can provide richer contextual information and enhance code readability and maintainability, facilitating subsequent analysis of call relationships.

[0076] By generating an abstract syntax tree (AST), the syntax structure of the source code under test can be represented in a tree structure. This allows for analysis and preservation of complete syntax structure information without needing the source code itself, making the analysis more accurate. Furthermore, metadata from the source code can be inserted to improve readability. This can aid in subsequent recovery of program dependencies between smart contracts and the location of source code vulnerabilities.

[0077] Step 103: Obtain the control flow graph of the smart contract under test, and complete the call relationship of the control flow graph according to the abstract syntax tree to obtain the cross-contract control flow graph.

[0078] In some implementations, to avoid situations where the control flow graph only focuses on the call relationships between functions and lacks support for cross-contract call semantics in complex contracts, a cross-contract control flow graph can be generated based on the abstract syntax tree and the control flow graph to complete the call relationships between cross contracts, thereby achieving more comprehensive cross-contract vulnerability detection and verification.

[0079] Among them, the control flow graph is used to represent the graph structure of the smart contract execution process, which can show the execution path, branch conditions, loop structure and other control information of the smart contract under test.

[0080] Among them, the cross-contract control flow graph is an extension of the control flow graph. The cross-contract control flow graph can be obtained by using the abstract syntax tree of smart contracts to complete the cross-contract call relationship of the control flow graph. It can show the call relationship between contracts and realize more comprehensive cross-contract vulnerability detection and verification.

[0081] For example, by analyzing the abstract syntax tree, a control flow graph within each smart contract can be constructed, and cross-contract call points can be identified. By identifying cross-contract call points and connecting cross-contract call points with call relationships using edges, a cross-contract control flow graph can be obtained. The cross-contract control flow graph, by capturing the semantic information of cross-contract calls, provides a foundation for analyses such as cross-contract vulnerability detection and global verification.

[0082] Furthermore, relevant source code information can be recovered from the abstract syntax tree, and metadata such as function names and variable names can be injected into the cross-contract control flow graph for improvement, so as to more accurately understand the execution process of smart contracts and improve the readability of smart contracts.

[0083] By using the abstract syntax tree of the smart contract under test to complete the call relationship in the control flow graph, the semantic information of cross-contract calls can be captured, and the call relationship between contracts can be displayed, thereby achieving more comprehensive cross-contract vulnerability detection and verification.

[0084] In some implementations, to accurately identify potential security vulnerabilities, a first smart contract with a calling relationship to the smart contract under test can be identified to detect potential data leakage, tampering, or inconsistency issues. For example, step 103, "completing the calling relationship of the control flow graph based on the abstract syntax tree to obtain a cross-contract control flow graph," may include:

[0085] (103.1) Based on the abstract syntax tree, identify the target nodes in the source code under test that have cross-contract calls, and mark the target nodes;

[0086] (103.2) Based on the marked target node, determine the first smart contract that the target node calls across contracts;

[0087] (103.3) Obtain the first control flow graph of the first smart contract, and connect the target nodes with the control flow graph of the smart contract under test according to the first control flow graph to obtain the cross-contract control flow graph.

[0088] In this context, the target node can be a specific node in the cross-contract control flow graph used to execute cross-contract calls. The target node can be represented in the abstract syntax tree as a specific code element, such as a function call or jump instruction. It is a key point for interaction between the smart contract and external contracts, and the target node can be accurately identified by combining it with the abstract syntax tree.

[0089] The first smart contract can be another smart contract that has cross-contract interactions with the smart contract under test.

[0090] For example, please refer to Figure 3In the process of generating a cross-contract control flow graph, the abstract syntax tree (AST) can be used to locate the target nodes involved in cross-contract calls. For example, if the smart contract under test is smart contract A, by analyzing the AST, the cross-contract call node for the valueStore function in smart contract A can be identified and marked as the target node for further analysis and processing.

[0091] Furthermore, based on the marked target node, the first smart contract called across contracts by the target node can be identified, and the first control flow graph of the first smart contract can be obtained, thus obtaining control flow information such as the execution path, branch conditions, and loop structure of the first smart contract.

[0092] Furthermore, the target node can be used as a control transfer point. Centered on the control flow graph of the smart contract under test, the corresponding functions of other smart contracts that have a calling relationship with the target node are connected through the target node to form a cross-contract control flow graph.

[0093] Furthermore, relevant source code information can be recovered based on the abstract syntax tree, and metadata such as function names and variable names can be injected into the cross-contract control flow graph to form a more complete and interpretable cross-contract control flow graph.

[0094] In some implementations, cross-contract control flow graphs can serve as a foundation for combining with other analytical techniques to achieve more comprehensive cross-contract vulnerability detection and verification. For example, cross-contract control flow graphs can be combined with analytical techniques such as symbolic execution and fuzzing.

[0095] Taking symbolic execution as an example, symbolic values ​​can be assigned to all input variables at the entry point of the cross-contract control flow graph. Based on the control flow of the cross-contract control flow graph, corresponding path conditions are generated for each control path. The symbolic values ​​are then used to traverse the cross-contract control flow graph to evaluate whether each path condition is satisfied, thereby detecting vulnerabilities in smart contracts. By combining symbolic execution with the cross-contract control flow graph, symbolic execution can track data flow and control flow transfers in cross-contract calls, achieving more accurate path exploration and vulnerability detection.

[0096] Using the above methods, the call relationships in the control flow graph can be completed through the abstract syntax tree. This allows for the accurate identification of the target node in the cross-contract call within the smart contract under test, and the determination of the first smart contract with which it has a call relationship. In this way, a cross-contract control flow graph can be generated for further analysis.

[0097] Step 104: Construct a global state dependency graph based on the dependency relationships of each statement node in the cross-contract control flow graph.

[0098] In some implementations, in order to gain a more comprehensive and accurate understanding of the execution flow of the smart contract under test, global control flow analysis can be performed based on the control dependencies between statements in the cross-contract control flow diagram to detect cross-contract vulnerabilities and verify the logical integrity of the contract.

[0099] Statement nodes can be the basic units of cross-contract control flow graphs. Each statement node corresponds to an executable basic operation in the contract code, such as assignment, condition judgment, loop start or end, etc. Statement nodes can be used to reflect the key steps and control transfers in the execution process of the smart contract under test.

[0100] The Inter-contract State Dependency Graph (I-SDG) can be a graph structure used to represent the dependencies between different statement nodes during the execution of a smart contract. Dependencies include data dependencies and control dependencies. Data dependencies refer to the value of one variable depending on the value of another variable, while control dependencies refer to the order of program execution depending on the execution results of certain statements.

[0101] Understandably, a global state dependency graph can be generated by analyzing the dependency relationships between statement nodes in the cross-contract control flow graph of a smart contract, thereby detecting potential vulnerabilities in the contract, such as data inconsistency and control flow errors. At the same time, it can also be used to comprehensively verify the contract logic based on dependency relationships.

[0102] Please refer to Figure 4 For example, each statement node (also called a basic block) in the cross-contract control flow graph can be traversed, the control dependencies and data dependencies between statement nodes can be analyzed, and these dependencies can be recorded. Then, the analysis results of the statement nodes and dependencies in the cross-contract control flow graph are merged to construct a global state dependency graph. The nodes of the global state dependency graph are the statement nodes of the cross-contract control flow graph, and the edges represent control dependencies or data dependencies.

[0103] Furthermore, metadata such as function names and variable names in the source code under test can be injected into the global state dependency graph to improve its readability.

[0104] By performing global control flow analysis based on the control dependencies between statement nodes in the cross-contract control flow graph, a more comprehensive and accurate understanding of the execution process of the smart contract under test can be achieved. This not only enables the detection of cross-contract vulnerabilities but also verifies the logical integrity of the smart contract under test, facilitating subsequent efficient and accurate vulnerability and taint analysis.

[0105] In some implementations, dependencies include data dependencies and control dependencies. Data dependencies can help detect errors in the data processing process, such as uninitialized variables and inappropriate data dependencies. Control dependencies help detect control flow errors, such as unhandled exceptions and incorrect branch conditions. To more comprehensively understand and analyze the behavior of smart contracts, the dependencies of each statement node can be analyzed to clearly represent the contract's execution flow. For example, step 104 may include:

[0106] (104.1) Based on the cross-contract control flow graph, perform data flow detection on each statement node and obtain the detection results;

[0107] (104.2) When the detection result indicates that any two statement nodes have a data dependency relationship, the data dependency relationship is marked in the cross-contract control flow graph to obtain a global state dependency graph; or, when the detection result indicates that any two statement nodes have a control dependency relationship, the control dependency relationship is marked in the cross-contract control flow graph to obtain a global state dependency graph.

[0108] The detection results can be obtained by detecting dependencies in the cross-contract control flow graph. The detection results reflect the relationships between statement nodes in the smart contract code, especially data dependencies and control dependencies.

[0109] In some implementations, the detection results can also characterize the cross-contract state flow graph as having some statement nodes with data dependencies and some statement nodes with control dependencies. The global state dependency graph can be obtained simply by connecting the statement nodes with data dependencies or control dependencies at the corresponding positions.

[0110] For example, an Inter-contract Control Flow Graph (I-CFG) can be used as the basic framework. Each statement node (basic block) is traversed, and it is determined whether the execution of a statement in one statement node depends on the execution result of a statement in another statement node. If so, a control dependency exists between the two statement nodes. Simultaneously, it is determined whether the value of a variable or data element in one statement node depends on the value of a variable or data element in another statement node. If so, a data dependency exists between the two statement nodes.

[0111] Specifically, data dependencies can be categorized into true data dependencies, output data dependencies, and anti-data dependencies. True data dependencies occur when the definition of one variable directly affects the use of another variable. For example, in `B = A + 1`, the calculation of B depends on the value of A. Output data dependencies occur when two statements write to the same variable. For example, in `A = 1` and `A = 2`, both statements write to variable A. Anti-data dependencies occur when the definition of one variable affects the definition of another variable. For example, in `A = B + 1` and `B = 2`, if the assignment of B is after A, then the new value of B will affect the result of A.

[0112] Specifically, control dependency occurs when the execution of one statement depends on the result of the execution of another statement. Control dependency is generally related to conditional statements (such as if, while, etc.). If the execution path of a statement node depends on the result of the condition of another statement node, then there is a control dependency between these two statement nodes. For example:

[0113] if(condition){

[0114] statement1;

[0115] }else{

[0116] statement2;

[0117] }

[0118] Here, the execution of statement1 and statement2 depends on the outcome of the condition. Therefore, both statement1 and statement2 have a control dependency on the evaluation of the condition.

[0119] For example, after determining the dependencies between statement nodes in the entire cross-contract control flow graph, the statement nodes extracted from the cross-contract control flow graph and the detection results can be merged to form a global state dependency graph, or a global state dependency graph can be formed based on the original cross-contract control flow graph. In the global state dependency graph, each statement node represents a specific statement or operation, and edges represent the control dependencies or data dependencies between these statements.

[0120] Furthermore, metadata such as function names and variable names in the source code under test can be injected into the global state dependency graph to improve the readability and understanding of the graph.

[0121] By constructing a cross-contract control flow graph, the dependencies between statement nodes can be further analyzed, and a global state dependency graph can be built to help identify potential security issues and vulnerabilities. For example, if a function of a smart contract depends on data returned by an external call, and this external call may be controlled by an attacker, then there is a potential security risk. This allows for more comprehensive and accurate vulnerability detection in the future.

[0122] Step 105: Perform vulnerability and taint analysis on the smart contract under test based on the global state dependency graph to obtain the vulnerability detection results of the smart contract under test.

[0123] In some implementations, since global state dependency graphs help analyze the dependencies between cross-contract call addresses and input variables, as well as the flow of cross-contract interactive data, enabling combinatorial analysis of vulnerabilities, in order to deeply analyze the complex relationships between various statement nodes in the smart contract under test and improve the accuracy and comprehensiveness of vulnerability detection, vulnerability taint analysis of the smart contract under test can be performed based on global state dependency graphs to optimize the vulnerability detection process and efficiency.

[0124] Among them, vulnerability detection results can be information about potential security issues of the contract obtained during the smart contract vulnerability detection process. Vulnerability detection results can include the location, type, description, etc. of the vulnerability.

[0125] In some implementations, a global state dependency graph can be used to determine whether the statement nodes in the smart contract under test satisfy a vulnerability pattern. Specifically, the statement sequence and variable assignments of the statement nodes can be analyzed to determine whether they meet the vulnerability exploitation conditions. If they do, a vulnerability detection result for the corresponding type of vulnerability in the smart contract under test is obtained.

[0126] For example, performing statement sequence analysis on a specific statement node can specifically examine whether there are any further state-changing operations after an external contract call (such as a `call` or `delegatecall`). If code executes after the external call, and this code can access or modify the contract state, then there may be a reentrancy risk.

[0127] By analyzing the dependencies between cross-contract call addresses and input variables using a global state dependency graph, combinatorial analysis of vulnerabilities in the smart contract under test can be achieved. This helps to deeply analyze the complex relationships between various statement nodes in the smart contract under test, thereby improving the accuracy and comprehensiveness of vulnerability detection.

[0128] In some implementations, to focus on the most likely vulnerable code segments and avoid treating all dependencies as potential security issues, key code nodes can be extracted for analysis to narrow the scope of the analysis and make vulnerability detection more efficient. For example, step 105 may include:

[0129] (105.1) Based on the global state dependency graph, determine at least one vulnerability feature of the smart contract under test;

[0130] (105.2) Match the corresponding taint analysis rules for each vulnerability feature, and extract multiple key code nodes from the global state dependency graph based on the taint analysis rules;

[0131] (105.3) Based on multiple key code nodes, vulnerability analysis is performed to obtain the vulnerability detection results of the smart contract under test.

[0132] In this context, vulnerability characteristics can refer to the specific features of a particular type of security vulnerability in the code. For example, the characteristics of an integer overflow vulnerability might include unchecked mathematical operations that could cause variables to exceed their allowed range.

[0133] Taint analysis rules can be logical guidelines used to guide the analysis process. Designed based on vulnerability characteristics, taint analysis rules are used to identify potential vulnerabilities in the code. Rules typically define taint sources, taint propagation (sanitizer), and taint sinks.

[0134] Critical code nodes can be statement nodes used for vulnerability analysis. Focusing on critical code nodes allows us to concentrate on the code most likely to contain vulnerabilities. By analyzing critical code nodes in the global state dependency graph, we can reduce the workload of analysis and improve its relevance.

[0135] For example, potential vulnerability starting points can be identified in the global state dependency graph. These starting points could be parts of the smart contract under test that interact with the outside world, such as external function calls and functions that can receive external input. Furthermore, the data flow and control flow in the smart contract under test can be analyzed using the global state dependency graph. Based on known vulnerability patterns, such as reentrancy attacks, integer overflows, and unchecked transmissions, the graph can be checked for these patterns. For instance, operations that directly change the state after an external call can be searched to confirm the existence of reentrancy vulnerabilities.

[0136] Furthermore, once the vulnerability pattern is confirmed, at least one vulnerability characteristic of the smart contract under test can be identified. Vulnerability characteristics may include insecure external calls, lack of input validation, incorrect error handling, etc.

[0137] Please refer to Figure 5 For example, matching corresponding taint analysis rules based on vulnerability characteristics can effectively identify critical code nodes. For instance, in the taint analysis process for detecting integer overflows, analyzing the global state dependency graph of the smart contract under test can quickly locate statements performing addition and subtraction operations, and these operation points are identified as taint sources. Then, through reverse engineering, variable usage is traced from taint sources to taint convergence points, retaining semantic nodes involving relevant control and data dependencies, and identifying these semantic nodes as critical code nodes.

[0138] Furthermore, after identifying key code nodes, the statement sequences and variable assignments within these nodes can be analyzed to verify whether they meet the conditions for vulnerability exploitation. If they do, the smart contract under test will have a vulnerability of the corresponding type, and taint analysis can be used to effectively locate key statements related to the vulnerability, improving the targeting and accuracy of vulnerability detection. If neither condition is met, the smart contract under test will not have a vulnerability of the corresponding type.

[0139] For example, the global state dependency graph corresponding to a smart contract under test may involve multiple vulnerability features, such as two or three vulnerability features. It is only necessary to determine the corresponding key code nodes based on each vulnerability feature for analysis.

[0140] By using the above methods, it is not necessary to analyze the entire global state dependency graph. Only the corresponding key code nodes need to be identified based on the characteristics of the vulnerability and vulnerability taint detection needs to be performed. This reduces irrelevant path analysis and effectively alleviates problems such as path explosion in complex contracts.

[0141] In some implementations, to accurately identify key code nodes so as to facilitate accurate analysis of the smart contract under test based on these key code nodes and reduce redundant analysis operations, key code nodes can be extracted from the global state dependency graph according to different taint analysis rules to achieve accurate analysis of the smart contract under test. For example, (105.2) may include:

[0142] (105.2.1) Based on taint analysis rules, determine the taint sources and taint aggregation points corresponding to the vulnerability characteristics from the global state dependency graph;

[0143] (105.2.2) Based on taint sources and taint aggregation points, determine the propagation path of taint information from the global state dependency graph;

[0144] (105.2.3) Extract multiple key code nodes corresponding to the propagation path.

[0145] In this context, taint sources can be user input, return values ​​from external contracts, or data sent by other contracts. Taint sources are the starting point of interest in the analysis, as they may introduce malicious or unpredictable data.

[0146] Among them, taint aggregation points can be calls to external contracts, changes in contract state, or inputs to critical contract logic.

[0147] The propagation path of taint information can be considered as the flow path of data within a program from the taint source to the taint accumulation point. This propagation path includes all data transfer and processing, such as variable assignment, function calls, and returns.

[0148] For example, in the taint analysis process for detecting integer overflow, analyzing the global state dependency graph of the smart contract under test can quickly locate statements that perform addition and subtraction operations, and these operation points are identified as taint sources. Then, through reverse engineering, variable usage is traced from taint sources to taint convergence points, retaining semantic nodes involving relevant control and data dependencies, and identifying the corresponding semantic nodes as key code nodes.

[0149] By accurately identifying and extracting key code nodes from the global state dependency graph corresponding to the smart contract under test, the efficiency, comprehensiveness, and accuracy of detecting potential security vulnerabilities can be significantly improved.

[0150] In some implementations, to identify security flaws in the smart contract under test that could be exploited by attackers, so that the contract's developers or auditors can promptly fix these vulnerabilities and prevent potential data loss or abuse of contract functionality, analysis can be performed on critical code nodes to more accurately and quickly determine whether dangerous vulnerability patterns exist in the contract under test. For example, (105.3) may include:

[0151] (105.3.1) Analyze the statement sequence and variable assignments of each key code node to obtain the analysis results;

[0152] (105.3.2) Obtain the preset vulnerability conditions, and perform vulnerability detection on the analysis results of each key code node according to the preset vulnerability conditions to obtain the vulnerability detection results of the smart contract under test.

[0153] The statement sequence can be the lines of code executed sequentially within the key code nodes of the global state dependency graph corresponding to the smart contract under test. Statement sequences include variable declarations, assignment operations, conditional statements, loop structures, etc. Analyzing statement sequences helps to understand the code's execution flow and logic.

[0154] Variable assignment refers to the operation of assigning a specific value to a variable in code. By tracking and analyzing variable assignments, it is possible to identify the dependencies between variables across different code nodes and how these variables change during the execution of the smart contract under test.

[0155] The analysis results can be conclusions drawn from analyzing statement sequences and variable assignments. These results may include code execution paths, changes in variable states, and potential anomalies. The analysis results provide fundamental data for vulnerability detection.

[0156] The preset vulnerability conditions can be a predefined set of conditions based on known security vulnerability patterns and attack methods. These preset vulnerability conditions are used to detect potential security flaws in smart contracts. Examples include reentrancy attack patterns, integer overflows, unchecked data transmissions, and improper permission management.

[0157] For example, when the statement sequence of the key code nodes of the smart contract under test is:

[0158] require(balances[msg.sender]>=amount,"Insufficientbalance");

[0159] balances[msg.sender]-=amount;

[0160] balances[to] + = amount;

[0161] The variable is assigned the following value:

[0162] balances[msg.sender], balances[to],amount

[0163] Analyzing the statement sequence and variable assignments yields the following results: statement sequence analysis: checks if the require condition is met; variable assignment analysis: updates the value of the balances array.

[0164] Furthermore, if the preset vulnerability condition is whether `balances[msg.sender]` has a negative value, then vulnerability detection can be performed to check whether the `require` condition adequately prevents overflow, and to check the update logic of `balances[msg.sender]` and `balances[to]`. If the preset vulnerability condition is found to match, the vulnerability and its location are noted in the report as the vulnerability detection result.

[0165] In some implementations, in addition to analyzing the statement sequences and variable assignments of key code nodes, control flow analysis can also be performed, such as analyzing the code execution path, including conditional branches, loops, and exception handling, as well as data flow analysis, such as discovering unencrypted sensitive information or input that has not been properly validated.

[0166] By conducting in-depth analysis of key code nodes in smart contracts, including detailed review of statement sequences and variable assignments, potential security vulnerabilities can be identified and fixed more effectively. This improves the accuracy and speed of vulnerability detection, ensures the security and functionality of contracts, prevents data loss and abuse of contract functions, and safeguards user data security and the reliable operation of contracts.

[0167] In some implementations, to improve the accuracy and comprehensiveness of the analysis, metadata can be injected into the cross-contract control flow graph to increase the completeness of the information in the graph. For example, after obtaining the cross-contract control flow graph, the following steps can be performed:

[0168] (A.1) Based on the abstract syntax tree, determine the function names and variable names of each statement node in the cross-contract control flow diagram;

[0169] (A.2) Inject the function name and variable name into the cross-contract control flow graph to obtain the updated cross-contract control flow graph.

[0170] Among them, function names and variable names are identifiers used in programming to represent the names of functions and variables and their scope.

[0171] Understandably, in addition to injecting function names and variable names into the cross-contract control flow graph, metadata such as data type information, call relationships, and sensitive functions or variables can also be injected into the cross-contract control flow graph to more comprehensively analyze the behavior of the smart contract under test and other cross-contract calls, thereby enhancing the ability to detect vulnerabilities and perform global verification.

[0172] In some implementations, in addition to injecting function names and variable names into the cross-contract control flow graph, metadata such as function names and variable names can also be injected into the global state dependency graph to generate a global state dependency graph with more complete information, which is beneficial for faster and more accurate vulnerability detection.

[0173] Please refer to Figure 6 The following is combined with Figure 6 The general embodiments of this application are described below.

[0174] This application takes the source code of the smart contract under test as input and outputs detection results such as the location and type of vulnerabilities. Specifically, by inputting the source code of the smart contract under test and compiling it, an abstract syntax tree (AST) is obtained. Then, based on the AST, the control flow graph of the smart contract under test is completed, resulting in a cross-contract control flow graph that includes cross-contract function calls and internal program relationships. Through the inheritance and dependency relationships between smart contracts, a global state dependency graph is generated based on the cross-contract control flow graph to facilitate a more comprehensive and accurate analysis later.

[0175] Furthermore, taint analysis can be performed on the global state dependency graph based on vulnerability characteristics. Specifically, key code nodes related to the vulnerability can be extracted from the global state dependency graph, thereby reducing the scope of analysis. Finally, contract semantic modeling is performed by analyzing the control flow and data flow relationships in the code to determine whether the vulnerability exploitation pattern is met, and information such as relevant functions and their locations is reported. In summary, this application improves detection efficiency while ensuring high-reliability analysis by fully utilizing global state dependency analysis of the contract to assist in path pruning.

[0176] This application embodiment obtains the source code of the smart contract under test; parses the syntax structure of the source code to obtain the corresponding abstract syntax tree; obtains the control flow graph of the smart contract under test, and completes the call relationships of the control flow graph according to the abstract syntax tree to obtain a cross-contract control flow graph; constructs a global state dependency graph based on the dependency relationships of each statement node in the cross-contract control flow graph; and performs vulnerability and taint analysis on the smart contract under test based on the global state dependency graph to obtain the vulnerability detection results of the smart contract under test. In this way, the call relationships of the smart contract under test can be completed, that is, the cross-contract relationships can be completed, taking into account the collaborative effects between multiple smart contracts, thereby achieving a more comprehensive and accurate analysis of the smart contract under test. Furthermore, by considering the dependency relationships of each statement node, the propagation of vulnerabilities and taints in the contract can be analyzed, further improving the comprehensiveness and accuracy of the detection of the smart contract under test.

[0177] Please see Figure 7 This application also provides a vulnerability detection device that can implement the above-described vulnerability detection method. The vulnerability detection device includes:

[0178] Module 71 is used to obtain the source code of the smart contract to be tested.

[0179] Parsing module 72 is used to parse the syntax structure of the source code under test and obtain the abstract syntax tree corresponding to the source code under test;

[0180] The completion module 73 is used to obtain the control flow graph of the smart contract under test, and to complete the call relationship of the control flow graph according to the abstract syntax tree to obtain the cross-contract control flow graph.

[0181] Module 74 is used to build a global state dependency graph based on the dependency relationships between statement nodes in the cross-contract control flow graph;

[0182] Analysis module 75 is used to perform vulnerability and taint analysis on the smart contract under test based on the global state dependency graph, and obtain the vulnerability detection results of the smart contract under test.

[0183] The specific implementation of this vulnerability detection device is basically the same as the specific embodiments of the vulnerability detection method described above, and will not be repeated here. Subject to meeting the requirements of the embodiments of this application, the vulnerability detection device may also be equipped with other functional modules to implement the vulnerability detection method in the above embodiments.

[0184] This application also provides a computer device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned vulnerability detection method. This computer device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0185] Please see Figure 8 , Figure 8 The hardware structure of a computer device according to another embodiment is illustrated. The computer device includes:

[0186] The processor 81 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0187] The memory 82 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 82 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 82 and is called and executed by the processor 81 using the vulnerability detection method of the embodiments of this application.

[0188] Input / output interface 83 is used to implement information input and output;

[0189] The communication interface 84 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0190] Bus 85 transmits information between various components of the device (e.g., processor 81, memory 82, input / output interface 83, and communication interface 84);

[0191] The processor 81, memory 82, input / output interface 83, and communication interface 84 are connected to each other within the device via bus 85.

[0192] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned vulnerability detection method.

[0193] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0194] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0195] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0196] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0197] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0198] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0199] It should be understood that in this application, "at least one" and "several" refer to one or more, and "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0200] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0201] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0202] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0203] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0204] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A vulnerability detection method, characterized in that, The method includes: Obtain the source code of the smart contract to be tested; The syntax structure of the source code under test is parsed to obtain the abstract syntax tree corresponding to the source code under test. Obtain the control flow graph of the smart contract under test, and based on the abstract syntax tree, determine the target node in the source code under test that has cross-contract calls, and mark the target node; based on the marked target node, determine the first smart contract called by the target node across contracts; obtain the first control flow graph of the first smart contract, and use the target node as a control transfer, with the control flow graph as the center, connect the target node with the first control flow graph and the control flow graph of the smart contract under test to obtain a cross-contract control flow graph; based on the abstract syntax tree, determine the function name and variable name of each statement node in the cross-contract control flow graph; inject the function name and variable name into the cross-contract control flow graph to obtain an updated cross-contract control flow graph; Based on the cross-contract control flow graph, data flow is detected for each statement node to obtain detection results. When the detection results indicate that any two statement nodes have a data dependency relationship, the data dependency relationship is marked in the cross-contract control flow graph to obtain a global state dependency graph. Alternatively, when the detection results indicate that any two statement nodes have a control dependency relationship, the control dependency relationship is marked in the cross-contract control flow graph to obtain a global state dependency graph. Herein, the data dependency relationship is that the value of one variable depends on the value of another variable, and the control dependency relationship is that the execution order of the program depends on the execution result of the corresponding statement. The data dependency relationship is divided into true data dependency, output data dependency, and anti-data dependency. True data dependency occurs when the definition of one variable directly affects the use of another variable; output data dependency occurs when two statements write the same variable; and anti-data dependency occurs when the definition of one variable affects the definition of another variable. The nodes of the global state dependency graph are the statement nodes of the cross-contract control flow graph, and the edges are either control dependencies or data dependencies. Based on the global state dependency graph, vulnerability and taint analysis is performed on the smart contract under test to obtain the vulnerability detection results of the smart contract under test.

2. The vulnerability detection method according to claim 1, characterized in that, The step of performing vulnerability and taint analysis on the smart contract under test based on the global state dependency graph to obtain the vulnerability detection results of the smart contract under test includes: Based on the global state dependency graph, determine at least one vulnerability feature of the smart contract under test; For each of the aforementioned vulnerability characteristics, a corresponding taint analysis rule is matched, and multiple key code nodes are extracted from the global state dependency graph based on the taint analysis rule; Based on the aforementioned multiple key code nodes, vulnerability analysis is performed to obtain the vulnerability detection results of the smart contract under test.

3. The vulnerability detection method according to claim 2, characterized in that, The extraction of multiple key code nodes from the global state dependency graph based on the taint analysis rules includes: Based on the taint analysis rules, the taint sources and taint aggregation points corresponding to the vulnerability characteristics are determined from the global state dependency graph. Based on the taint source and the taint aggregation point, the propagation path of taint information is determined from the global state dependency graph; Extract multiple key code nodes corresponding to the propagation path.

4. The vulnerability detection method according to claim 2, characterized in that, The vulnerability analysis based on the multiple key code nodes, to obtain the vulnerability detection results of the smart contract under test, includes: The analysis results are obtained by analyzing the statement sequence and variable assignments of each key code node. Obtain preset vulnerability conditions, and perform vulnerability detection on the analysis results of each key code node according to the preset vulnerability conditions to obtain the vulnerability detection results of the smart contract under test.

5. A vulnerability detection device, characterized in that, The device includes: The acquisition module is used to acquire the source code of the smart contract to be tested. The parsing module is used to parse the syntax structure of the source code under test and obtain the abstract syntax tree corresponding to the source code under test. The completion module is used to obtain the control flow graph of the smart contract under test, and based on the abstract syntax tree, determine the target node in the source code under test that has cross-contract calls, and mark the target node; based on the marked target node, determine the first smart contract called by the target node across contracts; obtain the first control flow graph of the first smart contract, and use the target node as a control transfer, with the control flow graph as the center, connect the target node with the control flow graph of the first control flow graph and the control flow graph of the smart contract under test to obtain the cross-contract control flow graph; based on the abstract syntax tree, determine the function name and variable name of each statement node in the cross-contract control flow graph; inject the function name and variable name into the cross-contract control flow graph to obtain the updated cross-contract control flow graph; A construction module is used to perform data flow detection on each statement node based on the cross-contract control flow graph and obtain detection results. When the detection results indicate that any two statement nodes have a data dependency relationship, the data dependency relationship is marked in the cross-contract control flow graph to obtain a global state dependency graph; or, when the detection results indicate that any two statement nodes have a control dependency relationship, the control dependency relationship is marked in the cross-contract control flow graph to obtain a global state dependency graph. Herein, the data dependency relationship is that the value of one variable depends on the value of another variable, and the control dependency relationship is that the execution order of the program depends on the execution result of the corresponding statement. The data dependency relationship is divided into true data dependency, output data dependency, and anti-data dependency. True data dependency occurs when the definition of one variable directly affects the use of another variable; output data dependency occurs when two statements write the same variable; and anti-data dependency occurs when the definition of one variable affects the definition of another variable. The nodes of the global state dependency graph are the statement nodes of the cross-contract control flow graph, and the edges are either control dependencies or data dependencies. The analysis module is used to perform vulnerability and taint analysis on the smart contract under test based on the global state dependency graph, and obtain the vulnerability detection results of the smart contract under test.

6. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the vulnerability detection method according to any one of claims 1 to 4.

7. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the vulnerability detection method according to any one of claims 1 to 4.

Images