Intelligent contract vulnerability detection method and system based on parallel fuzzy test

Abstract

The invention discloses an intelligent contract vulnerability detection method and system based on parallel fuzzy testing, and the method comprises the following steps: S1, statically analyzing an intelligent contract code, and obtaining a to-be-detected function sequence which may have vulnerabilities according to keywords of the vulnerabilities; s2, for each to-be-tested function, regarding the input and non-local variables of the to-be-tested function as the input variables of the function, generating a test case through a fuzzer, and generating a test case set; s3, performing parallel testing on the test case set by using processes, and performing parallel testing on different test cases by using threads; and S4, analyzing a detection result to obtain a vulnerability detection report. According to the method, the smart contract is analyzed through the static tool, the key vulnerability function is identified, the test case is generated by using the fuzzer, the process and thread parallel test is adopted, the detection report is efficiently generated according to the preset rule, the detection efficiency, the accuracy and F1-score are improved, high-quantity detection is realized, and the security of the smart contract is guaranteed.

Description

Technical Field

[0001] The present invention belongs to the field of network security technology, and more specifically, particularly relates to a smart contract vulnerability detection method and system based on parallel fuzzy testing. Background Art

[0002] Smart contracts are an important part of blockchain. They are essentially a promise defined in digital form, representing the obligations and responsibilities that contract participants should fulfill. On the one hand, when smart contracts are deployed to blockchain, the terms in the contract will be automatically executed and cannot be tampered with; on the other hand, there are a large number of digital assets in smart contracts. Therefore, once hackers have conquered smart contracts, they can obtain huge amounts of digital assets that are difficult to recover. This has led to frequent smart contract security incidents in recent years, resulting in heavy economic losses.

[0003] At present, dozens of smart contract vulnerabilities have been discovered, including delegate call vulnerabilities, block information dependency vulnerabilities, ether freezing vulnerabilities, short address attack vulnerabilities, and reentrancy vulnerabilities. Detecting these vulnerabilities before deploying smart contracts can help developers patch them in time, greatly reducing the risk of smart contracts being exploited.

[0004] Generally speaking, smart contract vulnerability detection methods can be divided into two categories: static detection and dynamic detection. The difference between the two lies in whether the smart contract needs to be deployed to the blockchain during detection. Symbolic execution, formal verification, intermediate representation, and machine learning belong to static detection methods. Fuzzy detection is a typical dynamic detection method.

[0005] However, there are some problems with the existing technology: First, due to the huge input space of smart contracts and limited testing resources, the testing process is time-consuming and difficult to fully cover all potential vulnerabilities, resulting in low detection efficiency. Second, fuzz testing may produce false positives and false negatives, making it difficult to accurately identify complex vulnerabilities and vulnerabilities triggered by specific contexts, resulting in low test accuracy. Therefore, we propose a smart contract vulnerability detection method and system based on parallel fuzz testing. Summary of the invention

[0006] In view of the problems existing in the prior art, the purpose of the present invention is to provide a smart contract vulnerability detection method and system based on parallel fuzz testing, which analyzes smart contracts through static analysis tools and identifies the functions to be tested related to key vulnerabilities. For each function, its input and non-local variables are regarded as input variables, and a large number of test cases are generated through the fuzzer. These cases are tested in parallel using processes and threads, and detection reports are efficiently generated based on preset vulnerability detection rules. This method significantly improves detection efficiency, accuracy and F1-score, achieves a high number of detections per unit time, and provides a strong guarantee for the security of smart contracts.

[0007] To achieve the above object, the present invention provides the following technical solution: a smart contract vulnerability detection method and system based on parallel fuzzy testing, comprising the following steps:

[0008] S1. Statically analyze the smart contract code and obtain the function sequence to be tested that may have vulnerabilities based on the vulnerability keywords;

[0009] S2. For each function to be tested, its own input and non-local variables are considered as input variables of the function, and a large number of test cases are generated through the fuzzer, and a test case set is generated for each function;

[0010] S3. Use process parallel testing for test case sets of different functions to be tested, and use thread parallel testing for different test cases in each test case set;

