A Vulnerability Detection Method for Cross-chain Bridge Smart Contracts Combining Dynamic and Static Analysis

Abstract

The present invention provides a method and device for detecting vulnerabilities in cross-chain bridge smart contracts by combining dynamic and static analysis, which relates to the technical field of detecting vulnerabilities in blockchain smart contracts. The method includes: constructing a cross-chain control flow graph and a cross-chain data flow graph according to the smart contract bytecode; performing taint analysis based on vulnerable functions according to the cross-chain control flow graph and the cross-chain data flow graph to obtain cross-chain vulnerability information; generating an initial seed pool by a new seed initialization algorithm based on the static analysis method according to the single-chain control flow graph, the single-chain data flow graph and the application binary interface; performing dynamic fuzz testing based on the dynamic data flow feedback mechanism according to the initial seed pool, the smart contract bytecode, the single-chain data flow graph and the single-contract vulnerability pattern to obtain single-chain vulnerability information. The present invention is a method for detecting vulnerabilities in cross-chain bridge smart contracts that combines dynamic analysis and static analysis and has a comprehensive type of vulnerability detection.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain smart contract vulnerability detection, and particularly to a method and device for detecting cross-chain bridge smart contract vulnerabilities by combining dynamic and static analysis. Background Art

[0002] Since the initial design of blockchain did not consider the interconnection between different blockchains, most different blockchain systems are heterogeneous and cannot communicate with each other, that is, "value islands". How to connect the "islands" formed by individual blockchain ledgers to each other has become an urgent problem to be solved in this field.

[0003] Cross-chain technology refers to a technical means that can effectively perform data interaction, information transmission, and value transfer between independent blockchains. Cross-chain technology connects two independent blockchain ecosystems in the encrypted world, which is called a cross-chain bridge in practical applications. The cross-chain bridge aims to enable users and developers to seamlessly move decentralized applications, digital assets, and smart contracts between different blockchains. With the continuous expansion of blockchain applications, cross-chain bridges have shown great potential in multiple fields such as decentralized finance, supply chain management, and the Internet of Things.

[0004] As a core component of the cross-chain bridge, the security of smart contracts fundamentally affects the security of the cross-chain bridge. Smart contracts are program codes written by developers and may have security vulnerabilities; smart contracts carry out the execution of digital transactions and the storage of assets, greatly increasing the risk of being attacked. Due to the complex logic and large code volume of the cross-chain bridge, it is not easy to detect and discover the vulnerabilities existing in smart contracts. Existing smart contract vulnerability detection methods cover fewer types of vulnerabilities and rarely achieve practical effects on cross-chain bridge smart contracts. Therefore, designing and implementing an effective method for detecting cross-chain bridge smart contract vulnerabilities has important practical significance.

[0005] Traditional smart contract vulnerability detection methods are mainly divided into two categories: static analysis and dynamic analysis. Static analysis can discover potential vulnerabilities without executing the smart contract by performing syntax and semantic analysis on the source code, but it is difficult to capture the behavioral changes during runtime. Static analysis mainly includes techniques such as control flow analysis, taint analysis, and symbolic execution; dynamic analysis, on the other hand, can detect abnormal behaviors during runtime by simulating or actually executing the smart contract, but it is highly dependent on the environment and has limited test coverage. Dynamic analysis mainly focuses on fuzz testing. Traditional smart contract vulnerability detection methods cannot be effectively applied to cross-chain bridge smart contracts. There is less research on cross-chain bridge vulnerabilities and attack methods, and practical methods that can detect cross-chain bridge vulnerabilities and attacks are even rarer. Existing detection frameworks for cross-chain bridge smart contract vulnerabilities only adopt static analysis methods and can only support the detection of a few types of vulnerabilities.

[0006] In the prior art, there is a lack of a cross-chain bridge smart contract vulnerability detection method that comprehensively combines dynamic analysis and static analysis and covers various types of vulnerabilities. Summary of the Invention

[0007] To solve the technical problem of cross-chain vulnerabilities in the prior art caused by access control defects during cross-chain interaction and semantic inconsistencies between smart contracts on both sides, embodiments of the present invention provide a cross-chain bridge smart contract vulnerability detection method and device that combines dynamic and static analysis. The technical solutions are as follows:

[0008] On the one hand, a cross-chain bridge smart contract vulnerability detection method that combines dynamic and static analysis is provided. This method is implemented by a cross-chain bridge smart contract vulnerability detection device and includes:

[0009] S1. In the Ethereum virtual machine environment, obtain the bytecode of the smart contract to be detected and the application binary interface.

[0010] S2. Based on a decompiler, a neural machine translation model, and the SmartDagger tool, construct a single-chain control flow graph and a single-chain data flow graph according to the smart contract bytecode.

[0011] S3. Based on an event retrieval method, integrate and connect the single-chain control flow graph and the single-chain data flow graph to obtain a cross-chain control flow graph and a cross-chain data flow graph.

[0012] S4. Based on cross-chain semantic checking and access control constraint condition checking, perform vulnerability checking according to the cross-chain control flow graph and the cross-chain data flow graph to obtain vulnerable functions.

[0013] S5. Based on the vulnerable functions, perform taint analysis according to the cross-chain control flow graph and the cross-chain data flow graph to obtain cross-chain vulnerability information.

[0014] S6. Based on a static analysis method, generate seeds through a new seed initialization algorithm according to the single-chain control flow graph, the single-chain data flow graph, and the application binary interface to obtain an initial seed pool.

[0015] S7. Based on a dynamic data flow feedback mechanism, perform dynamic fuzz testing according to the initial seed pool, the smart contract bytecode, the single-chain data flow graph, and the single contract vulnerability pattern to obtain single-chain vulnerability information.

[0016] S8. Generate a vulnerability detection report according to the single-chain vulnerability information and the cross-chain vulnerability information.

[0017] On the other hand, a cross-chain bridge smart contract vulnerability detection device that combines dynamic and static analysis is provided. This device is applied to the cross-chain bridge smart contract vulnerability detection method that combines dynamic and static analysis and includes:

[0018] An information acquisition module, configured to acquire the bytecode of the smart contract to be detected and the application binary interface in the Ethereum virtual machine environment;

[0019] A first static analysis module, configured to construct a single-chain control flow graph and a single-chain data flow graph based on the bytecode of the smart contract according to a decompiler, a neural machine translation model, and the SmartDagger tool;

[0020] A second static analysis module, configured to perform integration connection based on an event retrieval method according to the single-chain control flow graph and the single-chain data flow graph to obtain a cross-chain control flow graph and a cross-chain data flow graph;

[0021] A vulnerable function acquisition module, configured to perform vulnerability checks based on cross-chain semantic checks and access control constraint condition checks according to the cross-chain control flow graph and the cross-chain data flow graph to obtain vulnerable functions;

[0022] A cross-chain vulnerability acquisition module, configured to perform taint analysis based on vulnerable functions according to the cross-chain control flow graph and the cross-chain data flow graph to obtain cross-chain vulnerability information;

[0023] A seed pool initialization module, configured to generate seeds through a new seed initialization algorithm based on a static analysis method according to the single-chain control flow graph, the single-chain data flow graph, and the application binary interface to obtain an initial seed pool;

[0024] A dynamic analysis module, configured to perform dynamic fuzz testing based on a dynamic data flow feedback mechanism according to the initial seed pool, the bytecode of the smart contract, the single-chain data flow graph, and the single-contract vulnerability pattern to obtain single-chain vulnerability information;

