Intelligent contract vulnerability automatic detection method and system based on directional test

Abstract

The invention discloses an intelligent contract vulnerability automatic detection method and system based on a directional test, combines static analysis and a directional grey box fuzzy test detection means, provides a novel grey box fuzzy test guidance strategy, and utilizes vulnerability information of preliminary investigation of an intelligent contract in a static analysis stage to realize automatic detection of the vulnerability of the intelligent contract. Seed scheduling in a grey box fuzzy test stage is guided, and the priority of seeds is judged through the path distance between a seed operation path and a target basic block and the data distance, so that the seeds closer to trigger vulnerabilities have more opportunities to generate filial generations, and a seed population closer to the target basic block is derived more pertinently. According to the method, directional testing is adopted, and static analysis and fuzzy testing are combined, so that quick and accurate detection of the vulnerability of the smart contract is realized.

Description

Technical Field

[0001] The present invention belongs to the field of information security technology in computer science, and relates to a method and system for detecting vulnerabilities in smart contracts, and specifically to an automated detection method and system for accurate smart contract vulnerabilities based on directional testing. Background Art

[0002] A smart contract is an automated computer program designed to execute, manage, and enforce the terms of a contract agreed upon between two parties. With the development of blockchain and smart contract technology, concepts and technologies such as digital wallets, distributed identity authentication, decentralized autonomous organizations, and non-fungible tokens have flourished. However, while smart contract technology brings opportunities, it also faces challenges. Since smart contracts have the characteristics of fast programming language updates, irreversibility after deployment, and high custody prices for digital currencies, problems caused by smart contract vulnerabilities often have more serious consequences. For these vulnerabilities, accurate and effective vulnerability detection solutions are needed to maintain the healthy development of the blockchain environment and smart contract ecosystem. Summary of the invention

[0003] The purpose of the present invention is to propose an automated detection method, system and product for accurate smart contract vulnerabilities based on targeted testing for smart contracts in Ethereum, the current mainstream blockchain platform.

[0004] The technical solution adopted by the method of the present invention is: a method for automatically detecting smart contract vulnerabilities based on directional testing, comprising the following steps:

[0005] Step 1: Perform static analysis on the target contract;

[0006] Compile the target contract, generate an abstract syntax tree, and recover important contract information from the abstract syntax tree, including the contract's high-level objects, inheritance diagram, and Solidity expressions; convert the Solidity expressions into intermediate representations to complete code analysis, including variable read and write operations, data dependencies, and protected functions; rely on the analysis results to match contract vulnerabilities according to vulnerability detection rules, complete vulnerability detection in the static analysis phase, and preliminarily determine the type of contract vulnerability and its location in the source code;

[0007] Step 2: Preprocess the target contract;

[0008] Build the control flow graph of the contract, set the target basic blocks to be reached in the fuzz test according to different vulnerability types, and insert special instructions at the corresponding position of the original contract for each vulnerability point detected in the static analysis, so as to locate the specific position of the vulnerability point in the Ethereum bytecode control flow graph, and then calculate the basic block distance and data distance of all basic blocks of the contract based on the control flow graph and the target basic block location information;

[0009] Step 3: Perform targeted gray-box fuzz testing on the target contract;

[0010] First, the Ethereum virtual machine is instrumented to obtain runtime information; then fuzz testing is performed to generate seeds, and the seed score is calculated based on the basic block distance and data distance passed in during the preprocessing process to guide seed scheduling, select the seed closest to the trigger target basic block for crossover and mutation operations, and perform vulnerability detection while executing to generate detection results.

[0011] Preferably, the specific implementation of step 1 includes the following steps:

[0012] Step 1.1: Generate an abstract syntax tree;

[0013] The solc compiler compiles the contract file input by the user and generates an abstract syntax tree in JSON format;

[0014] Step 1.2: Restore important contract information;

[0015] Extract high-level objects including contract objects, enumeration objects, and structure data objects from the abstract syntax tree, and determine the inheritance order of each contract in the .sol file, and then restore the contract inheritance relationship in the smart contract file; extract the Solidity high-level expression structure from the abstract syntax tree and restore it; finally restore the original control flow graph of the contract;

[0016] Step 1.3: Generate intermediate representation;

[0017] Use static single assignment intermediate representation to convert the Solidity expression of the node in the contract control flow graph into intermediate representation storage;

[0018] Step 1.4: Code analysis, including variable read and write analysis, data dependency analysis, and protected function analysis;

[0019] Step 1.5: Static vulnerability detection;

