A method and system for automatically detecting vulnerabilities of a smart contract based on directional testing

Abstract

The application discloses a kind of based on the automatic detection method and system of smart contract vulnerability of directional test, combines static analysis and directional grey box fuzzy test detection means, proposes a novel grey box fuzzy test guiding strategy, utilizes the vulnerability information of preliminary investigation of smart contract in static analysis stage, guides the seed scheduling of grey box fuzzy test stage, judges the priority of seed by the path distance and data distance of seed running path and target basic block, so that seed closer to triggering vulnerability has more opportunities to produce offspring, so as to more targetedly derive seed population close to target basic block.The application adopts directional test, combines static analysis and fuzzy test, realizes the rapid and accurate detection to smart contract vulnerability.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of information security technology in computer science, and relates to a vulnerability detection method and system for smart contract, in particular to an accurate and automated detection method and system for smart contract vulnerability based on directional testing. BACKGROUND

[0002] A smart contract is an automated computer program designed to execute, manage and enforce contractual clauses reached between the two parties. With the development of blockchain and smart contract technology, concepts and technologies such as digital wallet, distributed identity authentication, decentralized autonomous organization, non-fungible token, etc. have ushered in a boom. However, the smart contract technology brings opportunities as well as challenges. Due to the characteristics of smart contract such as fast iteration speed of programming language, irreversibility after deployment, high cost of digital currency storage, etc., problems caused by smart contract vulnerabilities often have 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

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

[0004] The technical scheme adopted by the method of the present application is: an automated detection method for smart contract vulnerability based on directional testing, comprising the following steps:

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

[0006] The target contract is compiled to generate an abstract syntax tree, and important information of the contract is recovered from the abstract syntax tree, including high-level objects of the contract, inheritance relationship diagram and Solidity expression; the Solidity expression is converted into an intermediate representation form, and code analysis is completed, including variable read-write operation, data dependency relationship and protected function; relying on the analysis results, the contract vulnerability is matched according to the vulnerability detection rules, the vulnerability detection in the static analysis stage is completed, and the type of the contract vulnerability and its position in the source code are preliminarily determined;

[0007] Step 2: preprocessing of the target contract;

[0008] The control flow graph of the contract is constructed, the target basic block to be reached in the fuzz testing is set according to different vulnerability types, special instructions are inserted at the corresponding positions 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 the basic block distance and data distance of all basic blocks of the contract are calculated relying on the control flow graph and the position information of the target basic block.

[0009] Step 3: 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, seeds are generated, and seed scores are calculated based on the basic block distance and data distance passed in during preprocessing to guide seed scheduling, select seeds closest to the target basic block for crossover and mutation operations, and perform vulnerability detection while executing to generate detection results.

[0011] As a preferred embodiment, 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 to generate a json format abstract syntax tree;

[0014] Step 1.2: Restore important contract information;

[0015] High-level objects including contract objects, enumeration objects, and structured data objects are extracted from the abstract syntax tree, and the inheritance order of each contract in the.sol file is determined to restore the contract inheritance relationship in the smart contract file; Solidity high-level expression structures are extracted from the abstract syntax tree and restored; finally, the original control flow graph of the contract is restored;

[0016] Step 1.3: Generate an intermediate representation;

[0017] An intermediate representation in the form of static single assignment is used to convert Solidity expressions in the nodes of the contract control flow graph into an intermediate representation for storage;

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

[0019] Step 1.5: Static vulnerability detection;

[0020] Predefined static vulnerability detection rules are used to detect vulnerabilities in the contract, thereby preliminarily marking target vulnerability points that need to be reached during subsequent targeted gray-box fuzz testing.

[0021] As a preferred embodiment, step 2 includes the following steps:

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

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

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

[0025] According to different vulnerability types, set the target basic block to be reached in the fuzz test, for each vulnerability point detected in static analysis, insert the INVALID instruction at the corresponding position of the original contract, thereby locating the specific position of the vulnerability point in the Ethereum bytecode control flow graph,

[0026] Step 2.3: Basic block distance and data distance calculation;

[0027] According to the pre-defined basic block distance calculation formula, calculate the basic block distance and data distance of each basic block in the control flow graph.