[0025] A vulnerability report generation module, configured to generate a vulnerability detection report according to the single-chain vulnerability information and the cross-chain vulnerability information.

[0026] On the other hand, a cross-chain bridge smart contract vulnerability detection device is provided, and the cross-chain bridge smart contract vulnerability detection device includes: a processor; a memory, on which computer-readable instructions are stored, and when the computer-readable instructions are executed by the processor, any one of the methods in the above-mentioned cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis is implemented.

[0027] On the other hand, a computer-readable storage medium is provided, in which at least one instruction is stored, and the at least one instruction is loaded and executed by a processor to implement any one of the methods in the above-mentioned cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis.

[0028] The beneficial effects brought by the technical solutions provided in the embodiments of the present invention at least include:

[0029] The present invention proposes a cross-chain bridge smart contract vulnerability detection method that combines dynamic and static analysis. Through the architecture that combines dynamic and static analysis, the detection can be completed based on the smart contract bytecode and the application binary interface as input. In the absence of source code, vulnerability detection can be carried out on smart contracts that have been deployed in the blockchain network; a new seed initialization algorithm is proposed to avoid generating seeds with high similarity, reduce the redundancy of the seed pool, and generate initial seeds that are more conducive to discovering vulnerabilities for dynamic single-chain vulnerability checks, thereby improving the operating efficiency of smart contract testing. In the process of dynamic single-chain vulnerability checking, based on data flow feedback information and code coverage, fuzz testing is effectively guided to improve the efficiency of vulnerability discovery. The present invention is a cross-chain bridge smart contract vulnerability detection method that combines dynamic analysis and static analysis with comprehensive vulnerability detection types. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0031] Figure 1 This is a flow chart of a cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis provided by an embodiment of the present invention;

[0032] Figure 2 It is a block diagram of a cross-chain bridge smart contract vulnerability detection device combining dynamic and static analysis provided by an embodiment of the present invention;

[0033] Figure 3 It is a structural schematic diagram of a cross-chain bridge smart contract vulnerability detection device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0034] The technical solution of the present invention is described below in conjunction with the accompanying drawings.

[0035] In the embodiments of the present invention, words such as "exemplarily" and "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "example" in the present invention should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of the word "example" is intended to present the concept in a specific way. In addition, in the embodiments of the present invention, the meaning expressed by "and / or" can be both, or it can be either of the two.

[0036] In the embodiments of the present invention, "image" and "picture" can sometimes be used interchangeably. It should be noted that when the difference is not emphasized, their intended meanings are the same. "of", "corresponding", and "corresponding" can sometimes be used interchangeably. It should be noted that when the difference is not emphasized, their intended meanings are the same.

[0037] In the embodiments of the present invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, their intended meanings are the same.

[0038] To make the technical problems, technical solutions, and advantages to be solved by the present invention clearer, the following will be described in detail with reference to the accompanying drawings and specific embodiments.

[0039] The embodiments of the present invention provide a method for detecting vulnerabilities in cross-chain bridge smart contracts by combining dynamic and static analysis. This method can be implemented by a cross-chain bridge smart contract vulnerability detection device, which can be a terminal or a server. As Figure 1 shown in the flowchart of the method for detecting vulnerabilities in cross-chain bridge smart contracts by combining dynamic and static analysis, the processing flow of this method can include the following steps:

[0040] S1. In the Ethereum virtual machine environment, obtain the bytecode of the smart contract to be detected and the application binary interface.

[0041] In a feasible implementation manner, the present invention is a practical detection method for vulnerabilities in cross-chain bridge smart contracts. Through the smart contract bytecode and the application binary interface (ABI), it realizes the detection of vulnerabilities before and after the smart contract is on the chain, and can detect cross-chain vulnerabilities and single-contract vulnerabilities existing in real-world cross-chain bridge smart contracts. The present invention is applicable to all smart contracts that can run in the Ethereum virtual machine environment.

[0042] The present invention fully considers the technical characteristics of domestic open-source consortium chains (such as FISCO BCOS), can adapt to its architecture, efficiently and accurately detect vulnerabilities in smart contracts written based on Solidity, discover potential vulnerabilities in deployed smart contracts, and can also detect vulnerabilities for smart contracts before deployment, providing security guarantees for the application development of domestic open-source consortium chains.

[0043] S2. Based on a decompiler, a neural machine translation model, and the SmartDagger tool, construct a single-chain control flow graph and a single-chain data flow graph according to the smart contract bytecode.

[0044] In a feasible implementation, in order to construct the basic control flow graphs of the smart contracts on both sides of the cross-chain bridge from the smart contract bytecode, it is necessary to first generate an intermediate representation from the bytecode using decompilation techniques.

[0045] The present invention decompiles the given smart contract bytecode into an intermediate representation through an existing decompiler, and this intermediate representation is three-address code. The smart contract attribute information in the above intermediate representation is restored through an existing neural machine translation model, and a set of intermediate representations with richer semantics is output.

[0046] The neural machine translation model uses an artificial neural network to translate a given word sequence into another type of word according to the features learned from a given set of training corpora on the smart contract source code, and uses this model to convert the variable names with no clear meaning in the above intermediate representation into actual smart contract attributes with clear meanings.

[0047] Based on the intermediate representation, the control flow graph and data flow graph of the smart contract on one side of the cross-chain bridge are constructed through identifying basic blocks and interprocedural analysis. The control flow edges between basic blocks are obtained by viewing the JUMP instructions in the bytecode, the function boundaries are determined, and a control flow graph is constructed for each function. Using the tool SmartDagger, the cross-contract control flow graph and data flow graph on the same blockchain are constructed. Compared with other static analysis tools at the bytecode level, this tool can construct a more complete cross-contract call control flow graph and data flow graph.

[0048] S3. Based on the event retrieval method, the single-chain control flow graph and the single-chain data flow graph are integrated and connected to obtain the cross-chain control flow graph and the cross-chain data flow graph.

[0049] Optionally, step S3 may further include the following steps S31 - S38:

[0050] S31. Obtain the source chain control flow graph and the target chain control flow graph according to the single-chain control flow graph;

[0051] S32. Perform a first event retrieval on the source chain control flow graph to obtain the first event broadcast statement; the first event includes the deposit event and the lock event;

[0052] S33. According to the source chain control flow graph, determine the node receiving the first event broadcast statement as the repeater node; determine the first event broadcast statement as the starting point of the first event broadcast edge; determine the repeater node as the ending point of the first event broadcast edge; determine the first event broadcast edge according to the starting point and the ending point of the first event broadcast edge;

[0053] S34. Perform a second event retrieval on the target chain control flow graph to obtain the second event broadcast statement; the second event includes the authorization event and the withdrawal event;

[0054] S35. According to the target chain control flow graph, determine the node that receives the second event broadcast statement as the client node; determine the second event broadcast statement as the starting point of the second event broadcast edge; determine the client node as the ending point of the second event broadcast edge; determine the second event broadcast edge according to the starting point and the ending point of the second event broadcast edge;

[0055] S36. Conduct an authorized event retrieval on the target chain control flow graph to obtain an authorization notification statement; determine the repeater node as the starting point of the notification edge; determine the authorization notification statement as the ending point of the notification edge; determine the notification edge according to the starting point and the ending point of the notification edge;