[0020] Use pre-defined static vulnerability detection rules to detect vulnerabilities in the contract, so as to preliminarily mark the target vulnerability points that need to be reached during the subsequent directed gray box fuzz testing process.

[0021] Preferably, the specific implementation of step 2 includes the following steps:

[0022] Step 2.1: Build a control flow graph;

[0023] Use the solc compiler to compile the contract and output the bytecode for the contract runtime, which is used to build the control flow graph of the contract based on the Ethereum virtual machine assembly language;

[0024] Step 2.2: Locate the vulnerability control flow graph according to the vulnerability constraint rules;

[0025] According to different vulnerability types, the target basic blocks to be reached in the fuzz test are set. For each vulnerability point detected in the static analysis, the INVALID instruction is inserted at the corresponding position of the original contract to locate the specific position of the vulnerability point in the Ethereum bytecode control flow graph.

[0026] Step 2.3: Calculation of basic block distance and data distance;

[0027] According to the predefined basic block distance calculation formula, the basic block distance and data distance of each basic block in the control flow graph are calculated.

[0028] Preferably, in step 2.1, the construction of the contract is based on the control flow graph of the Ethereum virtual machine assembly language, which converts the hexadecimal bytecode into Ethereum virtual machine assembly instructions, performs preliminary segmentation of the basic blocks, performs PUSH-type jump connections and isolated jump connections, and finally cleans up the control flow graph.

[0029] Preferably, in step 2.2, the specific location of the vulnerability point in the Ethereum bytecode control flow graph is located, and the specific implementation includes the following steps:

[0030] (1) Compile the source code of the smart contract to obtain its bytecode, and construct a bytecode-level contract control flow graph from the bytecode;

[0031] (2) Obtain the location of the contract vulnerability in the source code through static analysis, insert the INVALID operation code at the location of the vulnerability in the source code, and record it as a new source code file;

[0032] (3) Compile the new source code file to obtain its bytecode, and construct the contract control flow graph corresponding to the new source code file, which contains the INVALID operation code;

[0033] (4) Compare the original contract control flow graph with the new source code file control flow graph to obtain the offset of the vulnerability point in the bytecode control flow graph.

[0034] As a preference, in step 2.3, the i-th basic block in the control flow graph is B i , the jth target basic block is T j , basic block B i To basic block T j Distance The distance calculation formula is:

[0035]

[0036] in, Indicates Bi To T j If there is a jump edge, the path distance is 1; Indicates B i For those who can reach T j Other basic blocks B k If there is a jump edge, take the shortest directed path and add 1; Oterwise means B i is the target basic block or an unreachable target basic block, the distance is recorded as infinity∞;

[0037] After calculating the distances of all basic blocks B to all target basic blocks T, calculate the distances of basic block B to all target basic blocks T. i The basic block distance d T (B i ):

[0038]

[0039] In the above formula, B i ∈T means that the basic block is the target basic block, and the basic block distance of the basic block is recorded as 0; If a basic block is unreachable to any target basic block, the basic block will not be included in the basic block distance calculation, and will not be included in the seed execution path in the fuzz testing module; Oterwise means that for the remaining basic blocks, the basic block distance is calculated by taking the harmonic average of the path distances to all target basic blocks, where n is the total number of target basic blocks.

[0040] Preferably, in step 2.3, basic block B i Data distance d D (B i ) is calculated as:

[0041]

[0042] Among them, B i ∈T indicates that the basic block is the target basic block, data(B i ) Determine basic block B i Whether the data constraints are met, d T (B i ) is the basic block B i The basic block distance of B, NaN means that the basic block distance or data distance of the basic block is not considered; i ∈T∧data(B i )=True means that the target basic block data distance that satisfies the data constraint is set to 0; d T (B i)isNaN means ignoring the basic blocks that cannot reach any target basic blocks and the subsequent basic blocks of the target basic blocks that are not calculated in the basic block distance calculation; Oterwise means setting the data distance of all other basic blocks to the MAX value.

[0043] Preferably, in step 3, the Ethereum virtual machine is plugged in, and the specific implementation process is:

[0044] The official Python implementation of Ethereum virtual machine, eth library, was called to obtain the key parameters of the call for the external call instruction corresponding to the reentrancy vulnerability point and the delegate call delegatecall instruction corresponding to the dangerous delegate call vulnerability point;

