CN116821913A - Intelligent contract vulnerability detection method based on utility adjustment strategy - Google Patents

Intelligent contract vulnerability detection method based on utility adjustment strategy Download PDF

Info

Publication number
CN116821913A
CN116821913A CN202310498204.1A CN202310498204A CN116821913A CN 116821913 A CN116821913 A CN 116821913A CN 202310498204 A CN202310498204 A CN 202310498204A CN 116821913 A CN116821913 A CN 116821913A
Authority
CN
China
Prior art keywords
test case
test
pool
information
branch
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310498204.1A
Other languages
Chinese (zh)
Inventor
徐向华
王顺
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Dianzi University
Original Assignee
Hangzhou Dianzi University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou Dianzi University filed Critical Hangzhou Dianzi University
Priority to CN202310498204.1A priority Critical patent/CN116821913A/en
Publication of CN116821913A publication Critical patent/CN116821913A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3676—Test management for coverage analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3696—Methods or tools to render software testable
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The invention discloses an intelligent contract fuzzy test method and system based on a utility regulation strategy, firstly, a fuzzy test system preprocesses an intelligent contract to be tested, acquires structural information and branch information related to each function in the contract, randomly generates an initial test case and equally distributes the initial test case into a branch coverage test case pool and a data dependence test case pool generated by a fuzzy; then, the fuzzy test system performs optimization iteration on each test case according to the self test case optimization strategy in different test case pools; and finally, the fuzzy test system respectively executes the test cases in the different test case pools, analyzes the byte code execution logic of the test cases and reports vulnerabilities, calculates the utility values of the different test case pools after the execution is finished, and redistributes the number of the test cases in the test case pools. The intelligent contract fuzzy test method and the intelligent contract fuzzy test system effectively improve the test efficiency of intelligent contract fuzzy test, can explore more branches in the tested intelligent contracts, and can find more contract vulnerabilities.

Description