[0056] S37. According to the first event broadcast edge, the second event broadcast edge and the notification edge, perform connection integration on the single-chain control flow graph to obtain a cross-chain control flow graph;

[0057] S38. Based on the code operations and data dependency relationships of the single-chain data flow graph, perform forward data flow analysis on the cross-chain control flow graph to obtain a cross-chain data flow graph.

[0058] In a feasible implementation manner, a cross-chain control flow graph (ccCFG) and a cross-chain data flow graph (ccDFG) are constructed by aligning and connecting the single-chain control flow graph obtained in the previous step.

[0059] The cross-chain bridge consists of three parts, namely the source chain smart contract, the repeater, and the target chain smart contract. The workflow is divided into three steps, namely asset deposit and locking, cross-chain communication, and asset authorization and withdrawal. The constructed ccCFG is represented as .

[0060] The nodes of the ccCFG are a set of basic block nodes representing program operations, repeater nodes representing cross-chain data transmission, and client nodes representing cross-chain bridge clients. Among them, represents the basic block node, represents the repeater node, represents the client node.

[0061] The edges of the ccCFG consist of control flow edges , event broadcast (referring to the emit keyword in the smart contract used to record events to the blockchain) edges and notification edges . Among them, It represents the information flow in which the repeater and the client observe broadcast events, that is, the repeater observes the deposit events broadcast on the source chain, or the client observes the withdrawal events on the target chain. It represents the information flow in which the repeater notifies the contract on the target chain to execute authorization and withdrawal.

[0062] It is a marking function that maps edges to one of three types. It represents that the smart contract broadcasts events. It represents that the repeater notifies the smart contract on the target chain to perform authorization and cash withdrawal.

[0063] The ccDFG is constructed by performing data flow analysis on the ccCFG. Therefore, in terms of data structure, the ccDFG constructed by the present invention is similar to the traditional data flow graph. The ccDFG is represented as . Among them, represents different operations in the cross-chain bridge smart contract code. represents the data dependency relationship between operations.

[0064] In order to construct the above cross-chain control flow graph and data flow graph for cross-chain program analysis.

[0065] The ccCFG is constructed by adding event broadcast edges and notification edges to the single-chain control flow graph. When adding event broadcast edges, in order to represent that the repeater observes the issued deposit events on the source chain, search for the first event broadcast statement of the deposit and lock events on the source chain control flow graph as the source of the event broadcast edge, take the repeater node as the target of the event broadcast edge, and connect them with a directed edge.

[0066] In order to represent that the client observes the withdrawal events on the target chain, connect another event broadcast edge. For such an edge, the source is the second event broadcast statement of the authorization and cash withdrawal events on the target chain control flow graph, and the target is the client node.

[0067] When adding notification edges, in order to represent that the repeater notifies the smart contract on the target chain to perform authorization and cash withdrawal, take the repeater node as the source, further search for the authorization statement as the target of the notification edge, and connect them with a directed edge. The ccDFG is constructed by the designed dedicated data flow analysis. Similar to the traditional data flow analysis, the present invention performs forward data flow analysis on the control flow edges. The difference is that for event broadcast edges, only the parameters of the event can propagate forward through the event broadcast edge, because only these parameters are recorded in the cross-chain data transmitted to the repeater. In terms of notification edges, only the parameters of the authorization method call can propagate forward through the notification edge.

[0068] S4. Based on cross-chain semantic checking and access control constraint checking, perform vulnerability checking according to the cross-chain control flow graph and the cross-chain data flow graph to obtain vulnerable functions.

[0069] Optionally, step S4 may further include the following steps S41 - S47:

[0070] S41. Perform semantic granularity checking according to the cross-chain control flow graph to obtain the first vulnerable functions;

[0071] S42. Based on the cross-chain data flow graph, perform semantic integrity checking on the cross-chain control flow graph to obtain the second vulnerable functions;

[0072] S43. According to the cross-chain control flow graph, identify and analyze the security check points of access control to obtain access control constraints and security check statements;

[0073] S44. According to the cross-chain data flow graph, identify the resource access points protected by the access control policy to obtain access control resources;

[0074] S45. Based on the probabilistic pattern reasoning method, construct a security check model according to the security check statements and access control resources;

[0075] S46. Use the security check model to compare the access control constraints for access control omission checking to obtain the third vulnerable functions;

[0076] S47. Based on the control flow paths of the cross-chain control flow graph, perform constraint violation checking according to the access control constraints and the security check model to obtain the fourth vulnerable functions.

[0077] In a feasible implementation, the insufficient granularity of the deposit event causes the target chain smart contract to be unable to distinguish different types of deposits and enter the same withdrawal logic. On the ccCFG, this aspect is detected by pairwise comparing cross-chain paths to identify possible vulnerable paths that converge to the same withdrawal logic on the target chain but have different deposit logics on the source chain. This process outputs all the first vulnerable functions on the paths containing deposit events with insufficient granularity.

[0078] A typical parsing error is due to judging the amount or type of withdrawal only through the withdrawal function itself, lacking the check of the source chain deposit event. On the ccDFG, this aspect is detected by identifying whether the state variables of the withdrawal have a data flow dependency on the state variables of the deposit. If a lack of data flow dependency is found between them, the corresponding function is determined to be the second vulnerable.

[0079] Model the access control of cross-chain bridge smart contracts and normalize various types of security checks into a canonical form. Based on the probabilistic pattern reasoning method, associate resources with security checks. Based on the extracted access control constraints, identify functions that contain access control flaws.

[0080] The security checks for access control are divided into three categories. The category related to asset deposit and locking includes deposit success checks and parameter verification checks for the parameters passed by users. The category related to the cross-chain router mainly checks the correctness of cross-chain routing, including whether the asset identifier to be cross-chained and the target chain identifier are within the range supported by this cross-chain router, and checks whether external calls go wrong. The category related to asset authorization and withdrawal includes validity checks for authorization, duplicate checks, and correctness checks for withdrawals.

[0081] After extracting all the security checks for the access control of cross-chain bridge smart contracts, identify the resources that require access control constraints, and associate the resources with the corresponding security checks through the probabilistic pattern reasoning method. The present invention considers four types of resources, including state variable read and write statements, internal calls, application binary interfaces, and event broadcast statements.

[0082] Given the extracted access control constraints, identify vulnerabilities in cross-chain bridge smart contracts caused by access control flaws.

[0083] Check for access control omissions by comparing the extracted access control constraints with the security check model. If omissions in the security checks of a certain category are found, output the corresponding third vulnerable function.

[0084] If a path allows users without sufficient permissions to access sensitive resources, it violates the access control constraints. For the entry points of cross-chain bridge smart contracts, pairwise compare their sub-control flow graphs to identify possible paths that can reach the same sensitive resources but perform different security checks. The paths that do not satisfy the given access control constraints are the violation paths, and all the functions on this violation path are determined as the fourth vulnerable functions.

[0085] S5. Based on the vulnerable functions, perform taint analysis according to the cross-chain control flow graph and the cross-chain data flow graph to obtain cross-chain vulnerability information.

[0086] Optionally, step S5 may further include the following steps S51 - S55:

[0087] S51. According to the cross-chain control flow graph, obtain the external call parameters of the common function entry points; determine the external call parameters as the taint sources;

[0088] S52. Based on the vulnerable functions, perform taint propagation analysis on the cross-chain control flow graph according to the cross-chain data flow graph to obtain taint propagation paths;