[0045] The data distance of the target basic block of the reentrancy vulnerability is determined as follows: modify the Call class in eth / vm / logic / call.py. When reading the call parameter, compare the to parameter of call (i.e. the callee of the external call) to see if it is the msg.sender (i.e. the transaction sender) at this time. If so, determine whether the basic block being executed at this time is the target basic block. If so, determine the data distance of the basic block to be 0.

[0046] The data distance of the target basic block of the dangerous delegate call vulnerability is judged as follows: modify the calldatacopy method in eth / vm / logic / context.py. The call of this method indicates that msg.data is copied to memory. According to the mem_start_position parameter in calldatacopy, the corresponding position in memory is marked as contaminated. Modify the Delegatecall class in eth / vm / logic / call.py to check whether the parameter memory_input_start_position (that is, the position where the parameter is read from memory) is contaminated during the delegate call. If so, determine whether the target basic block is executed at this time. If so, determine the data distance of the basic block to 0.

[0047] Preferably, in step 3, the seed score is calculated by:

[0048] Compute basic block B i The seed distance d(B i ) is the basic block distance b of the basic block T (B i ) and the data distance d D (B i ) and d(B i ) = d T (B i )+dD (B i );

[0049] Calculating Seeding Score Among them, t l is a single transaction in seed s, Trace(t l ) indicates t l All basic blocks traversed.

[0050] The technical solution adopted by the system of the present invention is: a smart contract vulnerability automatic detection system based on directed testing, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the smart contract vulnerability automatic detection method based on directed testing when executing the program.

[0051] Compared with the prior art, the beneficial effects of the present invention are mainly reflected in the following aspects:

[0052] (1) Compared with the strategy of randomly exploring the program code space in the traditional coverage-guided gray-box fuzz testing method, the use case generation guidance strategy of the present invention is more targeted at the target vulnerability points and has a higher utilization rate for single seed selection, thus avoiding ineffective exploration of irrelevant program branches and reducing vulnerability detection time.

[0053] (2) The detection method of the present invention combines static analysis with directed gray-box fuzz testing, which not only heuristically optimizes the use case generation of fuzz testing, but also further verifies the authenticity of the vulnerabilities reported by static analysis through dynamic analysis during the fuzz testing process, thus avoiding the problem of high false alarm rate when using a single vulnerability detection method to a certain extent.

[0054] (3) The present invention and related works were compared on multiple data sets to compare the efficiency indicators of smart contract vulnerability detection tools, including the time required for vulnerability detection, the number of transactions required for vulnerability detection, the vulnerability detection accuracy and recall rate, and false positive reports. The results show that the vulnerability detection effect of the present invention is better than that of the traditional CGF scheme, which illustrates the feasibility and effectiveness of the algorithm of the present scheme. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] The technical solution of the present invention is further described below using embodiments and specific implementation methods. In addition, in the process of describing the technical solution, some drawings are also used. For those skilled in the art, other drawings and the intention of the present invention can also be obtained based on these drawings without paying creative work.

[0056] Figure 1 It is the principle framework of the method of the embodiment of the present invention;

[0057] Figure 2This is a schematic diagram of a static analysis module in an embodiment of the present invention;

[0058] Figure 3 This is a schematic diagram of a preprocessing module in an embodiment of the present invention;

[0059] Figure 4 Schematic diagram of a directed gray box fuzzy testing module in an embodiment of the present invention. DETAILED DESCRIPTION

[0060] In order to facilitate ordinary technicians in the field to understand and implement the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the implementation examples described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0061] The present invention combines static analysis with targeted gray-box fuzz testing detection methods, and proposes a novel gray-box fuzz testing guidance strategy. It uses the vulnerability information of the preliminary investigation of the smart contract in the static analysis phase to guide the seed scheduling in the gray-box fuzz testing phase. The priority of the seed is determined by the path distance and data distance between the seed running path and the target basic block, so that seeds that are closer to the triggering vulnerability have more opportunities to generate offspring, thereby deriving a seed group close to the target basic block in a more targeted manner.

[0062] Please see Figure 1 , this embodiment provides a method for automatically detecting smart contract vulnerabilities based on targeted testing, comprising the following steps:

[0063] Step 1: Perform static analysis on the target contract;

[0064] Compile the target contract, generate an abstract syntax tree, and recover important contract information from the abstract syntax tree, including the contract's high-level objects, inheritance diagram, and Solidity expressions; convert the Solidity expressions into intermediate representations to complete code analysis, including variable read and write operations, data dependencies, and protected functions; rely on the analysis results to match contract vulnerabilities according to pre-written vulnerability detection rules, complete vulnerability detection in the static analysis phase, and preliminarily determine the type of contract vulnerability and its location in the source code;