[0011] S4. Analyze the detection results and obtain a vulnerability detection report.

[0012] Optionally, the specific process of step S1 is:

[0013] S11, reading the source code or bytecode of the smart contract, including extracting the structure, function definition and variable declaration;

[0014] S12, analyzing the smart contract code through static analysis tools, extracting information such as functions, variables, and control flow graphs, and obtaining analyzed code;

[0015] S13, based on known smart contract vulnerabilities, define a keyword list, and based on the keyword list, traverse the analyzed code to obtain functions that may contain vulnerabilities;

[0016] S14, marking the functions that may contain vulnerabilities as functions to be tested, and generating a sequence of functions to be tested.

[0017] Optionally, the specific process of step S2 is:

[0018] S21, identifying the direct input parameters of each function to be tested, and treating the non-local variables in the function as input variables, and performing name standardization;

[0019] S22, configure the fuzzifier, specify the type, range and constraints of the input variables,

[0020] S23, generating a test case for each function to be tested through the fuzzer, and organizing the generated test cases into a test case set;

[0021] The non-local variables include global variables defined in the contract and information lookup variables of the block;

[0022] The fuzzer is a common tool for fuzz testing, which is used to assign randomly generated values ​​to the input parameters of the function;

[0023] The test case refers to a set of input values ​​generated by the fuzzer for the function.

[0024] Optionally, the specific process of step S3 is:

[0025] S31, assigning a process to test each function to be tested in the function set to be tested;

[0026] S32, allocating a thread to test each test case in the test case set corresponding to each function to be tested.

[0027] Optionally, the process test in S31 is specifically:

[0028] 1) Obtain the function set Fv to be tested;

[0029] 2) Initialize the process pool, traverse the set of functions to be tested Fv, and assign an idle process to Fv from the process pool. If there is no idle process, wait for the process to be released;

[0030] 3) Start the task of the assigned process and monitor the process execution status;

[0031] 4) Collect test results and release the process that completed the test for subsequent use.

[0032] Optionally, the thread test in S32 is specifically:

[0033] 1) For each function to be tested f, configure a set Tv containing all its test cases;

[0034] 2) Set up thread pools based on system resources and test requirements;

[0035] 3) Traverse the test case set Tv of each function to be tested f and allocate idle threads;

[0036] 4) Start and monitor thread execution and collect test results.

[0037] Optionally, the allocating a process for testing is specifically:

[0038] 1) Initialize the process queue, add all processes that need to be scheduled to the queue, and sort them according to priority;

[0039] 2) The scheduler selects the process with the highest priority from the queue to execute the test of the function to be tested;

[0040] 3) When a process is executing and there is an idle process with a higher priority, the higher priority process will be executed;

[0041] 4) When a process is blocked or completed during execution, the scheduler selects the process with the highest priority from the ready queue to execute again;

[0042] 5) Repeat the above process until all the functions to be tested are tested;

[0043] The priority of the queue is determined according to the arrival time and execution time of the process.

[0044] Optionally, the specific process of step S4 is:

[0045] S41, preset vulnerability judgment rules, clarify the characteristics, detection conditions and judgment criteria of each vulnerability;

[0046] S42, collecting the test results of each function to be tested in the parallel test process, including the execution status, exception information, execution time, etc. of the test case, and arranging the analysis format;

[0047] S43, analyzing the collected detection results according to the preset vulnerability judgment rules, and further analyzing the detailed information of the vulnerability, such as the vulnerability type, location, impact range, etc., for the vulnerability features matching the rules;

[0048] S44, generating a vulnerability detection report according to the analysis result;

[0049] The vulnerability detection report includes: vulnerability overview, vulnerability details, repair suggestions, test case set, and preset vulnerability judgment rules.

[0050] Optionally, the vulnerability judgment rule includes:

[0051] Delegate call vulnerability judgment rules: whether this test triggers the delegatecall instruction and whether the global variables of the smart contract are modified;

[0052] Reentrancy vulnerability judgment rules: whether this test triggers reentry and whether the account balance is abnormal after execution;

[0053] Block parameter dependency vulnerability judgment rules: Check whether block parameters are used and participate in the calculation within the smart contract;

[0054] Self-destruction vulnerability judgment rules: Determine whether there is a self-destruction vulnerability based on the flow of tokens and the status of the contract.

[0055] A smart contract vulnerability detection system based on parallel fuzz testing, the system is used to implement the above method, including:

[0056] Smart contract compilation and parsing module: used to compile smart contracts, generate opcodes or bytecodes, and parse them;

[0057] Test case generation module: Generates initial test cases based on the functions and vulnerability types of smart contracts. The test cases contain various possible input data and function call sequences;

[0058] Parallel fuzz testing module: Use multi-threading or distributed computing to run multiple fuzz testing instances simultaneously. Each test instance independently performs a large amount of random data input tests on the smart contract to find vulnerabilities. After the test is completed, the results are collected and returned.

[0059] Vulnerability detection and verification module: Analyze the abnormal behaviors found by the parallel fuzz testing module to detect whether there are vulnerabilities;

[0060] Test report generation module: generates a test report based on the results of the vulnerability detection and verification module. The test report includes a list of discovered vulnerabilities, vulnerability descriptions, vulnerability impact scope, and repair suggestions;

[0061] Logging and monitoring module: records the log information of the entire test process, including the execution of test cases, the capture of abnormal behaviors, and monitors the test process in real time;

[0062] Resource management module: manages the resources required during the testing process, including computing resources and storage resources.

[0063] The technical effects and advantages of the present invention are as follows: the present invention analyzes the main information of the smart contract through a static analysis tool, obtains the tested functions that may have vulnerabilities based on some keywords, and then for each tested function, considers its own input and non-local variables as the input variables of the function, generates a large number of test cases through a fuzzer, generates a test case set for each function, and then tests the large number of test cases in a combination of processes and threads, and finally generates a detection report according to preset vulnerability detection rules. The entire detection method has high detection efficiency, high accuracy and F1-score, and a high number of detections per unit time.

[0064] Further features and advantages of the present invention will become apparent from the following detailed description of exemplary embodiments of the present invention with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Figure 1 It is a schematic flow chart of the method provided by the present invention;

[0066] Figure 2 It is a schematic diagram of test case generation provided by the present invention;

[0067] Figure 3 It is a schematic diagram of the process allocation of the fuzzy test provided by the present invention;

[0068] Figure 4It is a thread allocation diagram of the fuzzy test provided by the present invention;

[0069] Figure 5 This is a comparison diagram of the fuzzy tool test effect provided by the present invention;

[0070] Figure 6 It is a framework diagram of the method provided by the present invention. DETAILED DESCRIPTION

[0071] In order to make the purpose, technical scheme and advantages of the present invention clearer, the present invention is further described in detail below in conjunction with specific embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0072] like Figures 1 to 6 As shown, an embodiment of the present invention provides a smart contract vulnerability detection method based on parallel fuzz testing, including the following operations:

[0073] S1. Statically analyze the smart contract code and obtain the function sequence to be tested that may have vulnerabilities based on the vulnerability keywords;

[0074] S2. For each function to be tested, its own input and non-local variables are considered as input variables of the function, and a large number of test cases are generated through the fuzzer, and a test case set is generated for each function;

[0075] S3. Use process parallel testing for test case sets of different functions to be tested, and use thread parallel testing for different test cases in each test case set;

[0076] S4. Analyze the detection results and obtain a vulnerability detection report.

[0077] Furthermore, the present invention realizes efficient and comprehensive vulnerability detection by combining static analysis with fuzzy testing. First, the function to be tested is accurately located through static analysis, which greatly reduces the detection scope. Secondly, the input variables are extended to non-local variables, which improves the comprehensiveness and depth of the test cases. Furthermore, the parallel processing technology of processes and threads is used to significantly improve the detection efficiency, and more test cases can be processed per unit time. Finally, a vulnerability detection report is automatically generated to ensure the accuracy and reliability of the detection results. This method not only improves the detection efficiency, but also reduces the risk of missed reports and false reports, providing a strong guarantee for the security of smart contracts.

[0078] Specifically, the specific process of step S1 is:

[0079] S11, reading the source code or bytecode of the smart contract, including extracting the structure, function definition and variable declaration;

[0080] S12, analyzing the smart contract code through static analysis tools, extracting information such as functions, variables, and control flow graphs, and obtaining analyzed code;

[0081] S13, based on known smart contract vulnerabilities, define a keyword list, and based on the keyword list, traverse the analyzed code to obtain functions that may contain vulnerabilities;

[0082] S14, marking the functions that may contain vulnerabilities as functions to be tested, and generating a sequence of functions to be tested.

[0083] It should be noted that the predefined keywords closely related to the vulnerability may trigger the vulnerability only when the smart contract uses such keywords. If such keywords are not used, the smart contract cannot have such vulnerabilities. The vulnerabilities and corresponding keywords are detailed in Table 1:

[0084] Table 1: Vulnerabilities and corresponding keywords

[0085]

[0086] For any function f in the smart contract, if the above keywords exist, the function may have a vulnerability, and the function is defined as a potential vulnerability function f v All F in a smart contract v It constitutes a potential vulnerability function sequence Fv = [f v1 ,f v2 ,f v3 ,f v4 ].

[0087] Specifically, the specific process of step S2 is:

[0088] S21, identifying the direct input parameters of each function to be tested, and treating the non-local variables in the function as input variables, and performing name standardization;

[0089] S22, configure the fuzzifier, specify the type, range and constraints of the input variables,

[0090] S23, generating a test case for each function to be tested through the fuzzer, and organizing the generated test cases into a test case set;

[0091] The non-local variables include global variables defined in the contract and information lookup variables of the block;

[0092] The fuzzer is a common tool for fuzz testing, which is used to assign randomly generated values ​​to the input parameters of the function;

[0093] The test case refers to a set of input values ​​generated by the fuzzer for the function.

[0094] Furthermore, the specific operation of variable merging is: define a non-local variable sequence Including the parameters and global variables of the block itself. If a function is used by V * , then V * It will also be used as the input variable V' of the function, and the subsequent fuzzifier will also generate random values ​​for such variables. Formally, a function's input sequence V' = [V1', V2', V3', V4'] will be composed of the input variable sequence V' and the non-local variable sequence V * Composition, that is Variable merging increases the dimension of test cases, making all paths testable, and effectively avoiding the shortcoming of fuzzy testing detection methods that test cases cannot cover vulnerability paths.

[0095] Furthermore, in the specific operation of the fuzzer generating test cases, the fuzzer will start with simple, randomly generated inputs, and generate some random function calls and parameters according to the input format of the contract. The generation of the initial input can be completely random, or more meaningful input can be generated based on historical data or prior knowledge; then, based on the initial input, the fuzzer will perform a series of mutation operations to obtain a large number of different test cases, which are a set of random values ​​of function variables. Finally, all the test cases generated by the fuzzer for the function are stored in the test case collection.

[0096] like Figure 2 The detailed process of test case generation shown in the figure is to generate a test case for each potential vulnerability function f in the contract to be tested. v Generate test cases. The input parameter of the algorithm is the set of potential vulnerability functions F v , the output is a set of potential vulnerability function test cases T v First, initialize F v 、T v , test case generation time Maxtime, test case generation quantity MaxSize and mutation rate MutationRate (first line); for each test function f in the test function set vi (Second row); both generate a large number of test cases t v (third line); then t v Insert test case set T v(Line 4); The specific function Test_case_generation for generating test cases is shown in (Lines 7-18); First, initialize the current test case generation set CurrentSet to an empty set (Line 8); then generate a new test case based on the mutation rate (Line 10); if the test case meets the variable type requirements (Line 11); then add the test case to CurrentSet (Line 12); repeat the test case generation process until timeout or the number of test cases reaches the upper limit (Line 9).

[0097] Specifically, the specific process of step S3 is:

[0098] S31, assigning a process to test each function to be tested in the function set to be tested;

[0099] S32, allocating a thread to test each test case in the test case set corresponding to each function to be tested.

[0100] The process test in S31 is specifically as follows:

[0101] 1) Get the function set F to be tested v ;

[0102] 2) Initialize the process pool and traverse the set of functions to be tested F v , assign an idle process from the process pool to F v , if there is no idle process, wait for the process to be released;

[0103] 3) Start the task of the assigned process and monitor the process execution status;

[0104] 4) Collect test results and release the process that completed the test for subsequent use.

[0105] The thread test in S32 is specifically as follows:

[0106] 1) For each function f to be tested, configure a set T containing all its test cases v ;

[0107] 2) Set up thread pools based on system resources and test requirements;

[0108] 3) Traverse the test case set T of each function f to be tested v , and allocate idle threads;

[0109] 4) Start and monitor thread execution and collect test results.

[0110] Furthermore, the advantage of using a combination of processes and threads is that it significantly improves the efficiency of calculations, allowing more test cases to be detected per unit time, which can indirectly improve the accuracy of the detection results;

[0111] like Figure 3 The process allocation algorithm of the fuzz test shown in the figure aims to allocate a process to each function to be tested. The input of the algorithm is the set of functions to be tested F v , maximum number of processes P max , the output is the result set of the test case execution;

[0112] First, a vulnerable function fv is taken from the set of functions to be tested, and a process is assigned to it (lines 2-4). The functions to be tested are taken out and assigned to processes repeatedly until all processes p in all process pools P are assigned (line 1).

[0113] Then, monitor the processes in the process pool P and collect the test results r;

[0114] When a test is finished, r is stored in R;

[0115] When a process p finishes executing, it releases p and assigns it a new function to be tested (line 6);

[0116] After all test case sets are tested, the test result set R is returned (line 7);

[0117] Different test cases in each test case set are tested in parallel using threads. The specific operation is as follows: Similar to the thread allocation method, the fuzzy test thread allocation algorithm is as follows: Figure 4 As shown:

[0118] The input parameter of the algorithm is the set of functions to be tested T v , Maximum number of threads TP max , the output is the result set of the test case execution;

[0119] First, from the function to be tested f v The corresponding test case set T v Take out a test case t v , assign a thread to it (lines 2-4);

[0120] Until all threads tp in all thread pools TP are allocated (line 1);

[0121] Then, monitor the threads of the thread pool TP, collect the test results r, and store r in R. When a thread tp finishes execution;

[0122] Release tp and reallocate a function to be tested to it (line 6);

[0123] Finally, the test result set R is returned (line 7).

[0124] Specifically, the allocation of a process for testing is as follows:

[0125] 1) Initialize the process queue, add all processes that need to be scheduled to the queue, and sort them according to priority;

[0126] 2) The scheduler selects the process with the highest priority from the queue to execute the test of the function to be tested;

[0127] 3) When a process is executing and there is an idle process with a higher priority, the higher priority process will be executed;

[0128] 4) When a process is blocked or completed during execution, the scheduler selects the process with the highest priority from the ready queue to execute again;

[0129] 5) Repeat the above process until all the functions to be tested are tested;

[0130] The priority of the queue is determined according to the arrival time and execution time of the process.

[0131] Specifically, the specific process of step S4 is:

[0132] S41, preset vulnerability judgment rules, clarify the characteristics, detection conditions and judgment criteria of each vulnerability;

[0133] S42, collecting the test results of each function to be tested in the parallel test process, including the execution status, exception information, execution time, etc. of the test case, and arranging the analysis format;

[0134] S43, analyzing the collected detection results according to the preset vulnerability judgment rules, and further analyzing the detailed information of the vulnerability, such as the vulnerability type, location, impact range, etc., for the vulnerability features matching the rules;

[0135] S44, generating a vulnerability detection report according to the analysis result;

[0136] The vulnerability detection report includes: vulnerability overview, vulnerability details, repair suggestions, test case set, and preset vulnerability judgment rules.

[0137] The vulnerability judgment rules include:

[0138] Delegate call vulnerability judgment rules: whether this test triggers the delegatecall instruction and whether the global variables of the smart contract are modified;

[0139] Reentrancy vulnerability judgment rules: whether this test triggers reentry and whether the account balance is abnormal after execution;

[0140] Block parameter dependency vulnerability judgment rules: Check whether block parameters are used and participate in the calculation within the smart contract;

[0141] Self-destruction vulnerability judgment rules: Determine whether there is a self-destruction vulnerability based on the flow of tokens and the status of the contract.

[0142] Furthermore, the specific methods of analyzing the detection results are as follows: 1. Analyze the amount and direction of token flow to determine whether there are abnormal transactions;

[0143] 2. Analyze whether the block parameters are involved in numerical calculations, or directly or indirectly affect the results of transactions;

[0144] 3. Analyze whether the transaction is successful, failed, or rolled back;

[0145] 4. Analyze whether the expected return value is obtained and whether the gas (the handling fee when Ethereum executes transactions) consumption is normal.

[0146] To verify the effect of the detection method provided in this embodiment, the following experiments were performed:

[0147] As shown in Table 2, all experiments were conducted on a PC running Ubuntu 22.04. This computer is equipped with an Intel i5 processor, 16GB of memory, and 1TB of storage space. The detection method provided in this embodiment is a Python-based intelligent detection tool, and all experiments are implemented in Python.

[0148] Table 2 Experimental configuration

[0149]

[0150] Dataset: 54,721 smart contracts deployed before October 2024 were collected from Ethereum and labels were provided for these contracts. In this dataset, 713 smart contracts have reentrancy vulnerabilities, 257 smart contracts have block parameter dependency vulnerabilities, 124 smart contracts have self-destruction vulnerabilities, and 131 smart contracts have delegated call vulnerabilities;

[0151] Metrics: The experiment collected four measurement values: true positive (TP), true negative (TN), false positive (FP), and false negative (FN). TP is the number of vulnerable contracts correctly detected by the method; TN is the number of non-vulnerable contracts correctly detected by the method; FP is the number of non-vulnerable contracts mistakenly identified as vulnerable by the method; FN is the number of vulnerable contracts that the method cannot detect; and the detection effect is shown in terms of accuracy, precision, recall, and F1-score;

[0152] Detection efficiency: Table 3 is a table of detection efficiency.

[0153] Table III Comparison of parallel fuzzy detection efficiency

[0154]

[0155] Where T represents the total test time, and Num represents the number of test cases generated by a single function to be tested.

[0156] As can be seen from Table 3, as the number of test cases increases, the number of TPs of parallel fuzz testing cases gradually increases, the branch coverage rate gradually increases, and the speedup ratio of a single contract gradually increases. In other words, the use of parallel fuzz testing to detect smart contract vulnerabilities in this implementation case significantly improves the detection efficiency compared to traditional fuzz testing tools. In addition, the change in the number of TPs may be due to the increased dimensionality of the input variables in S2, which indirectly increases the coverage rate and thus increases the TP.

[0157] Accuracy: In order to analyze the impact of parallel fuzz testing on accuracy, the accuracy of different fuzz testing tools is compared, such as Figure 5 shown.

[0158] The accuracy, precision, recall and F1 of this embodiment (both T and Num select the settings with the highest accuracy) are 90.21%, 70.11%, 99.71% and 82.43% respectively, which are better than the best existing smart contract vulnerability detection tool SFuzz (accuracy, precision, recall and F1 are 82.92%, 89.51%, 72.81% and 80.30% respectively).

[0159] The following conclusions can be drawn from the above experiments:

[0160] a. This embodiment uses parallel fuzz testing, and its accuracy is significantly higher than the currently widely used smart contract vulnerability detection tools based on fuzz testing, such as IR-Fuzz, ContractFuzzer, SFuzz, and XFuzz. This is because parallel fuzz testing improves the detection efficiency of fuzz testing and increases the path coverage, which indirectly improves the detection accuracy.

[0161] b. The recall rate of this embodiment is very high, which means that its FP is very low. The FP of fuzzy testing is often caused by imperfect vulnerability detection rules. The high recall rate means that the judgment rules of this embodiment for fuzzy testing results are more accurate.

[0162] A smart contract vulnerability detection system based on parallel fuzz testing, the system is used to implement the above method, including:

[0163] Smart contract compilation and parsing module: used to compile smart contracts, generate opcodes or bytecodes, and parse them;

[0164] Test case generation module: Generates initial test cases based on the functions and vulnerability types of smart contracts. The test cases contain various possible input data and function call sequences;

[0165] Parallel fuzz testing module: Use multi-threading or distributed computing to run multiple fuzz testing instances simultaneously. Each test instance independently performs a large amount of random data input tests on the smart contract to find vulnerabilities. After the test is completed, the results are collected and returned.

[0166] Vulnerability detection and verification module: Analyze the abnormal behaviors found by the parallel fuzz testing module to detect whether there are vulnerabilities;

[0167] Test report generation module: generates a test report based on the results of the vulnerability detection and verification module. The test report includes a list of discovered vulnerabilities, vulnerability descriptions, vulnerability impact scope, and repair suggestions;

[0168] Logging and monitoring module: records the log information of the entire test process, including the execution of test cases, the capture of abnormal behaviors, and monitors the test process in real time;

[0169] Resource management module: manages the resources required during the testing process, including computing resources and storage resources.

[0170] In summary: the present invention realizes efficient and comprehensive vulnerability detection through the combination of static analysis and fuzzy testing. First, the function to be tested is accurately located through static analysis, which greatly reduces the detection scope. Secondly, the input variables are extended to non-local variables, which improves the comprehensiveness and depth of the test cases. Furthermore, the parallel processing technology of processes and threads is used to significantly improve the detection efficiency, and more test cases can be processed per unit time. Finally, a vulnerability detection report is automatically generated to ensure the accuracy and reliability of the detection results. This method not only improves the detection efficiency, but also reduces the risk of missed reports and false positives, providing a strong guarantee for the security of smart contracts.

[0171] Finally, it should be noted that the above is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, it is still possible for those skilled in the art to modify the technical solutions described in the aforementioned embodiments or to make equivalent substitutions for some of the technical features therein. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A smart contract vulnerability detection method based on parallel fuzz testing, characterized in that: The steps include: S1. Statically analyze the smart contract code and obtain the function sequence to be tested that may have vulnerabilities based on the vulnerability keywords; S2. For each function to be tested, its own input and non-local variables are considered as input variables of the function, and a large number of test cases are generated through the fuzzer, and a test case set is generated for each function; S3. Use process parallel testing for test case sets of different functions to be tested, and use thread parallel testing for different test cases in each test case set; S4. Analyze the detection results and obtain a vulnerability detection report.

2. According to claim 1, a smart contract vulnerability detection method based on parallel fuzz testing is characterized in that: The specific process of step S1 is: S11, reading the source code or bytecode of the smart contract, including extracting the structure, function definition and variable declaration; S12, analyzing the smart contract code through static analysis tools, extracting information such as functions, variables, and control flow graphs, and obtaining analyzed code; S13, based on known smart contract vulnerabilities, define a keyword list, and based on the keyword list, traverse the analyzed code to obtain functions that may contain vulnerabilities; S14, marking the functions that may contain vulnerabilities as functions to be tested, and generating a sequence of functions to be tested.

3. According to claim 1, a smart contract vulnerability detection method based on parallel fuzz testing is characterized in that: The specific process of step S2 is: S21, identifying the direct input parameters of each function to be tested, and treating the non-local variables in the function as input variables, and performing name standardization; S22, configure the fuzzifier, specify the type, range and constraints of the input variables, S23, generating a test case for each function to be tested through the fuzzer, and organizing the generated test cases into a test case set; The non-local variables include global variables defined in the contract and information lookup variables of the block; The fuzzer is a common tool for fuzz testing, which is used to assign randomly generated values ​​to the input parameters of the function; The test case refers to a set of input values ​​generated by the fuzzer for the function.

4. According to claim 1, a smart contract vulnerability detection method based on parallel fuzz testing is characterized in that: The specific process of step S3 is: S31, assigning a process to test each function to be tested in the function set to be tested; S32, allocating a thread to test each test case in the test case set corresponding to each function to be tested.

5. According to claim 4, a smart contract vulnerability detection method based on parallel fuzz testing is characterized in that: The process test in S31 is specifically as follows: 1) Obtain the function set Fv to be tested; 2) Initialize the process pool, traverse the set of functions to be tested Fv, and assign an idle process to Fv from the process pool. If there is no idle process, wait for the process to be released; 3) Start the task of the assigned process and monitor the process execution status; 4) Collect test results and release the process that completed the test for subsequent use.

6. According to claim 4, a smart contract vulnerability detection method based on parallel fuzz testing is characterized in that: The thread test in S32 is specifically as follows: 1) For each function to be tested Fv, configure a set Tv containing all its test cases; 2) Set up thread pools based on system resources and test requirements; 3) Traverse the test case set Tv of each function to be tested f and allocate idle threads; 4) Start and monitor thread execution and collect test results.

7. The method for detecting smart contract vulnerabilities based on parallel fuzz testing according to claim 4, characterized in that: The specific steps of allocating a process for testing are as follows: 1) Initialize the process queue, add all processes that need to be scheduled to the queue, and sort them according to priority; 2) The scheduler selects the process with the highest priority from the queue to execute the test of the function to be tested; 3) When a process is executing and there is an idle process with a higher priority, the higher priority process will be executed; 4) When a process is blocked or completed during execution, the scheduler selects the process with the highest priority from the ready queue to execute again; 5) Repeat the above process until all the functions to be tested are tested; The priority of the queue is determined according to the arrival time and execution time of the process.

8. The method for detecting smart contract vulnerabilities based on parallel fuzz testing according to claim 1, characterized in that: The specific process of step S4 is as follows: S41, preset vulnerability judgment rules, clarify the characteristics, detection conditions and judgment criteria of each vulnerability; S42, collecting the test results of each function to be tested in the parallel test process, including the execution status, exception information, execution time, etc. of the test case, and arranging the analysis format; S43, analyzing the collected detection results according to the preset vulnerability judgment rules, and further analyzing the detailed information of the vulnerability, such as the vulnerability type, location, impact range, etc., for the vulnerability features matching the rules; S44, generating a vulnerability detection report according to the analysis result; The vulnerability detection report includes: vulnerability overview, vulnerability details, repair suggestions, test case set, and preset vulnerability judgment rules.

9. The method for detecting smart contract vulnerabilities based on parallel fuzz testing according to claim 8, characterized in that: The vulnerability judgment rules include: Delegate call vulnerability judgment rules: whether this test triggers the delegatecall instruction and whether the global variables of the smart contract are modified; Reentrancy vulnerability judgment rules: whether this test triggers reentry and whether the account balance is abnormal after execution; Block parameter dependency vulnerability judgment rules: Check whether block parameters are used and participate in the calculation within the smart contract; Self-destruction vulnerability judgment rules: Determine whether there is a self-destruction vulnerability based on the flow of tokens and the status of the contract.

10. A smart contract vulnerability detection system based on parallel fuzz testing, characterized by: The system is used to implement the method described in any one of claims 1 to 9, including: Smart contract compilation and parsing module: used to compile smart contracts, generate opcodes or bytecodes, and parse them; Test case generation module: Generates initial test cases based on the functions and vulnerability types of smart contracts. The test cases contain various possible input data and function call sequences; Parallel fuzz testing module: Use multi-threading or distributed computing to run multiple fuzz testing instances simultaneously. Each test instance independently performs a large amount of random data input tests on the smart contract to find vulnerabilities. After the test is completed, the results are collected and returned. Vulnerability detection and verification module: Analyze the abnormal behaviors found by the parallel fuzz testing module to detect whether there are vulnerabilities; Test report generation module: generates a test report based on the results of the vulnerability detection and verification module. The test report includes a list of discovered vulnerabilities, vulnerability descriptions, vulnerability impact scope, and repair suggestions; Logging and monitoring module: records the log information of the entire test process, including the execution of test cases, the capture of abnormal behaviors, and monitors the test process in real time; Resource management module: manages the resources required during the testing process, including computing resources and storage resources.

Images