Smart contract vulnerability detection method and system based on constraint-guided fuzz testing

Abstract

The present invention relates to the field of smart contract vulnerability detection, specifically a smart contract vulnerability detection method and system based on constraint-guided fuzz testing, which uses constraint-guided gray box fuzz testing to detect vulnerabilities in smart contracts, statically analyzes the data flow and control flow of smart contracts, introduces a new smart contract constraint template based on the static analysis results, and inserts the constraint template into the front or back position of the corresponding branch node in the form of code stubs, guides the execution of the smart contract, and ensures that the fuzz test can easily reach the target code position while covering the target code, and meets the required execution state. The test order and priority of the function in the fuzzer are set according to the function call sequence to discover vulnerabilities in the shortest time, which can reduce the time consumption of fuzz testing and improve the efficiency of vulnerability detection.

Description

Technical Field

[0001] The present invention relates to the technical field of smart contract vulnerability detection, and specifically to a smart contract vulnerability detection method and system based on constraint-guided fuzz testing. Background Art

[0002] A smart contract is a computer program that runs on a blockchain system. It can encode predefined rules and clauses into executable code. Once a smart contract is deployed on the blockchain, it will automatically execute the triggered predefined rules and clauses. The automatic execution and immutability of smart contracts have promoted the development of various decentralized applications. At present, a series of smart contract security incidents occur frequently, and new vulnerabilities are discovered and exploited every few months. Therefore, it is very important to conduct a security review of smart contracts before they are deployed on the blockchain.

[0003] The detection of smart contract vulnerabilities is currently focused on two hot research directions: static analysis and dynamic analysis. Representative technologies of static analysis include formal verification and symbolic execution. Formal verification uses mathematical proofs to check whether the behavior of smart contracts meets expectations. It has not yet been widely used. Symbolic execution can treat program variables as symbols and systematically explore all possible execution paths. However, symbolic execution cannot actually execute every path of the program, and there is a high false positive rate. Therefore, more and more tools use fuzz testing technology to dynamically analyze smart contract vulnerabilities.

[0004] Existing smart contract fuzzers perform well in finding shallow errors, but perform poorly in finding deep errors. At the same time, they still face challenges in achieving high coverage and fuzz testing efficiency. With the development of blockchain technology, the logic of smart contracts is becoming more and more complex. Only through the data read and write dependencies between functions, we can often only get a simple function call sequence, which cannot effectively find complex deep errors. Most current fuzzers are too focused on the initial state of the contract, unable to fully explore errors triggered by complex states, and unable to cover complex branches. In addition, only a few fuzzers consider the environment information when the smart contract is running. However, due to the immutability of the environment information, it is difficult to meet the conditions set by the program in a short time in some cases, which limits the effectiveness of the fuzzer. Summary of the invention

[0005] The present invention provides a smart contract vulnerability detection method and system based on constraint-guided fuzz testing.

[0006] The technical solution of the present invention is as follows:

[0007] A smart contract vulnerability detection method based on constraint-guided fuzz testing includes the following steps:

[0008] S1. Static analysis:

[0009] Analyze the data flow and control flow of the smart contract code to be tested, and obtain the constraint relationships of each branch node in the initial execution state; the specific operation of analyzing the data flow and control flow of the smart contract code to be tested is as follows: first, obtain the read-write relationships of global variables in each branch node, and then determine the data dependencies between each branch node according to the read-write relationships of global variables;

[0010] Obtain the global variables and block parameters with dependencies in the branch node, and set them as function parameters;

[0011] Locate the insecure code in the smart contract to be tested based on predefined expert rules, and obtain the functions containing the insecure code;

[0012] S2. Construct constraint templates:

[0013] Based on the obtained constraint relationships, parse the constraint relationships according to the set parsing rules to obtain executable constraint statements, and generate several constraint templates after constraint collection;

[0014] Based on the positions of the insecure code in the smart contract to be tested, obtain the functions containing all the insecure code, form an initial function call sequence, and sort the number of insecure code blocks contained in the functions in the initial function call sequence in descending order to obtain a function call sequence with a priority relationship;

[0015] S3. Perform preprocessing:

[0016] Insert the generated several constraint templates into the front or back positions of the corresponding branch nodes in the form of code instrumentation to obtain the smart contract after code instrumentation;