[0065] In one embodiment, the specific implementation of step 1 includes the following steps:

[0066] Step 1.1: Generate an abstract syntax tree;

[0067] The solc compiler compiles the contract file input by the user and generates an abstract syntax tree in JSON format;

[0068] Step 1.2: Restore important contract information;

[0069] Extract high-level objects including contract objects, enumeration objects, and structure data objects from the abstract syntax tree, and determine the inheritance order of each contract in the .sol file, and then restore the contract inheritance relationship in the smart contract file; extract the Solidity high-level expression structure from the abstract syntax tree and restore it; finally restore the original control flow graph of the contract;

[0070] Step 1.3: Generate intermediate representation;

[0071] Adopting the intermediate representation in the form of static single assignment, the Solidity expression of the node in the contract control flow graph is converted into the intermediate representation storage, making the analysis process more convenient without losing the necessary semantic information;

[0072] Step 1.4: Code analysis, including variable read and write analysis, data dependency analysis, and protected function analysis; used for static vulnerability detection;

[0073] Step 1.5: Static vulnerability detection;

[0074] Use pre-defined static vulnerability detection rules to detect vulnerabilities in the contract, so as to preliminarily mark the target vulnerability points that need to be reached during the subsequent directed gray box fuzz testing process.

[0075] Step 2: Preprocess the target contract;

[0076] Build the control flow graph of the contract, set the target basic blocks to be reached in the fuzz test according to different vulnerability types, insert special instructions at the corresponding position of the original contract for each vulnerability point detected in the static analysis step, so as to locate the specific position of the vulnerability point in the Ethereum bytecode control flow graph, and then calculate the basic block distance and data distance of all basic blocks of the contract based on the control flow graph and the target basic block location information;

[0077] In one embodiment, the specific implementation of step 2 includes the following steps:

[0078] Step 2.1: Build a control flow graph;

[0079] Use the solc compiler to compile the contract and output the bytecode for the contract runtime, which is used to build the control flow graph of the contract based on the Ethereum virtual machine assembly language;

[0080] In one embodiment, the contract is constructed based on the control flow graph of the Ethereum virtual machine assembly language, which converts the hexadecimal bytecode into Ethereum virtual machine assembly instructions, performs preliminary segmentation of the basic blocks, performs PUSH-type jump connections and isolated jump connections, and finally cleans up the control flow graph.

[0081] Step 2.2: Locate the vulnerability control flow graph according to the vulnerability constraint rules;

[0082] According to different vulnerability types, the target basic blocks to be reached in the fuzz test are set. For each vulnerability point detected in the static analysis, the INVALID instruction is inserted at the corresponding position of the original contract to locate the specific position of the vulnerability point in the Ethereum bytecode control flow graph.

[0083] In one embodiment, the locating of the vulnerability point at a specific position in the Ethereum bytecode control flow graph includes the following steps:

[0084] (1) Compile the source code of the smart contract to obtain its bytecode, and construct a bytecode-level contract control flow graph from the bytecode;

[0085] (2) Obtain the location of the contract vulnerability in the source code through static analysis, insert the INVALID operation code at the location of the vulnerability in the source code, and record it as a new source code file;

[0086] (3) Compile the new source code file to obtain its bytecode, and construct the contract control flow graph corresponding to the new source code file, which contains the INVALID operation code;

[0087] (4) Compare the original contract control flow graph with the new source code file control flow graph to obtain the offset of the vulnerability point in the bytecode control flow graph.

[0088] Step 2.3: Calculation of basic block distance and data distance;

[0089] According to the predefined basic block distance calculation formula, the basic block distance and data distance of each basic block in the control flow graph are calculated. The basic block distance measures the path length from the basic block to each target basic block, that is, the control flow graph path length from the target; the data distance describes whether the data constraints during the fuzz test execution meet the requirements for triggering the target vulnerability.

[0090] In one embodiment, the i-th basic block in the control flow graph is B i , the jth target basic block is T j , basic block B i To basic block T j Distance The distance calculation formula is:

[0091]

[0092] in, Indicates B i To T j If there is a jump edge, the path distance is 1; Indicates B i For those who can reach T jOther basic blocks B k If there is a jump edge, take the shortest directed path and add 1; Oterwise means B i is the target basic block or an unreachable target basic block, the distance is recorded as infinity∞;

[0093] After calculating the distances of all basic blocks B to all target basic blocks T, calculate the distances of basic block B to all target basic blocks T. i The basic block distance d T (B i ):