Intelligent contract vulnerability detection method based on utility adjustment strategy
Technical Field
The invention belongs to the technical field of intelligent contract security vulnerability detection, and particularly relates to an intelligent contract vulnerability detection method and system based on a utility adjustment strategy.
Background
The smart contracts are complete programs of the Turn-on program executing on the blockchain infrastructure, unlike traditional programs, which once deployed cannot be patched to an exposed vulnerability. The intelligent contract fuzzy test is used as a means for intelligent contract vulnerability detection, and has the advantages of automation and high detection accuracy.
The intelligent contract vulnerability detection related open source tool and patent based on fuzzy test are as follows:
ContractFuzzer is the first tool to introduce fuzzy test technology into intelligent contract vulnerability detection, which generates intelligent contract fuzzy test inputs through ABI files of contracts and detects vulnerability problems through a predictor approach. The sFuzz tool considers the problem of how to break through complex branches in the intelligent contracts, and proposes a fuzzy test method based on distance measurement. Smart in generates a more efficient transaction sequence by combining static and dynamic, and analyzes vulnerability issues of smart contracts by obscuring execution phases. Confuzzius is a hybrid ambiguity test tool that turns on the symbol executor to solve for valid parameters when the ambiguities are not progressing.
CN115794625a proposes a fuzzy test method based on genetic algorithm, which generates new test cases for fuzzification by continuously selecting, crossing and mutating the population containing the test cases.
CN115659358A mutates each transaction sequence to be tested and its function parameters by a specific mutation mode, and generates test cases for execution. CN115455435a uses coverage information in the test case execution process to guide the generation of subsequent test cases. CN114840857a adopts a multi-level coverage policy, and uses whether the test case has new coverage characteristics to guide the iterative process of the test case.
However, the intelligent contract fuzzy testing tool and the patent are both single test case optimization strategies, and do not consider that the detection strategies are dynamically adjusted according to the intelligent contract operation process, so that the leak detection of the current intelligent contract cannot be performed in a targeted manner. The fuzzy resource is wasted in the normal test case execution process, so that the efficiency of the fuzzy test on the current intelligent contract vulnerability detection is reduced. Aiming at the problems, the invention provides an intelligent contract fuzzy test method and system based on a utility regulation strategy, which are characterized in that: a plurality of test case optimization schemes exist in the fuzzy system, and the fuzzy resources are distributed to the test case optimization schemes which are more suitable for detecting the current intelligent contract loopholes through the difference of the loopholes detection capability of different test cases in the fuzzy execution process.
Disclosure of Invention
The existing intelligent contract fuzzy test tool and patent are single test case optimization strategies, and the detection strategies are not dynamically adjusted according to the intelligent contract operation process, so that vulnerability detection cannot be carried out on the current intelligent contract in a targeted manner. The fuzzy resource is wasted in the normal test case execution process, so that the efficiency of the fuzzy test on the current intelligent contract vulnerability detection is reduced. Aiming at the problems, the invention provides an intelligent contract fuzzy test method based on a utility regulation strategy, which mainly comprises three stages: a preprocessing stage, an optimization processing stage and an execution analysis stage. Firstly, preprocessing an intelligent contract to be tested by a fuzzy test system, obtaining the dependency information between each function and state variable in the contract and the branch information contained in each function, randomly generating an initial test case by a fuzzifier through analyzing an ABI file compiled by the contract, and equally distributing the initial test case to a branch coverage test case pool and a data dependency test case pool generated by the fuzzifier; then, the fuzzy test system performs optimization iteration on the test cases contained in each test case pool according to the self test case optimization strategies in different test case pools; and finally, the fuzzy test system respectively executes the test cases in the different test case pools, analyzes the byte code execution logic of the test cases and reports vulnerabilities, and the fuzzers calculate utility values of the different test case pools and redistribute the number of the test cases in each test case pool after the execution is finished.
1. Pretreatment stage of the invention
Firstly, performing static analysis on an intelligent contract, acquiring an ABI file of the intelligent contract, converting the ABI file into an intermediate representation (Intermediate Representation, IR) of the intelligent contract by using a split tool, namely the split IR, and collecting dependent information of a function and contract state variables, branch information contained in the function and the like by using a data collection related API in the split tool on the split IR;
and secondly, extracting a public function signature according to the ABI file by utilizing a solc tool, constructing a function selector mapping table, and selecting available function codes in a cyclic sequence to be an initial test case.
Finally, the fuzzifier creates a branch overlay test case pool and a data dependency test case pool and equally distributes the initial test cases into two test case pools.
1.1 static analysis
1.1.1ABI file generation
The fuzzy test system compiles the intelligent contract given by the user into an application binary interface file (Application Binary Interface, ABI) and converts the ABI file into a middle representation of a likelihood IR through a likelihood tool;
1.1.2 contract information acquisition
The fuzzy test system calls a related API of a slit tool on a slit IR for collecting three types of information in contracts and for guiding a subsequent test case optimization process;
The three types of information collected include: function and state variable information defined by the function (F: S define ) The method comprises the steps of carrying out a first treatment on the surface of the Function and state variable information (F: S) used by the function use ) The method comprises the steps of carrying out a first treatment on the surface of the A function and the branches of the function cover data information (F: B); wherein F represents a function in the contract, S define Representing state variables defined in the function, S use Representing state variables used in the function, and B representing function branch override information.
1.1.3 availability of function acquisitions
The fuzzy test system uses a solc tool to extract public function signatures of all claims in ABI based on ABI files in JSON format. Selector m for computing function signature by system using first four bytes hash value l Wherein 0.ltoreq.l.ltoreq.max, max being the maximum number of functions available in the whole contract. And constructs a map M using the selector. In the map M, each function selector corresponds to a tuple consisting of the function name and the function entry information. For example, if the function name is "transfer", the function entry references "address to, uint256 value", then the tuple is "transfer", [ "address", "uint256 ]"]) The map M associates all function selectors with their corresponding tuples so that subsequent fuzzy tests can make random calls to all public functions. At the same time The system automatically filters out functions in the ABI file that do not change the contract state, such as view functions, pure functions, to ensure that fuzzy testing is only performed for functions that change the contract state.
1.1.4 Branch overlay information ordering
For the (F: B) information obtained in 1.1.2, arranging the (F: B) information according to the order of the branch coverage rate from the big to the small according to the order arrangement principle, wherein the lowest branch coverage rate function is F min The highest branch coverage function is F max . In particular, initially each function branch coverage is 0. After each test case execution, the (F: B) information is updated and reordered.
1.1.5 user configuration acquisition
The system reads the user input and saves the following configuration information.
1.2 test case pool initialization
1.2.1 test case pool Generation
The system firstly generates two sets of test cases with the length of c in the memory, and the test cases after being coded are stored in the sets. Two sets are initially defined as branch coverage test case pools, respectivelyData dependent test case pool->Wherein->And (3) representing the ith test case in the jth test case pool, wherein i=c, j= (1, 2), when j=1 represents the test case in the branch coverage test case pool, and j=2 represents the test case in the data dependent test case pool.
1.2.2 registration of the value quantity calculation formula
The system will cover test case pool P for branches branch And data dependent test case pool P data Registering different value calculation formulas and value meterThe calculation formula is used for quantifying the value of the current test case and for the subsequent replacement process of the test case.
1.2.2.1 Branch overlay test case pool price registration: for the value Val_b of the test case in the branch coverage test case pool, the judgment formula is shown in the formula (1-1):
wherein Val_b (T i 1 ) Representative Branch overlay test case pool P branch The value amount of the i-th test case; newBranch (T) i 1 ) For test case T i 1 The number of newly discovered branches, namely the number of branches triggering the jump; total FindBranch (T) i 1 ) For the current test case T i 1 The number of branches found together; tatalBranch (T) i 1 ) For the test case T i 1 All the number of branches owned.
1.2.2.2 data dependent test case pool price quantity registration: for the value Val_d of the test case in the data-dependent test case pool, the judgment formula is shown by the formula (1-2):
wherein the method comprises the steps ofRepresenting a data dependent test case pool P data The value amount of the i-th test case;for the current test case->The number of newly discovered branches; / >Representing the current test case->The number of read-write pairs of each state variable, namely the number of times a state variable is defined and then used.
1.2.3 Utility value initialization
Test case pool P branch And P data Initially, a utility value of 0 is assigned, which is dynamically adjusted during the execution phase and is used for P branch And P data And (3) a process of reassigning the number of test cases.
1.3 test case initialization
1.3.1 function selection
The system will select the function selector in the M mapping table built by 1.1.3 in a round robin order. For each selected function selector, the system will acquire its corresponding function name and function entry type in the M-mapping table, and use these information to construct test cases. The system continues to select functions and construct test cases until the number of functions selected is equal to the user configuration information c, and the system flow ends.
1.3.2 function parameter Generation
The system acquires the function name and the function parameter selected in 1.3.1, constructs real parameters with the same type as the function parameter by a random generation mode, and simultaneously, the fuzzy test system randomly generates environment information parameters including block numbers, time stamps and block difficulties.
1.3.3 test case Structure
The encoding work of the ConFuzzius tool on the test case is utilized to encode the function parameter information selected in 1.3.2 and the environment information into a transaction tx, and the expansion encoding field theta is used for recording that the parameters are mutated in the fuzzy execution process.
The invention is used for each test caseFormalized description of (2)The following is shown:
test caseIs the ith test case in the jth test case pool and is a series of transactions tx k I.e., the order of execution of transactions, wherein the maximum value of k is obtained from the user configuration, and the default value is 8, which represents that the maximum length of the test case is limited to 8 transactions. K=1 when the test case is initialized.
The invention is used for each transaction tx k Is shown below:
tx k ＝(δ,ε,θ) k
transaction tx k Is a triplet made up of environmental information delta, parameter information epsilon and additional information theta. Triplet (delta, epsilon, theta) k Represents the kth transaction tx k 。
The formalized description of the environment information delta is shown in the following formula:
δ＝(b,t,d)
the environment information delta is composed of three parts, wherein b is a block number, t is a time stamp, and d is a block difficulty.
The formalized description of the parameter information epsilon is shown in the following formula:
ε＝(f,gl)
the parameter information epsilon consists of two parts, one being the function related information f and the other being the lowest limit gl of gas consumption.
The formalized description of the function related information f is shown in the following formula:
f∈(m 1 (p 1 ,p 2 ,...p m ),m 2 (p 1 ,p 2 ,...p m ),...,m l (p 1 ,p 2 ,...p m ))
the function-related information f mainly comprises two parts, one of which is a function selector m l Wherein 0.ltoreq.l.ltoreq.max, where max is the maximum number of functions available in the whole contract. Two are functions of entering parameter p m M represents the maximum number of entries of the current function, wherein 0.ltoreq.m.
The formalized description of the additional information theta of the invention is shown in the following formula:
the additional information θ, which is used to facilitate the key of implementing the mutation of the guiding parameters of the present invention in the fuzzy test, is stored with the parameters mutated in the previous round, so it is a subset of the function parameters.
1.3.4 initial test case Allocation
All test cases generated at initialization in 1.3.3 will be equally allocated to the branch overlay test case pool P branch And data dependent test case pool P data And the method is used for optimizing the follow-up fuzzers according to different optimization strategies.
2. The optimizing processing stage of the invention
2.1 test case selection
The system traverses the test case pool P in parallel branch And P data Test cases in (1) and obtaining the test cases in (2)
2.2 selection of transactions to be mutated
System traversal test caseAll transactions tx in (a) k And determining whether to mutate the current transaction parameters with the probability of P, wherein the mutation comprises parameter information epsilon and environment information delta.
2.3 parameter information mutation
Test case pool P branch And P data The same parameter information mutation scheme was used: for function informationThe parameter part in f is mutated.
Breadth mutation: the system acquires the function parameter information (p) stored in the θ information i ,p j ,…,p k ) And no longer mutate the parameters at the current parameter mutation stage (p i ,p j ,…,p k ) And randomly selects the remaining parameters (p q ,p p ,…,p m ) Random mutagenesis is performed on one or more of the above.
Depth mutation: the system acquires the function parameter information (p) stored in the θ information i ,p j ,…,p k ) And continuing the mutation parameters (p during the current parameter mutation phase i ,p j ,…,p k )。
Completely random mutation: the system randomly selects (p 1 ,p 2 ,...p m ) Random mutagenesis is performed for one or more parameters of (a).
2.3.1θ information acquisition
The fuzzy test system obtains theta information in the current transaction tx.
2.3.2 mutant selection
The system can judge whether the current theta information is None, and if so, a gamma mutation mode is selected. Otherwise, the fuzzy test system randomly selects one of three mutation modes to mutate the parameters.
2.3.3 mutation Performance
After the system determines the mutation mode, the parameters to be mutated are selected. For the alpha mutation direction, the fuzzy test system can mutate the parameters contained in the current transaction theta information again, and mutate the parameters in a bit flipping mode, a byte flipping mode and the like provided by the sFuzz tool. For the beta mutation direction, the fuzzy test system mutates other parameters contained in the theta information of the current transaction, mutates the parameters in a bit flipping mode, a byte flipping mode and the like provided by the sFuzz tool, and finally updates the theta information into the mutated parameters.
2.4 environmental information mutations
The fuzzy test system generates new environment information parameters through operations such as bit flipping, byte flipping and the like.
2.5 transaction sequence optimization
2.5.1 Branch coverage test case pool transaction sequence optimization
The system will cover the test case pool P from the branch branch Middle recursion fetch test case T i 1 And optimizing the transaction sequence in the test case until all the test cases in the current test case pool finish the optimization process and finish the current stage.
2.5.1.1 high branch coverage function acquisition: the system scans the transaction level of the test cases acquired in 2.5.1 and acquires the function selector m in each transaction tx i The branch coverage rate corresponding to the current function is recorded through the (F: B) information collected in the 1.1 stage, the system compares all the branch coverage rate conditions and acquires the current test case T through an M mapping table i 1 Function F with highest branch coverage b-max 。
2.5.1.2 test case optimization: for the branch coverage test case pool, the system randomly selects one of three optimization modes:
first, a low branch coverage function F is selected from the (F: B) information collected in section 1.1.2 min Encoding to append a transaction to the current test case T i 1 Random positions in (a);
secondly, deleting the current test case T i 1 Function F with highest branch coverage in (3) b-max Corresponding transaction;
third, replace test case T i 1 Function F of highest branch coverage in b-max The corresponding transaction is a low-branch coverage function F min Coded transactions
2.5.1.3 temporary storage of new test cases: new test cases generated by 2.5.1.2 stagesWill be temporarily stored in P ranch Is a kind of medium. Wait->After execution, calculating the value and determiningWhether to perform test case coverage.
2.5.2 data-dependent test case pool transaction sequence optimization
The obfuscator will be from the data-dependent test case pool P data Take out test casesThe transaction sequence in the test case is optimized. During the optimization, the optimization process will be based on the two types of information collected in section 1.1.2 (F: S define ) And (F: S) use ) Guiding.
2.5.2.1 test case optimization for a data dependent test case pool, the system will randomly select one of three optimization modes:
the method comprises the following steps: adding a data dependent transaction, randomly selecting test casesA transaction tx in (a) λ Through (F: S) define ) Information find transaction tx λ The state variables defined by the corresponding function are then passed (F: S use ) Information finds a function using the state variable and acts as a transaction (transaction tx μ ) Additional to transaction tx λ Thereafter, if there is no transaction tx μ Then randomly selecting a function as a transaction tx v Additional to transaction tx λ Then, completing the adding process of the test case transaction sequence;
and two,: randomly deleting current test casesIs a transaction in the middle;
and thirdly,: random replacement of current test casesOne of the transactions is a transaction of another function. The ambiguity unit can wait for possible selection of function selectors in the M mapping table, acquire corresponding functions and encode the corresponding functions into a transaction, and finally ensure that the length of the test case is not smallAt 1.
2.5.2.2 temporary storage of new test cases: new test cases generated by 2.5.2.1 stageWill be temporarily stored in P data Is a kind of medium. Wait->After the execution is finished, the value quantity is calculated and whether the test case coverage is carried out or not is determined.
3. The analysis stage of the invention
Firstly, the fuzzifier executes a test case and judges whether to trigger a vulnerability according to a byte code path and a state variable data flow direction in the execution process of the fuzzifier; secondly, after the execution of all the test case pools is finished, the system calculates the utility value of each test case pool according to the information such as the execution time, the branch jump frequency, the vulnerability discovery number, the difference degree among the test cases and the like; and finally, carrying out reassignment on the number of the test cases by comparing the utility values of different test case pools, and randomly transferring the test cases with the corresponding numbers in the test case pool with the low utility value into the test case pool with the high utility value according to a reassignment number calculation formula.
3.1 vulnerability detection
3.1.1 test case execution
The system can follow the execution module of ConFuzzius tool to optimize the test casesSimulation execution by Py-EVM, where j=1 represents the branch overlay test case pool P branch J=2 represents the data-dependent test case pool P data . And obtaining the newly discovered branch number of the current test case in the execution process>The total number of branches found by test cases +.>All branches contained in test case +.>Read-write pair number of state variables in test case>Number of loopholes found->Branch jump frequency->And execution time->Etc.
In particular, the fuzzifier records the number of the byte codes such as JumpI, jump and the like triggered in the execution process of each test case in the current test case pool as the branch Jump frequency
3.1.2 value calculation
The system calculates the current test case according to the value quantity calculation formula registered in the current test case pool and the test case execution information acquired in 3.1.1Is a valuable quantity of (3).
3.1.3 test case substitution
The system calculates the test case according to 3.1.2The value of (2) and the original test case +.>In particular, the value amounts of (a) are compared:
coverage test case pool P for branches branch Test case T in (1) i 1 The value of (C) is Val_b (T i 1 ) Test caseThe value of (2) is->If->Then replace the current test case pool P branch T in (1) i 1 The test case is +.>Test case, otherwise, will->And deleting from the test case pool.
For data dependent test case pool P data Test cases in (a)The value of (2) is->Test caseThe value of (2) is->If->Then replace the current test case pool P data Is->The test case is +.>Test case, otherwise, will->And deleting from the test case pool.
In particular, the initially generated test case only calculates its value amount in execution and does not participate in the test case replacement process.
3.1.4 vulnerability reporting
The system sequentially executes each test case and analyzes the byte code path and the data flow direction in the execution process, and the loophole predictor constructed by the invention judges whether the current test case triggers a certain loophole. Specifically, the obfuscator may determine the dependency between the bytecodes by analyzing the execution information of the current test case. The fuzzifier is used for obtaining the execution process of the current test case and judging the type of the vulnerability by analyzing the dependency relationship, and updating the information (F: B) in section 1.1.2 according to the lifting degree of the function branches in the execution process.
3.2 test case pool utility value adjustment
The fuzzifier pairs test case pool P in this stage branch And P data According to the number of loopholes, branch jump information, difference degree information and the like generated by each test case in the test case pool in the execution process, calculating the utility of the current test case pool through a utility value calculation formula, and using the result value in the test case redistribution process.
3.2.1 test case pool overall execution time calculation
For test case pool P branch : the system accumulates the time T (T) spent by each test case in the current test case pool in the execution process i 1 ) And calculating the execution time t of the final test case pool 1 。
For test case pool P data : the system accumulates the time spent by each test case in the current test case pool in the execution processAnd calculating the execution time t of the final test case pool 2 。
3.2.2 vulnerability count
For test case pool P branch : the system accumulates the vulnerability discovery quantity b (T) i 1 ) And calculating the total vulnerability discovery number b of the final test case pool 1 。
For test case pool P data : the system accumulates the vulnerability discovery quantity of each test case in the current test case pool in the execution process And calculating the execution time b of the final test case pool 2 。
3.2.3 branch hopping frequency calculation:
for test case pool P branch : the system accumulates the branch jump frequency b (T) i 1 ) Calculating total vulnerability jump frequency b of final test case pool 1 。
For test case pool P data : the system accumulates the branch jump frequency of each test case in the current test case pool in the executing processCalculating total vulnerability jump frequency b of final test case pool 2 。
3.2.4 test case pool variability calculation
For test case pool P branch And P data Degree of difference d between test cases j The calculation formula is shown as formula (3-2):
wherein d is j For the degree of difference of different test case pools, d is when j=1 1 For testing coverage of branchesExample pool P branch D when j=2 2 For data dependent test case pool P data The test case variability of (2). n represents the number of test cases in the current test case pool,reference test cases for representing the difference degree between the calculated test cases are selected as reference test cases by randomly selecting a certain test case in the current test case pool, and the test cases are added with the reference test cases>Represents except->Test cases other than->Representing test case->And- >Jaccard coefficients in between.
The Jaccard similarity coefficient calculation formula is shown as (3-3):
as defined in the present description of the invention,representing the intersection of trade functions between two test cases,/->Representing the union of trade functions between test cases. Therefore, the larger the difference degree between the test cases in the test case pool, the larger the value of d, whereind has the following value range: d is more than or equal to 0 and less than or equal to 1;
in order to ensure the speed and efficiency of test case execution, the default selection starts the test case utility value adjustment function every s seconds,
3.2.5 utility value calculation
According to the weight information configured by the user in 1.2.1 and the information counted by the system in 3.2.1-3.2.4, the utility value of the current test case pool is calculated according to a utility formula, and the utility formula defined by the invention is shown as formula (3-1):
in the utility formula, when j=1, test case pool P is covered for the branch branch Utility value of (2), data-dependent test case pool P when j=2 data Utility value of (2). Utility Utilityj contains 9 parameters, respectively:
(1)w 1 : the weight parameter of the time factor gradually decreases with the increase of time, and the utility of the test case is gradually reduced, w 1 The intensity of this utility factor is controlled.
(2)w 2 : the greater the index of the exponential factor, the faster the utility decreases with time.
(3) t: the execution time of the current test case pool is used for representing the real time of executing the current test case pool by the fuzzer, the shorter the time is, the higher the utility value is, and the utility value gradually becomes gentle along with the increase of the execution time of the current test case pool. Because the number of test cases in each test case pool may be different and the execution time of the test cases may be different, the time utility factors of different test case pools may be different.
(4)w 3 : the higher the total branch jump frequency in the test case pool, the higher the utility of the test case, and w 3 The intensity of this utility factor is controlled.
(5) b: and the branch jump frequency represents the total branch jump frequency of the current test case pool.
(6)w 4 : vulnerability discovery weight parameter, the more vulnerability discovery, the higher the utility of test case pools, w 4 The intensity of this utility factor is controlled.
(7) And v, the vulnerability discovery number represents the vulnerability number generally discovered by each test case in the current test case pool in the execution process.
(8)w 5 The larger the difference degree, the higher the utility of the test case pool, and the w 5 The intensity of this effect is controlled.
(9) And d, the difference degree represents the difference degree between the test cases in the current test case pool.
3.2.6 Utility value update
The system updates the utility value of the current test case pool to the utility value calculated in 3.2.5 and is used for comparison operations in the test case number reassignment stage.
3.3 test case number redistribution
The stage is a processing stage performed after each test case pool is executed, the two test case pools may have different utility value values, the stage increases the number of test cases in the test case pool with high utility value, and reduces the number of test cases in the test case pool with low utility value. To achieve more allocation of fuzzy resources into the valuable test case pool. After this phase is completed, the utility value of each test case pool is reset to the initial value.
3.3.1 number of reassignments calculation
The system determines the reassignment number according to the utility value of the different test case pools calculated in 3.2.6 and a reassignment number calculation formula, wherein the reassignment number calculation formula is shown as formula (3-4):
wherein count represents the number and availability of test case reassignment in the current stage 1 、Utility 2 Utility values in two test case pools. The idea of reassignment is to transfer test cases in low utility value test cases to a pool of high utility value test cases. m and n respectively represent the interval range of the number of reassignments each time, wherein m is larger than or equal to n. The user can configure the values of m and n in a custom mode.
3.3.2 reassignment test case selection
After the system passes through the reassignment number determined in 3.3.1, randomly selecting the count test cases from the test case pool with low utility value, and transferring the count test cases to the test cases with high utility value, wherein in the process, the count value is ensured to be smaller than the number T of the test cases in the test cases with low current utility value count Guarantee T after the end of this phase count ≥1
3.3.3 Utility value reset
After the test case reassignment stage is finished, the system resets the utility values of the two test case pools to 0, and prepares for the utility value calculation of the next stage.
Another object of the present invention is to provide an intelligent contract ambiguity test system based on a utility adjustment strategy, which mainly includes three modules: a blurring engine module: the module generates all test cases in the initial test case pool according to the intelligent contract related information, and prepares for the subsequent execution analysis stage. This stage is the beginning of the loop in the ambiguity test procedure.
Test case optimization module: the module is used for updating and optimizing all test cases in the test case pool, and different test case pools have different test case optimization schemes. The branch coverage test case pool is favorable for exploring deep branch loopholes, and the data dependence test case pool is required to construct complex test cases with data dependence relations, so that the loophole problems existing among multiple transactions can be explored.
And an execution analysis module: the module runs the test cases in each test case pool, and discovers whether the intelligent contract has the loopholes or not according to the information generated in the test case executing process through the judgment of the loophole predictor. Meanwhile, the module dynamically adjusts the number of test cases in each test case pool according to the number of loopholes found in the test case execution process.
The invention is characterized in that: 1. the invention adopts a mode of combining various test case optimization schemes, takes a test case pool as an overall optimization object, selects different optimization schemes for different test cases in the dynamic execution process, and provides a more comprehensive test case optimization means. 2. According to the invention, the utility value formula is adopted to carry out dynamic test case quantity scheduling, so that more fuzzy resources are distributed into the test case pool with good effect, and the utilization rate of the fuzzy test resources is further improved. 3. By using the method and the device, the vulnerability exploration efficiency can be remarkably improved, and compared with the existing fuzzy test system, the vulnerability existing in the contract can be explored more quickly under the same test environment, and the fuzzy test efficiency is improved.
Drawings
FIG. 1 is a flowchart of an intelligent contract ambiguity test method and system based on a utility adjustment strategy.
FIG. 2 is a schematic diagram of a static analysis stage in a method and system for intelligent contract fuzzy test based on utility adjustment strategy according to the present invention.
FIG. 3 is a structured symbolic depiction of an intelligent contract fuzzy test method and system based on a utility adjustment strategy in accordance with the present invention.
FIG. 4 is a schematic diagram of a test case optimization flow in a test case pool for intelligent contract fuzzy test method and system branch coverage based on utility adjustment strategy according to the present invention.
FIG. 5 is a schematic diagram of a test case optimization flow in a utility adjustment strategy-based intelligent contract fuzzy test method and system data dependent test case pool.
Detailed Description
The technical scheme of the invention is further specifically described below through specific embodiments and with reference to the accompanying drawings.
An intelligent contract fuzzy test method based on a utility regulation strategy, as shown in fig. 1, mainly comprises three stages: a preprocessing stage, an optimization processing stage and an execution analysis stage.
1. Pretreatment stage of the invention
Firstly, performing static analysis on an intelligent contract, acquiring an ABI file of the intelligent contract, converting the ABI file into an intermediate representation (Intermediate Representation, IR) of the intelligent contract by using a split tool, namely the split IR, and collecting dependent information of a function and contract state variables, branch information contained in the function and the like by using a data collection related API in the split tool on the split IR;
And secondly, extracting a public function signature according to the ABI file by utilizing a solc tool, constructing a function selector mapping table, and selecting available function codes in a cyclic sequence to be an initial test case.
Finally, the fuzzifier creates a branch overlay test case pool and a data dependency test case pool and equally distributes the initial test cases into two test case pools. The method specifically comprises the following steps:
1.1 static analysis
1.1.1ABI file generation
As shown in fig. 2, the fuzzy test system would compile a user-given smart contract into an application binary interface file (Application Binary Interface, ABI) and convert the ABI file to a split IR intermediate representation by a split tool;
1.1.2 contract information acquisition
The fuzzy test system calls a related API of a slit tool on a slit IR for collecting three types of information in contracts and for guiding a subsequent test case optimization process;
in particular, the three types of information collected are shown in the following table:
information type symbology Description of the invention
(F∶S define ) Function and state variable information defined by the function
(F∶S use ) Function and state variable information used by the function
(F∶B) Function and branch of the function to cover data information
Wherein F represents a function in the contract, S define Representing state variables defined in the function, S use Representing state variables used in the function, and B representing function branch override information.
1.1.3 availability of function acquisitions
The fuzzy test system uses a solc tool to extract public function signatures of all claims in ABI based on ABI files in JSON format. Selector m for computing function signature by system using first four bytes hash value l Wherein 0.ltoreq.l.ltoreq.max, max being the maximum number of functions available in the whole contract. And constructs a map M using the selector. In the map M, each function selector corresponds to a tuple consisting of the function name and the function entry information. For example, if the function name is "transfer", the function entry references "address to, uint256 value", then the tuple is "transfer", [ "address", "uint256 ]"]) The map M associates all function selectors with their corresponding tuples so that subsequent fuzzy tests can make random calls to all public functions. At the same time, the system automatically filters out functions in the ABI file that do not change the contract state, such as view functions, pure functions, etc., to ensure that fuzzy testing is only performed for functions that change the contract state.
1.1.4 Branch overlay information ordering
For the (F: B) information obtained in 1.1.2, the (F: B) information is arranged according to the order of the branch coverage rate from large to smallSequentially, wherein the lowest branch coverage function is F min The highest branch coverage function is F max . In particular, initially each function branch coverage is 0. After each test case execution, the (F: B) information is updated and reordered.
1.1.5 user configuration acquisition
The system reads the user input and saves the following configuration information, as shown in the following table:
(symbol) description of the invention Default value
c Initial test case generation number 10 (A)
t Fuzzy system execution time 600 (seconds)
k Maximum transaction length of test case 8
w 1 Time factor weight parameters in utility formulas 6.0
w 2 Time factors in utility formulasIndex parameter 50.0
w 3 Branch hopping frequency weight parameters in utility formulas 2.0
w 4 Vulnerability discovery weight parameters in utility formulas 3.0
w 5 Test case pool difference degree weight parameter in utility formula 5.0
m Maximum value of reassignment formula 3
n Reassignment formula minimum 0
1.2 test case pool initialization
1.2.1 test case pool Generation
The system firstly generates two sets of test cases with the length of c in the memory, and the test cases after being coded are stored in the sets. Two sets are initially defined as branch coverage test case pools, respectively Data dependent test case pool->Wherein->And (3) representing the ith test case in the jth test case pool, wherein i=c, j= (1, 2), when j=1 represents the test case in the branch coverage test case pool, and j=2 represents the test case in the data dependent test case pool. As shown in fig. 3, a general symbolic depiction of the present invention is shown.
1.2.2 registration of the value quantity calculation formula
The system will cover test case pool P for branches branch And data dependent test case pool P data Registering different value calculation formulas, wherein the value calculation formulas are used for quantifying the value of the current test case and are used for the subsequent replacement process of the test case.
1.2.2.1 Branch overlay test case pool price registration: for the value Val_b of the test case in the branch coverage test case pool, the judgment formula is shown in the formula (1-1):
wherein Val_b (T i 1 ) Representative Branch overlay test case pool P branch The value amount of the i-th test case; newBranch (T) i 1 ) For test case T i 1 The number of newly discovered branches, namely the number of branches triggering the jump; total FindBranch (T) i 1 ) For the current test case T i 1 The number of branches found together; total branch (T) i 1 ) For the test case T i 1 All the number of branches owned.
1.2.2.2 data dependent test case pool price quantity registration: for the value Val_d of the test case in the data-dependent test case pool, the judgment formula is shown by the formula (1-2):
wherein the method comprises the steps ofRepresenting a data dependent test case pool P data The value amount of the i-th test case;for the current test case->The number of newly discovered branches; />Representing the current test case->The number of read-write pairs of each state variable, namely the number of times a state variable is defined and then used.
1.2.3 Utility value initialization
Test case pool P branch And P data Initially, a utility value of 0 is assigned, which is dynamically adjusted during the execution phase and is used for P branch And P data And (3) a process of reassigning the number of test cases.
1.3 test case initialization
1.3.1 function selection
The system will select the function selector in the M mapping table built by 1.1.3 in a round robin order. For each selected function selector, the system will acquire its corresponding function name and function entry type in the M-mapping table, and use these information to construct test cases. The system continues to select functions and construct test cases until the number of functions selected is equal to the user configuration information c, and the system flow ends.
1.3.2 function parameter Generation
The system acquires the function name and the function parameter selected in 1.3.1, constructs real parameters with the same type as the function parameter by a random generation mode, and simultaneously, the fuzzy test system randomly generates environment information parameters including block numbers, time stamps, block difficulties and the like.
1.3.3 test case Structure
The encoding work of the ConFuzzius tool on the test case is utilized to encode the function parameter information selected in 1.3.2 and the environment information into a transaction tx, and the expansion encoding field theta is used for recording that the parameters are mutated in the fuzzy execution process.
The invention is used for each test caseIs shown below:
test caseIs the ith test case in the jth test case pool and is a series of transactions tx k I.e., the order of execution of transactions, wherein the maximum value of k is obtained from the user configuration, and the default value is 8, which represents that the maximum length of the test case is limited to 8 transactions. K=1 when the test case is initialized.
The invention is used for each transaction tx k Is shown below:
tx k ＝(δ,ε,θ) k
transaction tx k Is a triplet made up of environmental information delta, parameter information epsilon and additional information theta. Triplet (delta, epsilon, theta) k Represents the kth transaction tx k 。
The formalized description of the environment information delta is shown in the following formula:
δ＝(b,t,d)
the environment information delta is composed of three parts, wherein b is a block number, t is a time stamp, and d is a block difficulty.
The formalized description of the parameter information epsilon is shown in the following formula:
ε＝(f,gl)
the parameter information epsilon consists of two parts, one being the function related information f and the other being the lowest limit gl of gas consumption.
The formalized description of the function related information f is shown in the following formula:
f∈(m 1 (p 1 ,p 2 ,...p m ),m 2 (p 1 ,p 2 ,...p m ),...,m l (p 1 ,p 2 ,...p m ))
the function-related information f mainly comprises two parts, one of which is a function selector m l Wherein 0.ltoreq.l.ltoreq.max, where max is the maximum number of functions available in the whole contract. Two are functions of entering parameter p m M represents the maximum number of entries of the current function, wherein 0.ltoreq.m.
The formalized description of the additional information theta of the invention is shown in the following formula:
the additional information θ, which is used to facilitate the key of implementing the mutation of the guiding parameters of the present invention in the fuzzy test, is stored with the parameters mutated in the previous round, so it is a subset of the function parameters.
1.3.4 initial test case Allocation
All test cases generated at initialization in 1.3.3 will be equally allocated to the branch overlay test case pool P branch And data dependent test case pool P data And the method is used for optimizing the follow-up fuzzers according to different optimization strategies.
2. The optimizing processing stage of the invention
2.1 test case selection
The system traverses the test case pool P in parallel branch And P data Test cases in (1) and obtaining the test cases in (2)
2.2 selection of transactions to be mutated
System traversal test caseAll transactions tx in (a) k And determining whether to mutate the current transaction parameters with the probability of P, wherein the mutation comprises parameter information epsilon and environment information delta. The P value is typically chosen to be 0.5 based on empirical analysis. />
2.3 parameter information mutation
Test case pool P branch And P data The same parameter information mutation scheme was used: the parameter part in the function information f is mutated. Three mutation modes are specifically described in the following table:
breadth mutation: the system acquires the function parameter information (p) stored in the θ information i ,p j ,…,p k ) And no longer mutate the parameters at the current parameter mutation stage (p i ,p j ,…,p k ) And randomly selects the remaining parameters (p q ,p p ,…,p m ) Random mutagenesis is performed on one or more of the above.
Depth mutation: the system acquires the function parameter information (p) stored in the θ information i ,p j ,…,p k ) And continuing the mutation parameters (p during the current parameter mutation phase i ,p j ,…,p k )。
Completely random mutation: the system randomly selects (p 1 ,p 2 ,...p m ) Random mutagenesis is performed for one or more parameters of (a).
The phase parameter mutation flow pseudo code is as follows:
2.3.1θ information acquisition
The fuzzy test system obtains theta information in the current transaction tx.
2.3.2 mutant selection
The system can judge whether the current theta information is None, and if so, a gamma mutation mode is selected. Otherwise, the fuzzy test system randomly selects one of three mutation modes to mutate the parameters.
2.3.3 mutation Performance
After the system determines the mutation mode, the parameters to be mutated are selected. For the alpha mutation direction, the fuzzy test system can mutate the parameters contained in the current transaction theta information again, and mutate the parameters in a bit flipping mode, a byte flipping mode and the like provided by the sFuzz tool. For the beta mutation direction, the fuzzy test system mutates other parameters contained in the theta information of the current transaction, mutates the parameters in a bit flipping mode, a byte flipping mode and the like provided by the sFuzz tool, and finally updates the theta information into the mutated parameters.
2.4 environmental information mutations
The fuzzy test system generates new environment information parameters through operations such as bit flipping, byte flipping and the like.
2.5 transaction sequence optimization
2.5.1 Branch coverage test case pool transaction sequence optimization
As shown in FIG. 4, the system will cover the test case pool P from the branch branch Middle recursion fetch test case T i 1 And optimizing the transaction sequence in the test case until all the test cases in the current test case pool finish the optimization process and finish the current stage.
2.5.1.1 high branch coverage function acquisition: the system scans the transaction level of the test cases acquired in 2.5.1 and acquires the function selector m in each transaction tx i The branch coverage rate corresponding to the current function is recorded through the (F: B) information collected in section 1.1.2, the system compares all the branch coverage rate conditions and acquires the current test case T through an M mapping table i 1 Function F with highest branch coverage b-max 。
2.5.1.2 test case optimization: for the branch coverage test case pool, the system randomly selects one of three optimization modes:
first, a low branch coverage function F is selected from the (F: B) information collected in stage 1.1 min Encoding to append a transaction to the current test case T i 1 Random positions in (a);
secondly, deleting the current test case T i 1 Function F with highest branch coverage in (3) b-max Corresponding transaction;
third, replace test case T i 1 Function F of highest branch coverage in b-max The corresponding transaction is a low-branch coverage function F min Coded transactions
2.5.1.3 temporary storage of new test cases: new test cases generated by 2.5.1.2 stagesWill be temporarily stored in P branch Is a kind of medium. Wait->After the execution is finished, the value quantity is calculated and whether the test case coverage is carried out or not is determined.
The branch coverage test case pool transaction sequence optimization flow pseudocode is as follows:
2.5.2 data-dependent test case pool transaction sequence optimization
As shown in FIG. 5, the obfuscator will be from the data-dependent test case pool P data Take out test casesThe transaction sequence in the test case is optimized. During the optimization, two types of information (F: S) are collected according to the 1.1 stage define ) And (F: S) use ) Guiding.
2.5.2.1 test case optimization for a data dependent test case pool, the system will randomly select one of three optimization modes:
the method comprises the following steps: adding a data dependent transaction, randomly selecting test casesA transaction tx in (a) λ Through (F: S) define ) Information find transaction tx λ The state variables defined by the corresponding function are then passed (F: S use ) Information finds a function using the state variable and acts as a transaction (transaction tx μ ) Additional to transaction tx λ Thereafter, if there is no transaction tx μ Then randomly selecting a function as a transaction tx v Additional to transaction tx λ Then, completing the adding process of the test case transaction sequence;
and two,: randomly deleting current test casesIs a transaction in the middle;
and thirdly,: random replacement of current test casesOne of the transactions is a transaction of another function. The obfuscator may wait for a possible selection of a function selector existing in the M mapping table, acquire a corresponding function, and encode the corresponding function into a transaction, and finally ensure that the length of the test case is not less than 1.
2.5.2.2 temporary storage of new test cases: new test cases generated by 2.5.2.1 stageWill be temporarily stored in P data Is a kind of medium. Wait->After the execution is finished, the value quantity is calculated and whether the test case coverage is carried out or not is determined.
The data-dependent test case pool transaction sequence optimization flow pseudocode is as follows:
3. the analysis stage of the invention
Firstly, the fuzzifier executes a test case and judges whether to trigger a vulnerability according to a byte code path and a state variable data flow direction in the execution process of the fuzzifier; secondly, after the execution of all the test case pools is finished, the system calculates the utility value of each test case pool according to the information such as the execution time, the branch jump frequency, the vulnerability discovery number, the difference degree among the test cases and the like; and finally, carrying out reassignment on the number of the test cases by comparing the utility values of different test case pools, and randomly transferring the test cases with the corresponding numbers in the test case pool with the low utility value into the test case pool with the high utility value according to a reassignment number calculation formula.
3.1 vulnerability detection
3.1.1 test case execution
The system can follow the execution module of ConFuzzius tool to optimize the test casesSimulation execution by Py-EVM, where j=1 represents the branch overlay test case pool P branch J=2 represents the data-dependent test case pool P data . And obtaining the newly discovered branch number of the current test case in the execution process>The total number of branches found by test cases +.>All branches contained in test case +.>Read-write pair number of state variables in test case>Number of loopholes found->Branch jump frequency->And execution time->Etc.
In particular, the fuzzifier records the number of the byte codes such as JumpI, jump and the like triggered in the execution process of each test case in the current test case pool as the branch Jump frequency
3.1.2 value calculation
The system calculates the current test case according to the value quantity calculation formula registered in the current test case pool and the test case execution information acquired in 3.1.1Is a valuable quantity of (3).
3.1.3 test case substitution
The system calculates the test case according to 3.1.2The value of (2) and the original test case +.>In particular, the value amounts of (a) are compared:
coverage test case pool P for branches branch Test case T in (1) i 1 The value of (C) is Val_b (T i 1 ) Test caseThe value of (2) is->If->Then replace the current test case pool P branch T in (1) i 1 The test case is +.>Test case, otherwise, will->And deleting from the test case pool.
For data dependent test case pool P data Test cases in (a)The value of (2) is->Test caseThe value of (2) is->If->Then replace the current test case pool P data In (a) and (b)/>The test case is +.>Test case, otherwise, will->And deleting from the test case pool.
In particular, the initially generated test case only calculates its value amount in execution and does not participate in the test case replacement process.
3.1.4 vulnerability reporting
The system sequentially executes each test case and analyzes the byte code path and the data flow direction in the execution process, and the loophole predictor constructed by the invention judges whether the current test case triggers a certain loophole. Specifically, the obfuscator may determine the dependency between the bytecodes by analyzing the execution information of the current test case. The fuzzifier is used for obtaining the execution process of the current test case and judging the type of the vulnerability by analyzing the dependency relationship, and updating the information in the stage 1.1 (F: B) according to the lifting degree of the function branches in the execution process.
3.2 test case pool utility value adjustment
The fuzzifier pairs test case pool P in this stage branch And P data According to the number of loopholes, branch jump information, difference degree information and the like generated by each test case in the test case pool in the execution process, calculating the utility of the current test case pool through a utility value calculation formula, and using the result value in the test case redistribution process.
3.2.1 test case pool overall execution time calculation
For test case pool P branch : the system accumulates the time T (T) spent by each test case in the current test case pool in the execution process i 1 ) And calculating the execution time t of the final test case pool 1 。
For test case pool P data : the system accumulates the time spent by each test case in the current test case pool in the execution processAnd calculating the execution time t of the final test case pool 2 。
3.2.2 vulnerability count
For test case pool P branch : the system accumulates the vulnerability discovery quantity v (T) i 1 ) And calculating the total vulnerability discovery number v of the final test case pool 1 。
For test case pool P data : the system accumulates the vulnerability discovery quantity of each test case in the current test case pool in the execution process And calculating the execution time v of the final test case pool 2 。
3.2.3 branch hopping frequency calculation:
for test case pool P branch : the system accumulates the branch jump frequency b (T) i 1 ) Calculating total vulnerability jump frequency b of final test case pool 1 。
For test case pool P data : the system accumulates the branch jump frequency of each test case in the current test case pool in the executing processCalculating total vulnerability jump frequency b of final test case pool 2 。
3.2.4 test case pool variability calculation
For test case pool P branch And P data Degree of difference d between test cases j The calculation formula is shown as formula (3-2):
wherein d is j For the degree of difference of different test case pools, d is when j=1 1 Coverage test case pool P for branches branch D when j=2 2 For data dependent test case pool P data The test case variability of (2). n represents the number of test cases in the current test case pool,reference test cases for representing the difference degree between the calculated test cases are selected as reference test cases by randomly selecting a certain test case in the current test case pool, and the test cases are added with the reference test cases>Represents except->Test cases other than->Representing test case->And- >Jaccard coefficients in between.
The Jaccard similarity coefficient calculation formula is shown as (3-3):
as defined in the present description of the invention,representing the intersection of trade functions between two test cases,/->Representing the union of trade functions between test cases. Therefore, the larger the difference degree between the test cases in the test case pool is, the larger the value of d is, wherein the range of the value of d is as follows: g is more than or equal to 0 and less than or equal to 1;
in order to ensure the speed and efficiency of test case execution, the default selection starts the test case utility value adjustment function every s seconds, and s is suitable for selecting 2.0 according to experience discovery.
3.2.5 utility value calculation
According to the weight information configured by the user in 1.2.1 and the information counted by the system in 3.2.1-3.2.4, the utility value of the current test case pool is calculated according to a utility formula, and the utility formula defined by the invention is shown as formula (3-1):
/>
in the utility formula, when j=1, test case pool P is covered for the branch branch Utility value of (2), data-dependent test case pool P when j=2 data Utility value of (2). Utility Utilityj contains 9 parameters, respectively:
(10)w 1 : the weight parameter of the time factor gradually decreases with the increase of time, and the utility of the test case is gradually reduced, w 1 The intensity of this utility factor is controlled. According to experience, when the number of initial test cases is 10, w 1 Is suitable for taking 6.0
(11)w 2 : the greater the index of the exponential factor, the faster the utility decreases with time. According to experience, when the number of initial test cases is 10, w 2 Is suitable for taking 50.0
(12) t: the execution time of the current test case pool is used for representing the real time of executing the current test case pool by the fuzzer, the shorter the time is, the higher the utility value is, and the utility value gradually becomes gentle along with the increase of the execution time of the current test case pool. Because the number of test cases in each test case pool may be different and the execution time of the test cases may be different, the time utility factors of different test case pools may be different.
(13)w 3 : the higher the total branch jump frequency in the test case pool, the higher the utility of the test case, and w 3 The intensity of this utility factor is controlled. According to experience, when the number of initial test cases is 10, w 3 Is suitable for taking 2.0
(14) b: and the branch jump frequency represents the total branch jump frequency of the current test case pool.
(15)w 4 : vulnerability discovery weight parameter, the more vulnerability discovery, the higher the utility of test case pools, w 4 The intensity of this utility factor is controlled. According to experience, when the number of initial test cases is 10, w 4 Is suitable for taking 3.0
(16) And v, the vulnerability discovery number represents the vulnerability number generally discovered by each test case in the current test case pool in the execution process.
(17)w 5 The larger the difference degree, the higher the utility of the test case pool, and the w 5 The intensity of this effect is controlled. According to experience, when the number of initial test cases is 10, w 5 Is suitable for taking 5.0
(18) And d, the difference degree represents the difference degree between the test cases in the current test case pool.
3.2.6 Utility value update
The system updates the utility value of the current test case pool to the utility value calculated in 3.2.5 and is used for comparison operations in the test case number reassignment stage.
3.3 test case number redistribution
The stage is a processing stage performed after each test case pool is executed, the two test case pools may have different utility value values, the stage increases the number of test cases in the test case pool with high utility value, and reduces the number of test cases in the test case pool with low utility value. To achieve more allocation of fuzzy resources into the valuable test case pool. After this phase is completed, the utility value of each test case pool is reset to the initial value.
3.3.1 number of reassignments calculation
The system determines the reassignment number according to the utility value of the different test case pools calculated in 3.2.6 and a reassignment number calculation formula, wherein the reassignment number calculation formula is shown as formula (3-4):
wherein count represents the number and availability of test case reassignment in the current stage 1 、Utility 2 Utility values in two test case pools. The idea of reassignment is to transfer test cases in low utility value test cases to a pool of high utility value test cases. m and n respectively represent the interval range of the number of reassignments each time, wherein m is larger than or equal to n. When the number of initial test cases of the test case pool is 10, m is generally selected to be 3, and n is generally selected to be 0 through experience value judgment. The range of the test case reassignment number representing the reassignment stage is 0.ltoreq.i.ltoreq.3, and the user can configure the values of m and n in a custom mode.
3.3.2 reassignment test case selection
After the system passes through the reassignment number determined in 3.3.1, randomly selecting the count test cases from the test case pool with low utility value, and transferring the count test cases to the test cases with high utility value, wherein in the process, the count value is ensured to be smaller than the number T of the test cases in the test cases with low current utility value count Guarantee T after the end of this phase count ≥1
3.3.3 Utility value reset
After the test case reassignment stage is finished, the system resets the utility values of the two test case pools to 0, and prepares for the utility value calculation of the next stage.