[0089] S53. Based on the taint propagation path, perform an external attack entry check on vulnerable functions to obtain a list of vulnerable functions with external attack entries.

[0090] S54. Based on the list of vulnerable functions, perform state variable tracking according to the cross-chain data flow graph to obtain tainted state variables.

[0091] S55. Determine cross-chain vulnerability information based on the list of vulnerable functions and the tainted state variables.

[0092] In a feasible implementation, cross-chain vulnerabilities are caused by access control defects and inconsistent semantics of smart contracts on both sides during the cross-chain interaction process.

[0093] Based on vulnerable functions, use taint analysis technology to trace the propagation path of untrusted data or sensitive data (taint sources) during the execution of smart contracts, and identify the vulnerability exploitation paths corresponding to each vulnerable function.

[0094] Taint sources include parameters passed by contract callers and parameters of public functions. Taint sinks consist of external calls or state variables of smart contracts. Given a vulnerable function, if the following two conditions are met, the vulnerability exploitation path can be confirmed.

[0095] Condition 1: There is an entry for an external call. Use taint propagation to detect whether a vulnerable function can be tainted by an external attacker. Let the taint start from the external call entry point (such as a public function) of the cross-chain bridge smart contract and detect whether the taint can reach the vulnerable function. If it can reach, the vulnerable function has an entry for an external call; otherwise, it does not.

[0096] Condition 2: There are tainted state variables. After finding the entry of the external attacker, perform forward propagation on the ccDFG and identify the tainted state variables.

[0097] Based on the tainted functions and state variables, obtain the vulnerability exploitation paths corresponding to the vulnerable functions, reveal the operable paths for external entities to exploit cross-chain vulnerabilities, and obtain cross-chain vulnerability information.

[0098] S6. Based on static analysis methods, according to the single-chain control flow graph, single-chain data flow graph, and application binary interface, generate seeds through a new seed initialization algorithm to obtain an initial seed pool.

[0099] Optionally, step S6 may further include the following steps S61 - S63:

[0100] S61. Construct information quadruples using static analysis methods based on the single-chain control flow graph and the single-chain data flow graph to obtain information quadruples;

[0101] S62. Based on the Def-Use chain, construct a set of function call sequences according to the information quadruples;

[0102] S63. According to the application binary interface and the information quadruples, convert each function call sequence in the set of function call sequences into a transaction sequence to obtain an initial seed pool.

[0103] In a feasible implementation, construct a corresponding information quadruple (All_funcs, Checked_funcs, Def_map, Use_map) for each smart contract, where All_Funcs represents the set of all identified functions in the smart contract, Checked_funcs represents the set of functions that have performed the check on whether the transaction sender is the same as the contract deployer among all identified functions, Def_map represents the mapping between state variables and the functions that define these state variables, and Use_map represents the mapping between state variables and the functions that use these state variables.

[0104] Through existing constant propagation analysis techniques, find the destinations of control flow transfer instructions (such as JUMP) and identify functions including constructors in the smart contract. Based on the abstract interpretation theory, calculate the abstract values stored in the stack and memory to determine the state variables defined and used by each function. Use taint analysis techniques to track the flow related to the contract deployer's address and judge the following two conditions: The constructor of the smart contract saves the contract deployer's address to storage; The sender address returned by the CALLER instruction flows into the conditional branch and is compared with the contract deployer's address. If a function satisfies both of these conditions, add it to the Checked_funcs set.

[0105] Generate an initial seed pool based on the information quadruple (All_funcs, Checked_funcs, Def_map, Use_map). In fuzz testing for smart contract vulnerability detection, a single test case (test input) is a transaction sequence that initiates a series of function calls to the smart contract, and the test cases input into fuzz testing are called seeds.

[0106] The interdependencies between smart contract functions are of great significance for vulnerability discovery. To effectively test whether the logic of a smart contract has vulnerabilities, its functions must be called in a meaningful order to form a function call sequence. The process of initializing the seed pool is to predict meaningful function call sequences according to a specific algorithm. Such sequences help improve code coverage, branch coverage, or help discover potential vulnerability exploitation paths. These function call sequences are filled to generate specific transaction sequences, and the final obtained transaction sequences are used as seeds.

[0107] Convert each predicted function call sequence in the set S into a transaction sequence to obtain seeds. For each function in each transaction, check whether the function belongs to the set Checked_funcs. If so, set the sender of the transaction to the contract deployer; otherwise, randomly select one from the default user address list (including the contract deployer) as the sender of the transaction. Set the function parameters for each transaction. Represent each function parameter as a byte stream, and set the parameter type and the length of the byte stream accordingly according to the ABI of the smart contract to be tested. Each parameter type corresponds to a default parameter. For example, the default parameter for the integer type is 0. After the above sub-process, the initial seed pool is obtained.

[0108] Optionally, step S62 may further include the following steps S621 - S627:

[0109] S621. Obtain function information according to the information quadruple; set the total number of functions of the function information as N, the current function number as i, and let i = 1; the function call sequence set is S, and S is initially an empty set; the set of retrieved Def-Use chains is Observed, and Observed is initially an empty set; the Def-Use chain is a triple representing the data dependency relationship between functions;

[0110] S622. Judge whether i is greater than N. If i is greater than N, go to execute step S627. If i is less than or equal to N, execute step S623;

[0111] S623. Based on the function call sequence set S, according to the function information, judge whether the current function is in S. If the current function is in S, let i = i + 1 and execute step S622; if function i is not in S, create a function call sequence seq according to the current function;

[0112] S624. Based on the function information, retrieve the data dependency relationship according to the function call sequence seq to obtain a new set of Def-Use chains;

[0113] S625. Based on the retrieved set of Def-Use chains Observed, and according to the new set of Def-Use chains, determine whether the new set of Def-Use chains is a subset of Observed. If the new set of Def-Use chains is a subset of Observed, update S according to seq, let i = i + 1, and execute step S622. If the new set of Def-Use chains is not a subset of Observed, execute step S626.

[0114] S626. Update seq according to the new set of Def-Use chains; update Observed with the new set of Def-Use chains, and execute step S624.

[0115] S627. Output the set of function call sequences S.

[0116] In a feasible implementation, a Def-Use chain is a data dependency relationship between functions, expressed as a triple (func1, var, func2), which means that in a sequence, function func1 defines variable var, and function func2 uses this variable. Before execution, define set S to record the generated function call sequences, and define set Observed to record the observed Def-Use chains. Initially, both are empty sets. During execution, loop through the All_funcs set. If a function f does not define any state variables or has already appeared in any function call sequence in set S, then skip this function; otherwise, define a new function call sequence seq consisting of function f alone.

[0117] Perform an inner loop through the All_funcs set. If a new Def-Use chain, that is, a Def-Use chain not included in set Observed, can be observed in the new sequence obtained by appending a function g to the end of the current sequence seq, then update the current sequence seq to the new sequence obtained by appending a function g to the end; add the new Def-Use chain to set Observed.

[0118] The length of the current sequence seq is increased by 1 to complete one expansion, then perform the next inner loop and continue to try to expand seq. If at the end of a certain inner loop, the current sequence seq still has not been expanded, then add this sequence seq to set S, and then perform the next outer loop. When the outer loop traversal ends, the prediction function call sequence sub-process ends, and set S is the finally generated set of predicted function call sequences.

[0119] S7. Based on the dynamic data flow feedback mechanism, perform dynamic fuzz testing according to the initial seed pool, smart contract bytecode, single-chain data flow graph, and single-contract vulnerability patterns to obtain single-chain vulnerability information.