[0094]

[0095] In the above formula, B i ∈T means that the basic block is the target basic block, and the basic block distance of the basic block is recorded as 0; If a basic block is unreachable to any target basic block, the basic block will not be included in the basic block distance calculation, and will not be included in the seed execution path in the fuzz testing module; Oterwise means that for the remaining basic blocks, the basic block distance is calculated by taking the harmonic average of the path distances to all target basic blocks, where n is the total number of target basic blocks.

[0096] In one embodiment, the basic block B i Data distance d D (B i ) is calculated as:

[0097]

[0098] Among them, B i ∈T indicates that the basic block is the target basic block, data(B i ) Determine basic block B i Whether the data constraints are met, d T (B i ) is the basic block B i The basic block distance of B, NaN means that the basic block distance or data distance of the basic block is not considered; i ∈T∧data(B i )=True means that the target basic block data distance that satisfies the data constraint is set to 0; d T (B i )isNaN means ignoring the basic blocks that cannot reach any target basic blocks and the subsequent basic blocks of the target basic blocks that are not calculated in the basic block distance calculation; Oterwise means setting the data distance of all other basic blocks to the MAX value.

[0099] Step 3: Perform targeted gray-box fuzz testing on the target contract;

[0100] First, the Ethereum virtual machine is instrumented to obtain the necessary runtime information; then fuzz testing is performed to generate seeds, and the seed score is calculated based on the basic block distance and data distance passed in during the preprocessing process to guide seed scheduling, select the seed closest to the trigger target basic block for crossover and mutation operations, and perform vulnerability detection while executing, generate detection results, and automatically complete smart contract vulnerability detection.

[0101] In order to obtain runtime information, some modifications need to be made to the Ethereum virtual machine, including collecting data flow information at CALL and DELEGATECALL instructions to determine the data distance during the fuzz testing process.

[0102] In one embodiment, the plugging operation on the Ethereum virtual machine is specifically implemented as follows:

[0103] The official Python implementation of Ethereum virtual machine, eth library, was called to obtain the key parameters of the call for the external call instruction corresponding to the reentrancy vulnerability point and the delegate call delegatecall instruction corresponding to the dangerous delegate call vulnerability point;

[0104] The data distance of the target basic block of the reentrancy vulnerability is determined as follows: modify the Call class in eth / vm / logic / call.py. When reading the call parameter, compare the to parameter of call (i.e. the callee of the external call) to see if it is the msg.sender (i.e. the transaction sender) at this time. If so, determine whether the basic block being executed at this time is the target basic block. If so, determine the data distance of the basic block to be 0.

[0105] The data distance of the target basic block of the dangerous delegate call vulnerability is judged as follows: modify the calldatacopy method in eth / vm / logic / context.py. The call of this method indicates that msg.data is copied to memory. The corresponding position in memory at this time should be marked as contaminated according to the mem_start_position parameter in calldatacopy; modify the Delegatecall class in eth / vm / logic / call.py to check whether the parameter memory_input_start_position (that is, the position where the parameter is read from the memory) is contaminated during the delegate call. If so, determine whether the target basic block is executed at this time. If so, determine the data distance of the basic block to 0.

[0106] The present invention combines static analysis with directional gray-box fuzz testing, and guides the seed scheduling process of gray-box fuzz testing according to the vulnerability point information obtained in the static analysis. Compared with traditional fuzz testing schemes, the present invention has stronger targeting and faster vulnerability detection speed. Compared with the static analysis method, the vulnerability false alarm rate of the present invention is lower, and the constructed transaction sequence is easy to reproduce and verify.

[0107] In one implementation, the seed score is calculated by:

[0108] Compute basic block B i The seed distance d(B i ) is the basic block distance d of the basic block T (B i ) and the data distance d D (B i ) and d(B i ) = d T (B i )+d D (B i );

[0109] To calculate the seed score S(s), first calculate the transaction scores of all single transactions in seed s. The calculation method is to take the inverse of the arithmetic mean of the seed distances of all basic blocks that the transaction passes through. After calculating the scores of all single transactions, the seed score of the seed is the maximum value of all transactions.

[0110]

[0111] Among them, t l is a single transaction in seed s, Trace(t l ) indicates t l All basic blocks traversed.