[0017] S4. Constraint-guided grey-box fuzz testing:

[0018] Deploy the smart contract after code instrumentation to the blockchain, and based on the seed selection strategy of branch distance, guide the fuzzer to generate test cases;

[0019] Based on the order in the function call sequence, use the test cases to call the corresponding functions of the smart contract in turn, trigger and detect vulnerabilities, and output the vulnerability detection results.

[0020] Specifically, the parsing of the constraint relationships based on the set parsing rules in S2 is as follows:

[0021] If there is a > b, a >= b or a ≠ b in the constraint relationship statement, it is correspondingly parsed as a = b + 1;

[0022] If there is a <= b or a < b in the constraint relationship statement, it is correspondingly parsed as b = a + 1;

[0023] If a == b exists in the constraint statement, the corresponding analysis is a = b or b = a;

[0024] If a = address exists in the constraint statement, it will be resolved to a = contract caller;

[0025] If there is a function call relationship in the constraint relationship statement, the assignment result of the statement is parsed according to the constraint relationship.

[0026] Specifically, the static analysis in S1 also includes obtaining the constraint conditions that satisfy the execution of the branch for each branch node based on the data flow dependency and the control flow dependency, checking the constraint conditions of each branch node in turn, judging whether there are invalid or contradictory conditions in the constraints, determining whether the constraint relationship exists, retaining the constraints of the code executed first, and deleting the constraints of the code executed later that do not satisfy the constraints of the code executed first.

[0027] Specifically, S2 also includes setting a Boolean lock for the constraint of each branch to achieve the initialization of the state when the branch is executed for the first time, specifically:

[0028] Use Boolean variables. Boolean variables are initialized to True when the smart contract is deployed. When the conditions for branch execution are met and the branch execution is completed, the Boolean variable is assigned to False.

[0029] Furthermore, the unsafe code in the smart contract is located based on the predefined expert rules in S1, which is:

[0030] Based on the vulnerability type keywords, the statements of the smart contract are matched with rules to locate the unsafe code in the smart contract.

[0031] Specifically, when inserting the smart contract code in S3, a predefined function is used to modify the abstract syntax tree of the Solidity contract to implement the insertion operation of the smart contract code; the code insertion is implemented using the abstract syntax tree modification interface reserved in the Solidity detection framework.

[0032] The present invention also provides a smart contract vulnerability detection system based on constraint-guided fuzz testing, comprising:

[0033] Static analysis module: Analyze the data flow and control flow of the smart contract code to be tested, and obtain the constraint relationship of each branch node in the initial execution state; the data flow and control flow of the smart contract code to be tested are analyzed, and the specific operations are: first obtain the read-write relationship of the global variables in each branch node, and then determine the data dependency relationship between each branch node according to the read-write relationship of the global variables; obtain the global variables and block parameters with dependencies in the branch nodes, and set them as function parameters; locate the unsafe code in the smart contract to be tested based on the predefined expert rules, and obtain the function containing the unsafe code;

[0034] Constraint template construction module: Based on the obtained constraint relationship, the constraint relationship is parsed according to the set parsing rules to obtain executable constraint statements, and several constraint templates are generated after constraint collection; the initial function call sequence is generated based on the location of the obtained unsafe code, and the function call sequence with priority relationship is generated based on the number of unsafe code blocks in different functions;

[0035] Execute the preprocessing module: insert the generated constraint templates into the front or back position of the corresponding branch node in the form of code plugging, and obtain the smart contract after code plugging;

[0036] Constraint-guided gray-box fuzz testing module: deploys the smart contract after code instrumentation to the blockchain, guides the fuzzer to generate test cases based on the seed selection strategy of branch distance; based on the order in the function call sequence, uses the test cases to call the corresponding functions of the smart contract in sequence to trigger and detect vulnerabilities, and outputs the vulnerability detection results.

[0037] Furthermore, the data flow and control flow analysis in the static analysis module is as follows: parsing the execution statements containing global variables, obtaining the read-write relationship of the global variables in each branch node, and determining the data dependency relationship between each branch node based on the read-write relationship of the global variables.

[0038] The beneficial effects of the present invention are:

