Cross-contract vulnerability fuzzy test method and device, equipment and medium

Abstract

The invention discloses a cross-contract vulnerability fuzzy test method and device, equipment and a medium, and the method comprises the steps: S1, randomly generating a test case, inputting the test case into a system, enabling the system to execute an intelligent contract, detecting vulnerabilities, and analyzing a code path coverage rate; s2, judging whether preset test time is reached or whether codes cover all paths or not, if so, executing a step S4, and otherwise, executing a step S3; s3, when coverage rate stagnation occurs or a complex branch occurs, generating a variation test case through the pre-training model, returning the test case as a test case to the step S1, and when coverage rate stagnation does not occur or a preset complex branch does not occur, returning to the step S1; and S4, obtaining a code path coverage rate and a vulnerability detection result. Therefore, the problem that the applicability and the coverage rate of the fuzzy test in the cross-contract environment are limited due to the fact that the prior art is prone to falling into the bottleneck of code coverage rate stagnation and it is difficult to continuously generate effective test cases is solved.

Description

Technical Field

[0001] The present invention relates to the field of software testing technology, and in particular to a cross-contract vulnerability fuzz testing method, device, equipment and medium. Background Art

[0002] With the rapid development of blockchain technology, smart contracts have become a core component supporting decentralized applications. Smart contracts run on multiple blockchain platforms, allowing users to automatically execute transactions and operations through defined rules. However, the security of smart contracts has always been a focus of the industry, especially when multiple smart contracts interact. These interactions may cause cross-contract vulnerabilities, allowing attackers to trigger vulnerabilities in contracts through specific function call sequences and interleaving, thereby stealing assets or compromising the correctness of contract execution.

[0003] Although existing fuzz testing technologies (such as X-Fuzz) can be used to discover vulnerabilities in a single contract, they still have problems such as insufficient code coverage and low efficiency when dealing with complex paths of cross-contract interactions. As the complexity of code execution paths increases, fuzz testing often falls into a bottleneck of stagnant code coverage and it is difficult to continue to generate effective test cases, which results in the applicability and coverage of fuzz testing being limited in a cross-contract environment. Summary of the invention

[0004] The present invention provides a cross-contract vulnerability fuzz testing method, device, equipment and medium, which are used to solve the problem that the prior art is prone to fall into the bottleneck of code coverage stagnation, making it difficult to continue to generate effective test cases, resulting in the applicability and coverage of fuzz testing in a cross-contract environment being limited.

[0005] In view of this, the first aspect of the present application provides a cross-contract vulnerability fuzz testing method, the method comprising:

[0006] S1. Generate test cases randomly through fuzz testing method and input them into the system, so that the system can execute smart contracts, detect vulnerabilities and analyze code path coverage;

[0007] S2, determine whether the preset test time has been reached or whether the code covers all paths, if so, execute step S4, otherwise execute step S3;

[0008] S3, when coverage stagnation occurs or complex branches appear, generate a variant test case through the pre-trained model, and return the test case as the test case to step S1; when coverage stagnation does not occur or the preset complex branch does not appear, return to step S1;

[0009] S4. Obtain code path coverage and vulnerability detection results.

[0010] Optionally, the pre-trained model includes: a large language model, a model based on the Transformer architecture, and a graph neural network.

[0011] Optionally, the detecting of the vulnerability includes:

[0012] When a preset abnormal situation occurs during the execution of the smart contract, it is determined that the smart contract has a vulnerability, and the preset abnormal situation includes: call failure, inconsistent state, and rollback error;

[0013] Alternatively, the execution process of the smart contract is monitored in combination with a threshold vulnerability feature library to identify the vulnerabilities of the smart contract.

[0014] Optionally, analyzing the code path coverage includes:

[0015] By analyzing the function call stack, execution branches and loop structure when the smart contract is executed, the coverage of the current test case is determined.

[0016] Optionally, the analysis method for the occurrence of the complex branch includes:

[0017] Dynamically analyzing whether there are preset complex branches, wherein the preset complex branches include: loop nesting and frequent conditional judgment;

[0018] Or, use static analysis tools to determine whether complex branches occur.

[0019] Optionally, when the pre-trained model is the large language model, generating a variation test case through the pre-trained model includes:

[0020] According to the vulnerability detection situation and the code path coverage analysis situation, prompts are designed and input into the pre-trained model, so that the pre-trained model outputs mutation test cases.