Claims (10)

1. An intelligent contract ambiguity test method based on a utility adjustment strategy is characterized by comprising the following steps:
in the preprocessing stage, the fuzzy test system preprocesses the intelligent contract to be tested, acquires structural information and branch information related to each function in the contract, randomly generates an initial test case and equally distributes the initial test case into a branch coverage test case pool and a data dependence test case pool generated by the fuzzifier;
in the optimization processing stage, the fuzzy test system performs optimization iteration on each test case according to the self test case optimization strategy in different test case pools;
and in the execution analysis stage, the fuzzy test system respectively executes the test cases in the different test case pools, analyzes the byte code execution logic of the fuzzy test system and reports vulnerabilities, and calculates utility values of the different test case pools and redistributes the number of the test cases in the test case pools after the execution is finished.
2. The smart contract fuzziness testing method based on utility tuning strategy of claim 1, wherein the preprocessing stage comprises:
Performing static analysis processing on the intelligent contract to collect intelligent contract related information, including: function and state variable information defined by the function (F: S define ) The method comprises the steps of carrying out a first treatment on the surface of the Function and state variable information (F: S) used for the function use ) The method comprises the steps of carrying out a first treatment on the surface of the A function and the function branch cover data information (F: B);
wherein F represents a function in the contract, S define Representing state variables defined in the function, S use Representing state variables used in the function, and B representing function branch coverage information;
generating an initial test case according to the ABI file information;
the fuzzifier creates two test case pools and allocates initial test cases.
3. The utility adjustment policy based intelligent contract fuzziness testing method of claim 2, wherein the test case pool generation comprises:
2.1 the system generates two sets of test cases with the length of c in the memory, and the test cases after being coded are stored in the sets;
two sets are initially defined as branch coverage test case pools, respectivelyData dependent test case pool->
Wherein the method comprises the steps ofRepresenting an ith test case in the jth test case pool, wherein i=c, j= (1, 2), when j=1 represents the test case in the branch coverage test case pool, and j=2 represents the test case in the data dependent test case pool;
2.2 registration of the value quantity calculation formula
The system will cover test case pool P for branches branch And data dependent test case pool P data Registering different value calculation formulas, wherein the value calculation formulas are used for quantifying the value of the current test case and are used for the subsequent replacement process of the test case;
2.3 Utility value initialization
Test case pool P branch And P data Initially, a utility value of 0 is assigned, which is dynamically adjusted during the execution phase and is used for P branch And P data A reassignment process of the number of test cases between the test cases;
2.4 test case initialization
2.4.1 test case Structure
Encoding the selected function parameter information and the environment information into a transaction tx together for the encoding work of the test case, and expanding an encoding field theta for recording that the parameters are mutated in the fuzzy execution process;
the invention is to each test case T i j Is shown below:
test case T i j Is the ith test case in the jth test case pool and is a series of transactions tx k The ordered set of (a) is a transaction execution sequence, wherein the maximum value of k is obtained through user configuration, the default value is 8, and the maximum length of the representative test case is limited to 8 transactions; k=1 when the test case is initialized;
The invention is used for each transaction tx k Is shown below:
tx k ＝(δ，ε，θ) k
transaction tx k Is a triplet composed of environmental information delta, parameter information epsilon and additional information theta; triplet (delta, epsilon, theta) k Represents the kth transaction tx k ；
The formalized description of the environment information delta is shown in the following formula:
δ＝(b，t，d)
the environment information delta consists of three parts, wherein b is a block number, t is a time stamp, and d is a block difficulty;
the formalized description of the parameter information epsilon is shown in the following formula:
ε＝(f，gl)
the parameter information epsilon consists of two parts, one is the function related information f, and the other is the lowest limit gl of gas consumption; the formalized description of the function related information f is shown in the following formula:
f∈(m 1 (p 1 ，p 2 ，...p m )，m 2 (p 1 ，p 2 ，...p m )，...，m l (p 1 ，p 2 ，...p m ))
the function-related information f includes: one is a function selector m l Wherein 0.ltoreq.l.ltoreq.max, where max is the maximum number of functions available in the whole contract; two are functions of entering parameter p m M represents the maximum parameter entering number of the current function, wherein m is more than or equal to 0;
the formalized description of the additional information theta of the invention is shown in the following formula:
the additional information theta is used for facilitating the key of implementing mutation of the guiding parameters in the fuzzy test, and the parameters mutated in the previous round are stored in the theta, so that the parameters are a subset of the function parameters;
2.4.2 initial test case Allocation
All test cases generated at initialization in 2.4.1 will be equally allocated to the branch overlay test case pool P branch And data dependent test case pool P data And the method is used for optimizing the follow-up fuzzers according to different optimization strategies.
4. The utility adjustment policy-based intelligent contract fuzziness testing method of claim 3, wherein the value quantity calculation formula registration comprises:
2.2.1 Branch overlay test case pool price registration: for the value Val_b of the test case in the branch coverage test case pool, the judgment formula is shown in the formula (1-1):
wherein Val_b (T i 1 ) Representative Branch overlay test case pool P branch The value amount of the i-th test case; newBranch (T) i 1 ) For test case T i 1 The number of newly discovered branches, namely the number of branches triggering the jump; total FindBranch (T) i 1 ) For the current test case T i 1 The number of branches found together; total branch (T) i 1 ) For the test case T i 1 All branch numbers owned;
2.2.2 data dependent test case pool price registration: for the value Val_d of the test case in the data-dependent test case pool, the judgment formula is shown by the formula (1-2):
wherein the method comprises the steps of Representing a data dependent test case pool P data The value amount of the i-th test case;for the current test case->The number of newly discovered branches; />Representing the current test case->The number of read-write pairs of each state variable, namely the number of times a state variable is defined and then used.
5. The intelligent contract fuzziness testing method based on utility adjustment strategy of claim 2, wherein the optimization processing stage: the fuzzy test system can conduct test case optimization iteration in a targeted manner according to test case optimization strategies in different test case pools;
comprising the following steps: optimizing iteration of transaction sequences in test cases and optimizing iteration of parameters in single transactions;
in the fuzzy test process, the test cases in each independent test case pool are subjected to parameter mutation and transaction sequence optimization;
for transaction sequence optimization behavior, the branch coverage test case pool is more focused on the improvement of function branch coverage for the optimization of test cases; the optimization of the data-dependent test case pools for test cases is more focused on creating test cases with data dependencies.
6. The intelligent contract fuzziness testing method based on utility adjustment strategy of claim 5, wherein the test case optimization comprises:
3.1 parameter mutation
Adopting an equal parameter mutation scheme for the two test case pools, wherein the scheme focuses on a parameter part in the function information f and the additional information theta;
3.1.1 test case selection
The system traverses the test case pool P in parallel branch And P data Test cases T are obtained i j ；
3.1.2 selection of transactions to be mutated
System traversal test case T i j All transactions tx in (a) k Determining whether to mutate the current transaction parameters according to the probability of P, wherein the parameters comprise parameter information epsilon and environment information delta;
3.1.3 parameter information mutation
Test case pool P branch And P data The same parameter information mutation scheme was used: mutating a parameter part in the function information f; the mutation modes comprise:
breadth mutation α: the system acquires the function parameter information (p) stored in the θ information i ，p j ，...，p k ) And no longer mutate the parameters at the current parameter mutation stage (p i ，p j ，...，p k ) And randomly selects the remaining parameters (p q ，p p ，...，p m ) Randomly mutating one or more of the above;
depth mutation beta: the system acquires the function parameter information (p) stored in the θ information i ，p j ，...，p k ) And at the current parameterMutation parameters (p) i ，p j ，...，p k )；
Completely random mutation γ: the system randomly selects (p 1 ，p 2 ，...p m ) Randomly mutating one or more parameters of (a) to obtain a random mutation;
3.1.4 Theta information acquisition
The fuzzy test system acquires theta information in the current transaction tx;
3.1.5 mutant selection
The system judges whether the current theta information is None, if yes, a gamma mutation mode is selected, otherwise, the fuzzy test system randomly selects one of three mutation modes to mutate the parameters;
3.1.6 mutation Performance
After the system determines the mutation mode, parameters to be mutated are selected; for the alpha mutation direction, the fuzzy test system can mutate the parameters contained in the current transaction theta information again, and mutate the parameters in a bit overturning and byte overturning mode provided by the sFuzz tool; for the beta mutation direction, the fuzzy test system mutates other parameters contained in the theta information of the current transaction, mutates the parameters in a bit-flipping and byte-flipping manner provided by a sFuzz tool, and finally updates the theta information into the mutated parameters;
3.2 environmental information mutations
The fuzzy test system generates new environment information parameters through bit flipping and byte flipping operations;
3.3 transaction sequence optimization
3.3.1 Branch coverage test case pool transaction sequence optimization
The system will cover the test case pool P from the branch branch Middle recursion fetch test case T i 1 Optimizing the transaction sequence in the test case until all the test cases in the current test case pool finish the optimization process and finish the current stage;
3.3.2 data-dependent test case pool transaction sequence optimization
The obfuscator will be from the data-dependent test case pool P data Take out test casesOptimizing the transaction sequence in the test case; in the optimization process, the information is collected according to two types (F: S define ) And (F: s is S use ) Guiding.
7. The utility adjustment policy based intelligent contract fuzziness testing method of claim 6, wherein the branch overlay test case pool transaction sequence optimization comprises:
3.3.1.1 high branch coverage function acquisition: the system scans the transaction level of the test cases acquired in 3.1.1 and acquires the function selector m in each transaction tx i By recording the branch coverage corresponding to the current function through the collected (F: B) information, the system compares all the branch coverage conditions and acquires the current test case T through the M mapping table i 1 Function F with highest branch coverage b-max ；
3.3.1.2 test case optimization: for the branch coverage test case pool, the system randomly selects one of three optimization modes:
first, selecting a low branch coverage function F from the collected (F: B) information min Encoding to append a transaction to the current test case T i 1 Random positions in (a);
secondly, deleting the current test case T i 1 Function F with highest branch coverage in (3) b-max Corresponding transaction;
third, replace test case T i 1 Function F of highest branch coverage in b-max The corresponding transaction is a low-branch coverage function F min Coded transactions;
3.3.1.3 temporary storage of new test cases: new test cases generated by 3.3.1.2 stagesWill be temporarily stored in P branch In wait->After the execution is finished, calculating the value quantity and determining whether to carry out test case coverage or not;
data dependent test case pool transaction sequence optimization comprising:
3.3.2.1 test case optimization for a data dependent test case pool, the system randomly selects one of three optimization modes:
the method comprises the following steps: adding a data dependent transaction, randomly selecting test case T i 2 A transaction tx in (a) λ Through (F: S) define ) Information find transaction tx λ The state variables defined by the corresponding function are then passed (F: S use ) Information finds a function using the state variable and acts as a transaction tx μ Added to transaction tx λ Thereafter, if there is no transaction tx μ Then randomly selecting a function as a transaction tx v Additional to transaction tx λ Then, completing the adding process of the test case transaction sequence;
And two,: randomly deleting current test casesIs a transaction in the middle;
and thirdly,: random replacement of current test casesOne transaction in the system is other function transactions; the ambiguity unit can wait for possible selection of function selectors in the M mapping table, acquire corresponding functions and encode the corresponding functions into a transaction, and finally ensure that the length of the test case is not less than 1;
3.3.2.2 temporary storage of new test cases: new test cases generated by 3.3.2.1 stageWill be temporarily stored in P data In wait->After the execution is finished, the value quantity is calculated and whether the test case coverage is carried out or not is determined.
8. The utility tuning policy based intelligent contract fuzziness testing method of claim 1, wherein the performing an analysis phase comprises:
the fuzzy test system executes the test case and judges whether to trigger the vulnerability according to the byte code path and the state variable data flow direction in the execution process;
secondly, after all the test case pools are executed, the fuzzy test system calculates the utility value of each test case pool according to the execution time, the branch jump frequency, the vulnerability discovery number and the degree of difference among the test cases;
and (3) carrying out reassignment on the number of the test cases by comparing the utility values of different test case pools, and randomly transferring the test cases with the corresponding numbers in the test case pool with the low utility value into the test case pool with the high utility value according to a reassignment number calculation formula.
9. The intelligent contract fuzziness testing method based on utility adjustment strategy of claim 8, wherein the utility value in the test case pool is calculated as formula (3-1):
wherein w is 1 : the weight parameter of the time factor gradually decreases with the increase of time, and the utility of the test case is gradually reduced, w 1 Controlling the intensity of this utility factor; w (w) 2 : the larger the index parameter of the time factor, the faster the utility decreases with increasing time; t: the execution time of the current test case pool is used for representing the real time of the current test case execution, and the shorter the time is, the higher the utility is, with seconds as a basic unitThe utility value gradually becomes gentle along with the increase of the execution time of the current test case pool; w (w) 3 : the higher the total branch jump frequency in the test case pool, the higher the utility of the test case, and w 3 Controlling the intensity of this utility factor; b: the branch Jump frequency represents the total branch Jump times of the current test case pool, and statistics is carried out by recording the byte codes JumpI and Jump; w (w) 4 : vulnerability discovery weight parameter, the more vulnerability discovery, the higher the utility of test case pools, w 4 Controlling the intensity of this utility factor; v: the vulnerability discovery number represents the vulnerability number discovered by the current test case pool; w (w) 5 : the larger the difference degree, the higher the utility of the test case pool, and the w 5 Controlling the intensity of this effect; d: the difference degree parameter represents the difference degree between test cases in the current test case pool;
and (3) for the difference degree calculation formula in the test case pool, the formula is as follows:
wherein n represents the number of test cases in the current test case pool, A represents the reference test case for calculating the difference degree between the test cases, the reference test case is selected in a random selection mode, and B i Represents test cases other than A, J (A, B i ) Representing test cases A and B i Jaccard coefficients in between;
the Jaccard similarity coefficient calculation formula is shown as (3-3):
the invention is defined by A and B i Representing the intersection of transactions between two test cases, A U B i Representing the union of transactions between test cases; therefore, the larger the difference degree between the test cases in the test case pool is, the larger the value of d is,wherein the value range of d is as follows: d is more than or equal to 0 and less than or equal to 1;
the calculation in the reassignment of the number of test cases is shown in the following formula (3-4):
Wherein count represents the number of test case reassignments in the current stage, the reassignment idea is to transfer the test cases in the low utility value test cases to the high utility value test case pool; m and n respectively represent the interval range of the number of reassignments each time, wherein m is more than or equal to n; x2 and x1 are utility values in two test case pools.
10. A utility adjustment policy based intelligent contract fuzzing test system adapted for use in the utility adjustment policy based intelligent contract fuzzing test method of claim 1, comprising:
a blurring engine module: the module generates all test cases in the initial test case pool according to the intelligent contract related information, and prepares for the subsequent execution analysis stage;
test case optimization module: the module is used for updating and optimizing all test cases in the test case pool, different test case pools have different test case optimization schemes, wherein the branch coverage test case pool is favorable for exploring deep branch loopholes, and the data dependence test case pool is favorable for exploring loopholes existing among multiple transactions by constructing complex test cases with data dependence relations;
and an execution analysis module: the module runs the test cases in each test case pool, and discovers whether a vulnerability exists in the intelligent contract according to the information generated in the test case executing process through the judgment of the vulnerability predictor; meanwhile, the module dynamically adjusts the number of test cases in each test case pool according to the number of loopholes found in the test case execution process.
CN202310498204.1A 2023-05-06 2023-05-06 Intelligent contract vulnerability detection method based on utility adjustment strategy Pending CN116821913A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310498204.1A CN116821913A (en) 2023-05-06 2023-05-06 Intelligent contract vulnerability detection method based on utility adjustment strategy

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310498204.1A CN116821913A (en) 2023-05-06 2023-05-06 Intelligent contract vulnerability detection method based on utility adjustment strategy

