Cross-chain-bridge intelligent contract vulnerability detection method combining dynamic and static analysis

Abstract

The invention provides a dynamic and static analysis combined cross-chain bridge smart contract vulnerability detection method and device, and relates to the technical field of block chain smart contract vulnerability detection. The method comprises the following steps: constructing a cross-chain control flow diagram and a cross-chain data flow diagram according to an intelligent contract byte code; performing taint analysis according to the cross-chain control flow diagram and the cross-chain data flow diagram based on the vulnerability function to obtain cross-chain vulnerability information; based on a static analysis method, according to the single-chain control flow diagram, the single-chain data flow diagram and an application program binary interface, seed generation is carried out through a novel seed initialization algorithm, and an initial seed pool is obtained; and based on a dynamic data flow feedback mechanism, performing dynamic fuzzy testing according to the initial seed pool, the intelligent contract byte code, the single-chain data flow diagram and the single-contract vulnerability mode to obtain single-chain vulnerability information. According to the cross-chain bridge intelligent contract vulnerability detection method, dynamic analysis and static analysis are combined, and vulnerability detection types are comprehensive.

Description

Technical Field

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

[0002] Since the interconnection between different blockchains was not considered at the beginning of blockchain design, 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 has become an urgent problem to be solved in this field.

[0003] Cross-chain technology refers to the technical means by which independent blockchains can effectively interact with each other, transmit information, and transfer value. In the crypto world, cross-chain technology connects two independent blockchain ecosystems, which is called a cross-chain bridge in practical applications. The cross-chain bridge is designed 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 many 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 there is a possibility of security vulnerabilities; smart contracts carry the execution of digital transactions and the storage of assets, and the risk of being attacked is greatly increased. Due to the complex logic and huge code of the cross-chain bridge, the vulnerabilities in smart contracts are not easy to detect and detect. The existing smart contract vulnerability detection methods cover fewer types of vulnerabilities, and rarely achieve practical results on cross-chain bridge smart contracts. Therefore, it is of great practical significance to design and implement effective cross-chain bridge smart contract vulnerability detection methods.

[0005] Traditional smart contract vulnerability detection methods are mainly divided into two categories: static analysis and dynamic analysis. Static analysis can find potential vulnerabilities without executing smart contracts by performing syntax and semantic analysis on source code, but it is difficult to capture behavioral changes at runtime. Static analysis mainly uses control flow analysis, taint analysis, symbolic execution and other technologies; dynamic analysis can detect abnormal behaviors at runtime by simulating or actually executing smart contracts, but it has strong dependence on the environment and limited test coverage. Dynamic analysis mainly uses fuzz testing. Traditional smart contract vulnerability detection methods cannot be effectively applied to cross-chain bridge smart contracts. There are few studies on cross-chain bridge vulnerabilities and attack methods, and practical methods that can detect cross-chain bridge vulnerabilities and attacks are even rarer. The existing detection framework for cross-chain bridge smart contract vulnerabilities only uses static analysis methods and can only support the detection of a few types of vulnerabilities.

[0006] In the existing technology, there is a lack of a cross-chain bridge smart contract vulnerability detection method that combines dynamic analysis and static analysis to comprehensively detect vulnerability types. Summary of the invention

[0007] In order to solve the technical problems of cross-chain vulnerabilities caused by access control defects in the cross-chain interaction process and semantic inconsistency of smart contracts on both sides in the prior art, the embodiment of the present invention provides a cross-chain bridge smart contract vulnerability detection method and device combining dynamic and static analysis. The technical solution is as follows:

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

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

[0010] 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;

[0011] 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;

[0012] 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;

[0013] 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;

[0014] 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;

[0015] 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;

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

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

[0018] 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;

[0019] 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;

[0020] 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;

[0021] 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;

[0022] 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;

[0023] 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;

[0024] 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;

[0025] The vulnerability report generation module is used to generate vulnerability detection reports based on single-chain vulnerability information and 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, and the memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, any one of the cross-chain bridge smart contract vulnerability detection methods combining dynamic and static analysis as mentioned above 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 above-mentioned cross-chain bridge smart contract vulnerability detection methods combining dynamic and static analysis.

[0028] The beneficial effects brought about by the technical solution provided by the embodiment of the present invention include at least:

[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 following briefly introduces the drawings required for use in the description of the embodiments. 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 between them is not emphasized, the meanings they intend to express are the same. "of", "corresponding, relevant" and "corresponding" can sometimes be used interchangeably. It should be noted that when the difference between them is not emphasized, the meanings they intend to express are the same.

[0037] In the embodiments of the present invention, sometimes the subscripts such as W 1 It may be written in non-subscript form such as W1. When the difference is not emphasized, the meaning is the same.

[0038] In order to make the technical problems, technical solutions and advantages to be solved by the present invention more clear, a detailed description will be given below with reference to the accompanying drawings and specific embodiments.

[0039] The embodiment of the present invention provides a cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis, which can be implemented by a cross-chain bridge smart contract vulnerability detection device, which can be a terminal or a server. Figure 1 The flowchart of the cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis is shown. The processing flow of the method may include the following steps:

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

[0041] In a feasible implementation, the present invention is a practical detection method for cross-chain bridge smart contract vulnerabilities. Through the smart contract bytecode and application binary interface (ABI), vulnerability detection before and after smart contract on-chain is realized, and cross-chain vulnerabilities and single contract vulnerabilities existing in cross-chain bridge smart contracts in the real world can be mined. 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 alliance chains (such as FISCO BCOS), can adapt to their architecture, perform efficient and accurate vulnerability detection on smart contracts written based on Solidity, explore potential vulnerabilities in deployed smart contracts, and can also check for vulnerabilities in smart contracts before they are deployed, providing security protection for the application development of domestic open source alliance chains.

[0043] 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.

[0044] In a feasible implementation, in order to construct the basic control flow graph 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 technology.

[0045] The present invention decompiles a given smart contract bytecode into an intermediate representation through an existing decompiler, and the intermediate representation is a 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 based on features learned from a given set of training corpora of smart contract source code. The model is used to convert the meaningless variable names in the above intermediate representation into actual meaningful smart contract attributes.

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

[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 a source chain control flow graph and a target chain control flow graph according to the single chain control flow graph;

[0051] S32, searching the source chain control flow graph for the first event to obtain a first event broadcast statement; the first event includes a deposit event and a lock event;

[0052] 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;

[0053] S34, perform 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;

[0054] 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;

[0055] 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;

[0056] 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;

[0057] 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.

[0058] In a feasible implementation, 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 graphs obtained in the previous step.

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

[0060] ccCFG Node It is a set of basic block nodes representing program operations, relay nodes representing cross-chain data transmission, and client nodes representing cross-chain bridge clients. Represents the basic block node, Represents a relay node, Represents a client node.

[0061] ccCFG edge By controlling the flow edge , event broadcast (referring to the emit keyword used in smart contracts to record events to the blockchain) and notification side Among them, Represents the information flow of relayers and clients observing broadcast events, i.e. relayers observing deposit events broadcasted on the source chain, or clients observing withdrawal events on the target chain. Represents the information flow of the relayer notifying the contract execution authorization and withdrawal of the target chain.

[0062] is a labeling function that maps edges to one of three types, Indicates that the smart contract broadcasts the event. Indicates that the relayer notifies the smart contract of the target chain to authorize and withdraw funds.

[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 .in, Represents different operations in the cross-chain bridge smart contract code, Represents data dependencies between operations.

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

[0065] The ccCFG is constructed by adding event broadcast edges and notification edges in the single-chain control flow graph. When adding event broadcast edges, in order to indicate that the relay observes the deposit event issued on the source chain, the first event broadcast statement of the deposit and lock events is searched on the source chain control flow graph as the source of the event broadcast edge, and the relay node is used as the target of the event broadcast edge and connected with the directed edge.

[0066] To indicate that the client observes the withdrawal event on the target chain, another event broadcast edge is connected. For such an edge, the source is the second event broadcast statement of the authorization and withdrawal events on the target chain control flow graph, and the target is the client node.

[0067] When adding a notification edge, in order to indicate that the repeater notifies the smart contract of the target chain for authorization and withdrawal, the repeater node is used as the source, and authorization statements are further found as the target of the notification edge, and they are connected with the directed edge. The ccDFG is constructed through a designed dedicated data flow analysis. Similar to traditional data flow analysis, the present invention performs forward data flow analysis on control flow edges. The difference is that for event broadcast edges, only the parameters of the event can be propagated forward through the event broadcast edge, because only these parameters are recorded in the cross-chain data transmitted to the repeater. As for the notification edge, only the parameters of the authorization method call can be propagated forward through the notification edge.

[0068] S4. Based on cross-chain semantic checks and access control constraint checks, vulnerability checks are performed 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 check according to the cross-chain control flow graph to obtain the first vulnerable function;

[0071] 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;

[0072] 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;

[0073] 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;

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

[0075] S46. Using the security check model, perform an access control omission check by comparing the access control constraints to obtain a third vulnerable function.

[0076] 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.

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

[0078] A typical parsing error is caused by judging the withdrawal amount or type only by the withdrawal function itself, without checking the source chain deposit event. On ccDFG, this aspect is detected by identifying whether the withdrawal state variable has a data flow dependency on the deposit state variable. If it is found that there is a lack of data flow dependency between them, the corresponding function is judged as the second most vulnerable.

[0079] Model the access control of the cross-chain bridge smart contract and normalize various types of security checks into a canonical form. Associate resources with security checks based on a probabilistic pattern reasoning approach. Identify functions containing access control flaws based on the extracted access control constraints.

[0080] The security checks for access control are divided into three categories: those related to asset deposit and lock, including deposit success check and parameter verification check passed by the user; those related to cross-chain routers, mainly checking the correctness of cross-chain routing, including whether the asset identifier to be crossed and the target chain identifier are within the range supported by the cross-chain router, and checking whether external calls are wrong; and those related to asset authorization and withdrawal, including authorization validity check, duplication check, and withdrawal correctness check.

[0081] After extracting all the security checks of the cross-chain bridge smart contract access control, the resources that need access control constraints are identified, and the resources are associated with the corresponding security checks through the method of probabilistic pattern reasoning. 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 caused by access control flaws in the cross-chain bridge smart contract.

[0083] Access control omissions are checked by comparing the extracted access control constraints with the security check model. If a certain category of security checks is found to be missing, the corresponding third vulnerable function is output.

[0084] If a path allows users without sufficient permissions to access sensitive resources, it violates the access control constraint. For the entry points of the cross-chain bridge smart contract, their sub-control flow graphs are compared in pairs to identify possible paths that can reach the same sensitive resources but perform different security checks. The path that does not meet the given access control constraint is the violation path, and all functions on the violation path are determined as the fourth vulnerable function.

[0085] S5. Based on the vulnerable function, 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.

[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 public function entry point; determine the external call parameters as the taint source;

[0088] 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;

[0089] 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;

[0090] S54. Based on the vulnerable function list, state variables are tracked according to the cross-chain data flow graph to obtain contaminated state variables;

[0091] S55. Determine cross-chain vulnerability information based on the vulnerable function list and the contaminated state variables.

[0092] In one feasible implementation, the cross-chain vulnerability is caused by access control defects in the cross-chain interaction process and the inconsistency of the semantics of the smart contracts on both sides.

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

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

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

[0096] Condition 2: There are tainted state variables. After finding the entry point for the external attacker, forward propagate the ccDFG and identify the tainted state variables.

[0097] Based on the contaminated functions and state variables, the vulnerability exploitation path corresponding to the vulnerable function is derived, revealing the operable path for external entities to exploit cross-chain vulnerabilities to attack and obtain cross-chain vulnerability information.

[0098] 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, seeds are generated 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. 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;

[0101] S62. Based on the Def-Use chain, a function call sequence set is constructed according to the information quadruple;

[0102] 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 to obtain an initial seed pool.

[0103] In a feasible implementation, a corresponding information quadruple (All_funcs, Checked_funcs, Def_map, Use_map) is constructed 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 perform checks on whether the transaction sender and the contract deployer are consistent among all identified functions, Def_map represents the mapping between state variables and functions that define the state variables, and Use_map represents the mapping between state variables and functions that use the state variables.

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

[0105] Based on the information quadruple (All_funcs, Checked_funcs, Def_map, Use_map), an initial seed pool is generated. 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. The test case input to the fuzz test is called a seed.

[0106] The interdependence between smart contract functions is of great significance for vulnerability discovery. In order to effectively test whether there are vulnerabilities in the logic of smart contracts, 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 a meaningful function call sequence according to a specific algorithm. This sequence helps to improve code coverage, branch coverage or help discover potential vulnerability exploitation paths, fill these function call sequences, generate specific transaction sequences, and the final transaction sequence is used as a seed.

[0107] The seed is obtained by converting each predicted function call sequence in the set S into a transaction sequence. 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 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 of 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, 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 that represents the data dependency relationship between functions;

[0110] 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;

[0111] 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.

[0112] 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;

[0113] 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.

[0114] 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;

[0115] S627. Output function call sequence set S.

[0116] In a feasible implementation, the 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 the variable var, and function func2 uses the variable. Before execution, define a set S to record the generated function call sequence, and define a set Observed to record the observed Def-Use chain, both of which are empty sets initially. During execution, loop through the All_funcs set. If a function f does not define any state variables, or has appeared in any function call sequence in set S, skip the function; otherwise, define a new function call sequence seq, which consists of function f alone.

[0117] Perform an inner loop traversal on the All_funcs collection. If a new Def-Use chain can be observed in the new sequence obtained by appending a function g to the end of the current sequence seq, that is, the Def-Use chain not included in the set Observed, 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 the set Observed.

[0118] The length of the current sequence seq increases by 1, completing an expansion, and then proceeding to the next inner loop to continue trying to expand seq. If the current sequence seq has not been expanded at the end of an inner loop, this sequence seq is added to the set S, and then the next outer loop is performed. When the outer loop traversal ends, the prediction function call sequence subprocess ends, and the set S is the final generated prediction function call sequence set.

[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 fuzz testing technology, perform dynamic data flow analysis according to the mutated seed pool and 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 incorporate 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] Using 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] A data flow feedback mechanism is introduced during each execution process to evaluate the validity of the newly generated seed. The data flow feedback mechanism implements dynamic instrumentation in the smart contract bytecode by modifying the EVM simulator 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, except that 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), which means that the state variable pointed to by key in the storage space is defined at the instruction address addr1 and used at addr2.

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

[0132] The dynamic data flow feedback information is combined with the code coverage to form the feedback information of each test process. Therefore, when a seed shows a data flow that has not been seen before or covers a code that has not been visited before, the present invention will regard it as a meaningful seed and update the seed pool.

[0133] According to the predefined vulnerability pattern, during each execution of the smart contract, it is detected whether there is a corresponding vulnerability. The present invention implements the detection of 11 types of vulnerabilities, including assertion failure, arbitrary location write, block state dependency, ether leakage, ether freezing, integer overflow, unhandled exception, reentrancy vulnerability, violation of require statement, unprotected self-destruction and misuse of tx.origin authorization. The vulnerability pattern is 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 based on the single-chain vulnerability information and cross-chain vulnerability information.

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

[0136] The vulnerability detection effect was tested using annotated data sets including cross-chain bridge smart contracts and ordinary smart contracts. The results show that the present invention can achieve higher precision and recall than the existing technology. Compared with other fuzz testers for smart contract vulnerability detection, it has stronger vulnerability discovery capabilities and operating efficiency.

[0137] 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.

[0138] Figure 2 This is a block diagram of a cross-chain bridge smart contract vulnerability detection device combining dynamic and static analysis according to an exemplary embodiment, and the device is used for a cross-chain bridge smart contract vulnerability detection method combining dynamic and static analysis. Figure 2 The 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 obtain the smart contract bytecode and application binary interface to be detected in the Ethereum virtual machine environment;

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

[0141] The second static analysis module 230 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;

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

[0143] A cross-chain vulnerability acquisition module 250 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;

[0144] The seed pool initialization module 260 is used to generate seeds through a novel 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, to obtain an initial seed pool;

[0145] Dynamic analysis module 270, used to perform dynamic fuzzy testing based on the dynamic data flow feedback mechanism, 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;

[0146] The vulnerability report generation module 280 is used to generate a vulnerability detection report based on the single-chain vulnerability information and the cross-chain vulnerability information.

[0147] Optionally, the second static analysis module 230 is further configured to:

[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, searching the source chain control flow graph for the first event 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 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;

[0151] S34, perform 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;

[0152] 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;

[0153] 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;

[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 used for:

[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. Based on the probabilistic pattern reasoning method, construct a security check model according to the security check statements and access control resources;

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

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

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

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

[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 taint propagation paths;

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

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

[0169] S55. Determine the cross-chain vulnerability information according to the list of vulnerable functions and the contaminated state variables.

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

[0171] 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;

[0172] S62. Based on the Def-Use chain, a function call sequence set is constructed according to the information quadruple;

[0173] 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 to obtain an initial seed pool.

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

[0175] 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 that represents the data dependency relationship between functions;

[0176] 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;

[0177] 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.

[0178] 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;

[0179] 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.

[0180] 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;

[0181] S627. Output function call sequence set S.

[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, performing seed alternation mutation according to the initial seed pool to obtain a mutation seed pool;

[0184] 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;

[0185] 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;

[0186] S74. Based on the single contract vulnerability model, according to the updated seed pool, the smart contract is dynamically checked for vulnerabilities to obtain single chain vulnerability information.

[0187] 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.

[0188] Figure 3 is a schematic diagram of the structure of a cross-chain bridge smart contract vulnerability detection device provided by an embodiment of the present invention, such as Figure 3 As shown, the cross-chain bridge smart contract vulnerability detection device may include the above Figure 2 The cross-chain bridge smart contract vulnerability detection device combining dynamic and static analysis is 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 also include a memory 2002 and a transceiver 2003.

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

[0191] Combine the following Figure 3 The various components of the cross-chain bridge smart contract vulnerability detection device 310 are introduced in detail:

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

[0193] Optionally, the first processor 2001 can perform various functions of the cross-chain bridge smart contract vulnerability detection device 310 by running or executing a software program 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 may include one or more CPUs, such as Figure 3 CPU0 and CPU1 are shown in FIG.

[0195] In a specific implementation, as an embodiment, the cross-chain bridge smart contract vulnerability detection device 310 may also include multiple processors, such as Figure 3 The first processor 2001 and the second processor 2004 are shown in FIG. Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). The processor here may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0196] The memory 2002 is used to store the software program for executing the solution of the present invention, and is controlled to be executed by the first processor 2001. The specific implementation method can refer to the above method embodiment, which will not be repeated here.

[0197] Optionally, the memory 2002 may 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 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 compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, 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 may be integrated with the first processor 2001, or may exist independently, and may be accessed through the interface circuit ( Figure 3 (not shown) is coupled to the first processor 2001, which is not specifically limited in this embodiment of the present invention.

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

[0199] Optionally, the transceiver 2003 may include a receiver and a transmitter ( Figure 3 The receiver is used to implement a receiving function, and the transmitter is used to implement a sending function.

[0200] Optionally, the transceiver 2003 may be integrated with the first processor 2001, or may exist independently and be connected to the first processor 2001 through the interface circuit ( Figure 3 (not shown) is coupled to the first processor 2001, which is not specifically limited in this embodiment of the present invention.

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

[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 embodiment, which will not be repeated here.

[0203] It should be understood that the first processor 2001 in the embodiment of the present invention may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A 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 read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (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 and not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link 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 other combination. When implemented by 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 process or function described in the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. 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.). 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 available media sets. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state hard disk.

[0206] It should be understood that the term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship, but it may also indicate an "and / or" relationship. Please refer to the context for specific understanding.

[0207] In the present invention, "at least one" means one or more, and "plurality" means two or more. "At least one of the following" or similar expressions refers 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 mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0208] It should be understood that in various embodiments of the present invention, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on 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 brevity of description, the specific working processes of the devices, apparatuses, and units described above 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 may 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 couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of the devices or units can be in electrical, mechanical, or other forms.

[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 various embodiments 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] If the 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, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0215] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on 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; 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 static analysis method is based on the single-chain control flow graph, the single-chain data flow graph and the application binary interface, and the seed is generated by 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 to obtain an initial seed pool.

6. According to claim 5, 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.

7. 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.

8. 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 7, 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; 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.

9. 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 7 is implemented.

10. 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 7.

Images