[0021] Optionally, the fuzz testing method includes: a fuzz testing engine, reinforcement learning and a genetic algorithm.

[0022] A second aspect of the present application provides a cross-contract vulnerability fuzz testing device, the device comprising:

[0023] The test unit is used to randomly generate test cases through fuzz testing methods and input them into the system, so that the system can execute smart contracts, detect vulnerabilities, and analyze code path coverage;

[0024] The analysis unit is used to determine whether the preset test time has been reached or whether the code covers all paths. If so, the acquisition unit is triggered, otherwise the generation unit is triggered;

[0025] A generation unit, used for generating a variation test case through a pre-trained model when coverage stagnation occurs or a complex branch appears, and using the test case as the test case and triggering the test unit, and triggering the test unit when coverage stagnation does not occur or the preset complex branch does not appear;

[0026] The acquisition unit is used to obtain code path coverage and vulnerability detection results.

[0027] A third aspect of the present invention provides a cross-contract vulnerability fuzz testing device, the device comprising a processor and a memory:

[0028] The memory is used to store program code and transmit the program code to the processor;

[0029] The processor is used to execute the steps of the cross-contract vulnerability fuzz testing method as described in the first aspect according to the instructions in the program code.

[0030] A fourth aspect of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store program code, and the program code is used to execute the cross-contract vulnerability fuzz testing method described in the first aspect above.

[0031] It can be seen from the above technical solutions that the present invention has the following advantages:

[0032] 1) Through code path complexity analysis, it screens out cross-contract interaction paths that are difficult to cover, and intelligently determines the timing of calling the large language model. This mechanism improves the efficiency of cross-contract vulnerability detection and avoids wasting resources on simple paths.

[0033] 2) Combined with a large language model, complex test cases for cross-contract vulnerabilities are generated through carefully designed prompts, especially for tests of complex function call sequences, interleaving and dependency scenarios. This technology significantly improves the performance of fuzz testing in complex path coverage.

[0034] 3) An intelligent scheduling mechanism for fuzz testing and large language models is designed. When coverage growth stagnates or complex paths are detected, the large language model is called to generate efficient mutation test cases to break through the bottleneck of fuzz testing.

[0035] 4) It provides an efficient detection method for cross-contract vulnerabilities in complex interaction paths between multiple contracts, improving the code coverage and testing accuracy of fuzz testing in multi-contract scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0037] Figure 1 A schematic diagram of a cross-contract vulnerability fuzz testing method provided by an embodiment of the present invention;

[0038] Figure 2 A test flow chart of a cross-contract vulnerability fuzzy testing system provided by an embodiment of the present invention;

[0039] Figure 3 A schematic diagram of the structure of a cross-contract vulnerability fuzz testing device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0040] In order to make the purpose, features and advantages of the present invention more obvious and easy to understand, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described below are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0041] Terminology explanation:

[0042] 1. Cross-contract vulnerabilities: refers to security vulnerabilities caused by improper calls, parameter transfer or state dependencies between contracts during the interaction between multiple smart contracts. Such vulnerabilities may only be triggered in a specific contract interaction sequence, which increases the complexity of vulnerability detection.

[0043] 2. Fuzz Testing: An automated testing technique that inputs a large amount of random or specially crafted data into the software to detect whether the program crashes, behaves abnormally, or has security vulnerabilities when processing these inputs. Fuzz testing aims to discover potential code defects and security risks.

[0044] 3. Large Language Model (LLM): An AI model trained with a large amount of text data that can understand and generate text in natural language or programming language. Large language models are gradually being used for tasks such as automatic generation of test cases and code completion due to their ability to understand code.

[0045] 4. Path complexity analysis: By analyzing the complexity of function calls and branch structures in the program, the difficulty of a code path can be determined. Path complexity analysis helps identify the most challenging parts of the test, thereby optimizing the use of test resources.

[0046] 5. Static analysis: A technique that discovers potential problems by analyzing the static properties of source code or bytecode (without executing the code). Static analysis can detect syntax errors, potential security vulnerabilities, and code quality issues.

[0047] 6. Dynamic analysis: A technique for monitoring and analyzing the behavior of a program while it is running. This type of analysis can capture the actual execution of the program, thereby discovering runtime errors and security vulnerabilities.

[0048] 7. Prompt: When using a large language model, it refers to the prompt information or questions input to the model. The design of the prompt directly affects the quality and relevance of the output generated by the model. A good prompt can guide the model to generate more accurate and effective results.