[0028] As a preferred, in step 2.1, the contract based on the control flow graph of Ethereum virtual machine assembly language is to convert the hexadecimal bytecode into Ethereum virtual machine assembly instructions, preliminarily segment the basic blocks, perform PUSH type jump connection and isolated type jump connection, and finally perform control flow graph cleaning.

[0029] As a preferred, in step 2.2, the specific position of the vulnerability point in the Ethereum bytecode control flow graph is specifically implemented by the following steps:

[0030] (1) From the source code of the smart contract, compile its bytecode, and construct the contract control flow graph at the bytecode level from the bytecode;

[0031] (2) From the static analysis, get the vulnerability point in the source code, insert the INVALID opcode at the vulnerability point in the source code, and record it as a new source code file;

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

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

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

[0035]

[0036] Where, Bi For T j If a jump edge exists, the path distance is 1; B i For reachable T j Other basic blocks B k If a jump edge exists, take the shortest directed path and add 1; Otterwise represents B. i For a target basic block or an unreachable target basic block, the distance is denoted as infinity ∞;

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

[0038]

[0039] In the above formula, B i If ∈T, it 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 from any target basic block, then that basic block will not be included in the basic block distance calculation, nor will it be counted in the seed execution path in the fuzzing module; Otterwise means that for the remaining basic blocks, the basic block distance is calculated as the harmonic mean 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 The calculation method is as follows:

[0041]

[0042] Among them, B i ∈T indicates that the basic block is the target basic block, data(B i Determine the basic block B i Does it satisfy the data constraints, d T (B i ) is the basic block B i The basic block distance, NaN indicates that the basic block distance or data distance of this basic block is not considered; B i ∈T∧data(B i ) = True indicates that the data distance of the target basic block that satisfies the data constraints is set to 0; d T (B i)NaN means to ignore the basic blocks that cannot reach any target basic block and the successor basic blocks of the target basic blocks in the basic block distance calculation; Otherwise means to set the data distance of all other basic blocks to the MAX value.

[0043] As preferred, in step 3, the Ethereum virtual machine is instrumented, and the specific implementation process is as follows:

[0044] The official Python implementation of the Ethereum virtual machine, eth library, is called, and the key parameters of the corresponding external call call instruction and the corresponding delegate call delegatecall instruction of the dangerous delegate call vulnerability point are obtained.

[0045] For the data distance of the reentrant vulnerability target basic block, the following is judged: modify the Call class in eth / vm / logic / call.py, compare the to parameter of call (i.e. the external call callee) with msg.sender (i.e. the transaction sender) when reading the call parameter, if they are the same, it is determined whether the target basic block is executed, if so, the data distance of the basic block is determined as 0.

[0046] For the data distance of the dangerous delegate call vulnerability target basic block, the following is judged: modify the calldatacopy method in eth / vm / logic / context.py, which indicates that msg.data is copied to memory, and mark the corresponding position in memory as contaminated according to the mem_start_position parameter in calldatacopy; modify the Delegatecall class in eth / vm / logic / call.py, check whether the memory_input_start_position (i.e. the position of reading parameters in memory) is contaminated when the delegate call is executed, if so, it is determined whether the target basic block is executed, if so, the data distance of the basic block is determined as 0.

[0047] As preferred, in step 3, the seed score is calculated, and the specific implementation process is as follows:

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

[0049] Computing seed scores where t l is a single transaction in seed s, Trace(t l ) represents all basic blocks traversed by t l .

[0050] The technical scheme of the system of the present application is: an intelligent contract vulnerability automatic detection system based on directional testing, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, and the processor implements the intelligent contract vulnerability automatic detection method based on directional testing when executing the program.

[0051] Compared with the prior art, the beneficial effects of the present application mainly lie in the following aspects:

[0052] (1) Compared with the strategy of randomly exploring program code space of the traditional coverage-guided gray-box fuzzing method, the use case generation guidance strategy of the present application is more targeted to the target vulnerability point, has higher utilization rate for single seed selection, avoids invalid exploration of irrelevant program branches, and thus reduces the vulnerability detection time.

[0053] (2) The detection means combining static analysis with directional gray-box fuzzing of the present application not only optimizes the use case generation of fuzzing in an heuristic manner, but also further verifies the authenticity of the vulnerabilities reported by static analysis through dynamic analysis during the fuzzing process, to a certain extent, avoiding the problem of high false positive rate of using a single vulnerability detection method.

[0054] (3) Comparative tests of the present application and related work on multiple data sets are carried out, and the related efficiency indicators of the intelligent contract vulnerability detection tool for detecting vulnerabilities are compared, including the time required for detecting vulnerabilities, the number of transactions required for detecting vulnerabilities, the accuracy and recall rate of vulnerability detection, and false positive reports. The results prove that the vulnerability detection effect of the present application 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 DRAWINGS

[0055] The technical scheme of the present application is further illustrated below using examples and specific embodiments. In addition, some drawings are also used in the process of explaining the technical scheme. For those skilled in the art, other drawings and the intention of the present application can also be obtained from these drawings without creative labor.

[0056] Figure 1 The method principle framework of the embodiments of the present application is as follows:

[0057] Figure 2A static analysis module schematic diagram in an embodiment of the present application;

[0058] Figure 3 A preprocessing module schematic diagram in an embodiment of the present application;

[0059] Figure 4 A directed gray-box fuzz testing module schematic diagram in an embodiment of the present application. DETAILED DESCRIPTION

[0060] In order to facilitate those skilled in the art to understand and implement the present application, the present application will be further described in detail below in combination with the drawings and embodiments. It should be understood that the embodiments described herein are only used to illustrate and explain the present application, and are not used to limit the present application.

[0061] The present application combines static analysis and directed gray-box fuzz testing detection means, proposes a novel gray-box fuzz testing guidance strategy, uses the vulnerability information preliminarily checked by the static analysis stage for the smart contract to guide the seed scheduling in the gray-box fuzz testing stage, judges the priority of the seed through the path distance and data distance between the seed running path and the target basic block, so that the seed closer to triggering the vulnerability has more opportunities to produce offspring, thereby more targetedly deriving the seed population close to the target basic block.

[0062] See Figure 1 The present embodiment provides a kind of based on directed test's smart contract vulnerability automatic detection method, comprising the following steps:

[0063] Step 1: static analysis is carried out on target contract;

[0064] The target contract is compiled, the abstract syntax tree is generated, the important information of contract is recovered from the abstract syntax tree, including the high-level object of contract, inheritance relationship diagram and Solidity expression; the Solidity expression is converted into intermediate representation form, code analysis is completed, including variable reading and writing operation, data dependency relationship, protected function; according to the previously written vulnerability detection rule, the contract vulnerability is matched by relying on the analysis result, the vulnerability detection in static analysis stage is completed, so that the type of contract vulnerability and its position in source code are preliminarily determined;

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

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

[0067] The contract file input by the user is compiled by the solc compiler to generate a json format abstract syntax tree;

[0068] Step 1.2: recovering important contract information;

[0069] High-level objects including contract objects, enumeration objects, and structure data objects are extracted from the abstract syntax tree, and the inheritance order of each contract in the.sol file is determined to restore the contract inheritance relationship in the smart contract file; Solidity high-level expression structures are extracted from the abstract syntax tree and restored; and finally, the original control flow graph of the contract is restored;

[0070] Step 1.3: Generate intermediate representation;

[0071] The intermediate representation in the form of static single assignment is used to convert the Solidity expression of the node in the contract control flow graph into intermediate representation storage; so that the analysis process is more convenient without losing necessary semantic information;

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

[0073] Step 1.5: Static vulnerability detection;

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

[0075] Step 2: Preprocessing of the target contract;

[0076] The control flow graph of the contract is constructed, the target basic block that needs to be reached in the fuzz testing is set according to different vulnerability types, and for each vulnerability point detected in the static analysis step, a special 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, and then the basic block distance and data distance of all basic blocks of the contract are calculated based on the control flow graph and the target basic block position information;

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

[0078] Step 2.1: Construct the control flow graph;

[0079] The contract is compiled by using the solc compiler, and the output is the bytecode of the contract runtime, which is used to construct the control flow graph of the contract based on the Ethereum virtual machine assembly language;

[0080] In one embodiment, the control flow graph of the contract based on the Ethereum virtual machine assembly language is to convert the hexadecimal bytecode into Ethereum virtual machine assembly instructions, preliminarily segment the basic blocks, perform PUSH type jump connection and isolated type jump connection, and finally clean 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 block to be reached in the fuzz test is set, for each vulnerability point detected in the static analysis, an INVALID instruction is inserted at the corresponding position of the original contract, so as to locate the specific position of the vulnerability point in the Ethereum bytecode control flow graph,

[0083] In an embodiment, the specific position of the vulnerability point in the Ethereum bytecode control flow graph is located, and the implementation includes the following steps:

[0084] (1) From the source code of the smart contract, the bytecode is compiled, and the contract control flow graph at the bytecode level is constructed from the bytecode;

[0085] (2) The vulnerability point in the source code is obtained by static analysis, and the INVALID operation code is inserted at the vulnerability point in the source code, which is recorded as a new source code file;

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

[0087] (4) The original contract control flow graph is compared 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: Basic block distance and data distance calculation;

[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 of the basic block to reach each target basic block, that is, the control flow graph path length to reach the target; The data distance describes whether the data constraint in the fuzz test execution process meets the requirement of triggering the target vulnerability.

[0090] In an embodiment, the i-th basic block in the control flow graph is B i , the j-th target basic block is T j , the distance of the basic block B i to the basic block T j is The distance calculation formula is:

[0091]

[0092] Wherein, B i to T j exists a jump edge, then the path distance is 1; B i to T jother basic blocks B k If there exists a jump edge, take the shortest directed path among them and add 1; Otherwise, represent B i If it is a target basic block or an unreachable target basic block, the distance is recorded as infinity ∞;

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

[0094]

[0095] In the above formula, B i ∈ T represents that the basic block is a target basic block, and the basic block distance of the basic block is recorded as 0; represents that the basic block is unreachable to any target basic block, and the basic block is not included in the basic block distance calculation, and is not included in the execution path of the seed in the fuzzy testing module; Otherwise, for the remaining basic blocks, the calculation method of the basic block distance is to take the harmonic mean of the path distance of the basic block to all target basic blocks, where n is the total number of target basic blocks.

[0096] In an embodiment, the data distance d D (B i ) of basic block B i is calculated as follows:

[0097]

[0098] Wherein, B i ∈ T represents that the basic block is a target basic block, data(B i ) judges whether the basic block B i satisfies the data constraint, d T (B i ) is the basic block distance of basic block B i , NaN represents that the basic block distance or data distance of the basic block is not considered; B i ∈ T ∧ data(B i ) = True represents that the data distance of the target basic block satisfying the data constraint is set to 0; d T (B i ) isNaN represents that the basic block distance calculation ignores the basic blocks that cannot reach any target basic block and the subsequent basic blocks of the target basic block which are not calculated; Otherwise, it represents that the data distance of all other basic blocks is set 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 necessary runtime information; then fuzz testing is performed, seeds are generated, and seed scores are calculated according to the basic block distance and data distance passed in during preprocessing to guide seed scheduling, select seeds closest to the target basic block for crossover and mutation operations, and perform vulnerability detection while executing to generate detection results, thereby automatically completing smart contract vulnerability detection.

[0101] To obtain runtime information, some modifications need to be made to the Ethereum virtual machine. Specifically, data flow information is collected at the CALL and DELEGATECALL instructions to determine the data distance during fuzz testing.

[0102] In an embodiment, the Ethereum virtual machine is instrumented, and the implementation process is as follows:

[0103] The eth library, which is a Python implementation of the Ethereum virtual machine provided by Ethereum, is called, and the key parameters of the external call call instruction corresponding to the reentrant vulnerability point and the delegate call delegatecall instruction corresponding to the dangerous delegate call vulnerability point are obtained.

[0104] The data distance of the reentrant vulnerability target basic block is determined as follows: modify the Call class in eth / vm / logic / call.py, compare the to parameter of call (i.e., the external call callee) with the msg.sender (i.e., the transaction sender) at the time of reading the call parameters, and if they are the same, determine whether the target basic block is executed at this time, and if so, determine the data distance of the basic block as 0.

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

[0106] The application combines static analysis and directed gray-box fuzz testing, and according to the vulnerability point information obtained in the static analysis, the seed scheduling process of the gray-box fuzz testing is guided, compared with the traditional fuzz testing scheme, the application is more targeted and faster in detecting vulnerabilities; compared with the static analysis method, the application has a lower false positive rate, and the transaction sequence constructed is convenient for reproduction and verification.

[0107] In an embodiment, the seed score is calculated, and the specific implementation process is as follows:

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

[0109] The seed score S(s) is calculated, first, the transaction score of all single transactions in the seed s is calculated, the calculation method is to take the reciprocal of the arithmetic mean of the seed distances of all basic blocks passed by the transaction, after calculating the scores of all single transactions, the seed score of the seed is the maximum value in all transactions.

[0110]

[0111] Where t l is a single transaction in the seed s, and Trace(t l ) represents all basic blocks traversed by t l .

[0112] In an embodiment, in the fuzz testing stage, according to the number of callable functions in the contract, an initial seed population 2 times the number is generated, and the single transaction contains environment information and transaction information. The environment information includes timestamp, block number, call result, return data size and external code size; in the selection process of the seed parent, the higher the seed score, the more likely to be selected to produce offspring; the cross operation splices the transaction sequence of one seed after another to preserve the state variable read-write dependency relationship between the transaction sequences; in order to increase individual diversity, seed mutation is also needed by using a mutation pool.

[0113] Both the newly generated seed population or the initial seed population need to run all the seed individuals therein. The process of simulation running depends on the official Python implementation of Ethereum Virtual Machine, eth library. In the process of execution of each seed, the fuzzing module collects the basic block information thereof passed, counts the seed score, detects whether a vulnerability is triggered, and applies the score to the next seed scheduling.

[0114] In the process of seed running, the execution condition of the seed is detected simultaneously, and if the pre-set vulnerability template is met, the vulnerability point and type are reported, so as to realize dynamic detection of the vulnerability in the process of fuzzing.

[0115] The embodiment also provides an intelligent contract vulnerability automatic detection system based on directional testing, including a memory, a processor, and a computer program stored on the memory and capable of running on the processor, and the processor implements the intelligent contract vulnerability automatic detection method based on directional testing when executing the program.

[0116] In an implementation, the computer program can automatically detect common intelligent contract vulnerabilities (reentrant vulnerability, Ethereum lock vulnerability, dangerous delegate call vulnerability, and timestamp dependency vulnerability), including: an intelligent contract vulnerability detection tool is written, the tool is implemented by Python; in combination with static analysis and directional gray-box fuzzing means, the vulnerability point preliminarily detected in the static analysis is used to guide the seed scheduling in the process of fuzzing, so as to realize directional vulnerability detection; the self-defined basic block distance and data distance are used to measure the proximity of each basic block in the bytecode level control flow graph to the target basic block, and through the calculation of the seed distance, the seed selection algorithm of the traditional CGF is adjusted, so as to guide the seed scheduling and make the fuzzing proceed in a direction more likely to trigger a vulnerability; in the process of fuzzing, a vulnerability mode is matched, a vulnerability detection result is output, and automatic vulnerability detection is realized.

[0117] The following further illustrates the present application through specific experiments.

[0118] First, the efficiency of detecting vulnerabilities by the present application is detected, that is, the time required for detecting vulnerabilities and the number of transactions. A vulnerability data set verified by the static analysis tool Slither is used, 100 contracts audited by humans are selected as the data set of this experiment. The comparison work is ConFuzzius, which is also a fuzzing work. After running the test, 86 vulnerabilities in the data set are detected by the present application, 67 of which are detected in less time than ConFuzzius, accounting for 77.9%; 77 of which are detected in less number of transactions than ConFuzzius, accounting for 89.5%. This experiment shows the superiority of the present application scheme compared with the traditional gray-box fuzzing tool.

[0119] To verify the accuracy and recall of the vulnerability detection of the present application, 100 contracts without manual review in the Slither verification data set are used as the data set, and the comparison work is ConFuzzius. Among the total of 107 vulnerability samples in 100 contracts, the present application detects 93 true positive vulnerabilities, 4 false positive vulnerabilities and 10 false negative vulnerabilities; ConFuzzius detects 92 true positive vulnerabilities, 7 false positive vulnerabilities and 8 false negative vulnerabilities. Calculation can obtain the accuracy of the vulnerability detection of the present application as 95.9%, and the accuracy of the vulnerability detection of ConFuzzius as 92.9%; the recall of the vulnerability detection of the present application is 90.3%, and the recall of the vulnerability detection of ConFuzzius is 92.0%. The accuracy of the present application is higher than that of ConFuzzius, and the reason why the recall is slightly lower than that of ConFuzzius is that the present application adopts a directional detection method, and the method does not significantly reduce the branch exploration breadth of the fuzzing process, and retains the basic path exploration capability of the traditional CGF tool.

[0120] The present application and related work are compared and tested on multiple data sets in the experiment, and the related efficiency indicators of the vulnerability detection tools of the smart contract are compared, including the time required for detecting vulnerabilities, the number of transactions required for detecting vulnerabilities, the accuracy and recall of vulnerability detection, and the results prove that the vulnerability detection effect of the present application 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 above-described embodiments are part of the embodiments of the present application, but not all of the embodiments. In addition, the technical features in each embodiment or single embodiment provided by the present application can be combined with each other to form a feasible technical solution, and such combination is not restricted by the sequence of steps and / or structure mode, but must be based on the implementation by ordinary skilled in the art, when the combination of technical solutions appears contradictory or unfeasible, it should be considered that the combination of technical solutions does not exist, and is not within the protection scope of the present application.

[0122] It should be understood that the above description of the preferred embodiments is more detailed, and therefore should not be considered as a limitation on the scope of patent protection of the present application. Ordinary skilled in the art can make substitutions or modifications without departing from the scope of protection claimed by the present application, which falls within the protection scope of the present application. The scope of protection claimed by the present application should be subject to the appended claims.

Claims

1. A method for automatically detecting vulnerabilities of a smart contract based on a directed test, characterized in that, The method comprises the following steps: 1: static analysis of the target contract; compiling the target contract, generating an abstract syntax tree, recovering important information of the contract from the abstract syntax tree, including high-level objects of the contract, an inheritance relationship diagram and a Solidity expression; converting the Solidity expression into an intermediate representation form, completing code analysis, including variable reading and writing operations, data dependency relationships and protected functions; relying on the analysis results, matching the contract vulnerabilities according to the vulnerability detection rules, completing the vulnerability detection in the static analysis stage, and thus preliminarily determining the type of the contract vulnerability and the position of the contract vulnerability in the source code; 2: preprocessing of the target contract; constructing a control flow graph of the contract, setting target basic blocks needed to be reached in the fuzz testing according to different vulnerability types, inserting special instructions at the corresponding positions 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 calculating the basic block distance and data distance of all basic blocks of the contract according to the control flow graph and the position information of the target basic blocks; 2.1: constructing a control flow graph; compiling the contract by using a solc compiler, and outputting bytecode for runtime of the contract, which is used to construct a control flow graph of the contract based on an Ethereum virtual machine assembly language; 2.2: locating a vulnerability control flow graph according to a vulnerability constraint rule; setting target basic blocks needed to be reached in the fuzz testing according to different vulnerability types, inserting an INVALID instruction at the corresponding positions 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, the locating of the specific position of the vulnerability point in the Ethereum bytecode control flow graph comprises: (1) compiling the source code of the smart contract to obtain bytecode, and constructing a contract control flow graph at the bytecode level from the bytecode; (2) inserting an INVALID operation code at the position of the vulnerability point in the source code, and recording the new source code file as a new source code file; (3) compiling the new source code file to obtain bytecode of the new source code file, and constructing a contract control flow graph corresponding to the new source code file, wherein the contract control flow graph contains the INVALID operation code; (4) comparing the original contract control flow graph with the control flow graph of the new source code file to obtain an offset of the vulnerability point in the bytecode control flow graph; 2.3: basic block distance and data distance calculation; calculating the basic block distance and the data distance of each basic block in the control flow graph according to a pre-defined basic block distance calculation formula; 3: directional gray-box fuzz testing of the target contract; first, performing a plug-in operation on the Ethereum virtual machine to obtain runtime information; then, performing the fuzz testing, generating a seed, and calculating a seed score according to the basic block distance and the data distance input in the preprocessing process to guide the seed scheduling, selecting a seed closest to the target basic block for cross and mutation operations, and performing the vulnerability detection while executing to generate a detection result.

2. The method of claim 1, wherein, The specific implementation of step 1 comprises the following steps: 1.1: generating an abstract syntax tree; Compiling the contract file input by the user with the solc compiler to generate an abstract syntax tree in json format; 1.2: Recovering important information of the contract; Extracting high-level objects including contract objects, enumeration objects, and structure data objects from the abstract syntax tree, and judging the inheritance order of each contract in the.sol file to further recover the contract inheritance relationship in the smart contract file; extracting the Solidity high-level expression structure from the abstract syntax tree and recovering; and finally recovering the original control flow graph of the contract; 1.3: Generating an intermediate representation; Using a static single assignment form of intermediate representation, the Solidity expression of the nodes in the contract control flow graph is converted into an intermediate representation storage; 1.4: Code analysis, including variable read-write analysis, data dependency analysis, and protected function analysis; 1.5: Static vulnerability detection; Using pre-defined static vulnerability detection rules to detect vulnerabilities in the contract, thereby preliminarily marking the target vulnerability points that need to be reached in the subsequent directed gray-box fuzz testing process.

3. The method of claim 1, wherein the method further comprises: In step 2.1, the construction of the contract based on the control flow graph of the Ethereum virtual machine assembly language is to convert the hexadecimal bytecode into Ethereum virtual machine assembly instructions, preliminarily segment the basic blocks, perform PUSH type jump connection and isolated type jump connection, and finally perform control flow graph cleaning.

4. The method of claim 1, wherein the method further comprises: In step 2.3, the distance between the basic block i and the target basic block is calculated as follows: j where d is the distance between the basic block i and the target basic block . ； wherein, represents to there is a jump edge to the path distance is 1; represents to the reachable other basic blocks there is a jump edge, take the shortest directed path plus 1; represents target basic block or unreachable target basic block, the distance is recorded as infinity ; Compute all basic blocks Compute all basic blocks Compute basic block distances Compute basic block distances Compute basic block distances In the above formula, denotes that the basic block is the target basic block, the basic block distance of this basic block is recorded as 0; denotes that the basic block is not reachable to any target basic block, this basic block is not included in the basic block distance calculation, and is not included in the execution path of the seed in the fuzz testing module; denotes that for the remaining basic blocks, the basic block distance is calculated by taking the harmonic mean of the path distances of all target basic blocks, wherein n is the total number of target basic blocks.

5. The method of claim 1, wherein the method further comprises: In step 2.3, the basic block data distance is calculated as follows: wherein, indicates that the basic block is a target basic block, determines whether the basic block satisfies the data constraint, the basic block distance of the basic block is set to 0; indicates that the basic block distance or the data distance of the basic block is not considered; indicates that the data distance of the target basic block satisfying the data constraint is set to 0; indicates that the basic blocks which cannot reach any target basic block and the subsequent basic blocks of the target basic block which are not calculated in the basic block distance calculation are ignored; indicates that the data distance of all other basic blocks is set to the MAX value.

6. The method of claim 1, wherein the method further comprises: In step 3, the Ethereum virtual machine is instrumented, and the specific implementation process is: The eth library, a Python implementation of the Ethereum virtual machine by Ethereum officials, is called to obtain the key parameters of the call instruction corresponding to the reentrant vulnerability point and the delegatecall instruction corresponding to the dangerous delegate call vulnerability point. The data distance judgment for the reentrant vulnerability target basic block is as follows: modify the Call class in eth / vm / logic / call.py, compare the to parameter of call when reading the call parameter, and if it is the msg.sender at this time, judge whether the target basic block is executed, and if so, determine the data distance of the basic block as 0. The data distance judgment for the dangerous delegate call vulnerability target basic block is as follows: modify the calldatacopy method in eth / vm / logic / context.py, which indicates that msg.data is copied to memory according to the mem_start_position parameter in calldatacopy, and the corresponding position in memory at this time is marked as contaminated; modify the Delegatecall class in eth / vm / logic / call.py, check whether the memory_input_start_position parameter is contaminated when performing delegate call, and if so, judge whether the target basic block is executed, and if so, determine the data distance of the basic block as 0.

7. The method of claim 1, wherein the method further comprises: In step 3, the seed score is calculated, and the specific implementation process is: Seed distance of a basic block Seed distance of a basic block Seed distance of a basic block Seed distance of a basic block Seed distance of a basic block Seed distance of a basic block Computing seed scores wherein, is a seed single transaction, denotes all basic blocks traversed.

8. A system for automatically detecting vulnerabilities of a smart contract based on a directed test, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program comprises the following steps of: receiving a smart contract; generating a directed graph based on the smart contract; generating a directed test based on the directed graph; and executing the directed test on the smart contract. The processor implements the program to realize the method for automatically detecting the vulnerability of the smart contract based on the directional test according to any one of claims 1 to 7.

Images