[0120] Optionally, step S7 may further include the following steps S71 - S74:

[0121] S71. Based on the random mutation strategy and the grey-box symbolic execution strategy, perform alternating mutation of seeds according to the initial seed pool to obtain a mutated seed pool;

[0122] S72. Based on the fuzz testing technology, perform dynamic data flow analysis according to the mutated seed pool and the smart contract bytecode to obtain data flow feedback information and code coverage;

[0123] S73. Based on the single-chain data flow graph, update the mutated seed pool according to the data flow feedback information and code coverage to obtain an updated seed pool;

[0124] S74. Based on the single-contract vulnerability patterns, perform dynamic vulnerability checks on the smart contract according to the updated seed pool to obtain single-chain vulnerability information.

[0125] In a feasible implementation, fuzz testing for smart contract vulnerability detection is a dynamic analysis technique that constructs input data for the execution of smart contracts through randomly generated or test case generation algorithms based on certain strategies.

[0126] Execute the smart contract in the test environment, monitor the state changes, function call results, and triggered exceptions of the smart contract, etc., and implement vulnerability detection according to specific rules or constraints. Fuzz testing is usually a loop process that continuously generates new test cases and executes them until a predetermined number of test times, duration, or coverage target is reached. During the testing process, feedback information such as code coverage during the execution of the smart contract can be collected to guide the generation of subsequent test cases to improve the coverage and efficiency of fuzz testing.

[0127] The method based on static analysis provides effective initial guidance information for fuzz testing, points out the direction for fuzz testing, and continues to combine the idea of static analysis during the execution of dynamic fuzz testing. Adopt data flow-guided fuzz testing, that is, during fuzz testing, perform lightweight dynamic data flow analysis, collect actual data flow feedback information, and combine it with traditional code coverage to jointly guide fuzz testing.

[0128] Taking the initial seed pool as the input, start fuzz testing with the EVM simulator as the running environment of the smart contract, and mutate the seeds by alternately using two mutation strategies of random mutation and grey-box symbolic execution to generate a mutated seed pool.

[0129] During each execution, a data flow feedback mechanism is introduced to evaluate the effectiveness of newly generated seeds. The data flow feedback mechanism modifies the EVM simulator to achieve dynamic instrumentation in the smart contract bytecode, so as to monitor storage access during execution and collect dynamic data flow information.

[0130] The collected dynamic data flow information is similar to the Def-Use chain. The difference is that here the actual instruction address is used to represent the function, and the key value of the storage space is used to represent the state variable, that is, (addr1, key, addr2). Its meaning is that the state variable pointed to by key in the storage space is defined at instruction address addr1 and used at addr2.

[0131] The data flow information is approximately calculated at the function-level granularity using static analysis methods, but the dynamic data flow information in this step is calculated at the instruction-level granularity by tracking the data flow of the actual execution process. Using this dynamic data flow, more specific and fine-grained feedback information can be obtained.

[0132] The dynamic data flow feedback information is combined with the code coverage to form the feedback information for each test process. Therefore, when a seed shows a previously unseen data flow or covers previously unvisited code, the present invention regards it as a meaningful seed and updates the seed pool.

[0133] According to the predefined vulnerability patterns, during each execution of the smart contract, it is detected whether there are corresponding vulnerabilities. The present invention realizes the detection of 11 types of vulnerabilities, including assertion failure, write anywhere, block state dependence, Ether leakage, Ether freeze, integer overflow, unhandled exception, reentrancy vulnerability, violation of the require statement, unprotected self-destruction, and misuse of tx.origin authorization. The vulnerability patterns are formulated according to the characteristics of each vulnerability. For example, at the bytecode level, the assertion failure vulnerability corresponds to the execution of the INVALID instruction. Therefore, the assertion failure vulnerability can be accurately detected by checking whether the INVALID instruction is executed.

[0134] S8. Generate a vulnerability detection report according to the single-chain vulnerability information and the cross-chain vulnerability information.

[0135] In a feasible implementation manner, according to the comprehensive single-chain vulnerability information and the cross-chain vulnerability information, a final vulnerability detection report is formed.

[0136] Using an annotated data set containing cross-chain bridge smart contracts and ordinary smart contracts to conduct tests on the vulnerability detection effect, the results show that the present invention can achieve higher precision and recall rates than the prior art. And compared with other fuzz testers for smart contract vulnerability detection, it has stronger vulnerability discovery ability and running efficiency.

[0137] The present invention proposes a method for detecting vulnerabilities in cross-chain bridge smart contracts by combining dynamic and static analysis. Through an architecture that combines dynamic and static analysis, detection can be completed based on the smart contract bytecode and the application binary interface as inputs. In the case of no source code, it is possible to detect vulnerabilities in smart contracts that have been deployed in the blockchain network; a new seed initialization algorithm is proposed to avoid generating seeds with high similarity, reduce the redundancy of the seed pool, generate initial seeds that are more conducive to discovering vulnerabilities for dynamic single-chain vulnerability checks, and improve the running efficiency of smart contract testing. During the process of dynamic single-chain vulnerability checks, based on data flow feedback information and code coverage, fuzz testing is effectively guided to improve the efficiency of vulnerability discovery. The present invention is a method for detecting vulnerabilities in cross-chain bridge smart contracts with a comprehensive type of vulnerability detection that combines dynamic analysis and static analysis.

[0138] Figure 2 FIG. is a block diagram of a device for detecting vulnerabilities in cross-chain bridge smart contracts by combining dynamic and static analysis according to an exemplary embodiment. This device is used for the method of detecting vulnerabilities in cross-chain bridge smart contracts by combining dynamic and static analysis. Refer to Figure 2 FIG., this device includes an information acquisition module 210, a first static analysis module 220, a second static analysis module 230, a vulnerable function acquisition module 240, a cross-chain vulnerability acquisition module 250, a seed pool initialization module 260, a dynamic analysis module 270, and a vulnerability report generation module 280. Among them:

[0139] The information acquisition module 210 is used to acquire the smart contract bytecode to be detected and the application binary interface in the Ethereum virtual machine environment;

[0140] The first static analysis module 220 is used to construct a single-chain control flow graph and a single-chain data flow graph based on the smart contract bytecode by using a decompiler, a neural machine translation model, and the SmartDagger tool;

[0141] The second static analysis module 230 is used to perform integration and connection based on the event retrieval method according to the single-chain control flow graph and the single-chain data flow graph to obtain a cross-chain control flow graph and a cross-chain data flow graph;

[0142] The vulnerable function acquisition module 240 is used to perform vulnerability checks based on cross-chain semantic checks and access control constraint condition checks according to the cross-chain control flow graph and the cross-chain data flow graph to obtain vulnerable functions;

[0143] The cross-chain vulnerability acquisition module 250 is used to perform taint analysis based on the vulnerable functions according to the cross-chain control flow graph and the cross-chain data flow graph to obtain cross-chain vulnerability information;

[0144] A seed pool initialization module 260, which is used to generate seeds through a new seed initialization algorithm based on a static analysis method according to a single-chain control flow graph, a single-chain data flow graph, and an application binary interface, so as to obtain an initial seed pool;

[0145] A dynamic analysis module 270, which is used to perform dynamic fuzz testing based on a dynamic data flow feedback mechanism according to the initial seed pool, smart contract bytecode, a single-chain data flow graph, and a single-contract vulnerability pattern, so as to obtain single-chain vulnerability information;

[0146] A vulnerability report generation module 280, which is used to generate a vulnerability detection report according to the single-chain vulnerability information and cross-chain vulnerability information.

[0147] Optionally, a second static analysis module 230 is further used for:

[0148] S31. Obtain a source chain control flow graph and a target chain control flow graph according to the single-chain control flow graph;

[0149] S32. Perform a first event retrieval on the source chain control flow graph to obtain a first event broadcast statement; the first event includes a deposit event and a lock event;

[0150] S33. According to the source chain control flow graph, determine the node receiving the first event broadcast statement as a repeater node; determine the first event broadcast statement as the starting point of the first event broadcast edge; determine the repeater node as the ending point of the first event broadcast edge; determine the first event broadcast edge according to the starting point and the ending point of the first event broadcast edge;

[0151] S34. Perform a second event retrieval on the target chain control flow graph to obtain a second event broadcast statement; the second event includes an authorization event and a withdrawal event;

[0152] S35. According to the target chain control flow graph, determine the node receiving the second event broadcast statement as a client node; determine the second event broadcast statement as the starting point of the second event broadcast edge; determine the client node as the ending point of the second event broadcast edge; determine the second event broadcast edge according to the starting point and the ending point of the second event broadcast edge;

[0153] S36. Perform an authorization event retrieval on the target chain control flow graph to obtain an authorization notification statement; determine the repeater node as the starting point of the notification edge; determine the authorization notification statement as the ending point of the notification edge; determine the notification edge according to the starting point and the ending point of the notification edge;

[0154] S37. Connect and integrate the single-chain control flow graph according to the first event broadcast edge, the second event broadcast edge, and the notification edge to obtain a cross-chain control flow graph;

[0155] S38. Perform forward data flow analysis on the cross-chain control flow graph based on the single-chain data flow graph's code operations and data dependencies to obtain the cross-chain data flow graph.

[0156] Optionally, the vulnerable function acquisition module 240 is further configured to:

[0157] S41. Perform semantic granularity checking based on the cross-chain control flow graph to obtain the first vulnerable function;

[0158] S42. Perform semantic integrity checking on the cross-chain control flow graph based on the cross-chain data flow graph to obtain the second vulnerable function;

[0159] S43. Identify and analyze the security checkpoints of access control based on the cross-chain control flow graph to obtain access control constraints and security check statements;

[0160] S44. Identify the resource access points protected by the access control policy based on the cross-chain data flow graph to obtain access control resources;

[0161] S45. Build a security check model based on the security check statements and access control resources using the probabilistic pattern reasoning method;

[0162] S46. Use the security check model to perform access control omission checking by comparing the access control constraints to obtain the third vulnerable function;

[0163] S47. Perform constraint violation checking based on the access control constraints and security check model according to the control flow path of the cross-chain control flow graph to obtain the fourth vulnerable function.

[0164] Optionally, the cross-chain vulnerability acquisition module 250 is further configured to:

[0165] S51. Based on the cross-chain control flow graph, obtain the external call parameters of the public function entry point; determine the external call parameters as the taint source;

[0166] S52. Based on the vulnerable functions, perform taint propagation analysis on the cross-chain control flow graph according to the cross-chain data flow graph to obtain the taint propagation path;

[0167] S53. Based on the taint propagation path, perform external attack entry checking on the vulnerable functions to obtain a list of vulnerable functions with external attack entries;

[0168] S54. Based on the list of vulnerable functions, perform state variable tracking according to the cross-chain data flow graph to obtain the tainted state variables;

[0169] S55. Determine the cross-chain vulnerability information based on the list of vulnerable functions and the tainted state variables.

[0170] Optionally, the seed pool initialization module 260 is further configured to:

[0171] S61. Construct information tuples using static analysis methods according to the single-chain control flow graph and the single-chain data flow graph to obtain information quadruples;

[0172] S62. Based on the Def-Use chain, construct a set of function call sequences according to the information quadruples;

[0173] S63. According to the application binary interface and the information quadruples, convert each function call sequence in the set of function call sequences into a transaction sequence to obtain an initial seed pool.

[0174] Optionally, the seed pool initialization module 260 is further configured to:

[0175] S621. Obtain function information according to the information quadruples; set the total number of functions of the function information to N, the number of the current function to i, and let i = 1; the set of function call sequences is S, and S is initially an empty set; the set of retrieved Def-Use chains is Observed, and Observed is initially an empty set; the Def-Use chain is a triple representing the data dependency relationship between functions;

[0176] S622. Determine whether i is greater than N. If i is greater than N, go to step S627. If i is less than or equal to N, execute step S623;

[0177] S623. Based on the set of function call sequences S, according to the function information, determine whether the current function is in S. If the current function is in S, let i = i + 1 and execute step S622; if function i is not in S, create a function call sequence seq according to the current function;

[0178] S624. Based on the function information, retrieve the data dependency relationship according to the function call sequence seq to obtain a new set of Def-Use chains;

[0179] S625. Based on the retrieved set of Def-Use chains Observed, according to the new set of Def-Use chains, determine whether the new set of Def-Use chains is a subset of Observed. If the new set of Def-Use chains is a subset of Observed, update S according to seq, let i = i + 1, and execute step S622; if the new set of Def-Use chains is not a subset of Observed, execute step S626;

[0180] S626. Update seq according to the new set of Def-Use chains; update Observed with the new set of Def-Use chains, and execute step S624;

[0181] S627. Output the set S of function call sequences.

[0182] Optionally, the dynamic analysis module 270 is further configured to:

[0183] S71. Based on the random mutation strategy and the gray-box symbolic execution strategy, perform seed alternating mutation according to the initial seed pool to obtain a mutated seed pool;

[0184] S72. Based on the fuzz testing technology, perform dynamic data flow analysis according to the mutated seed pool and the smart contract bytecode to obtain data flow feedback information and code coverage;

[0185] S73. Based on the single-chain data flow graph, update the mutated seed pool according to the data flow feedback information and the code coverage to obtain an updated seed pool;

[0186] S74. Based on the single-contract vulnerability pattern, perform dynamic vulnerability checking on the smart contract according to the updated seed pool to obtain single-chain vulnerability information.

[0187] The present invention proposes a cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis. Through an architecture that combines dynamic and static analysis, the detection can be completed by using the smart contract bytecode and the application binary interface as inputs. In the case of no source code, it is possible to detect vulnerabilities in smart contracts that have been deployed in the blockchain network; a new seed initialization algorithm is proposed to avoid generating seeds with high similarity, reduce the redundancy of the seed pool, generate initial seeds that are more conducive to discovering vulnerabilities for dynamic single-chain vulnerability checking, and improve the running efficiency of smart contract testing. During the process of dynamic single-chain vulnerability checking, based on the data flow feedback information and the code coverage, it effectively guides fuzz testing and improves the efficiency of vulnerability discovery. The present invention is a cross-chain bridge smart contract vulnerability detection method with a comprehensive type of vulnerability detection that combines dynamic analysis and static analysis.

[0188] Figure 3 It is a schematic structural diagram of a cross-chain bridge smart contract vulnerability detection device provided by an embodiment of the present invention. As Figure 3 shown, the cross-chain bridge smart contract vulnerability detection device may include the above-mentioned Figure 2 cross-chain bridge smart contract vulnerability detection device that combines dynamic and static analysis as shown. Optionally, the cross-chain bridge smart contract vulnerability detection device 310 may include a first processor 2001.