Publications (1)

Publication Number Publication Date
CN116821913A true CN116821913A (en) 2023-09-29

Family

ID=88124866

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310498204.1A Pending CN116821913A (en) 2023-05-06 2023-05-06 Intelligent contract vulnerability detection method based on utility adjustment strategy

Country Status (1)

Country Link
CN (1) CN116821913A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117792967A (en) * 2024-02-26 2024-03-29 南京邮电大学 Camera fuzzy test method based on difference feedback

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117792967A (en) * 2024-02-26 2024-03-29 南京邮电大学 Camera fuzzy test method based on difference feedback
CN117792967B (en) * 2024-02-26 2024-05-10 南京邮电大学 Camera fuzzy test method based on difference feedback

Similar Documents

Publication Publication Date Title
Höppner et al. Profit driven decision trees for churn prediction
Ashouri et al. Micomp: Mitigating the compiler phase-ordering problem using optimization sub-sequences and machine learning
Muñoz et al. Algorithm selection for black-box continuous optimization problems: A survey on methods and challenges
CN110175120B (en) Fuzzy test case self-adaptive mutation method and device based on reinforcement learning
Cheng et al. Optimizing multiple-resources leveling in multiple projects using discrete symbiotic organisms search
Harman et al. A theoretical and empirical study of search-based testing: Local, global, and hybrid search
CN106250461A (en) A kind of algorithm utilizing gradient lifting decision tree to carry out data mining based on Spark framework
CN111797010B (en) Intelligent contract test case generation method applying improved genetic algorithm
Bausch et al. Making cost-based query optimization asymmetry-aware
CN102073708A (en) Large-scale uncertain graph database-oriented subgraph query method
CN116821913A (en) Intelligent contract vulnerability detection method based on utility adjustment strategy
CN109271421A (en) A kind of large data clustering method based on MapReduce
CN107885503A (en) A kind of iteration based on performance of program analysis compiles optimization method
Silva et al. Exploring the space of optimization sequences for code-size reduction: insights and tools
Das et al. Multi-objective feature selection (MOFS) algorithms for prediction of liquefaction susceptibility of soil based on in situ test methods
Deshpande et al. Pareto front approximation using a hybrid approach
Chen et al. LOGER: A learned optimizer towards generating efficient and robust query execution plans
Fan et al. Graph algorithms: parallelization and scalability
Kissel et al. Forward stability and model path selection
Fachin et al. Self-adaptive differential evolution applied to combustion engine calibration
CN114911844A (en) Approximate query optimization system based on machine learning
CN112527300A (en) Fine-grained compiling self-optimization method for multiple targets
CN117971475A (en) Intelligent management method and system for GPU computing force pool
Fister Jr et al. A brief overview of swarm intelligence-based algorithms for numerical association rule mining
CN116521176B (en) Compilation optimization option optimization method and device, intelligent terminal and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination