A smart contract vulnerability detection method based on dynamic and static combination mode
Patent Information
- Application Number
- CN202311350050.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-10-18
- Publication Date
- 2026-09-22
- Estimated Expiration
- 2043-10-18
AI Technical Summary
[0006]本发明的目的是为解决现有智能合约脆弱性检测方法的检测性能差的问题，而提出了一种基于动静结合模式的智能合约脆弱性检测方法
[0027]本发明基于特征相似性匹配与改进模糊测试的智能合约脆弱性分析，将动、静态方法的优势结合，突破传统方法在动态性与智能化的局限。同时，基于深度学习和模糊测试的脆弱性发现技术，能够针对复杂性更高的潜在漏洞，进行粒度更细、更全面的分析，充分、全面的掌握其安全状态，做到对合约脆弱点发现与预警，实现对智能合约进行动静结合的脆弱性感知，从而定位区块链合约层的脆弱点，提升了检测性能。
Smart Images
Figure CN117407883B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of blockchain smart contract security detection technology, specifically involving a smart contract vulnerability analysis method based on a dynamic and static combined mode. Background Technology
[0002] Blockchain, a significant product of computer technology development, is transforming traditional industries such as transportation, healthcare, and finance through the integrated application of cryptography, smart contracts, and peer-to-peer networks. However, its rapid development has also brought a surge of security issues. Incidents like TheDAO and Beauty Chain have served as wake-up calls for security professionals, emphasizing the need to examine blockchain's vulnerabilities and address security breaches while leveraging it to change society. According to statistics from bcsec and slowmist, smart contract security vulnerabilities have already resulted in trillions of dollars in economic losses, highlighting the critical importance of blockchain smart contract issues. Due to the immutability of blockchain, smart contracts must be checked and improved before deployment to enhance the defensive capabilities of the blockchain system.
[0003] Therefore, blockchain vulnerability analysis technology has demonstrated its superiority, acting as a "radar" in blockchain security research. Traditional smart contract vulnerability analysis methods mainly include formal verification, symbolic execution, fuzz testing, and machine learning. However, traditional smart contract code auditing tools typically rely on fixed rules or patterns defined by experts to analyze vulnerabilities in smart contracts, but these expert rules are prone to errors and struggle to cover some complex patterns. Rule-based detection tools have limited scalability, and with the explosive growth in the number of smart contracts, the applicability of this approach is decreasing.
[0004] While fuzzing and machine learning methods have offered significant automation and efficiency in smart contract vulnerability analysis, achieving groundbreaking progress and encouraging results, they remain imperfect. Existing contract-level vulnerability analysis methods are limited by their reliance on a single approach: static methods are constrained by existing vulnerability types and expert knowledge, failing to cover complex vulnerability types; dynamic methods face challenges in efficiently exploring the deep state space of contracts and analyzing highly structured transaction sequences. Therefore, exploring the deep state space of contracts through fuzzing becomes extremely difficult, placing higher demands on smart contract vulnerability analysis methods.
[0005] In summary, existing static methods cannot cover complex vulnerability types, and existing dynamic methods cannot explore the deep state space of contracts. Therefore, the detection performance of existing smart contract vulnerability detection methods is still poor, making it difficult to efficiently predict potential security risks at the smart contract layer. Summary of the Invention
[0006] The purpose of this invention is to address the poor detection performance of existing smart contract vulnerability detection methods by proposing a smart contract vulnerability detection method based on a dynamic-static combination mode.
[0007] The technical solution adopted by the present invention to solve the above-mentioned technical problems is as follows:
[0008] A smart contract vulnerability detection method based on a dynamic-static combined approach, the method specifically includes the following steps:
[0009] Step 1: Construct the control flow graph S = (N, i, E) of the smart contract to be tested, where N is the set of control blocks obtained from the binary code of the smart contract to be tested, i is the initial block of the binary code of the smart contract to be tested, i ∈ N, and E is the set of edges between control blocks, where edge e ∈ E, e = (n, c, n ′ ), e indicates that control block n is executed from control block n via condition or command c. ′ ;
[0010] The input of the control flow graph S of the smart contract to be tested is abstracted as (σ0,Σ), where σ0 is the control block information and Σ is the public function call sequence of the smart contract to be tested.
[0011] Step 2: Standardize the source code of the smart contract to be tested. Based on the binary code of the smart contract to be tested, the type of the smart contract to be tested, and the function call scale of the smart contract to be tested, the standardized source code is filtered to obtain the filtered source code.
[0012] The binary code of the smart contract to be tested is parsed into a code attribute graph, and the filtered source code is parsed into a source code attribute graph. Based on the code attribute graph and the source code attribute graph, the basic information features, symbol sequence features and control flow path features of the smart contract to be tested when calling each function are extracted.
[0013] Next, vulnerability detection is performed based on the extracted basic information features, symbol sequence features, and control flow path features. If the detection result indicates that the smart contract is vulnerable, the smart contract is deemed vulnerable, and the entire detection process ends; otherwise, proceed to step three.
[0014] Step 3: Model a Markov decision model and perform fuzz testing on the smart contract to be tested;
[0015] The training process of the Markov decision model is as follows: input the smart contract with known vulnerability state into the Markov decision model as the environment state; generate a corresponding number of seeds according to the number of functions in the function call sequence of the smart contract with known vulnerability state; use the mutation policy as the action policy of the Markov decision model; use the multi-level coverage index as the feedback reward of the Markov decision model; and use the DDPG deep reinforcement learning algorithm to learn the action selection policy.
[0016] Next, based on the number of functions in the public function call sequence of the smart contract to be tested, a corresponding number of seeds are generated. The generated seeds are mutated using a trained action selection strategy and a mutation strategy, resulting in mutated seeds. Seeds whose coverage rates of each indicator in the multi-level coverage indicators are all higher than the threshold are input into the smart contract to be tested. If the execution result of the smart contract is abnormal, the smart contract to be tested is considered to have vulnerabilities; otherwise, the smart contract to be tested does not have vulnerabilities.
[0017] Furthermore, the control block information includes the control block number, the control block timestamp, the address of the control block in the smart contract, and the initial balance of the control block.
[0018] Furthermore, when a function in the public function call sequence is called, a random value is generated based on the input parameter type of the called function. When the input parameter has a fixed length, the length of the generated random value is equal to the length of the input parameter. When the input parameter does not have a fixed length, a parameter is generated and the length of the generated random value is the length of the generated parameter.
[0019] Furthermore, the vulnerability detection based on the extracted basic information features, symbol sequence features, and control flow path features specifically includes:
[0020] For each function in the smart contract under test, when a function is called, after extracting a feature of the function, the similarity of that feature is compared with that feature of a known vulnerable function.
[0021] If this feature is similar to a known vulnerability function L, then continue to compare the similarity of other features of this function with other features of the vulnerability function L. If every feature of this function is similar to every feature of the vulnerability function L, then this function is a clone function of the vulnerability function L, that is, the smart contract under test has vulnerabilities.
[0022] If the characteristic is not similar to the characteristic of the known fragile function L, then continue to compare the next called function; until all called functions have been traversed. If there is no called function whose characteristics are similar to a certain fragile function, then continue to execute step three.
[0023] Furthermore, the generated seed is encoded in the form of a bit vector.
[0024] Further, the multi-level coverage indicators are <C1,C2,C3>, wherein C1 is an indicator for measuring the function of the execution path, C2 is an indicator for measuring the executed blocks, and C3 is an indicator for measuring the edges of the execution path.
[0025] Further, during the training process of the Markov decision model, after a mutation strategy is used to generate mutated seeds, the mutated seeds are screened. The screening method is: the mutated seeds calculate the coverage <M1,M2,M3> of the execution result through the multi-level coverage indicators <C1,C2,C3>, after calculating the average coverage of the three indicators, if the average coverage of the mutated seed is improved compared with that of the pre-mutation seed, the mutated seed is retained as a new seed; otherwise, the mutated seed is not retained.
[0026] The beneficial effects of the present invention are:
[0027] The present invention provides smart contract vulnerability analysis based on feature similarity matching and improved fuzzing testing, combines the advantages of dynamic and static methods, and breaks through the limitations of traditional methods in dynamics and intelligence. Meanwhile, the vulnerability discovery technology based on deep learning and fuzzing testing can conduct finer-grained and more comprehensive analysis for more complex potential vulnerabilities, fully and comprehensively grasp the security status of smart contracts, realize the discovery and early warning of contract vulnerabilities, and realize dynamic-static combined vulnerability perception for smart contracts, thereby locating vulnerabilities in the blockchain contract layer and improving detection performance. Description of Drawings
[0028] Figure 1 is an overall architectural diagram of the method of the present invention;
[0029] Figure 2 is an architectural diagram of vulnerability detection based on multi-level code similarity matching;
[0030] Figure 3 is an architectural diagram of vulnerability detection based on improved fuzzing testing. Detailed Description of Embodiments
[0031] Detailed Description of Embodiment 1, combined with Figure 1 , Figure 2 and Figure 3 illustrates this embodiment. This embodiment provides a smart contract vulnerability detection method based on a dynamic-static combined mode, and the method specifically includes the following steps:
[0032] Step 1: Based on the assembly instruction set of the smart contract binary code, construct the control flow graph S = (N, i, E) of the smart contract to be tested. N is the set of control blocks obtained from the binary code of the smart contract to be tested, i is the initial block of the binary code of the smart contract to be tested (i.e., the start of the contract), i ∈ N, and E is the set of edges between control blocks, with edge e ∈ E, e = (n, c, n ′ ), e indicates that control block n is executed from control block n via condition or command c. ′ The control flow graph S includes multiple paths for the execution of smart contracts.
[0033] The input to the control flow graph S of the smart contract to be tested is abstracted as (σ0, Σ), where σ0 represents the control block information and Σ represents the sequence of public function calls of the smart contract to be tested. Where m0 is the constructor call, and the function call m0 takes input parameters.
[0034] Step 2: Standardize the source code of the smart contract to be tested. Based on the binary code of the smart contract to be tested, the type of the smart contract to be tested, and the function call scale of the smart contract to be tested, the standardized source code is filtered to obtain the filtered source code.
[0035] Based on the vulnerable code to be detected, the source code is pre-screened from two aspects: smart contract type and function code size, thereby reducing the total amount of source code to be detected;
[0036] The binary code of the smart contract to be tested is parsed into a code property graph (CPG) with functions as units. The filtered source code is parsed into a source code property graph. Based on the code property graph and the source code property graph, the basic information features (including the return value and parameter type of the function, as well as the number of loops contained in the function), symbol sequence features, and control flow path features of the smart contract to be tested when calling each function are extracted.
[0037] Next, vulnerability detection is performed based on the extracted basic information features, symbol sequence features, and control flow path features. If the detection result indicates that the smart contract is vulnerable, the smart contract is deemed vulnerable, and the entire detection process ends; otherwise, proceed to step three.
[0038] Step 3: Model a Markov decision model and perform fuzz testing on the smart contract to be tested;
[0039] The training process of the Markov decision model is as follows: input the smart contract with known vulnerability state into the Markov decision model as the environment state; generate a corresponding number of seeds (the number of seeds is equal to the number of functions) based on the number of functions in the function call sequence of the smart contract with known vulnerability state; use the mutation policy as the action policy of the Markov decision model; use the multi-level coverage index as the feedback reward of the Markov decision model; and use the DDPG deep reinforcement learning algorithm to learn the action selection policy.
[0040] Then, the DDPG deep reinforcement learning algorithm, which integrates the value function and the policy function, is used to solve the process, thereby learning the optimal action selection policy. This enables the intelligent selection of mutation actions based on the current input sample data, reducing the blindness of sample mutation and allowing the mutated samples to obtain the maximum coverage reward. This reduces the generation of invalid samples, thereby improving the efficiency of the fuzzing method and further enhancing the efficiency and accuracy of the code evaluation model, ensuring code security in the blockchain network.
[0041] Next, based on the number of functions in the public function call sequence of the smart contract to be tested, a corresponding number of seeds are generated (in contract fuzz testing, seed t executes a path in the control flow graph S, and the coverage process is that the path visits a set of nodes and corresponding edges). The generated seeds are mutated using a trained action selection strategy and a mutation strategy, resulting in mutated seeds. Seeds whose coverage rates of each indicator in the multi-level coverage indicators are all higher than the threshold (which can be set according to the actual situation) are input into the smart contract to be tested. If the execution result of the smart contract is abnormal, the smart contract to be tested is considered to have a vulnerability; otherwise, the smart contract to be tested does not have a vulnerability.
[0042] This study targets various attribute features at the contract code level and fully leverages the automatic extraction capability of vulnerable path semantic features. Through CPG (Code Generation Tree) analysis of vulnerable contract code and source code, it effectively utilizes code semantic information and structured features to establish a progressively layered similarity matching method to discover potential vulnerabilities. Simultaneously, to explore deeper levels of the contract execution state space, an improved fuzzing method combining multi-level coverage strategies and deep reinforcement learning is constructed, providing valuable insights into the depth of contract state space coverage and vulnerability accuracy.
[0043] When static testing encounters bottlenecks, this paper proposes a combined static and dynamic approach to smart contract vulnerability analysis. The approach involves first static testing, then dynamic testing. This combined static and dynamic method ensures a certain level of accuracy in smart contract vulnerability analysis. Static methods conserve computational resources and time, while dynamic methods capture execution states and analyze vulnerabilities. This combined approach allows for a degree of contract screening. If a contract is found to be vulnerable using only static methods, it is considered vulnerable; if neither static nor dynamic testing reveals a vulnerability, it is considered relatively secure. This approach improves both the efficiency and accuracy of vulnerability analysis, enhancing the ability to efficiently predict and discover potential security risks at the contract level.
[0044] Specific Implementation Method Two: This implementation method differs from Specific Implementation Method One in that the control block information includes the control block number, control block timestamp, control block address in the smart contract, and initial balance of the control block.
[0045] The other steps and parameters are the same as in Specific Implementation Method 1.
[0046] Specific Implementation Method 3: This implementation method differs from Specific Implementation Method 1 or 2 in that, when a function in the public function call sequence is called, a random value is generated based on the input parameter type of the called function. When the input parameter has a fixed length, the length of the generated random value is equal to the length of the input parameter. When the input parameter does not have a fixed length, a parameter is generated and the length of the generated random value is the length of the generated parameter.
[0047] Other steps and parameters are the same as in specific implementation method one or two.
[0048] Specific Implementation Method Four: This implementation method differs from Specific Implementation Methods One to Three in that the vulnerability detection based on the extracted basic information features, symbol sequence features, and control flow path features is specifically as follows:
[0049] For each function in the smart contract under test, when a function is called, after extracting a feature of the function, the similarity of that feature is compared with that feature of a known vulnerable function.
[0050] If this feature is similar to a known vulnerability function L, then continue to compare the similarity of other features of this function with other features of the vulnerability function L. If every feature of this function is similar to every feature of the vulnerability function L, then this function is a clone function of the vulnerability function L, that is, the smart contract under test has vulnerabilities.
[0051] If this characteristic is not similar to the characteristic of the known fragile function L, then continue to compare the next function call;
[0052] Continue until all called functions have been traversed. If there is no called function whose features are similar to a certain vulnerable function in every category (vulnerability exists only if all the features of a function are similar to the corresponding features of a vulnerable function in every category), then continue to step three.
[0053] The other steps and parameters are the same as those in one of the specific implementation methods one to three.
[0054] It should be noted that during feature comparison, similarity comparisons are performed progressively in order of increasing complexity. This gradually narrows the scope of code detection, enabling fine-grained code feature similarity detection, thereby reducing the total number of detection targets and improving detection efficiency.
[0055] Specific Implementation Method Five: This implementation method differs from Specific Implementation Methods One to Four in that the generated seed is encoded in the form of a bit vector.
[0056] The other steps and parameters are the same as those in one of the specific implementation methods one to four.
[0057] Specific Implementation Method Six: This implementation method differs from Specific Implementation Methods One to Five in that the multi-level coverage index is...<C1,C2,C3> Where C1 is an indicator used to measure the functionality of the execution path, C2 is an indicator used to measure the executed block, and C3 is an indicator used to measure the edges of the execution path.
[0058] Definition 1: The coverage space Γ is defined as the set of enumerable features covered by the executing program.
[0059] The coverage space involved in this invention includes: the set of all contract functions Γ F The set of all contract blocks Γ B And the set of all contract edges Γ E .
[0060] Definition 2: Coverage metric C: (P×I)→Γ * To measure the performance of a contract p∈P, its input path i∈I produces a set of features that it has executed at least once, denoted as M∈Γ. * .
[0061] Since coverage metrics are primarily characterized by the coverage space Γ, this invention simplifies the corresponding coverage measure, where C F What is being measured is the functionality of the execution path, C B What is being measured is the block being executed, C EIt measures the edges of the execution path. Therefore, the multi-level coverage metric is defined as follows:
[0062] Definition 3: Coverage metric C n : From the coverage index sequence <C1,...,C n The system consists of input paths i∈I, detecting the execution of contracts p∈P, and generating a series of measurements. <M1,...,M n >
[0063] The other steps and parameters are the same as those in one of the specific implementation methods one to five.
[0064] Specific Implementation Method Seven: This implementation method differs from Specific Implementation Methods One through Six in that, during the training process of the Markov decision model, after generating mutation seeds using a mutation strategy, the mutation seeds are then screened. The screening method is as follows: the mutation seeds are selected through multi-level coverage indicators.<C1,C2,C3> Calculate coverage of execution results<M1,M2,M3> After calculating the average coverage of the three indicators, if the average coverage of the mutated seed is higher than that of the seed before mutation, the mutated seed is retained as a new seed; otherwise, the mutated seed is not retained.
[0065] In the coverage-oriented deep reinforcement learning model, a Markov decision process is used. Based on an improved fuzzy testing process, reinforcement learning is employed to model the seed generation problem, treating the input samples as the environment state and maintaining an effective sample queue Q. S And the set P of all path information executed by existing samples. If the sample state is s at time step t. t The mutated sample state is s′ t Furthermore, a new execution path p was generated during the execution process. t Then append it to queue Q. s And update set P, and set s′ t Use it as the state input for the next time step; otherwise, select the state input for the next time step based on the metric distance.
[0066] This invention constructs an intelligent fuzzing method for contract binary code through a multi-level coverage seed metric strategy and a coverage-oriented deep reinforcement learning model. It employs the DDPG algorithm to achieve intelligent selection of seed mutations, where the agent's action 'a' at each time step... t The deterministic action strategy μ is used to determine, i.e., a t =μ(s) t Meanwhile, a neural network is used to approximate it, called the policy network a = μ(s; θ). μ Value Network Q μWe still use the Bellman equation to define it, but approximate it using a neural network, called the value network Q(s, a; θ). Q The training objective of the DDPG algorithm consists of two parts: the objective function J. β The goal is to maximize μ and minimize the loss function of the value function Q. A mutation policy is selected using a trained policy network.
[0067] Then, by using a multi-level coverage strategy to evaluate and select suitable mutation seeds, the accuracy of the vulnerability assessment method is ensured, enabling in-depth mining of the contract state space and accurate discovery of vulnerabilities.
[0068] The method for selecting mutant seeds is as follows:
[0069] This invention uses coverage indices with different granularities.<C1,C2,C3> The seed pool is defined as a multi-layered seed tree. Mutated seeds calculate coverage metrics based on execution results using multi-level coverage indicators.<M1,M2,M3> The system filters mutated seeds based on metrics and guides seed selection in the next round. If a new coverage characteristic is found when evaluating the execution record of a mutated seed using existing coverage metrics, such as an improved edge coverage rate after mutation compared to before mutation, it is retained as a new seed and placed in an appropriate cluster. Meanwhile, in the hierarchical coverage mechanism, the top-level metric M1 directly classifies all seeds into different clusters, while the lower-level metric M... i Then used for M i-1 The generation of clusters and the classification of their seeds into smaller sub-clusters is called incremental seed clustering. The purpose of multi-level coverage metrics is to explore the deep state space of smart contracts. This hierarchical structure relies on low-level, fine-grained coverage metrics to preserve subtle differences between seeds, increasing seed richness and narrowing the search space for effective test cases.
[0070] The other steps and parameters are the same as those in one of the specific implementation methods one to six.
[0071] In summary, current research on vulnerability analysis techniques in the blockchain field is relatively limited, and there is a lack of dynamic and global understanding of vulnerabilities in the blockchain contract layer. This makes it difficult to provide sufficient security analysis strategies for data storage, security authentication, and other facilities in the contract layer infrastructure. This invention proposes a smart contract vulnerability analysis method based on a dynamic-static combined approach. It employs a multi-level static similarity matching method to analyze vulnerable code, and then combines this with improved fuzzing to dynamically analyze global information during smart contract execution. The final vulnerability analysis results are provided, and the generation of effective vulnerable code examples and parameters is explored. The use of static similarity matching ensures the efficiency of the vulnerability analysis method. The dynamically improved fuzzing strategy can analyze more complex and latent vulnerabilities, improve the coverage of smart contract states, and more effectively uncover network protocol vulnerabilities. Applying the dynamic-static combined approach to smart contract vulnerability detection provides more comprehensive protection for contract-level security. The method proposed in this invention improves the accuracy of vulnerability analysis, enhances contract layer data security, and is highly effective in discovering vulnerabilities in smart contracts.
[0072] The above examples of the present invention are merely illustrative of the computational model and process of the present invention, and are not intended to limit the implementation of the present invention. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is impossible to exhaustively list all possible implementations here. Any obvious variations or modifications derived from the technical solutions of the present invention are still within the scope of protection of the present invention.
Claims
1. A smart contract vulnerability detection method based on a dynamic-static combined mode, characterized in that, The method specifically includes the following steps: Step 1: Construct the control flow graph S = (N, i, E) of the smart contract to be tested, where N is the set of control blocks obtained from the binary code of the smart contract to be tested, i is the initial block of the binary code of the smart contract to be tested, i ∈ N, and E is the set of edges between control blocks, where edge e ∈ E, e = (n, c, n ′ ), e indicates that control block n is executed from control block n via condition or command c. ′ ; The input of the control flow graph S of the smart contract to be tested is abstracted as (σ0,Σ), where σ0 is the control block information and Σ is the public function call sequence of the smart contract to be tested. Step 2: Standardize the source code of the smart contract to be tested. Based on the binary code of the smart contract to be tested, the type of the smart contract to be tested, and the function call scale of the smart contract to be tested, the standardized source code is filtered to obtain the filtered source code. The binary code of the smart contract to be tested is parsed into a code attribute graph, and the filtered source code is parsed into a source code attribute graph. Based on the code attribute graph and the source code attribute graph, the basic information features, symbol sequence features and control flow path features of the smart contract to be tested when calling each function are extracted. Next, vulnerability detection is performed based on the extracted basic information features, symbol sequence features, and control flow path features. If the detection result indicates that the smart contract is vulnerable, the smart contract is deemed vulnerable, and the entire detection process ends; otherwise, proceed to step three. Step 3: Model a Markov decision model and perform fuzz testing on the smart contract to be tested; The training process of the Markov decision model is as follows: input the smart contract with known vulnerability state into the Markov decision model as the environment state; generate a corresponding number of seeds according to the number of functions in the function call sequence of the smart contract with known vulnerability state; use the mutation policy as the action policy of the Markov decision model; use the multi-level coverage index as the feedback reward of the Markov decision model; and use the DDPG deep reinforcement learning algorithm to learn the action selection policy. Next, based on the number of functions in the public function call sequence of the smart contract to be tested, a corresponding number of seeds are generated. The generated seeds are mutated using a trained action selection strategy and a mutation strategy, resulting in mutated seeds. Seeds whose coverage rates of each indicator in the multi-level coverage indicators are all higher than the threshold are input into the smart contract to be tested. If the execution result of the smart contract is abnormal, the smart contract to be tested is considered to have vulnerabilities; otherwise, the smart contract to be tested does not have vulnerabilities.
2. The smart contract vulnerability detection method based on a dynamic-static combined mode according to claim 1, characterized in that, The control block information includes the control block number, control block timestamp, control block address in the smart contract, and initial balance of the control block.
3. The smart contract vulnerability detection method based on a dynamic-static combined mode according to claim 2, characterized in that, When a function in the public function call sequence is called, a random value is generated based on the type of the input parameter of the called function. When the input parameter has a fixed length, the length of the generated random value is equal to the length of the input parameter. When the input parameter does not have a fixed length, a parameter is generated and the length of the generated random value is the length of the generated parameter.
4. The smart contract vulnerability detection method based on a dynamic-static combined mode according to claim 3, characterized in that, The vulnerability detection based on the extracted basic information features, symbol sequence features, and control flow path features is specifically as follows: For each function in the smart contract under test, when a function is called, after extracting a feature of the function, the similarity of that feature is compared with that feature of a known vulnerable function. If this feature is similar to a known vulnerability function L, then continue to compare the similarity of other features of this function with other features of the vulnerability function L. If every feature of this function is similar to every feature of the vulnerability function L, then this function is a clone function of the vulnerability function L, that is, the smart contract under test has vulnerabilities. If the characteristic is not similar to the characteristic of the known fragile function L, then continue to compare the next called function; until all called functions have been traversed. If there is no called function whose characteristics are similar to a certain fragile function, then continue to execute step three.
5. The smart contract vulnerability detection method based on a dynamic-static combined mode according to claim 4, characterized in that, The generated seed is encoded in the form of a bit vector.
6. The smart contract vulnerability detection method based on a dynamic-static combined mode according to claim 5, characterized in that, The multi-level coverage index is<C1,C2,C3> Where C1 is an indicator used to measure the functionality of the execution path, C2 is an indicator used to measure the executed block, and C3 is an indicator used to measure the edges of the execution path.
7. The smart contract vulnerability detection method based on a dynamic-static combined mode according to claim 6, characterized in that, During the training of the Markov decision model, after generating mutation seeds using a mutation strategy, the mutation seeds are then screened. The screening method is as follows: mutation seeds are selected based on multi-level coverage indicators.<C1,C2,C3> Calculate coverage of execution results<M1,M2,M3> After calculating the average coverage of the three indicators, if the average coverage of the mutated seed is higher than that of the seed before mutation, the mutated seed is retained as a new seed; otherwise, the mutated seed is not retained.