[0189] Optionally, the cross-chain bridge smart contract vulnerability detection device 310 may further include a memory 2002 and a transceiver 2003.

[0190] Wherein, the first processor 2001, the memory 2002, and the transceiver 2003 may be connected through a communication bus.

[0191] The following will combine Figure 3 to specifically introduce each component of the cross-chain bridge smart contract vulnerability detection device 310:

[0192] Among them, the first processor 2001 is the control center of the cross-chain bridge smart contract vulnerability detection device 310, which can be a single processor or a collective term for multiple processing elements. For example, the first processor 2001 is one or more central processing units (CPUs), or can be an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention, such as: one or more digital signal processors (DSPs), or one or more field programmable gate arrays (FPGAs).

[0193] Optionally, the first processor 2001 can execute various functions of the cross-chain bridge smart contract vulnerability detection device 310 by running or executing software programs stored in the memory 2002 and calling data stored in the memory 2002.

[0194] In a specific implementation, as an embodiment, the first processor 2001 can include one or more CPUs, such as Figure 3 the CPU0 and CPU1 shown in

[0195] In a specific implementation, as an embodiment, the cross-chain bridge smart contract vulnerability detection device 310 can also include multiple processors, such as Figure 3 the first processor 2001 and the second processor 2004 shown in

[0196] Among them, the memory 2002 is used to store the software program for implementing the solution of the present invention and is controlled by the first processor 2001 for execution. The specific implementation manner can refer to the above method embodiments and will not be elaborated here.

[0197] Optionally, the memory 2002 can be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or can also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 2002 can be integrated with the first processor 2001 or exist independently, and is coupled to the first processor 2001 through an interface circuit ( Figure 3 not shown) of the cross-chain bridge smart contract vulnerability detection device 310. The embodiments of the present invention do not make specific limitations on this.

[0198] The transceiver 2003 is used to communicate with a network device or with a terminal device.

[0199] Optionally, the transceiver 2003 can include a receiver and a transmitter ( Figure 3 not shown separately). Among them, the receiver is used to implement the receiving function, and the transmitter is used to implement the sending function.

[0200] Optionally, the transceiver 2003 can be integrated with the first processor 2001 or exist independently, and is coupled to the first processor 2001 through an interface circuit ( Figure 3 not shown) of the cross-chain bridge smart contract vulnerability detection device 310. The embodiments of the present invention do not make specific limitations on this.

[0201] It should be noted that Figure 3 the structure of the cross-chain bridge smart contract vulnerability detection device 310 shown does not constitute a limitation on the router. The actual knowledge structure recognition device may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0202] In addition, the technical effects of the cross-chain bridge smart contract vulnerability detection device 310 can refer to the technical effects of the cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis described in the above method embodiments, and will not be elaborated here.

[0203] It should be understood that the first processor 2001 in the embodiments of the present invention may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0204] It should also be understood that the memory in the embodiments of the present invention may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM) or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM) and direct rambus RAM (DR RAM).

[0205] The above embodiments can be implemented in whole or in part by software, hardware (such as circuits), firmware, or any combination thereof. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions described in the embodiments of the present invention are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wired (such as infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more collections of available media. The available media can be magnetic media (such as floppy disks, hard disks, magnetic tapes), optical media (such as DVDs), or semiconductor media. The semiconductor media can be a solid-state drive.

[0206] It should be understood that the term "and / or" in this document is merely a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. Here, A and B can be singular or plural. In addition, the character " / " in this document generally represents an "or" relationship between the associated objects before and after, but it may also represent an "and / or" relationship, which can be specifically understood by referring to the context before and after.

[0207] In the present invention, "at least one" means one or more, and "a plurality" means two or more. "At least one of the following" or its similar expressions refer to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, a - b, a - c, b - c, or a - b - c, where a, b, and c can be single or multiple.

[0208] It should be understood that in various embodiments of the present invention, the magnitudes of the sequence numbers of the above processes do not mean the order of execution. The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.

[0209] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0210] Those skilled in the art can clearly understand that for the convenience and conciseness of description, the specific working processes of the above-described devices, apparatuses, and units can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0211] In several embodiments provided by the present invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling, direct coupling, or communication connection to each other can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be in an electrical, mechanical, or other form.

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

[0213] In addition, the functional units in each embodiment of the present invention can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit.

[0214] When the above-mentioned functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The foregoing storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs.

[0215] As described above, the above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of changes or substitutions, which should all be covered by the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.

Claims

1. A cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis, characterized in that: The method comprises: S1. In the Ethereum virtual machine environment, obtain the smart contract bytecode and application binary interface to be tested; S2. Based on the decompiler, neural machine translation model and SmartDagger tool, a single-chain control flow graph and a single-chain data flow graph are constructed according to the smart contract bytecode; S3. Based on the event retrieval method, the single-chain control flow graph and the single-chain data flow graph are integrated and connected to obtain the cross-chain control flow graph and the cross-chain data flow graph; S4. Based on cross-chain semantic checks and access control constraint checks, vulnerability checks are performed according to cross-chain control flow graphs and cross-chain data flow graphs to obtain vulnerable functions; S5. Based on the vulnerable function, perform taint analysis according to the cross-chain control flow graph and the cross-chain data flow graph to obtain cross-chain vulnerability information; S6. Based on the static analysis method, according to the single-chain control flow graph, the single-chain data flow graph and the application binary interface, a new seed initialization algorithm is used to generate seeds to obtain an initial seed pool; The method based on static analysis, according to the single-chain control flow graph, the single-chain data flow graph and the application binary interface, generates seeds through a new seed initialization algorithm to obtain an initial seed pool, including: S61. According to the single-chain control flow graph and the single-chain data flow graph, a static analysis method is used to construct an information tuple to obtain an information quadruple; S62. Based on the Def-Use chain, a function call sequence set is constructed according to the information quadruple; S63. Convert each function call sequence in the function call sequence set into a transaction sequence according to the application binary interface and the information quadruple, and obtain an initial seed pool; S7. Based on the dynamic data flow feedback mechanism, dynamic fuzzy testing is performed according to the initial seed pool, smart contract bytecode, single-chain data flow graph and single-contract vulnerability pattern to obtain single-chain vulnerability information; S8. Generate a vulnerability detection report based on the single-chain vulnerability information and cross-chain vulnerability information.

2. According to claim 1, the cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis is characterized in that: The event-based retrieval method integrates and connects the single-chain control flow graph and the single-chain data flow graph to obtain the cross-chain control flow graph and the cross-chain data flow graph, including: S31. Obtain a source chain control flow graph and a target chain control flow graph according to the single chain control flow graph; S32, performing a first event search on the source chain control flow graph to obtain a first event broadcast statement; the first event includes a deposit event and a lock event; S33. According to the source chain control flow graph, determine the node that receives the first event broadcast statement as a repeater node; determine the first event broadcast statement as the starting point of the first event broadcast edge; determine the repeater node as the end point of the first event broadcast edge; determine the first event broadcast edge according to the starting point of the first event broadcast edge and the end point of the first event broadcast edge; S34, performing a second event search on the target chain control flow graph to obtain a second event broadcast statement; the second event includes an authorization event and a withdrawal event; S35. According to the target chain control flow graph, the node receiving the second event broadcast statement is determined as the client node; the second event broadcast statement is determined as the second event broadcast edge starting point; the client node is determined as the second event broadcast edge end point; the second event broadcast edge is determined according to the second event broadcast edge starting point and the second event broadcast edge end point; S36, perform authorization event retrieval on the target chain control flow graph to obtain an authorization notification statement; determine the repeater node as the notification edge starting point; determine the authorization notification statement as the notification edge end point; determine the notification edge according to the notification edge starting point and the notification edge end point; S37. Connect and integrate the single-chain control flow graph according to the first event broadcast edge, the second event broadcast edge, and the notification edge to obtain a cross-chain control flow graph; S38. Based on the code operations and data dependencies of the single-chain data flow graph, a forward data flow analysis is performed on the cross-chain control flow graph to obtain a cross-chain data flow graph.

3. According to claim 1, the cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis is characterized in that: The cross-chain semantic check and access control constraint check are based on the cross-chain control flow graph and the cross-chain data flow graph to perform vulnerability checks and obtain vulnerable functions, including: S41. Perform semantic granularity check according to the cross-chain control flow graph to obtain the first vulnerable function; S42. Based on the cross-chain data flow graph, a semantic integrity check is performed on the cross-chain control flow graph to obtain a second vulnerable function; S43. According to the cross-chain control flow graph, identify and analyze the security checkpoints of the access control to obtain the access control constraints and security check statements; S44. According to the cross-chain data flow graph, the resource access point protected by the access control policy is identified to obtain the access control resource; S45. Based on the probabilistic pattern reasoning method, a security check model is constructed according to the security check statements and access control resources; S46. Using the security check model, perform an access control omission check by comparing the access control constraints to obtain a third vulnerable function. S47. Based on the control flow path of the cross-chain control flow graph, a constraint violation check is performed according to the access control constraints and the security check model to obtain a fourth vulnerable function.

4. According to claim 1, the cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis is characterized in that: Based on the vulnerable function, the taint analysis is performed according to the cross-chain control flow graph and the cross-chain data flow graph to obtain cross-chain vulnerability information, including: S51. According to the cross-chain control flow graph, obtain the external call parameters of the public function entry point; determine the external call parameters as the taint source; S52. Based on the vulnerable function and the cross-chain data flow graph, perform taint propagation analysis on the cross-chain control flow graph to obtain the taint propagation path; S53, based on the taint propagation path, perform an external attack entry check on the vulnerable function to obtain a list of vulnerable functions with external attack entries; S54. Based on the vulnerable function list, state variables are tracked according to the cross-chain data flow graph to obtain contaminated state variables; S55. Determine cross-chain vulnerability information based on the vulnerable function list and the contaminated state variables.

5. According to claim 1, the cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis is characterized in that: The method of constructing a function call sequence set based on the Def-Use chain according to the information quadruple includes: S621, according to the information quadruple, obtain function information; set the total number of functions in the function information to N, the number of the current function to i, and set i=1; the function call sequence set to S, which is initially an empty set; the retrieved Def-Use chain set to Observed, which is initially an empty set; the Def-Use chain is a triple representing the data dependency relationship between functions; S622, determine whether i is greater than N, if i is greater than N, then go to step S627, if i is less than or equal to N, then go to step S623; S623. Based on the function call sequence set S, determine whether the current function is in S according to the function information. If the current function is in S, set i=i+1 and execute step S622. If the function i is not in S, create a function call sequence seq according to the current function. S624, based on the function information, retrieve the data dependency according to the function call sequence seq, and obtain a new Def-Use chain set; S625. Based on the retrieved Def-Use chain set Observed, according to the new Def-Use chain set, determine whether the new Def-Use chain set is a subset of Observed. If the new Def-Use chain set is a subset of Observed, update S according to seq, set i=i+1, and execute step S622. If the new Def-Use chain set is not a subset of Observed, execute step S626. S626, update seq according to the new Def-Use chain set; use the new Def-Use chain set to update Observed, and execute step S624; S627. Output function call sequence set S.

6. The cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis according to claim 1 is characterized in that: Based on the dynamic data flow feedback mechanism, dynamic fuzzy testing is performed according to the initial seed pool, smart contract bytecode, single-chain data flow graph and single-contract vulnerability pattern to obtain single-chain vulnerability information, including: S71, based on the random mutation strategy and the gray box symbolic execution strategy, performing seed alternation mutation according to the initial seed pool to obtain a mutation seed pool; S72. Based on fuzz testing technology, dynamic data flow analysis is performed according to the mutation seed pool and smart contract bytecode to obtain data flow feedback information and code coverage; S73. Based on the single-chain data flow graph, the mutation seed pool is updated according to the data flow feedback information and the code coverage to obtain an updated seed pool; S74. Based on the single contract vulnerability model, according to the updated seed pool, the smart contract bytecode is dynamically checked for vulnerabilities to obtain single chain vulnerability information.

7. A cross-chain bridge smart contract vulnerability detection device combining dynamic and static analysis, the cross-chain bridge smart contract vulnerability detection device combining dynamic and static analysis is used to implement the cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis as claimed in any one of claims 1 to 6, characterized in that: The device comprises: The information acquisition module is used to obtain the bytecode and application binary interface of the smart contract to be detected in the Ethereum virtual machine environment; The first static analysis module is used to build a single-chain control flow graph and a single-chain data flow graph according to the smart contract bytecode based on the decompiler, neural machine translation model and SmartDagger tool; The second static analysis module is used to integrate and connect the single-chain control flow graph and the single-chain data flow graph based on the event retrieval method to obtain the cross-chain control flow graph and the cross-chain data flow graph; The vulnerable function acquisition module is used to perform vulnerability checks based on cross-chain semantic checks and access control constraint checks, and obtain vulnerable functions according to cross-chain control flow graphs and cross-chain data flow graphs; The cross-chain vulnerability acquisition module is used to perform taint analysis based on vulnerable functions, cross-chain control flow graphs, and cross-chain data flow graphs to obtain cross-chain vulnerability information; A seed pool initialization module is used to generate seeds through a new seed initialization algorithm based on a static analysis method, a single-chain control flow graph, a single-chain data flow graph, and an application binary interface to obtain an initial seed pool; The method based on static analysis, according to the single-chain control flow graph, the single-chain data flow graph and the application binary interface, generates seeds through a new seed initialization algorithm to obtain an initial seed pool, including: S61. According to the single-chain control flow graph and the single-chain data flow graph, a static analysis method is used to construct an information tuple to obtain an information quadruple; S62. Based on the Def-Use chain, a function call sequence set is constructed according to the information quadruple; S63. Convert each function call sequence in the function call sequence set into a transaction sequence according to the application binary interface and the information quadruple, and obtain an initial seed pool; Dynamic analysis module, which is used to perform dynamic fuzzy testing based on the dynamic data flow feedback mechanism, the initial seed pool, smart contract bytecode, single-chain data flow graph and single-contract vulnerability pattern to obtain single-chain vulnerability information; The vulnerability report generation module is used to generate vulnerability detection reports based on single-chain vulnerability information and cross-chain vulnerability information.

8. A cross-chain bridge smart contract vulnerability detection device, characterized in that: The cross-chain bridge smart contract vulnerability detection device includes: processor; A memory having computer-readable instructions stored thereon, wherein when the computer-readable instructions are executed by the processor, the method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program codes, which can be called by a processor to execute the method according to any one of claims 1 to 6.

Images