[0039] 1. The present invention designs a new smart contract vulnerability detection method, which uses constraint-guided gray box fuzz testing to detect vulnerabilities in smart contracts. Static analysis is performed on the data flow and control flow of the smart contract, and a new smart contract constraint template is introduced based on the static analysis results. The constraint template is inserted into the front or back position of the corresponding branch node in the form of code stubs to guide the execution of the smart contract, ensuring that the fuzz test can easily reach the target code position while covering the target code, and meet the required execution state.

[0040] 2. The present invention locates the dangerous code according to preset expert rules, and uses the results of dangerous code location to determine the function call sequence, and further sets the test order and priority of the function in the fuzzifier according to the function call sequence to discover vulnerabilities in the shortest time, which can reduce the time consumption of fuzz testing and increase the effectiveness of the fuzzifier.

[0041] 3. The present invention selects a distance-based seed selection strategy to build a fuzzer, and performs fuzz testing on smart contracts based on static analysis, which can significantly improve complex branch coverage and code coverage, fully explore and trigger complex state errors, identify more vulnerabilities, and improve the efficiency of vulnerability detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In the attached picture:

[0043] Figure 1 It is a flow chart of a smart contract vulnerability detection method based on constraint-guided fuzz testing in an embodiment;

[0044] Figure 2 This is a schematic diagram showing the comparison of the average coverage of overall instructions between CGFuzz and various static analysis tools and dynamic analysis tools on a small contract data set in the embodiment;

[0045] Figure 3 This is a schematic diagram showing the comparison of the average coverage of overall instructions between CGFuzz and various static analysis tools and dynamic analysis tools on a large contract data set in the embodiment;

[0046] Figure 4 This is a schematic diagram showing the comparison of the average instruction coverage of CGFuzz and four detection tools over time on a small contract data set in the embodiment;

[0047] Figure 5 This is a schematic diagram showing the comparison of average instruction coverage of CGFuzz and four detection tools over time on a large contract data set in the embodiment;

[0048] Figure 6 Schematic diagram of the comparison of vulnerability detection efficiency of different smart contract detection tools in the embodiments. DETAILED DESCRIPTION

[0049] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings.

[0050] Embodiment This embodiment provides a smart contract vulnerability detection method based on constraint-guided fuzz testing, see Figure 1 , including the following steps:

[0051] S1. Static analysis:

[0052] Analyze the data flow and control flow of the smart contract code to be tested to obtain the constraint relationship of each branch node in the initial execution state; the specific operation of analyzing the data flow and control flow of the smart contract code to be tested is as follows: first obtain the read-write relationship of the global variables in each branch node, and then determine the data dependency relationship between each branch node according to the read-write relationship of the global variables;

[0053] Get the global variables and block parameters with dependencies in the branch node and set them as function parameters;

[0054] Based on predefined expert rules, the unsafe code in the smart contract to be tested is located, and the function containing the unsafe code is obtained.

[0055] Specifically, in step S1, a static analysis is first performed on the smart contract to be tested, and the data flow and control flow of the smart contract code to be tested are analyzed to obtain the constraint relationship of each branch node in the initial execution state; the data flow and control flow of the smart contract code to be tested are analyzed, and the specific operations are as follows: first, the read-write relationship of the global variables in each branch node is obtained, and then the data dependency relationship between each branch node is determined according to the read-write relationship of the global variables; the global variables and block parameters with dependency relationships in the branch nodes are obtained, and they are set as function parameters; the unsafe code in the smart contract to be tested is located based on predefined expert rules to obtain the function containing the unsafe code.

[0056] Static analysis also includes obtaining the constraint conditions that satisfy the execution of each branch node based on data flow dependencies and control flow dependencies, checking the constraint conditions of each branch node in turn, judging whether there are invalid or contradictory conditions in the constraints, determining whether the constraint relationship exists, retaining the constraints of the code executed first, and deleting the constraints of the code executed later that do not satisfy the constraints of the code executed first.

[0057] Unsafe codes in smart contracts are located based on predefined expert rules. Specifically, the statements of smart contracts are matched with rules based on vulnerability type keywords to locate unsafe codes in smart contracts.

[0058] The static analysis process algorithm is shown in Table 1.

[0059] Table 1 Static analysis process algorithm

[0060]

[0061] The static analysis process algorithm accepts the control flow graph CFG and expert rules Er of the smart contract as input, and outputs the constraints Cons of each branch, the parameters pars of the function, and the functions vuls that may have vulnerabilities.

[0062] First, obtain the read-write relationship R of the global variables in each node of CFG w / r (line3), then, according to R w / s Relationships determine the data dependencies between each node E dep (Table 1, row 4). First, the execution statements containing global variables are parsed to determine the read and write relationship of each node to the global variables. Then, we determine the data dependency between them based on the relationship that global variables are written first and read later. Next, the statements of the smart contract are matched according to the pre-set expert rule Er to determine the functions that may have vulnerabilities (Table 1, row 5).

[0063] According to the data flow dependency Edep (explicit dependency) and the control flow dependency CFG (implicit dependency), the constraints that satisfy the execution of the branch are obtained for each branch node (row 7 of Table 1). There are invalid or contradictory situations in these constraints, so we use the z3 solver to check the constraints of each branch node in turn to determine whether there is a real constraint relationship between them, and delete the unsatisfied constraints (row 8 of Table 1). Finally, under the premise of satisfying the branch conditions, we obtain the global variables with dependencies in the branch node and use them as parameters that need to be set in the function to reduce the coverage difficulty of the branch.

[0064] To further improve the code coverage, when building constraints for other nodes (except branch nodes), the difference from branch node constraint construction is that we need to consider not only the constraints of branch nodes, but also the constraints of other nodes that have been analyzed in the current branch (Table 1, line 13). We delete the dependencies that are opposite to the node dependencies to ensure that the coverage of the branch is the primary goal. Finally, we return the constraint relationship cons, the function setting parameter pars, and the function vuls that may have vulnerabilities (Table 1, line 15).

[0065] S2. Build constraint template:

[0066] Based on the obtained constraint relationship, the constraint relationship is parsed according to the set parsing rules to obtain executable constraint statements, and several constraint templates are generated after constraint collection.

[0067] Based on the location of the unsafe code in the smart contract to be tested, the functions containing all the unsafe codes are obtained to form an initial function call sequence, and the number of unsafe code blocks contained in the functions in the initial function call sequence is sorted in descending order to obtain a function call sequence with a priority relationship;

[0068] In the present invention, step S2 is to construct a constraint template. The constraint relationships of each branch node and each in-branch node obtained through the static analysis in step S1, including conditional statements, special assignment statements, and function call statements, cannot be used as execution statements to directly set the initial state for the branch. Set parsing rules to parse the constraint relationships, specifically:

[0069] If there is a > b, a >= b or a ≠ b in the constraint relationship statement, it is correspondingly parsed as a = b + 1;

[0070] If there is a <= b or a < b in the constraint relationship statement, it is correspondingly parsed as b = a + 1;

[0071] If there is a == b in the constraint relationship statement, it is correspondingly parsed as a = b or b = a;

[0072] If there is a = address in the constraint relationship statement, it is correspondingly parsed as a = contract caller;

[0073] If there is a function call relationship in the constraint relationship statement, parse the assignment result of this statement according to the constraint relationship.

[0074] After parsing, executable constraint statements can be obtained, which can be used to set the state required when the branch is initially executed. Since the initialization state only needs to be set at the first execution, constraint collection is performed on the constraint statements to generate several constraint templates to realize the initialization of the state when the branch is first executed. Table 2 is an example diagram of two constraint templates.

[0075] Table 2 Schematic diagrams of two constraint templates

[0076]

[0077] In order to realize the initialization of the state when the branch is first executed and ensure that the constraints of the initial state are only set at the first execution, a boolean lock is set for the constraints of each branch, specifically:

[0078] Use a boolean variable, which is initialized to True when the smart contract is deployed; when the conditions for branch execution are met and the branch execution ends, the boolean variable is assigned False.

[0079] S3. Execution preprocessing:

[0080] Insert the generated several constraint templates into the front or back position of the corresponding branch node in the way of code instrumentation to obtain the smart contract after code instrumentation.

[0081] Step S3 is to perform preprocessing. Code instrumentation technology is a method of dynamically modifying or monitoring code during program execution. It is used to collect program execution information or change program behavior. When instrumenting smart contract code, predefined functions are used to modify the abstract syntax tree (AST) of the Solidity contract to implement instrumentation operations on the smart contract code. Code instrumentation is implemented using the abstract syntax tree modification interface reserved in the Solidity detection framework, which reduces the difficulty of code instrumentation and ensures the correctness of the smart contract syntax after instrumentation.

[0082] According to the constraint template and function parameter settings, the interface for modifying AST is implemented in SIF. Then, we use the modified AST to generate the instrumented contract code so that we can use the code generation function of SIF. We insert the code snippets of the constraint template into the corresponding branch nodes respectively. Then, according to the function parameter settings, we modify the variable names of the corresponding nodes and pass them in as function parameters. Finally, according to the function call sequence, the fuzzer sets the test order of the functions.

[0083] Table 3 is a diagram of a vulnerable smart contract, and Table 4 is the smart contract in Table 3 after code instrumentation. For each branch of the contract, CGFuzz passes the global variables with dependencies in the branch conditions as function parameters, which greatly reduces the difficulty of the fuzzer to generate test cases to cover the branches. Secondly, CGFuzz collects the execution constraints of each branch statement and sets the initial execution state before the first execution of the branch. Compared with other fuzzers, this can reduce the time consumption of calling other functions to obtain the initial state. Finally, on this basis, CGFuzz matches the unsafe code blocks that may exist in the smart contract according to predefined expert rules, such as the call.value transfer operation in the withdraw function in Table 3, and sets the test priority of the withdraw function higher than other functions, further reducing the time consumption of obtaining detection results.

[0084] Table 3 Schematic diagram of a vulnerable smart contract

[0085]

[0086] Table 4 Schematic diagram of smart contract code after plugging

[0087]

[0088] S4. Constraint-guided gray-box fuzz testing:

[0089] Deploy the smart contract after code instrumentation to the blockchain, and guide the fuzzer to generate test cases based on the seed selection strategy of branch distance;

[0090] Based on the order in the function call sequence, the corresponding functions of the smart contract are called in sequence using test cases to trigger and detect vulnerabilities and output vulnerability detection results.

[0091] Step S4 is constraint-guided gray-box fuzz testing. In vulnerability analysis and reporting, the smart contract vulnerability detection method based on constraint-guided fuzz testing (hereinafter referred to as CGFuzz) analyzes the logs during the fuzz testing process and generates a detailed error report for further manual confirmation. Specific detection modes for 10 types of vulnerabilities are set, including assertion failure (AF), unhandled exception (UE), unsafe delegate call (UD), ether leakage (LE), ether freeze (LO), unprotected self-destruction (US), integer overflow (IO), reentrancy (RE), transaction order dependency (TOD), and block dependency (BD).

[0092] The present invention also provides a smart contract vulnerability detection system based on constraint-guided fuzz testing, comprising:

[0093] Static analysis module: Analyze the data flow and control flow of the smart contract code to be tested, and obtain the constraint relationship of each branch node in the initial execution state; the data flow and control flow of the smart contract code to be tested are analyzed, and the specific operations are: first obtain the read-write relationship of the global variables in each branch node, and then determine the data dependency relationship between each branch node according to the read-write relationship of the global variables; obtain the global variables and block parameters with dependencies in the branch nodes, and set them as function parameters; locate the unsafe code in the smart contract to be tested based on the predefined expert rules, and obtain the function containing the unsafe code;

[0094] Constraint template construction module: Based on the obtained constraint relationship, the constraint relationship is parsed according to the set parsing rules to obtain executable constraint statements, and several constraint templates are generated after constraint collection; the initial function call sequence is generated based on the location of the obtained unsafe code, and the function call sequence with priority relationship is generated based on the number of unsafe code blocks in different functions;

[0095] Execute the preprocessing module: insert the generated constraint templates into the front or back position of the corresponding branch node in the form of code plugging, and obtain the smart contract after code plugging;

[0096] Constraint-guided gray-box fuzz testing module: deploys the smart contract after code instrumentation to the blockchain, guides the fuzzer to generate test cases based on the seed selection strategy of branch distance; based on the order in the function call sequence, uses the test cases to call the corresponding functions of the smart contract in sequence to trigger and detect vulnerabilities, and outputs the vulnerability detection results.

[0097] Among them, the data flow and control flow analysis in the static analysis module is: parsing the execution statements containing global variables, obtaining the read-write relationship of the global variables in each branch node, and determining the data dependency relationship between each branch node based on the read-write relationship of the global variables.

[0098] Experimental content

[0099] This scheme compares CGFuzz and baseline tools in terms of code coverage, vulnerability detection capability, and vulnerability detection efficiency. All experiments are conducted on an Ubuntu 20.04 server equipped with 8 Intel(R) Xeon(R) Gold 6161 CPU @ 2.20GHz processors and 200GB physical memory. Each experiment is repeated 10 times and the average results are obtained.

[0100] Table 5 shows the vulnerability detection types supported by different smart contract vulnerability detection tools, where tools marked with ● support detection of corresponding vulnerabilities, and tools marked with 0 do not support detection of corresponding vulnerabilities.

[0101] Table 5 Vulnerability detection types supported by different smart contract vulnerability detection tools

[0102]

[0103] In the experiment, we selected 6 open source static analysis and dynamic analysis methods that have received many positive reviews or high citations on Github, as shown in Table 5. We also provided the types of vulnerabilities they can detect, the number of paper citations or the number of positive reviews on Github, and the conferences or journals where they were published. For static analysis tools, we used Oyente and Mytrhil for comparison; for dynamic analysis tools, we used ILF, sFuzz, IRFuzz, and Confuzzius for comparison.

[0104] Table 6 Statistics of source code lines and instructions in the dataset

[0105]

[0106] In the experiment, two different datasets were used, see Table 6. The purpose of using the first dataset is to test the code coverage of CGFuzz. The purpose of using the second dataset is to test the vulnerability detection ability of CGFuzz and whether CGFuzz can detect vulnerabilities in the shortest time compared with the optimal tool. Therefore, this dataset needs to meet two conditions: (1) The dataset needs to contain the 10 vulnerabilities that CGFuzz can detect; (2) All smart contracts in the dataset need to be manually reviewed and the locations of the vulnerabilities are accurately marked to facilitate accurate verification of the tool detection results. In order to meet the above two conditions, Dataset 2 uses the CURATED dataset provided by ConFuzzius.

[0107] Figure 2 and Figure 3 The average coverage of overall instructions of CGFuzz and various static analysis tools and dynamic analysis tools on Dataset 1 and Dataset 2, respectively. Dataset 1 is a small contract data set, and Dataset 2 is a large contract data set. CGFuzz achieved an average instruction coverage of 95% and 93% on the large contract data set and the small contract data set, respectively. However, the average instruction coverage of other analysis tools on the large contract data set and the small contract data set is quite different. Compared with the small contract data set, the instruction coverage of the large contract data set is lower overall. The tool with the largest difference in code coverage between the large contract data set and the small contract data set is Mythril, with a difference of 31%. The tools with the lowest average instruction coverage are IRFuzz and sFuzz. The average instruction coverage of the two is not much different, and their average instruction coverage is both below 30%. Figure 4 and Figure 5 The figure below shows the average instruction coverage of CGFuzz and four detection tools over time. Figure 4 is the average instruction coverage of different detection tools on small contracts over time, Figure 5 is the average instruction coverage of different detection tools on large contracts over time. CGFuzz always outperforms other testing tools in the detection of small contract datasets and large contract datasets. CGFuzz achieved 82% instruction coverage on the small contract dataset and 73% instruction coverage on the large contract dataset within 10 seconds, which is much higher than the average instruction coverage of other tools.

[0108] CGFuzz greatly reduces the difficulty of branch coverage by setting variables with dependencies in branch statements as function parameters. Under the premise of ensuring branch coverage, CGFuzz collects the constraints of each branch and sets the initial state for its first execution to satisfy the execution status of the statements in the branch, achieving high code coverage.

[0109] Table 7 shows the true positive and false positive results of each detection tool when detecting eight types of smart contract vulnerabilities, where "-" indicates that the tool cannot detect a specific vulnerability.

[0110] Table 7: The situation of each type of vulnerability detected by different detection tools

[0111]

[0112] Table 7 summarizes the number of vulnerabilities detected by each detection tool on Dataset 2 for each category. The number of true positives is shown on the left side of each entry and the number of false positives is shown on the right side. For static analysis tools, Oyente can only detect a small number of AF, IO, RE, and TD vulnerabilities, and there are false positives for AF and IO vulnerabilities. Although Mythril can detect most vulnerabilities, there are still a large number of false negatives and false positives in the detection results. For dynamic analysis tools, they can detect more true positive contracts and have fewer false positives. ILF cannot detect any BD vulnerabilities, but its detection results for UD, LE, LO, and US are closest to the actual number of vulnerabilities in the dataset. sFuzz and IRFuzz have similar performances and can detect 6 vulnerabilities, but there are a large number of false negatives in the detection results. ConFuzzius is the tool with the best detection ability in the comparison. It can detect 10 types of vulnerabilities, and its detection results are closest to the actual number of vulnerabilities in the dataset. ConFuzzius can detect 106 out of 148 vulnerabilities and is the only tool other than our tool that achieves zero false positives. CGFuzz can detect 126 out of 148 vulnerabilities, making it the tool with the best detection capability. Compared with ConFuzzius, CGFuzz has better results in detecting RE, UE, and LE vulnerabilities, especially in detecting RE and LE, achieving a 100% true positive rate. Compared with other dynamic analysis tools, CGFuzz reduces the difficulty of code coverage while setting the required initial state for each branch execution of the contract, making it easier to satisfy unreachable paths and states. Therefore, CGFuzz can effectively detect 10 smart contract vulnerabilities, and its detection capabilities exceed existing static analysis tools and dynamic analysis tools.

[0113] To verify the vulnerability detection efficiency of CGFuzz, we first compare GFuzz with dynamic analysis tools (sFuzz, IRFuzz, and ConFuzzius) to perform vulnerability detection on BD, UE, and UD to compare the average time consumed by the fuzzers in detecting vulnerabilities.

[0114] The visual comparison results of CGFuzz, sFuzz, IRFusz, and ConFuzzius on BD, UE, and UD are shown in Figure 2. Figure 6 As shown in the figure. CGFuzz detected the three vulnerabilities in the shortest time, with an average detection time of less than 5 seconds. However, sFuzz took the most time to detect vulnerabilities, with an average detection time of more than 40 seconds. In comparison, CGFuzz's detection efficiency is more than 4 times that of sFuzz, and the detection time of RFuzz and ConFuzzius is between sFuzz and CGFuzz. Specifically, the average detection time of ConFuzzius is about 10 seconds, and the average detection time of IRFuzz is about 30 seconds, which is a difference of 3 times.

Claims

1. A smart contract vulnerability detection method based on constraint-guided fuzz testing, characterized in that: The following steps are involved: S1. Static analysis: Analyze the data flow and control flow of the smart contract code to be tested to obtain the constraint relationship of each branch node in the initial execution state; the specific operation of analyzing the data flow and control flow of the smart contract code to be tested is as follows: first obtain the read-write relationship of the global variables in each branch node, and then determine the data dependency relationship between each branch node according to the read-write relationship of the global variables; Get the global variables and block parameters with dependencies in the branch node and set them as function parameters; Locate the unsafe code in the smart contract to be tested based on predefined expert rules and obtain the function containing the unsafe code; Locate unsafe codes in smart contracts based on predefined expert rules, which include: matching smart contract statements with rules based on vulnerability type keywords to locate unsafe codes in smart contracts; S2. Build constraint template: Based on the obtained constraint relationship, the constraint relationship is parsed based on the set parsing rules to obtain executable constraint statements, and several constraint templates are generated after constraint collection; Based on the location of the unsafe code in the smart contract to be tested, the functions containing all the unsafe codes are obtained to form an initial function call sequence, and the number of unsafe code blocks contained in the functions in the initial function call sequence is sorted in descending order to obtain a function call sequence with a priority relationship; The constraint relationship is parsed based on the set parsing rules, specifically: If a > b, a >= b, or a ≠ b exists in the constraint statement, the corresponding solution is a = b + 1; If a <= b or a < b exists in the constraint statement, the corresponding solution is b = a + 1; If a == b exists in the constraint statement, the corresponding analysis is a = b or b = a; If a = address exists in the constraint statement, it will be resolved to a = contract caller; If there is a function call relationship in the constraint relationship statement, the assignment result of the statement is parsed according to the constraint relationship; S3. Perform preprocessing: Insert the generated constraint templates into the front or back position of the corresponding branch node in the form of code stubs to obtain the smart contract after code stubs. S4, Constraint-guided gray-box fuzz testing: Deploy the smart contract after code instrumentation to the blockchain, and guide the fuzzer to generate test cases based on the seed selection strategy of branch distance; Based on the order in the function call sequence, the corresponding functions of the smart contract are called in sequence using test cases to trigger and detect vulnerabilities and output vulnerability detection results.

2. The smart contract vulnerability detection method based on constraint-guided fuzz testing according to claim 1 is characterized in that: The static analysis in S1 also includes obtaining the constraint conditions that satisfy the execution of the branch for each branch node based on the data flow dependency and the control flow dependency, checking the constraint conditions of each branch node in turn, judging whether there are invalid or contradictory situations in the constraints, determining whether the constraint relationship exists, retaining the constraints of the code executed first, and deleting the constraints of the code executed later that do not satisfy the constraints of the code executed first.

3. The smart contract vulnerability detection method based on constraint-guided fuzz testing according to claim 1 is characterized in that: The S2 also includes setting a Boolean lock for the constraint of each branch to achieve the initialization of the state when the branch is executed for the first time, specifically: Use Boolean variables. Boolean variables are initialized to True when the smart contract is deployed. When the conditions for branch execution are met and the branch execution is completed, the Boolean variable is assigned to False.

4. The smart contract vulnerability detection method based on constraint-guided fuzz testing according to claim 1 is characterized in that: When inserting the smart contract code in S3, a predefined function is used to modify the abstract syntax tree of the Solidity contract to implement the insertion operation of the smart contract code; the code insertion is implemented using the abstract syntax tree modification interface reserved in the Solidity detection framework.

5. A smart contract vulnerability detection system based on constraint-guided fuzz testing, characterized in that: include: Static analysis module: analyzes the data flow and control flow of the smart contract code to be tested, and obtains the constraint relationship of each branch node in the initial execution state; The data flow and control flow of the smart contract code to be tested are analyzed, and the specific operations are as follows: first, the read-write relationship of the global variables in each branch node is obtained, and then the data dependency relationship between each branch node is determined according to the read-write relationship of the global variables; the global variables and block parameters with dependency relationships in the branch nodes are obtained, and they are set as function parameters; the unsafe code in the smart contract to be tested is located based on the predefined expert rules, and the function containing the unsafe code is obtained; the unsafe code in the smart contract is located based on the predefined expert rules, which is: the statements of the smart contract are matched according to the vulnerability type keywords, and the unsafe code in the smart contract is located; Constraint template construction module: Based on the obtained constraint relationship, the constraint relationship is parsed according to the set parsing rules to obtain executable constraint statements, and several constraint templates are generated after constraint collection; Based on the location of the unsafe code in the smart contract to be tested, the functions containing all the unsafe codes are obtained to form an initial function call sequence, and the number of unsafe code blocks contained in the functions in the initial function call sequence is sorted in descending order to obtain a function call sequence with a priority relationship; The constraint relationship is parsed based on the set parsing rules, specifically: If a > b, a >= b, or a ≠ b exists in the constraint statement, the corresponding solution is a = b + 1; If a <= b or a < b exists in the constraint statement, the corresponding solution is b = a + 1; If a == b exists in the constraint statement, the corresponding analysis is a = b or b = a; If a = address exists in the constraint statement, it will be resolved to a = contract caller; If there is a function call relationship in the constraint relationship statement, the assignment result of the statement is parsed according to the constraint relationship; Execute the preprocessing module: insert the generated constraint templates into the front or back position of the corresponding branch node in the form of code plugging, and obtain the smart contract after code plugging; Constraint-guided gray-box fuzz testing module: deploys the smart contract after code instrumentation to the blockchain, and guides the fuzzer to generate test cases based on the seed selection strategy of branch distance; Based on the order in the function call sequence, the corresponding functions of the smart contract are called in sequence using test cases to trigger and detect vulnerabilities and output vulnerability detection results.

6. The smart contract vulnerability detection system based on constraint-guided fuzz testing according to claim 5 is characterized in that: The data flow and control flow analysis in the static analysis module is as follows: parsing the execution statements containing global variables, obtaining the read-write relationship of the global variables in each branch node, and determining the data dependency relationship between each branch node based on the read-write relationship of the global variables.

Images