[0112] In one embodiment, during the fuzz testing phase, an initial seed population twice the number of callable functions in the contract is generated, and a single transaction contains environmental information and transaction information. The environmental information includes timestamp, block number, call result, return data size, and external code size; in the selection process of seed parents, the higher the seed score, the more likely it is to be selected to produce offspring; the crossover operation splices the transaction sequence of one seed after another to preserve the read-write dependency of state variables between transaction sequences; in order to increase individual diversity, it is also necessary to use a mutation pool to mutate the seed.

[0113] The newly generated seed group or the initial seed group needs to run all the seed individuals in it. The simulation process relies on the official Python implementation of the Ethereum virtual machine, the eth library. During the execution of each seed, the fuzz test module collects the basic block information it passes through, calculates the seed score, detects whether the vulnerability is triggered, and applies the score to the next seed scheduling.

[0114] When the seed is running, the execution status of the seed is also detected. If it meets the pre-set vulnerability template, the vulnerability point and type are reported, realizing dynamic detection of vulnerabilities during the fuzz testing process.

[0115] An embodiment also provides an automatic smart contract vulnerability detection system based on directed testing, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the automatic smart contract vulnerability detection method based on directed testing is implemented when the processor executes the program.

[0116] In one embodiment, the computer program can automatically detect common smart contract vulnerabilities (reentrancy vulnerabilities, Ethereum lock vulnerabilities, dangerous delegate call vulnerabilities, and timestamp dependency vulnerabilities), including: writing a corresponding smart contract vulnerability detection tool, which is implemented in Python; combining static analysis with targeted gray box fuzz testing methods, using the vulnerability points initially detected in static analysis to guide the seed scheduling of the fuzz testing process, thereby achieving targeted vulnerability detection; using customized basic block distances and data distances to measure the proximity of each basic block in the bytecode level control flow graph to the target basic block, and adjusting the seed selection algorithm of the traditional CGF through the calculation of the seed distance, thereby guiding the seed scheduling, so that the fuzz test is carried out in a direction that is more likely to trigger the vulnerability; matching vulnerability patterns during the fuzz testing process, outputting vulnerability detection results, and achieving automated vulnerability detection.

[0117] The present invention is further described below through specific experiments.

[0118] First, the efficiency of the present invention in detecting vulnerabilities is tested, that is, the time and number of transactions required to detect vulnerabilities. Using the vulnerability data set verified by the static analysis tool Slither, 100 manually reviewed contracts were selected as the data set for this part of the experiment. The comparative work is ConFuzzius, which also performs fuzz testing. After running the test, the present invention detected 86 vulnerabilities in the data set, of which 67 took less time to detect than ConFuzzius, accounting for 77.9%; 77 of the vulnerabilities required less transactions than ConFuzzius, accounting for 89.5%. This experiment illustrates the superiority of the present invention's solution over traditional gray box fuzz testing tools.

[0119] The vulnerability detection accuracy and recall rate of the present invention were tested. The data set was 100 contracts that had not been manually reviewed in the verification data set of the static analysis tool Slither, and the comparison work was ConFuzzius. Among the total 107 vulnerability samples of 100 contracts, the present invention detected 93 true positive vulnerabilities, 4 false positive vulnerabilities, and 10 false negative vulnerabilities; ConFuzzius detected 92 true positive vulnerabilities, 7 false positive vulnerabilities, and 8 false negative vulnerabilities. Calculations show that the vulnerability detection accuracy of the present invention is 95.9%, and the vulnerability detection accuracy of ConFuzzius is 92.9%; the vulnerability detection recall rate of the present invention is 90.3%, and the vulnerability detection recall rate of ConFuzzius is 92.0%. The reason why the accuracy of the present invention is higher than that of ConFuzzius, and the recall rate is slightly lower than that of ConFuzzius, is that the present invention adopts a directional detection method, and this method does not significantly reduce the branch exploration breadth of the fuzz testing process, and retains the basic path exploration capabilities of traditional CGF tools.

[0120] This experiment conducted comparative tests on the present invention and related work on multiple data sets, and compared the efficiency indicators of smart contract vulnerability detection tools in detecting vulnerabilities, including the time required for vulnerability detection, the number of transactions required for vulnerability detection, and the accuracy and recall rate of vulnerability detection. The results showed that the vulnerability detection effect of the present invention is better than that of the traditional CGF scheme, which illustrates the feasibility and effectiveness of the algorithm of the present scheme.

[0121] It should be understood that the embodiments described above are part of the embodiments of the present invention, rather than all of the embodiments. In addition, the technical features in the various embodiments or single embodiments provided by the present invention can be combined with each other arbitrarily to form a feasible technical solution. Such combination is not restricted by the sequence of steps and / or the structural composition mode, but must be based on the ability of ordinary technicians in the field to implement. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the protection scope required by the present invention.