[0049] 8. Genetic Algorithm: An optimization algorithm based on the principles of natural selection and genetics that searches for the optimal solution by simulating the biological evolution process. Genetic algorithms are often used to solve complex optimization problems, such as test case generation.

[0050] 9. Graph Neural Network (GNN): A type of neural network model used to process graph structured data, which can effectively capture the relationship and structural information between nodes. In smart contracts, it can be used to model the dependencies between contracts.

[0051] 10. Code coverage: The ratio of the number of lines of code executed during the test to the total number of lines of code. High code coverage means that the test cases can effectively touch different paths in the program, thereby improving the effectiveness of vulnerability detection.

[0052] Embodiment 1:

[0053] See also Figure 1 , a cross-contract vulnerability fuzz testing method provided in an embodiment of the present invention includes:

[0054] Step 101: randomly generate test cases through fuzz testing method and input them into the system, so that the system executes the smart contract, detects vulnerabilities and analyzes the code path coverage.

[0055] In one embodiment, the fuzz testing method in step 101 includes: a fuzz testing engine, reinforcement learning, and a genetic algorithm.

[0056] It should be noted that the fuzz testing method of this embodiment adopts engine fuzz testing to randomly generate test cases. Furthermore, the fuzz testing engine can be replaced by other fuzz testing methods, such as fuzz testing methods based on reinforcement learning or genetic algorithms. These intelligent test generation methods can improve the efficiency of cross-contract vulnerability detection by continuously optimizing the generated test cases, and can also improve code coverage and vulnerability discovery rate when combined with large language models.

[0057] In one embodiment, in step 101, detecting a vulnerability includes:

[0058] When a preset abnormal situation occurs during the execution of a smart contract, it is determined that a vulnerability exists in the smart contract. The preset abnormal situations include: call failure, inconsistent state, and rollback error; or, the execution process of the smart contract is monitored in combination with the threshold vulnerability feature library to identify the vulnerabilities of the smart contract.

[0059] It should be noted that after the smart contract is executed, the results of each smart contract execution are analyzed to determine whether known vulnerabilities are triggered. Specifically, it is mainly through monitoring whether there are abnormal situations during the execution process, such as call failure, inconsistent state, rollback error, etc. In addition, it can also be matched with the existing vulnerability feature library to automatically identify potential risks.

[0060] In one embodiment, in step 101, analyzing the code path coverage includes:

[0061] Determine the coverage of the current test case by analyzing the function call stack, execution branches, and loop structure during smart contract execution.

[0062] It should be noted that in order to evaluate the effectiveness of the test case, the coverage of the code path is analyzed. The call sequence across contracts is complex, and the analysis of path coverage can help determine whether the fuzz test has effectively explored different execution paths in the code. Specifically, the coverage of the current test case is determined by analyzing the function call stack, execution branch, and loop structure during the execution of the smart contract.

[0063] Step 102 , determine whether the preset test time has been reached or whether the code covers all paths, if so, execute step 104 , otherwise execute step 103 .

[0064] Step 103, when coverage stagnation occurs or complex branches appear, generate mutation test cases through the pre-trained model, and return the test cases to step 101 as test cases. When coverage stagnation does not occur or preset complex branches do not appear, return to step 101.

[0065] In one embodiment, the analysis method for complex branches in step 103 includes:

[0066] Through dynamic analysis, determine whether there are preset complex branches, including: nested loops and frequent conditional judgments; or, determine whether there are complex branches through static analysis tools.

[0067] It should be noted that during the fuzzy testing process, when complex branches appear (such as nested loops and frequent conditional judgments), randomly generated test inputs may not be sufficient to continue exploring new paths. Specifically, the present invention uses dynamic analysis combined with path complexity judgment to trigger the large language model to generate test cases, but path screening can also be performed through static analysis. Static analysis tools can analyze the call graph and branch structure of the contract in advance, combine the dependencies and interaction complexity of the contract, determine which paths need to be tested, and then call the large language model to generate test cases.

[0068] In one embodiment, the pre-trained model in step 103 includes: a large language model, a model based on the Transformer architecture, and a graph neural network.

[0069] It should be noted that the present invention uses a large language model for illustration. In addition to large language models (such as the GPT series), other pre-trained models or custom models can be considered for test case generation. For example, a model based on the Transformer architecture can be used, or a graph neural network (GNN) can be combined to model the call dependencies between contracts and generate variant test cases. These models can also generate effective test cases in complex function call scenarios.

[0070] In one embodiment, when the pre-trained model is a large language model, in step 103, a mutation test case is generated by the pre-trained model, including: according to the vulnerability detection situation and the code path coverage analysis situation, prompts are designed and input into the pre-trained model, so that the pre-trained model outputs a mutation test case.

[0071] It should be noted that different strategies can be used to design prompts for large language models. For example, in addition to the current prompt design based on function signatures and input and output, more complex and accurate test cases can be generated by using code snippets as input or combining more contextual information (such as historical interaction records between contracts, path features, etc.).

[0072] Step 104: Obtain code path coverage and vulnerability detection results.

[0073] The present invention provides a cross-contract vulnerability fuzz testing method. First, the existing fuzz testing technology has a low coverage rate for complex paths in the detection of cross-contract vulnerabilities, especially in the scenario of multiple contract interactions. The present invention generates complex test cases by introducing a large language model, which can better solve the problems of function call order and interleaving in cross-contract vulnerabilities. The ability of the large language model in code semantic understanding and generation enables the present invention to generate more targeted and effective test cases, especially when the growth of fuzzy test code coverage stagnates, significantly improving the depth and efficiency of detection. Secondly, the present invention uses an intelligent scheduling mechanism combined with path complexity analysis to determine the calling time of the large language model, avoiding wasting resources on simple paths. Compared with existing technical solutions, the present invention can more accurately screen complex branches, improve the utilization efficiency of fuzzy test resources, and effectively reduce testing time.

[0074] Embodiment 2:

[0075] The cross-contract vulnerability fuzzy testing method of the present invention is described below through a specific cross-contract vulnerability fuzzy testing system:

[0076] The cross-contract vulnerability detection system of the present invention consists of the following modules:

[0077] Fuzz testing engine 201: used to perform basic fuzz testing tasks and detect vulnerabilities in smart contracts by randomly generating test inputs. This module is responsible for managing the execution of contracts and path coverage analysis. When the coverage growth of fuzz testing in a certain branch stagnates, it will trigger the call of the large language model module.

[0078] It should be noted that the fuzz testing engine is the core module of the system, which is used to randomly generate inputs and perform interactive tests on multiple smart contracts. The functions of the fuzz testing engine include:

[0079] Test input generation: Automates calls between smart contracts by randomly generating function calls, parameters, and interaction sequences.

[0080] Path coverage analysis: During the test execution process, the system will monitor the path coverage of the contract code in real time and record the coverage rate of each test.

[0081] Coverage stagnation detection: When the engine finds that the coverage of a branch has not improved for a long time, or is stagnant on a specific interaction path, it sends a signal to the code path screening module to screen complex paths.

[0082] Large language model module 202: Generates mutated test cases by calling the pre-trained large language model, especially for complex code paths with low coverage. This module generates targeted and sequentially dependent test cases through carefully designed prompt input, thereby improving the coverage of cross-contract vulnerabilities.

[0083] It should be noted that the large language model module generates complex test cases through pre-trained LLM (such as the GPT series), which is particularly suitable for generating test inputs with complex function call sequences and dependencies when multiple contracts interact. Its specific implementation includes:

[0084] Prompt design: By designing specific prompt input for the large language model, the function signature, input and output information, and target path conditions of the contract are provided. The goal of prompt design is to generate effective test cases that can meet complex conditions.

[0085] Mutation test case generation: When the fuzz testing engine triggers an LLM call, the model generates targeted mutation test cases based on the executed branch conditions. These cases usually have higher code coverage and are especially effective in dealing with function interleaving and dependencies.

[0086] Code path screening module 203: This module is used to analyze the execution of fuzz testing and identify those complex code paths that are difficult to cover with random test inputs. The screening module determines whether it is necessary to call the large language model to generate new test cases by setting multiple indicators (such as the complexity of branch conditions, the dependency of function calls, etc.).

[0087] It should be noted that the core function of the code path screening module is to screen out complex and difficult-to-cover code paths in order to trigger the call of the large language model. This is mainly achieved through the following steps:

[0088] Path Complexity Analysis: Identifies paths that are difficult to cover with random test inputs by analyzing function call dependencies, interaction order, and the complexity of branch conditions.

[0089] Determine the timing of calling: When the coverage growth of a branch stagnates or the number of mutations reaches a certain upper limit, the system will determine whether it is necessary to call the large language model to generate test cases.

[0090] Result analysis module 204: Analyze the results of each fuzz test, record the coverage of the code path, and classify and record each test case. If some branches have low coverage or are not triggered, the system will generate a warning to indicate potential cross-contract vulnerabilities.

[0091] It should be noted that the result analysis module is responsible for summarizing and recording the execution of each fuzz test. This module will analyze the effects of the generated test cases, the coverage improvement, and the triggering of potential vulnerabilities, and classify and summarize the detection results of cross-contract vulnerabilities.

[0092] The following is a description of the test process of the above cross-contract vulnerability fuzz testing system. Please refer to Figure 2 :

[0093] 1. Start the fuzz test engine: The fuzz test engine is the core startup module of the entire system, which is responsible for initializing the fuzz test process. The engine mainly receives the test contract and test input data, randomly generates test case input or calls the large language model to generate new test cases. The steps to start the engine include:

[0094] Initialize the test environment;

[0095] Randomly generate initial test input;

[0096] Load the target smart contract code;

[0097] Start executing the contract.

[0098] 2. Randomly generate test input: One of the basic principles of fuzz testing is to explore different execution paths of the program as widely as possible by randomly generating test input. In cross-contract vulnerability detection, the interaction paths of multiple contracts may be very complex, and randomly generated test input can cover simple paths without any specific direction.

[0099] 3. Contract execution: During the fuzz testing process, the contract will run in the blockchain virtual machine, and all calls and interactions will be recorded. The contract execution module is responsible for completing the execution task according to the business logic of the specified contract under the set input.

[0100] 4. Vulnerability detection: This module will analyze the results of each contract execution to determine whether a known vulnerability has been triggered. The vulnerability detection module mainly monitors whether there are abnormal situations during the execution process, such as call failure, inconsistent status, rollback error, etc. In addition, it can also be matched with the existing vulnerability feature library to automatically identify potential risks.

[0101] 5. Code path coverage analysis: In order to evaluate the effectiveness of the test case, the system will analyze the coverage of the code path. The call sequence across contracts is complex, and the analysis of path coverage can help determine whether the fuzz test has effectively explored different execution paths in the code. This module determines the coverage of the current test case by analyzing the function call stack, execution branches, and loop structure during contract execution.

[0102] 6. Coverage stagnation or complex branch judgment: During the fuzz testing process, when coverage stagnates or complex branches appear (such as nested loops and frequent conditional judgments), the randomly generated test input may not be sufficient to continue exploring new paths. At this time, the present invention introduces a key step: calling the large language model to generate new test cases.

[0103] 7. Calling the large language model to generate new test cases: The introduction of the large language model is one of the core innovations of this invention. By calling the pre-trained large language model, more targeted test inputs are generated. The large language model generates appropriate inputs based on previous test results and currently uncovered code paths, helping to explore deeper cross-contract call sequences.

[0104] 8. Generate new test cases and execute: After generating new test inputs, the system will execute the contract again and perform vulnerability detection and path analysis. In this way, the test cases generated by the language model can help break through the paths that the original fuzz test cannot cover, especially for the coverage of complex paths.

[0105] 9. Analyze coverage / vulnerabilities and output results: The system will continue to loop the above steps until all paths are covered or the specified test time is reached. When the test is completed, the system will automatically output all coverage data and detected vulnerability results. These data will provide a basis for further vulnerability repair and security analysis.

[0106] After the system is started, the fuzz testing engine is used to randomly generate test inputs and perform interactive operations between multiple contracts.

[0107] As fuzz testing progresses, the system will perform coverage analysis on the code paths. If the coverage of certain paths reaches a bottleneck or cannot be further improved in complex function interleaving scenarios, the system will call the large language model to generate new test cases.

[0108] The large language model module generates mutation test cases based on preset prompts. These cases are more targeted, especially when dealing with complex paths, and can generate accurate function call sequences.

[0109] The generated test cases are further executed through the fuzz testing engine, and the test results are fed back to the result analysis module to analyze the coverage and vulnerability information.

[0110] The above is a cross-contract vulnerability fuzz testing method provided in an embodiment of the present invention, and the following is a cross-contract vulnerability fuzz testing device provided in an embodiment of the present invention.

[0111] See also Figure 3 , a cross-contract vulnerability fuzz testing device provided in an embodiment of the present invention includes:

[0112] The testing unit 301 is used to randomly generate test cases through a fuzzy testing method and input them into the system, so that the system executes the smart contract, detects vulnerabilities, and analyzes the code path coverage.

[0113] The analyzing unit 302 is used to determine whether the preset test time is reached or whether the code covers all paths. If so, the acquiring unit 304 is triggered, otherwise, the generating unit 303 is triggered.

[0114] The generation unit 303 is used to generate a variation test case through a pre-trained model when coverage stagnation occurs or a complex branch appears, and use the test case as a test case and trigger the test unit 301. When coverage stagnation does not occur or a preset complex branch does not appear, the test unit 301 is triggered.

[0115] The acquisition unit 304 is used to obtain code path coverage and vulnerability detection results.

[0116] Furthermore, an embodiment of the present invention also provides a cross-contract vulnerability fuzz testing device, the device including a processor and a memory:

[0117] The memory is used to store program code and transmit the program code to the processor;

[0118] The processor is used to execute the steps of the cross-contract vulnerability fuzz testing method as described in the above method embodiment according to the instructions in the program code.

[0119] Furthermore, an embodiment of the present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store program codes, and the program codes are used to execute the method described in the above method embodiment.

[0120] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and units can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0121] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

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

[0123] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0124] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for 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 of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0125] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A cross-contract vulnerability fuzz testing method, characterized in that: include: S1. Generate test cases randomly through fuzz testing method and input them into the system, so that the system can execute smart contracts, detect vulnerabilities and analyze code path coverage; S2, determine whether the preset test time has been reached or whether the code covers all paths, if so, execute step S4, otherwise execute step S3; S3, when coverage stagnation occurs or complex branches appear, generate a variant test case through the pre-trained model, and return the test case as the test case to step S1; when coverage stagnation does not occur or the preset complex branch does not appear, return to step S1; S4. Obtain code path coverage and vulnerability detection results.

2. The cross-contract vulnerability fuzz testing method according to claim 1 is characterized in that: The pre-trained model includes: a large language model, a model based on the Transformer architecture, and a graph neural network.

3. The cross-contract vulnerability fuzz testing method according to claim 1 is characterized in that: The vulnerability detection includes: When a preset abnormal situation occurs during the execution of the smart contract, it is determined that the smart contract has a vulnerability, and the preset abnormal situation includes: call failure, inconsistent state, and rollback error; Alternatively, the execution process of the smart contract is monitored in combination with a threshold vulnerability feature library to identify the vulnerabilities of the smart contract.

4. The cross-contract vulnerability fuzz testing method according to claim 1 is characterized in that: The analysis of code path coverage includes: By analyzing the function call stack, execution branches and loop structure when the smart contract is executed, the coverage of the current test case is determined.

5. The cross-contract vulnerability fuzz testing method according to claim 1, characterized in that: The analysis method for the occurrence of the complex branch includes: Dynamically analyzing whether there are preset complex branches, wherein the preset complex branches include: loop nesting and frequent conditional judgment; Or, use static analysis tools to determine whether complex branches occur.

6. The cross-contract vulnerability fuzz testing method according to claim 2, characterized in that: When the pre-trained model is the large language model, generating a variation test case through the pre-trained model includes: According to the vulnerability detection situation and the code path coverage analysis situation, prompts are designed and input into the pre-trained model, so that the pre-trained model outputs mutation test cases.

7. The cross-contract vulnerability fuzz testing method according to claim 1, characterized in that: The fuzz testing method includes: a fuzz testing engine, reinforcement learning and a genetic algorithm.

8. A cross-contract vulnerability fuzz testing device, characterized in that: include: The test unit is used to randomly generate test cases through fuzz testing methods and input them into the system, so that the system can execute smart contracts, detect vulnerabilities, and analyze code path coverage; The analysis unit is used to determine whether the preset test time has been reached or whether the code covers all paths. If so, the acquisition unit is triggered, otherwise the generation unit is triggered; A generation unit, used for generating a variation test case through a pre-trained model when a coverage stagnation occurs or a complex branch appears, and using the test case as the test case and triggering the test unit, and triggering the test unit when a coverage stagnation does not occur or a preset complex branch does not appear; The acquisition unit is used to obtain code path coverage and vulnerability detection results.

9. A cross-contract vulnerability fuzz testing device, characterized in that: The device comprises a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the cross-contract vulnerability fuzz testing method described in any one of claims 1-7 according to the instructions in the program code.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium is used to store program code, and the program code is used to execute the cross-contract vulnerability fuzz testing method described in any one of claims 1-7.

Images