[0122] It should be understood that the above description of the preferred embodiment is relatively detailed and cannot be regarded as limiting the scope of patent protection of the present invention. Under the enlightenment of the present invention, ordinary technicians in this field can also make substitutions or modifications without departing from the scope of protection of the claims of the present invention, which all fall within the scope of protection of the present invention. The scope of protection requested for the present invention shall be based on the attached claims.

Claims

1. A method for automatic detection of smart contract vulnerabilities based on directional testing, characterized in that: The following steps are involved: Step 1: Perform static analysis on the target contract; Compile the target contract, generate an abstract syntax tree, and recover important contract information from the abstract syntax tree, including the contract's high-level objects, inheritance diagram, and Solidity expressions; convert the Solidity expressions into intermediate representations to complete code analysis, including variable read and write operations, data dependencies, and protected functions; rely on the analysis results to match contract vulnerabilities according to vulnerability detection rules, complete vulnerability detection in the static analysis phase, and preliminarily determine the type of contract vulnerability and its location in the source code; Step 2: Preprocess the target contract; Build the control flow graph of the contract, set the target basic blocks to be reached in the fuzz test according to different vulnerability types, and insert special instructions at the corresponding position of the original contract for each vulnerability point detected in the static analysis, so as to locate the specific position of the vulnerability point in the Ethereum bytecode control flow graph, and then calculate the basic block distance and data distance of all basic blocks of the contract based on the control flow graph and the target basic block location information; Step 3: Perform targeted gray-box fuzz testing on the target contract; First, the Ethereum virtual machine is instrumented to obtain runtime information; Then, fuzz testing is performed to generate seeds. The seed score is calculated based on the basic block distance and data distance passed in during the preprocessing process to guide seed scheduling, select the seed closest to the trigger target basic block for crossover and mutation operations, and perform vulnerability detection during execution to generate detection results.

2. The method for automatically detecting smart contract vulnerabilities based on directional testing according to claim 1 is characterized in that: The specific implementation of step 1 includes the following steps: Step 1.1: Generate an abstract syntax tree; The solc compiler compiles the contract file input by the user and generates an abstract syntax tree in JSON format; Step 1.2: Restore important contract information; Extract high-level objects including contract objects, enumeration objects, and structure data objects from the abstract syntax tree, and determine the inheritance order of each contract in the .sol file, and then restore the contract inheritance relationship in the smart contract file; extract the Solidity high-level expression structure from the abstract syntax tree and restore it; finally restore the original control flow graph of the contract; Step 1.3: Generate intermediate representation; Use static single assignment intermediate representation to convert the Solidity expression of the node in the contract control flow graph into intermediate representation storage; Step 1.4: Code analysis, including variable read and write analysis, data dependency analysis, and protected function analysis; Step 1.5: Static vulnerability detection; Use pre-defined static vulnerability detection rules to detect vulnerabilities in the contract, so as to preliminarily mark the target vulnerability points that need to be reached during the subsequent directed gray box fuzz testing process.

3. The method for automatically detecting smart contract vulnerabilities based on directional testing according to claim 1 is characterized in that: The specific implementation of step 2 includes the following steps: Step 2.1: Build a control flow graph; Use the solc compiler to compile the contract and output the bytecode for the contract runtime, which is used to build the control flow graph of the contract based on the Ethereum virtual machine assembly language; Step 2.2: Locate the vulnerability control flow graph according to the vulnerability constraint rules; According to different vulnerability types, the target basic blocks to be reached in the fuzz test are set. For each vulnerability point detected in the static analysis, the INVALID instruction is inserted at the corresponding position of the original contract to locate the specific position of the vulnerability point in the Ethereum bytecode control flow graph. Step 2.3: Calculation of basic block distance and data distance; According to the predefined basic block distance calculation formula, the basic block distance and data distance of each basic block in the control flow graph are calculated.

4. The method for automatically detecting smart contract vulnerabilities based on directional testing according to claim 3 is characterized in that: In step 2.1, the construction of the contract is based on the control flow graph of the Ethereum virtual machine assembly language, which converts the hexadecimal bytecode into Ethereum virtual machine assembly instructions, performs preliminary segmentation of the basic blocks, performs PUSH-type jump connections and isolated jump connections, and finally cleans up the control flow graph.

5. The method for automatically detecting smart contract vulnerabilities based on directional testing according to claim 3 is characterized in that: In step 2.2, the specific location of the vulnerability point in the Ethereum bytecode control flow graph is located, and the specific implementation includes the following steps: (1) Compile the source code of the smart contract to obtain its bytecode, and construct a bytecode-level contract control flow graph from the bytecode; (2) Obtain the location of the contract vulnerability in the source code through static analysis, insert the INVALID operation code at the location of the vulnerability in the source code, and record it as a new source code file; (3) Compile the new source code file to obtain its bytecode, and construct the contract control flow graph corresponding to the new source code file, which contains the INVALID operation code; (4) Compare the original contract control flow graph with the new source code file control flow graph to obtain the offset of the vulnerability point in the bytecode control flow graph.

6. The method for automatically detecting smart contract vulnerabilities based on directional testing according to claim 3 is characterized in that: In step 2.3, the i-th basic block in the control flow graph is B i , the jth target basic block is T j , basic block B i To basic block T j Distance The distance calculation formula is: in, Indicates B i To T j If there is a jump edge, the path distance is 1; Indicates B i For those who can reach T j Other basic blocks B k If there is a jump edge, take the shortest directed path and add 1; Oterwise means B i is the target basic block or an unreachable target basic block, the distance is recorded as infinity∞; After calculating the distances of all basic blocks B to all target basic blocks T, calculate the distances of basic block B to all target basic blocks T. i The basic block distance d T (B i ): In the above formula, B i ∈T means that the basic block is the target basic block, and the basic block distance of the basic block is recorded as 0; If a basic block is unreachable to any target basic block, the basic block will not be included in the basic block distance calculation, and will not be included in the seed execution path in the fuzz testing module; Oterwise means that for the remaining basic blocks, the basic block distance is calculated by taking the harmonic average of the path distances to all target basic blocks, where n is the total number of target basic blocks.

7. The method for automatically detecting smart contract vulnerabilities based on directional testing according to claim 3 is characterized in that: In step 2.3, basic block B i Data distance d D (B i ) is calculated as: Among them, B i ∈T indicates that the basic block is the target basic block, data(B i ) Determine basic block B i Whether the data constraints are met, d T (B i ) is the basic block B i The basic block distance of B, NaN means that the basic block distance or data distance of the basic block is not considered; i ∈T∧data(B i )=True means that the target basic block data distance that satisfies the data constraint is set to 0; d T (B i )isNaN means ignoring the basic blocks that cannot reach any target basic blocks and the subsequent basic blocks of the target basic blocks that are not calculated in the basic block distance calculation; Oterwise means setting the data distance of all other basic blocks to the MAX value.

8. The method for automatically detecting smart contract vulnerabilities based on directional testing according to claim 1 is characterized in that: In step 3, the Ethereum virtual machine is plugged in, and the specific implementation process is: The official Python implementation of Ethereum virtual machine, eth library, was called to obtain the key parameters of the call for the external call instruction corresponding to the reentrancy vulnerability point and the delegate call delegatecall instruction corresponding to the dangerous delegate call vulnerability point; The data distance of the target basic block of the reentrancy vulnerability is determined as follows: modify the Call class in eth / vm / logic / call.py. When reading the call parameter, compare whether the to parameter of call is msg.sender at this time. If so, determine whether the basic block being executed at this time is the target basic block. If so, determine the data distance of the basic block to 0. The data distance of the target basic block of the dangerous delegate call vulnerability is judged as follows: modify the calldatacopy method in eth / vm / logic / context.py. The call of this method indicates that msg.data is copied to memory. According to the mem_start_position parameter in calldatacopy, the corresponding position in memory is marked as contaminated. Modify the Delegatecall class in eth / vm / logic / call.py to check whether the parameter memory_input_start_position is contaminated during the delegate call. If so, determine whether the target basic block is executed at this time. If so, determine the data distance of the basic block to 0.

9. The method for automatically detecting smart contract vulnerabilities based on directional testing according to claim 1 is characterized in that: In step 3, the seed score is calculated, and the specific implementation process is: Compute basic block B i The seed distance d(B i ) is the basic block distance d of the basic block T (B i ) and the data distance d D (B i ) and d(B i ) = d T (B i )+d D (B i ); Calculating Seeding Score Among them, t l is a single transaction in seed s, Trace(t l ) indicates t l All basic blocks traversed.

10. A smart contract vulnerability automatic detection system based on directed testing, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method for automatically detecting smart contract vulnerabilities based on directed testing as described in any one of claims 1 to 9 is implemented.

Images