Cross-Contract Vulnerability Detection Method and System Based on Execution Opcode

Abstract

The present invention discloses a cross - contract vulnerability detection method and system based on running opcodes. In the present invention, basic data information is obtained in the pre - processing stage. In the fuzz testing stage, the test cases generated in the pre - processing stage are used to obtain suspicious cross - contract call chains through the cross - contract control flow graph generated by the dynamically constructed cross - contract control flow graph module, which is used to guide the py - EVM to execute to obtain the running opcode sequence, and the contract attribute parameters are used for mutation; in the dynamic process stage, a dynamic cross - contract control flow graph is constructed and the contract attributes are parameterized; the dynamic cross - contract control flow graph constructs static and dynamic cross - contract control flow graphs through running opcodes and static opcodes respectively, and continuously calculates and updates by overlapping; finally, the running opcode sequence generated in the fuzz testing stage is handed over to the vulnerability detection stage to generate a vulnerability report. The present invention is applicable to cross - contract vulnerability detection of smart contracts, with strong scalability and high vulnerability detection accuracy.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain smart contract security technology, and in particular to a cross-contract security vulnerability detection method and system for blockchain smart contracts. Background Art

[0002] As cross-contract security vulnerabilities become more and more numerous and prominent, blockchain smart contract security detection technology is also developing towards more complex cross-contract vulnerability detection.

[0003] Cross-contract vulnerability detection methods in existing smart contracts: The Clairvoyance tool constructs a cross-contract control flow graph xCFG from the smart contract source code, and uses custom vulnerability rules to analyze suspicious vulnerability paths in xCFG to achieve cross-contract vulnerability detection. The SmartDagger tool decompiles the contract bytecode into IR (intermediate representation), performs semantic recovery of IR through a neural machine translation model and constructs a contract control flow graph xCFG, and then discovers suspicious call chains and detects cross-contract vulnerabilities based on vulnerability rules. Since the constructed xCFG is static, it is impossible to determine which paths in the control flow graph are actually executable, and it is difficult to find unreachable branches in the control flow graph, resulting in a large number of false positives in vulnerability detection.

[0004] Solve the problem of effectiveness of cross-contract vulnerability detection through dynamic execution. The xFuzz tool constructs the control flow graph CFG and function call graph of each contract by inputting the contract source code, and then constructs the cross-contract control flow graph xCFG. It locates the vulnerability through machine learning and combines xCFG to build a suspicious call chain, uses the suspicious call chain for fuzz testing, and finally performs opcode vulnerability detection. This method reduces the false alarm rate of vulnerabilities, but because it does not consider the data dependency of contract attributes, it leads to more missed vulnerabilities.

[0005] In summary, in order to effectively detect cross-contract vulnerabilities in smart contracts, the present invention is based on the hybrid fuzzy testing framework ConFuzzius, and proposes a cross-contract vulnerability detection method based on running opcodes. Since function parameters are local variables and there is no data dependency between them, the global contract attributes can be eliminated and turned into function parameters, and the parameters are added to the function containing the contract attributes to generate a new contract to solve the problem of missed vulnerability detection in dynamic execution; since the running opcode is the real execution result of the transaction through EVM, the running opcode can be used to construct CFG, and further combined with the cross-contract function call statement to construct a cross-contract control flow graph xCFG, so that each edge of the constructed xCFG is truly reachable, solving the problem of false positive vulnerability detection in static analysis methods, thereby improving the accuracy of detecting cross-contract vulnerabilities in smart contracts. Summary of the invention

[0006] The purpose of the present invention is to address the deficiencies in the prior art and propose a cross-contract vulnerability detection method and system based on running operation codes, which includes four stages: a preprocessing stage, a fuzzy testing stage, a dynamic process stage, and a vulnerability detection stage.

[0007] I. Preprocessing stage

[0008] 1-1. Take the smart contract source code file SCCode as input, and use the smart contract compilation tool py-solc-x to compile the contract source code file SCCode to obtain the contract static bytecode SCByte, abstract syntax tree SCAST and application binary interface SCABI, where SCByte = 0xa 1 …a i , a i It represents an integer from 0 to 10, i represents an integer; 0x represents a 1 …a i It is a hexadecimal representation.

[0009] 1-2. Input the static bytecode SCByte and source code file SCCode of the contract, and use the open source tool ConFuzzius to obtain the mapping relationship diagram SRCMap between the opcode and the source code = {sm 1 ,…,s m , …, sm M}, where sm m ={pc m :[begin m , end m , opcode m ]}, indicating the operation code opcode m The mapping relationship between pc and its corresponding source code m 、begin m and end m Respectively represent the operation code opcode m The program counter value, the starting position and the ending position of the corresponding source code string.

[0010] 1-3. Input the static bytecode SCByte of the contract and use the ConFuzzius tool to generate the test case TCase.

[0011] 1-4. Input the abstract syntax tree SCAST, use the depth-first search algorithm DFS to search the abstract syntax tree, and obtain the contract attribute information set SCA = {sca 1 ,…,sca n ,…,sca N}, where each contract attribute sca n =(contract attribute name, attribute initial value, attribute type).

[0012] 1-5. Input the application binary interface SCABI and use the ConFuzzius tool to generate a binary relationship between the function name in the contract and its corresponding function hash value, which is defined as a function mapping: Hash = {[hash 1 :fun_name 1 ],…,[hash k :fun_name k ],…,[hash K :fun_name K ]}, where hash k : represents the hash value of the kth function, fun_name k Represents the name of the kth function.

[0013] II. Smart Contract Fuzz Testing Phase

[0014] 2-1. The first round of smart contract fuzz testing is as follows:

[0015] 2-1-1. Get the contract's running operation code sequence

[0016] Initialize the suspicious cross-contract function call chain FunCC = null, use the test case TCase obtained in the preprocessing phase as input and directly use the py-EVM tool to execute the test case TCase to obtain the running operation code sequence RCode;

[0017] Run the operation code sequence RCode, expressed as (OPCode 1 ,…,OPCode k1 ), where OPCode k1 ={pc k1 , opcode k1}, opcode k1 Indicates the k1th opcode, pc k1 Indicates the program counter value of the k1th opcode.

[0018] 2-1-2. Fuzzy mutation to generate new test cases

[0019] The test case TCase is used with the ConFuzzius fuzzy testing genetic mutation algorithm to generate a new test case N-TCase;

[0020] If the function parameters of the test case N-TCase are in the contract attribute information set SCA, the contract attribute value range C1 generated by the contract attribute parameterization in step 3-1 is used j , to perform random mutation on the function parameters corresponding to the contract attributes within a limited value range;

[0021] If the function parameter of the test case N-TCase is not in the contract attribute information set SCA, random mutation is performed according to the value range of the corresponding type of the function parameter.

[0022] Return to step 2-1-1, execute the loop G times (G can be specified according to actual conditions, generally 20 times), and then jump to step 3.

[0023] 2-2. The Nth (N is greater than or equal to 2) round of smart contract fuzz testing is as follows:

[0024] 2-2-1. Obtain suspicious cross-contract function call chains;

[0025] According to step 3-2 in the first round of smart contract fuzz testing, the cross-contract control flow graph is obtained. Then, the xCFG graph is used as input to traverse all nodes of the xCFG graph. The specific processing method is as follows:

[0026] Define each node in the xCFG graph as an opcode block, and use the opcode that may trigger the vulnerability to match the opcode contained in the opcode block. The opcode that may trigger the vulnerability is set according to the vulnerability characteristics, including SELFDESTRUCT, CALL, DELEGATECALL, ASSERTFAIL, and INVALID.

[0027] If the opcode matches, then according to the starting address of the opcode block where the opcode is located in the xCFG graph, traverse the vertices of the xCFG graph from back to front [start j1 , start k2 ], if the starting address is in vertices = {start i1 :[start j1 , start k2 ]}, the starting address and start i1 Add the suspected cross-contract vulnerability path, and then start i1 As the new starting address, repeat the traversal of the vertices in the xCF6 graph [start j1 , start k2 ], reverse engineering the suspected cross-contract vulnerability path path = [start 1 ->…->start n1 ](where start n1 It represents the starting address of the n1th opcode block), and uses the vulnerability path path to traverse the function entry address Fun_add generated in step 3-2-8 to obtain the suspicious cross-contract function call chain FunCC; FunCC = [{C 1 :fun 1}, ..., {C i2 :fun i2}], where C i2 Indicates the name of the i2th contract, fun i2 Indicates a function name in the i2th contract name. There are several functions in one contract.

[0028] 2-2-2. Get the contract's running operation code sequence

[0029] If FunCC! = null, use the test case TCase obtained in the preprocessing phase as input, use FunCC to sequentially guide the py-EVM tool to execute the corresponding functions of the corresponding contract of the suspicious cross-contract function call chain FunCC, and obtain the running operation code sequence RCode; otherwise, directly use the py-EVM tool to execute the test case TCase to obtain the running operation code sequence RCode;

[0030] 2-2-3. Fuzzy mutation generates new test cases, which is consistent with step 2-1-3.

[0031] III. Dynamic Processing Stage

[0032] 3-1. Contract attribute parameterization

[0033] 3-1-1. Traverse the operation opcode sequence RCode obtained in the fuzz testing phase and match it with the opcodes in the operation opcode set one by one. If the match is successful:

[0034] 3-1-1-1. According to the mapping relationship diagram SRCMap (in SRCMap, the same operation code and source code are in a 1:n relationship, and the same operation code has multiple source codes.), use the matching operation code to find the corresponding code statement in the contract source code file;

[0035] 3-1-1-2. Perform a regular expression match on the code statement according to the equal sign (=), and extract the variable p on the left side of the equal sign (=) at ;

[0036] 3-1-1-3. If variable p at In the contract attribute information set SCA, it indicates that the variable p at is a contract attribute, then the variable p at Add to the function parameters that read and write this attribute, such as fun i3 (p 1 ,…,p n2 ) → fun i3 (p 1 ,…,p n2 , p at ), where p at is a function funi3 New attribute parameters added in fun i3 represents the i3th function, (p 1 ,…,p n2 ) represents the original n2 parameters, → represents the function fun i3 Insert new attribute parameter p at Then generate a new function, and finally generate a new contract N-SCCode;

[0037] 3-1-1-4. Use regular matching to obtain the variable on the left side of the equal sign (=) and the constant on the right side of the code statement in step 3-1-1-1, and combine it with the operation code matched in step 3-1-1-2. If there is only a contract attribute in the variable, the step length of the contract attribute change step is the value of the constant; otherwise, the step length of the contract attribute change step is the value of the contract attribute type range change, that is, 1 or -1;

[0038] 3-1-1-5. Combine the step length step obtained in step 3-1-1-4 with the contract attribute information SCA (which contains the contract attribute type and initial value) obtained in the preprocessing stage to generate the value range C1 of the contract attribute j =type-initvalue_step(where C1 i represents the name of the i-th contract attribute, type represents the specific variable type of the attribute, initvalue represents the initial value of the attribute, and step represents the step size of the attribute change). j It serves the genetic mutation phase of fuzz testing (steps 2-1-2 and 2-2-3).

[0039] The operation code set = {ADD, SUB, MUL}, wherein the operation codes contained therein are set as required.

[0040] 3-1-2. Repeat step 3-1-1 to match the next opcode in the operation opcode set until the operation code processing in the operation opcode set is completed;

[0041] 3-1-3. Return to step 1-1 and re-execute the preprocessing stage.

[0042] 3-2. Construction of dynamic cross-contract control flow graph xCFG

[0043] 3-2-1. Generate static operation code sequence of the contract: Decompile the static bytecode SCByte of the contract obtained in the preprocessing stage to generate a static operation code sequence SCode = (OPCode 1 ,…,OPCode k3 ), OPCode k3Indicates the k3th operation code, where OPCode k3 ={pc k3 , opcode k3}, pc k3 It indicates the program counter value before the opcode. k3 It represents the opcode itself and traverses the static opcode sequence.

[0044] 3-2-2. Build a contract opcode block set. Each contract has an opcode block set Blocks.

[0045] Initialize the opcode block block, and add the static opcode obtained by traversing the static opcode sequence to the opcode block block;

[0046] If the static opcode obtained through traversal is a JUMP opcode, its jump address is the address introduced by the previous PUSH opcode;

[0047] If the static opcode obtained by traversal is a JUMPI opcode, its jump address is the next program counter PC (PC+1) position or the address introduced by the previous PUSH opcode;

[0048] If the static opcode obtained by traversal is a termination opcode (STOP, RETURN, REVERT, INVALID), the construction of the opcode block is terminated.

[0049] 3-2-3. Constructing the contract control flow graph

[0050] The opcode block set Blocks constructed in step 3-2-2 is connected by the jump addresses of the JUMP and JUMPI jump opcodes to construct a control flow graph CFG = {blocks = {start i1 :[baseblock i1 ]}, vertices = {start i1 :[start j1 , start k2 ]}}, where blocks represents all opcode blocks, start i1 It indicates the starting address of the i1th opcode block, baseblock i1 It represents the i1th opcode block, vertices represents all edge information, start j1 and start k2 It indicates the starting address of the j1th opcode block and the k2th opcode block to which the i1th opcode block can jump, where baseblock i1 ={pc j2:[opcode j2 ]}, pc j2 It indicates the value of the program counter before the opcode. j2 It represents the opcode itself;

[0051] 3-2-4. Go to step 3-2-1 and continue traversing the static operation code sequence SCode until the traversal is completed.

[0052] 3-2-5. Traverse all opcode blocks in the control flow graph CFG, and through the rule that the previous opcode is ISZERO and the current opcode is CALL, use the PC value of the CALL opcode to locate the contract source code statement through the mapping relationship graph SRCMap to obtain the cross-contract function call statement contract = c.fun, where c represents the contract object and fun represents the function name called by the contract object c;

[0053] 3-2-6. Use regular matching to find the function name where the cross-contract function call statement contract is located;

[0054] 3-2-7. Traverse the opcodes in all opcode blocks in the control flow graph CFG, combined with the function mapping Hash in the preprocessing stage. If the opcode is PUSH, and the value after the PUSH opcode is a function hash value in the function mapping Hash, then the last opcode of the opcode block where the PUSH opcode is located must be a JUMPI opcode. As described in step 3-2-2, the condition is established, and its jump address is the address introduced by the previous PUSH opcode, that is, the function entry address Fun_add = [C_fun_name i4 :pc i4 ], where C_fun_name i4 Indicates the function name of the i4th contract, pc i4 Indicates the function entry address corresponding to the i4th function name in the control flow graph.

[0055] 3-2-8. According to the function of the contract where the function call statement contract is located and the called contract function, obtain the entry addresses pc1 and pc2 corresponding to the two function names through the function entry address Fun_add generated in step 3-2-7;

[0056] 3-2-9. Connect the control flow graph CFG generated by steps 3-2-1 to 3-2-4 using the two function entry addresses pc1 and pc2 obtained in step 3-2-8 to generate a static cross-contract control flow graph.

[0057] 3-2-10. The operation code sequence RCode obtained in the fuzz testing phase is also constructed according to steps 3-2-1 to 3-2-4 to construct a dynamic cross-contract control flow graph;

[0058] 3-2-11. Calculate the overlap of the static cross-contract control flow graph and the dynamic cross-contract control flow graph. Specifically, traverse the dynamic cross-contract control flow graph operation code block generated in step 3-2-10 and the static cross-contract control flow graph operation code block generated in steps 3-2-1 to 3-2-4. Mark the overlapped operation code block on the static cross-contract control flow graph, leaving the marked static control flow graph. The marked static control flow graph part is the part actually needed.

[0059] 3-2-12. Go to step 3-2-10 and repeat steps 3-2-10 to 3-2-11 to improve this static control flow graph until the detection is completed to obtain the final accurate and true dynamic cross-contract control flow graph.

[0060] 4. Vulnerability detection phase

[0061] 4-1. Vulnerability rules:

[0062] The vulnerability rules are described in the form of ConFuzzius tool vulnerability oracle, and the ConFuzzius tool is used to write all the oracles to detect vulnerabilities;

[0063] 4-2. Vulnerability rule matching:

[0064] Input the running operation code sequence RCode into the vulnerability rule oracle for matching and analysis;

[0065] 4-3. Vulnerability Report:

[0066] If it matches the oracle of the vulnerability rule, then the operation opcode sequence RCode is judged to be a cross-contract operation opcode sequence according to whether the suspicious cross-contract function call chain FunCC is obtained in the fuzz testing phase; if it is a single-contract vulnerability, the vulnerability type, the program counter PC where the vulnerability occurs, the source code statement, line number, and function call information are output; if it is a cross-contract vulnerability, the cross-contract function call chain FunCC needs to be output. If it does not match the oracle of the vulnerability rule, it will be executed normally without reporting the vulnerability.

[0067] The execution logic of the cross-contract vulnerability detection method based on running operation codes is as follows:

[0068] The first round of execution: first input the smart contract file, and after the preprocessing stage, output the contract attribute set, test case, opcode source code mapping diagram, contract static bytecode, and function mapping; then input the contract attribute set and test case into the fuzz testing stage to generate a running opcode sequence; then input the opcode source code mapping diagram, contract attribute set, and running opcode output in the fuzz testing stage output in the preprocessing stage into the contract attribute parameterization stage, output the new smart contract and the contract attribute value range, and at the same time input the contract static bytecode, function mapping, and running opcode sequence output in the fuzz testing stage output in the preprocessing stage into the dynamic xCFG construction stage, output the cross-contract control flow graph, and at the same time input the running opcode sequence output in the fuzz testing stage into the vulnerability detection stage, and output the vulnerability report.

[0069] Subsequent rounds of execution: First, input the new smart contract output by the contract attribute parameterization phase in the previous round of execution, and output the contract attribute set, test cases, opcode source code mapping diagram, contract static bytecode, and function mapping through the preprocessing phase; then input the contract attribute set, test cases, attribute value range output by the previous round of contract attribute parameterization phase, and the cross-contract control flow graph output by the previous round of dynamic xCFG construction phase into the fuzz testing phase to generate a running opcode sequence; then input the opcode source code mapping diagram, contract attribute set, and running opcode sequence output by the fuzz testing phase output by the preprocessing phase into the contract attribute parameterization phase, output the new smart contract and contract attribute value range, and at the same time input the contract static bytecode, function mapping, and running opcode sequence output by the fuzz testing phase into the dynamic xCFG construction phase, output the cross-contract control flow graph, and at the same time input the running opcode sequence output by the fuzz testing phase into the vulnerability detection phase, and output the vulnerability report.

[0070]

[0071]

[0072] Another object of the present invention is to provide a cross-contract vulnerability detection system based on running opcodes, including a preprocessing module, a fuzz testing module, a dynamic process module and a vulnerability detection module;

[0073] Preprocessing module: obtain the basic data required by subsequent modules (contract static bytecode, contract attribute information, test cases, function mapping Hash, opcode source code mapping diagram). Mainly use the smart contract compilation tool py-solc-x to compile the contract source code to obtain the contract static bytecode SCByte, abstract syntax tree SCAST and application binary interface ABI, use the open source fuzz testing tool ConFuzzius to generate test case TCase, opcode source code mapping diagram SRCMap and function mapping Hash, and search the abstract syntax tree through the depth-first search algorithm DFS to obtain the contract attribute information set SCA;

[0074] Fuzz testing module: used for the execution and mutation of test cases. Input the test case TCase generated in the preprocessing stage. For the execution of the test case TCase, obtain the suspicious cross-contract function call chain FunCC from the xCFG generated in the dynamic cross-contract control flow graph stage in the dynamic process module to guide the py-EVM tool to execute the corresponding test case TCase and obtain the running opcode sequence RCode. If xCFG or FunCC does not exist, it degenerates into single contract vulnerability detection. For the mutation of the test case TCase, if the function parameters of the test case TCase contain contract attributes, the contract attributes are mutated using the corresponding contract attribute value range generated in the contract attribute parameterization stage in the dynamic process module. If not, it is completely random.

[0075] Dynamic process module: includes two parallel stages: contract attribute parameterization and construction of dynamic cross-contract control flow graph. For the contract attribute parameterization stage, the running opcode sequence RCode generated by the traversal fuzz testing stage is matched with the operation-related opcodes (ADD, SUB, MUL), and the matched opcode is used to obtain the contract source code statement using the mapping relationship diagram SRCMap between the opcode and the source code. If the statement modifies the contract attribute, the attribute is added to the function parameter that reads and writes the attribute, and a new contract N-SCCode is generated. The statement is then regular matched and statically analyzed to obtain the value range C of the attribute. i , in order to impose certain restrictions on the subsequent mutation of the contract attribute parameters in the function; for the construction of dynamic cross-contract control flow graphs, first decompile the contract static bytecode SCByte obtained in the preprocessing stage into a static opcode sequence, traverse the static opcode sequence to generate the control flow graph CFG of each contract, and then connect each control flow graph CFG through the cross-contract function call statement to generate a static cross-contract control flow graph xCFG, and then use the running opcode sequence RCode obtained in the fuzz testing stage to generate a dynamic cross-contract control flow graph as above, and finally calculate the two cross-contract control flow graphs, leaving the overlapping parts. Repeat and improve the dynamic cross-contract control flow graph;

[0076] Vulnerability detection module: used to detect and report contract vulnerabilities. Different vulnerability rule judges are generated according to the characteristics of different vulnerability types. The running operation code sequence RCode obtained in the fuzzy testing phase is used as input to the vulnerability rule judge for judgment. If one of the vulnerability rules is met, the test case execution information and vulnerability information are returned. If it is a cross-contract vulnerability, the suspected cross-contract vulnerability call chain FunCC needs to be output.

[0077] The beneficial effects of the present invention are as follows:

[0078] The present invention adopts a cross-contract vulnerability detection method based on running opcodes, eliminates contract attributes, converts them into function parameters, and adds the parameters to the function that has a read-write relationship with the contract attributes to solve the problem of missed vulnerability detection in dynamic execution; uses running opcodes to construct a control flow graph CFG for each contract, and further combines cross-contract function call statements to construct a cross-contract control flow graph xCFG, so that all edges of the constructed xCFG are truly reachable, solving the problem of false positive vulnerability detection in static analysis methods, thereby improving the accuracy of detecting cross-contract vulnerabilities in smart contracts.

[0079] Compared with the existing smart contract cross-contract vulnerability detection tools Clairvoyance, xFuzz, and SmartDagger, the cross-contract vulnerability detection method based on running opcodes proposed in the present invention constructs a dynamic cross-contract control flow graph for the above three tools, so that the suspicious vulnerability path or call chain obtained later according to the control flow graph is true and accurate, which can greatly reduce the false positive problem caused by static cross-contract control flow graph detection; for xFuzz, the contract attribute is parameterized by contract attribute, the contract attribute is eliminated and turned into a function parameter, and the parameter is added to the function that has a read-write relationship with the contract attribute to generate a new contract input, so that the read-write dependency relationship between functions on the contract attribute is eliminated, thereby reducing the problem of missed reports caused by the inability to break through the branch containing the contract attribute in the function. Therefore, the present invention can improve the accuracy of cross-contract vulnerability detection.

[0080] By using the method of the present invention, the accuracy of cross-contract vulnerability detection can be improved, and more and more accurate cross-contract vulnerabilities of smart contracts can be discovered within the same data set. BRIEF DESCRIPTION OF THE DRAWINGS

[0081] Figure 1 It is the overall flow chart of the present invention;

[0082] Figure 2 for Figure 1 Flowchart of the preprocessing stage.

[0083] Figure 3 for Figure 1Flowchart of the fuzz testing phase.

[0084] Figure 4 for Figure 1 Flowchart of the contract attribute parameterization phase in the dynamic process.

[0085] Figure 5 for Figure 1 Flowchart of the stages of constructing dynamic xCFG in the dynamic process.

[0086] Figure 6 for Figure 1 Flowchart of the vulnerability detection phase.

[0087] Figure 7 This is a detailed diagram of the cross-contract control flow. DETAILED DESCRIPTION

[0088] The technical solution of the present invention will be fully described below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0089] like Figure 1 As shown in the figure, the cross-contract vulnerability detection method based on running operation codes is divided into four stages: preprocessing stage, fuzzy testing module stage, dynamic process stage and vulnerability detection stage.

[0090] 1. Preprocessing stage, such as Figure 2 As shown, the following steps are included:

[0091] 1-1. Obtaining and processing contract compilation information: Take the smart contract source code file SCCode as input, and use the smart contract compilation tool py-solc-x to compile the source code SCCode to obtain the contract static bytecode SCByte, abstract syntax tree SCAST and application binary interface SCABI;

[0092] Input the static bytecode SCByte and source code SCCode of the contract, and use the open source smart contract fuzz testing tool ConFuzzius to obtain the mapping relationship diagram SRCMap between the opcode and the source code;

[0093] Input the static bytecode SCByte of the contract, and use the ConFuzzius tool to generate the test case TCase; input the abstract syntax tree SCAST, and use the depth-first search algorithm DFS to search the abstract syntax tree to obtain the contract attribute information set SCA;

[0094] The specific implementation of searching the abstract syntax tree to obtain contract attribute information through the depth-first search algorithm is: first traverse the key-value pair key, value of the abstract syntax tree SCAST. If the value is VariableDeclaration, it means that the tree structure is a contract attribute node. Then, according to the value of the key value name, value and typeName under the node, the contract attribute name, initial value and attribute type are obtained. The pseudo code of the depth-first search algorithm to search the abstract syntax tree to obtain the contract attribute information set SCA is as follows:

[0095]

[0096] Input the application binary interface SCABI, and use the ConFuzzius tool to generate the correspondence between the function name in the contract and its corresponding function hash value, which is defined as the function mapping Hash;

[0097] 2. Fuzz testing module stage, such as Figure 3 As shown, the following steps are included:

[0098] 2-1. The first round of smart contract fuzz testing is as follows:

[0099] 2-1-1. Get the contract's running operation code sequence

[0100] Initialize the suspicious cross-contract function call chain FunCC = null, use the test case TCase obtained in the preprocessing phase as input and directly use the py-EVM tool to execute the test case TCase to obtain the running operation code sequence RCode;

[0101] Run the operation code sequence RCode, expressed as (OPCode 1 ,…,OPCode k1 ), where OPCode k1 ={pc k1 , opcode k1}, opcode k1 Indicates the k1th opcode, pc k1 Indicates the program counter value of the k1th opcode.

[0102] 2-1-2. Fuzzy mutation to generate new test cases

[0103] The test case TCase is used with the ConFuzzius fuzzy testing genetic mutation algorithm to generate a new test case N-TCase;

[0104] If the function parameters of the test case N-TCase are in the contract attribute information set SCA, the contract attribute value range C1 generated by the contract attribute parameterization in step 3-1 is used j , to perform random mutation on the function parameter corresponding to the contract attribute within a limited value range; for example, if the initial value is 1 and the change step is 2, the possible values ​​are 1, 3, 5, 7…;

[0105] If the function parameter of the test case N-TCase is not in the contract attribute information set SCA, random mutation is performed according to the value range of the corresponding type of the function parameter. For example, the value range of uint8 is 0-2 8 -1, the value can be taken within this range.

[0106] Return to step 2-1-1, execute the loop G times (G can be specified according to actual conditions, generally 20 times), and then jump to step 3.

[0107] 2-2. The Nth (N is greater than or equal to 2) round of smart contract fuzz testing is as follows:

[0108] 2-2-1. Obtain suspicious cross-contract function call chains;

[0109] According to step 3-2 in the first round of smart contract fuzz testing, the cross-contract control flow graph is obtained. Then, the xCFG graph is used as input to traverse all nodes of the xCFG graph. The specific processing method is as follows:

[0110] Define each node in the xCFG graph as an opcode block, and use the opcode that may trigger the vulnerability to match the opcode contained in the opcode block. The opcode that may trigger the vulnerability is set according to the vulnerability characteristics, including SELFDESTRUCT, CALL, DELEGATECALL, ASSERTFAIL, and INVALID.

[0111] If the opcode matches, then according to the starting address of the opcode block where the opcode is located in the xCFG graph, traverse the vertices of the xCFG graph from back to front [start j1 , start k2 ], if the starting address is in vertices = {start i1 :[start j1 , start k2 ]}, the starting address and start i1 Add the suspected cross-contract vulnerability path, and then start i1 As the new starting address, repeatedly traverse the vertices of the xCFG graph [start j1 , start k2], reverse engineering the suspected cross-contract vulnerability path path = [start 1 ->…->start n1 ](where start n1 It represents the starting address of the n1th opcode block), and uses the vulnerability path path to traverse the function entry address Fun_add generated in step 3-2-8 to obtain the suspicious cross-contract function call chain FunCC; FunCC = [{C 1 :fun 1}, ..., {C i2 :fun i2}], where C i2 Indicates the name of the i2th contract, fun i2 Indicates a function name in the i2th contract name. There are several functions in one contract.

[0112] The pseudo code for obtaining the suspicious cross-contract vulnerability call chain is as follows:

[0113]

[0114]

[0115] 2-2-2. Get the contract's running operation code sequence

[0116] If FunCC! = null, use the test case TCase obtained in the preprocessing phase as input, use FunCC to sequentially guide the py-EVM tool to execute the corresponding functions of the corresponding contract of the suspicious cross-contract function call chain FunCC, and obtain the running operation code sequence RCode; otherwise, directly use the py-EVM tool to execute the test case TCase to obtain the running operation code sequence RCode;

[0117] 2-2-3. Fuzzy mutation generates new test cases, which is consistent with step 2-1-3.

[0118] 3. Dynamic process stage, including the following steps:

[0119] 3-1. Contract attribute parameterization, such as Figure 4 As shown, the specific steps include:

[0120] 3-1-1. Traverse the operation opcode sequence RCode obtained in the fuzzy testing phase, and match the traversed opcodes with the operation opcode set = {ADD, SUB, MUL}. If the match is successful, go to step 3-1-2;

[0121] 3-1-1-2. Perform regular expression matching on the code statement according to the equal sign (=), and extract the variable on the left side of the equal sign (=);

[0122] 3-1-1-3. If the variable is in the contract attribute information set SCA, it means that the variable is a contract attribute. Then, the contract attribute is added to the function parameters for reading and writing the attribute, a new function is generated, and finally a new contract N-SCCode is generated;

[0123] 3-1-1-4. Use regular matching to obtain the variables and constants on both sides of the equal sign (=) in the code statement of 3-1-1-1, and combine it with the operation code matched in step 3-1-1-2. If there is only a contract attribute in the variable, the step length of the contract attribute change step is the value of the constant. Otherwise, the step length of the contract attribute change step is the value of the contract attribute type range change, that is, 1 or -1;

[0124] 3-1-1-5. Combine the step length step obtained in step 3-1-1-4 with the contract attribute information SCA (which contains the contract attribute type and initial value) obtained in the preprocessing stage to generate the value range C1 of the contract attribute j , the C i It serves the genetic mutation phase of fuzz testing (steps 2-1-2 and 2-2-3).

[0125] 3-1-2. Return to step 3-1-1 and match the next opcode in the operation opcode set until the operation code processing in the set is completed;

[0126] 3-1-3. Go back to step 1-1 and re-execute the pre-processing stage.

[0127] The pseudo code for parameterizing contract attributes is as follows:

[0128]

[0129]

[0130] 3-2. Dynamic cross-contract control flow graph xCFG construction, such as Figure 5 As shown, the specific steps include:

[0131] 3-2-1. First, decompile the contract static bytecode SCByte obtained in the preprocessing stage into a static operation code sequence SCode, traverse the static operation code sequence SCode, and traverse the static operation code sequence;

[0132] 3-2-2. When the operation code block is constructed for the first time or the operation code block in step 3-2-3 is constructed, the operation code block is reinitialized and the operation code obtained by traversing step 3-2-1 is added to the operation code block;

[0133] 3-2-3. Operation code block construction method:

[0134] When encountering the two jump opcodes JUMP and JUMPI, one of the opcode blocks is built.

[0135] If it is a JUMP opcode, the jump address is the address introduced by the previous PUSH opcode;

[0136] If it is a JUMPI opcode, the jump address is the next program counter PC (PC+1) position or the address introduced by the previous PUSH opcode;

[0137] If it is a termination opcode (STOP, RETURN, REVERT, INVALID), the construction of the opcode block block is terminated.

[0138] 3-2-4. Connect the opcode block constructed in step 3-2-3 through the jump addresses of the JUMP and JUMPI jump opcodes therein to form a control flow graph CFG;

[0139] 3-2-5. Go to step 3-2-1 and continue to traverse the static operation code sequence SCode until the traversal ends;

[0140] 3-2-6. Then traverse the opcode blocks in the control flow graph CFG, and use the rules of function calls at the opcode level: the previous opcode is ISZERO, the current opcode is CALL, and use the CALL opcode PC value to locate the contract source code statement contract through the mapping relationship diagram SRCMap between opcodes and source codes, and filter and obtain cross-contract function call statements based on whether the function call statement has ".";

[0141] 3-2-7. Use regular expression matching to find the function name where the cross-contract function call statement contract is located;

[0142] 3-2-8. Traverse the opcodes in the opcode blocks in the control flow graph CFG, combined with the function mapping Hash generated in the preprocessing stage. If the opcode is PUSH, and the value after the PUSH opcode is a function hash value in the function mapping Hash, then the last opcode of the opcode block where the PUSH opcode is located must be a JUMPI opcode. As described in step 3-2-3, the condition is established, and its jump address is the address introduced by the previous PUSH opcode, that is, the function entry address Fun_add corresponding to the function name;

[0143] 3-2-9. Then, according to the function where the function call statement contract is located and the calling function, the entry address Fun_add generated in step 3-2-8 is used to obtain the entry addresses pc1 and pc2 corresponding to the two function names;

[0144] 3-2-10. Connect the control flow graph CFG generated from steps 3-2-1 to 3-2-5 using the two function entry addresses pc1 and pc2 obtained in step 3-2-2 to generate a static cross-contract control flow graph;

[0145] The pseudo code for constructing the cross-contract control flow graph xCFG is as follows:

[0146]

[0147] 3-2-11. Use the running opcode sequence RCode obtained in the fuzz testing phase to construct a dynamic cross-contract control flow graph as in steps 3-2-1 to 3-2-5;

[0148] 3-2-12. Then, the static cross-contract control flow graph and the dynamic cross-contract control flow graph are overlapped and calculated. Specifically, the dynamic cross-contract control flow graph operation code block generated in step 3-2-11 and the static cross-contract control flow graph operation code block generated in steps 3-2-1 to 3-2-5 are traversed. The operation code block block that overlaps between the two is marked on the static cross-contract control flow graph, leaving the marked static control flow graph. The marked static control flow graph part is the part that is actually needed;

[0149] 3-2-13. Go to step 3-2-11 and repeat steps 3-2-11 to 3-2-12 to improve this static control flow graph until the detection is completed to obtain the final accurate and true dynamic cross-contract control flow graph.

[0150] The pseudo code for constructing a dynamic cross-contract control flow graph xCFG is as follows:

[0151]

[0152] 4. Vulnerability detection stage, such as Figure 6 As shown, the specific steps include:

[0153] 4-1. Vulnerability rules: Vulnerability rules are described in the form of ConFuzzius tool vulnerability oracle. ConFuzzius tool is used to write all the oracles to detect vulnerabilities.

[0154] 4-2. Vulnerability rule matching: traverse the operation code sequence RCode obtained in step 2-2 and enter the vulnerability rule oracle in step 4-1 for matching and analysis;

[0155] 4-3. Vulnerability report: If it matches with the vulnerability oracle, then further determine whether the suspected cross-contract vulnerability call chain FunCC is obtained during the fuzz testing phase, that is, the value of the cross-contract vulnerability identifier 1x of the transaction is 1 to determine whether the obtained operation opcode sequence RCode is a cross-contract operation opcode sequence. If it is a single-contract vulnerability, then output the vulnerability type, the program counter PC where the vulnerability occurs, the source code statement, line number, and function call information. If it is a cross-contract vulnerability, then it is also necessary to output the cross-contract vulnerability call chain FunCC. If it does not match with the vulnerability oracle, it will execute normally and no vulnerability will be reported.

[0156] In summary, the present invention is based on a cross-contract vulnerability detection method based on running operation codes, which eliminates contract attributes and turns them into function parameters, and adds the parameters to the function that has a read-write relationship with the contract attributes to solve the problem of missed vulnerability detection in dynamic execution; the running operation code is used to construct a control flow graph CFG for each contract, and the cross-contract function call statement is further combined to construct a cross-contract control flow graph xCFG, so that each edge of the constructed xCFG is truly reachable, which solves the problem of false positive vulnerability detection in static analysis methods, thereby improving the accuracy of detecting cross-contract vulnerabilities in smart contracts.

[0157] Example:

[0158] In order to verify the effectiveness of the method of the present invention, three groups of experiments were conducted. The first group of experiments were: the most advanced static vulnerability detection framework for smart contracts Slither, the most advanced dynamic vulnerability detection framework for smart contracts ConFuzzius, and my tool cFuzz, which was improved based on the ConFuzzius framework, to compare the three tools in terms of smart contract vulnerability detection capabilities; the second group of experiments was to verify the effectiveness of contract attribute parameterization. On the cFuzz tool, the accuracy and recall of vulnerability detection in the same vulnerability data set were evaluated based on the parameterization mechanism and the use of the parameterization mechanism; the third group of experiments was to verify the effectiveness of building dynamic xCFG. On the cFuzz tool, the accuracy and recall of vulnerability detection in the same vulnerability data set were evaluated based on the static xCFG and dynamic xCFG. The final experimental data results are shown in the following table:

[0159]

[0160] Note: / *P / R, where P represents the precision (Precision: the accuracy of predicting the correct positive samples (TP)), which is calculated as TP / (TP+FP), R represents the recall (Recall: the coverage of the predicted correct positive samples), which is calculated as TP / (TP+FN), FP represents the number of false positive negative samples, FN represents the number of false negative positive samples, - represents that the tool does not support this type of vulnerability detection, cFuzz-Slither and cFuzz-ConFuzzius represent the difference between the precision and recall of the two tools on the corresponding vulnerability types* /

[0161] Vulnerability Type Reentrancy Vulnerability Integer Overflow Assertion failure Block Dependencies Unprotected self-destruct <![CDATA[ nP ]]> 92.00％ 99.10％ 92.30％ 92.30％ 100％ <![CDATA[ nR ]]> 63.60％ 71.30％ 66.70％ 70.60％ 72.70％ <![CDATA[ uP ]]> 94.60％ 99.30％ 94.10％ 93.30％ 100％ <![CDATA[ oeLh ]]> 92.30％ 90.00％ 88.90％ 82.40％ 90.90％ <![CDATA[ uP-n P]]> +2.60％ +0.2％ +1.8％ +1.0％ 0.0％ <![CDATA[ uR ]]> +28.7％ +18.7％ +22.2％ +11.8％ +18.2％

[0162] Note: / *nP represents the accuracy without using parameterized mechanism, nR represents the recall without using parameterized mechanism, uP represents the accuracy with parameterized mechanism, uR represents the recall with parameterized mechanism, uP-nP represents the accuracy difference between using parameterized mechanism and not using parameterized mechanism, uR-nR represents the recall difference between using parameterized mechanism and not using parameterized mechanism* /

[0163] Vulnerability Type Reentrancy Vulnerability Integer Overflow Assertion failure Block Dependencies Unprotected self-destruct <![CDATA[ sP ]]> 75.00％ 78.60％ 64.70％ 66.70％ 80.00％ <![CDATA[ sR ]]> 90.50％ 87.70％ 84.60％ 76.90％ 88.90％ <![CDATA[ dP ]]> 94.60％ 99.30％ 94.10％ 93.30％ 100％ <![CDATA[ dR ]]> 92.30％ 90.00％ 88.90％ 82.40％ 90.90％ <![CDATA[ dP-sP ]]> +19.6％ +20.7％ +29.4％ +26.6％ +20.0％ <![CDATA[ dR ]]> +1.8％ +2.3％ +4.3％ +5.5％ +2.0％

[0164] Note: / *sP represents the accuracy without using the dynamic xCFG mechanism, sR represents the recall without using the dynamic xCFG mechanism, dP represents the accuracy with the dynamic xCFG mechanism, dR represents the recall with the dynamic xCFG mechanism, dP-sP represents the accuracy difference between using the dynamic xCFG mechanism and not using the dynamic xCFG mechanism, dR-sR represents the recall difference between using the dynamic xCFG mechanism and not using the dynamic xCFG mechanism* /

[0165] It can be seen from the experimental data that although there are some differences in the effects due to the characteristics of different tools, in general, after using the method of the present invention, compared with the advanced smart contract static vulnerability detection framework Slither and the most advanced smart contract dynamic vulnerability detection framework ConFuzzius, the overall effect is improved. Therefore, the method of the present invention can effectively solve the false positive problem of the static tool Slither and the false negative problem of the dynamic execution tool ConFuzzius, and improve the accuracy of detecting cross-contract vulnerabilities in smart contracts.

[0166] The embodiments of the present invention are described in detail above in conjunction with the accompanying drawings. All equivalent changes and modifications made within the scope of the invention application of the present invention belong to the scope of protection of the present invention.

Claims

1. Cross - contract vulnerability detection method based on running opcodes, characterized in that it includes a pre - processing stage, a fuzzing testing stage, a dynamic process stage, and a vulnerability detection stage: Pre - processing stage: Pre - process the smart contract source code file to obtain contract static bytecode, abstract syntax tree, application binary interface, and data information of test cases; Fuzzing testing stage: Use the cross - contract control flow graph generated by the dynamic cross - contract control flow graph construction module for the test cases generated in the pre - processing stage to obtain a suspicious cross - contract function call chain, which is used to guide the execution of py - EVM to obtain the running opcode sequence, and mutate the contract attribute parameters in the corresponding test cases using the value range of the contract attributes obtained by the contract attribute parameterization module; Dynamic process stage: It includes the construction of a dynamic cross - contract control flow graph and the process of contract attribute parameterization; Construction of the dynamic cross - contract control flow graph: Respectively construct static and dynamic cross - contract control flow graphs through the running opcodes generated in the fuzzing testing stage and the static opcodes obtained in the pre - processing stage, and continuously perform overlapping calculations and updates to obtain the final dynamic cross - contract control flow graph; Process of contract attribute parameterization: Regularly match and analyze the source code statements for modifying contract attributes to obtain the step size, and then combine with the set of contract attributes obtained in the pre - processing stage to finally generate new contracts and the value range of contract attribute mutations; Vulnerability detection stage: Detect vulnerabilities in the running opcode sequence generated in the fuzzing testing stage and generate a vulnerability report.

2. The cross - contract vulnerability detection method based on running opcodes according to claim 1, characterized in that the pre - processing stage includes the following steps: 1 - 1. Take the smart contract source code file as input, and use the smart contract compilation tool py - solc - x to compile the contract source code file to obtain contract static bytecode SCByte, abstract syntax tree SCAST, and application binary interface 1 - 2. Input contract static bytecode SCByte and source code file SCCode, and use the open - source tool ConFuzzius to obtain the mapping relationship graph between opcodes and source code; 1 - 3. Input contract static bytecode SCByte, and use the ConFuzzius tool to generate test cases TCase; 1 - 4. Input abstract syntax tree SCAST, and use the depth - first search algorithm DFS to search the abstract syntax tree to obtain the contract attribute information set 1 - 5. Input application binary interface SCABI, and use the ConFuzzius tool to generate the correspondence between function names in the contract and their corresponding function hash values, which is defined as function mapping.

3. The cross - contract vulnerability detection method based on running opcodes according to claim 1, characterized in that the fuzzing testing stage includes the following steps: 2 - 1. The first - round smart contract fuzzing testing is as follows: 2 - 1 - 1. Obtain the running opcode sequence of the contract Initialize the suspicious cross - contract function call chain FunCC = null. Use the test case TCase obtained in the pre - processing stage as input and directly execute the test case TCase using the py - EVM tool to obtain the running opcode sequence RCode; 2 - 1 - 2. Fuzzing mutation to generate new test cases Use the ConFuzzius fuzz testing genetic mutation algorithm on the test case TCase to generate a new test case N - TCase; If the function parameters of the test case N - TCase are in the contract attribute information set SCA, use the value range of the contract attributes generated by contract attribute parameterization to perform random mutation with value range limitation on the function parameters corresponding to the contract attributes; If the function parameters of the test case N - TCase are not in the contract attribute information set SCA, perform random mutation according to the value range of the corresponding type of the function parameters; Return to step 2 - 1 - 1 and loop G times; 2 - 2. The N - th round of smart contract fuzz testing is as follows: 2 - 2 - 1. Obtain the suspicious cross - contract function call chain; Use the cross - contract control flow graph xCFG as input and traverse all nodes of the xCFG graph. The specific processing method is as follows: Define each node in the xCFG graph as an opcode block. Use the opcodes that may trigger vulnerabilities to perform opcode matching on the opcodes included in the opcode block. The opcodes that may trigger vulnerabilities are set according to the vulnerability characteristics. If the opcode matches, according to the starting address of the opcode block where the opcode is located in the xCFG graph, construct a suspicious cross - contract vulnerability path in reverse order from back to front to obtain the suspicious cross - contract function call chain; 2 - 2 - 2. Obtain the running opcode sequence of the contract Use the test case TCase obtained in the pre - processing stage as input. Use the suspicious cross - contract function call chain FunCC to sequentially guide the py - EVM tool to execute the corresponding functions of the contracts corresponding to the suspicious cross - contract function call chain FunCC to obtain the running opcode sequence RCode; otherwise, directly use the py - EVM tool to execute the test case TCase to obtain the running opcode sequence RCode; 2 - 2 - 3. Fuzzing mutation to generate new test cases.

4. The cross - contract vulnerability detection method based on running opcodes as described in claim 1, characterized in that the dynamic process stage includes the following steps: 3 - 1. Contract attribute parameterization: Use the mapping relationship graph between the contract attribute information, opcodes, and source code obtained in the pre - processing stage and the running opcode sequence obtained in the fuzz testing stage as input. First, traverse the running opcodes obtained in the fuzz testing stage to match with some characteristic opcodes that may trigger vulnerabilities. If there is a match, then combine the mapping relationship graph between the opcode and the source code to locate the source code statement. If there are contract attributes, further obtain the contract attribute change step size through static analysis. Combining the contract attribute information set obtained in the pre - processing stage, the parameterization result can be obtained, including generating a new contract and the value range of the corresponding contract attributes; among them, the new contract is handed over to the pre - processing stage, and the value range is handed over to the fuzz testing genetic mutation; 3-2. Construct the dynamic cross-contract control flow graph xCFG: Take the static bytecode obtained in the preprocessing stage and the running opcodes obtained in the fuzzing stage as inputs. First, decompile the static bytecode obtained in the preprocessing stage into a sequence of static opcodes, and use these opcodes to construct the control flow graph CFG for each contract. Then, combine the cross-contract function call statements to connect the CFGs of each contract to form a static cross-contract control flow graph. Secondly, use the sequence of running opcodes obtained in the fuzzing stage and the cross-contract function call statements to construct a dynamic cross-contract control flow graph in the same way as constructing the static one. Then, calculate the static cross-contract control flow graph and the dynamic cross-contract control flow graph, and leave the part of the static cross-contract control flow graph that coincides with the dynamic cross-contract control flow graph. Finally, repeat the construction of the dynamic cross-contract control flow graph according to the different running opcodes obtained in each fuzzing test, and keep calculating; finally, obtain a real and accurate cross-contract control flow graph xCFG.

5. The cross-contract vulnerability detection method based on running opcodes according to claim 1, characterized in that the vulnerability detection stage specifically includes the following steps: 4-1. Vulnerability rules: The vulnerability rules are described in the form of the vulnerability oracle of the ConFuzzius tool, and write the oracles for all vulnerabilities to be detected using the ConFuzzius tool; 4-2. Vulnerability rule matching: Input the sequence of running opcodes RCode obtained in the fuzzing stage into the vulnerability rule oracle for matching and analysis; 4-3. Vulnerability report: If it matches the vulnerability oracle, then judge whether the obtained sequence of running opcodes is a cross-contract sequence of running opcodes according to whether a suspicious cross-contract function call chain is obtained in the fuzzing stage; if it is a single-contract vulnerability, output the vulnerability type, the program counter where the vulnerability occurs, the source code statement and line number, and the function call information; if it is a cross-contract vulnerability, it is also necessary to output the cross-contract function call chain; if it does not match the vulnerability oracle, execute normally without reporting a vulnerability.

6. The cross-contract vulnerability detection method based on running opcodes according to claim 4, characterized in that the specific process of step 3-1 in the dynamic process stage is as follows: 3-1-1. Traverse the sequence of running opcodes obtained in the fuzzing stage, and match each opcode in the set of arithmetic opcodes one by one. If the match is successful: 3-1-1-1. Locate the corresponding code statement in the contract source code for the matched arithmetic opcode through the opcode-source code mapping relationship graph; 3-1-1-2. Perform regular matching on this code statement according to the equal sign, and extract the variable on the left side of the equal sign; 3-1-1-3. If the variable is in the contract attribute information set, it means that the variable is a contract attribute, then add this variable to the function parameters for reading and writing this attribute, generate a new function, and finally generate a new contract; 3-1-1-4. Use regular matching to obtain the variables and constants on both sides of the equal sign from the code statements in step 3-1-1-1. Combine with the operation opcode matched in step 3-1-1-2. If there is only a contract attribute among the variables, the step size of the change in this contract attribute is the value of this constant; otherwise, the step size of the change in this contract attribute is the value of the change in the range of this contract attribute type, that is, 1 or -1; 3-1-1-5. Combine the step size obtained in step 3-1-1-4 with the contract attribute information obtained in the preprocessing stage to generate the value range of this contract attribute. This value range serves the genetic mutation stage of fuzz testing; 3-1-2. Return to step 3-1-1, and perform the matching of the next opcode in the operation opcode set until the processing of the opcodes in the operation opcode set is completed; 3-1-3. Re-execute the preprocessing stage.

7. The cross-contract vulnerability detection method based on running opcodes as described in claim 4, characterized in that the specific process of step 3-2 in the dynamic process stage is as follows: 3-2-1. Generate a contract static opcode sequence: Decompile the static bytecode obtained in the preprocessing stage to generate a static opcode sequence, and traverse this static opcode sequence; 3-2-2. Construct a contract opcode block set, and each contract has an opcode block set Blocks; Initialize the opcode block block, and add the static opcodes obtained by traversing the static opcode sequence to this opcode block block; If the static opcode obtained by traversing is the JUMP opcode, its jump address is the address introduced by the previous PUSH opcode; If the static opcode obtained by traversing is the JUMPI opcode, its jump address is the next program counter PC position or the address introduced by the previous PUSH opcode; If the static opcode obtained by traversing is the termination opcode, end the construction of the opcode block block; 3-2-3. Construct a contract control flow graph Connect the opcode block set Blocks constructed in step 3-2-2 through the jump addresses of the JUMP and JUMPI jump opcodes among them to construct a control flow graph CFG; 3-2-4. Go to step 3-2-1, and continue to traverse the static opcode sequence SCode until the traversal is completed; 3-2-6. Traverse the opcode blocks in the control flow graph CFG. According to the rule that the previous opcode is ISZERO and the current opcode is CALL, use the PC value of the CALL opcode to locate the contract source code statement through the mapping relationship graph between the opcode and the source code to obtain the cross-contract function call statement; 3-2-5. Traverse all the opcode blocks blocks in the control flow graph CFG. According to the rule that the previous opcode is ISZERO and the current opcode is CALL, use the PC value of the CALL opcode to locate the contract source code statement through the mapping relationship graph to obtain the cross-contract function call statement; 3-2-6. Use regular matching on this cross-contract function call statement contract to find the function name where this call statement is located; 3-2-7. Traverse the opcodes in all opcode blocks in the control flow graph CFG. Combine with the function mapping Hash in the preprocessing stage. If the opcode is PUSH and the value following the PUSH opcode is the hash value of a certain function in the function mapping Hash, then the last opcode in the opcode block where the PUSH opcode is located must be the JUMPI opcode. As described in step 3-2-2, if the condition holds, its jump address is the address introduced by the previous PUSH opcode, that is, the function entry address corresponding to the function name. 3-2-8. According to the functions of the contract where the function call statement contract is located and the called contract function, obtain the entry addresses pc1 and pc2 corresponding to the two function names through the function entry address Fun_add generated in step 3-2-7. 3-2-9. Connect the control flow graph CFG generated in steps 3-2-1 to 3-2-4 using the two function entry addresses pc1 and pc2 obtained in step 3-2-8 to generate a static cross-contract control flow graph. 3-2-10. Based on the running opcode sequence RCode obtained in the fuzz testing stage, construct a dynamic cross-contract control flow graph in the same way as in steps 3-2-1 to 3-2-4. 3-2-11. Perform an overlapping calculation on the static cross-contract control flow graph and the dynamic cross-contract control flow graph. Specifically, traverse the opcode blocks of the dynamic cross-contract control flow graph generated in step 3-2-10 and the opcode blocks of the static cross-contract control flow graph generated in steps 3-2-1 to 3-2-4. Mark the overlapping opcode blocks block on the static cross-contract control flow graph to leave the marked static control flow graph. The marked part of the static control flow graph is the actual required part. 3-2-12. Go to step 3-2-10 and continuously repeat steps 3-2-10 to 3-2-11 to improve this static control flow graph until the detection ends to obtain the final accurate and real dynamic cross-contract control flow graph.

8. A cross-contract vulnerability detection system based on running opcodes Characterized in that It includes a preprocessing module, a fuzz testing module, a dynamic process module, and a vulnerability detection module; Preprocessing module: Obtain the basic data required by the subsequent modules, including contract static bytecode, contract attribute information, test cases, function mapping Hash, opcode source code mapping diagram; Compile the contract source code with the help of the intelligent contract compilation tool py-solc-x to obtain the contract static bytecode SCByte, abstract syntax tree SCAST, and application binary interface ABI. Generate test cases TCase, opcode source code mapping diagram SRCMap, and function mapping Hash with the help of the open-source fuzz testing tool ConFuzzius. Search the abstract syntax tree through the depth-first search algorithm DFS to obtain the contract attribute information set SCA. Fuzz testing module: Used for the execution and mutation of test cases. The test case TCase generated in the input preprocessing stage. For the execution of the test case TCase, the suspicious cross-contract function call chain FunCC is obtained from the xCFG generated in the stage of constructing the dynamic cross-contract control flow graph in the dynamic process module to guide the py-EVM tool to execute the corresponding test case TCase, and the running opcode sequence RCode is obtained. If there is no xCFG or FunCC, it degrades to single-contract vulnerability detection; for the mutation of the test case TCase, if the function parameter of the test case TCase contains a contract attribute, the corresponding contract attribute value range generated in the contract attribute parameterization stage in the dynamic process module is used to mutate the contract attribute. If not, it is completely random. Dynamic process module: It includes two parallel stages, namely contract attribute parameterization and construction of the dynamic cross-contract control flow graph. For the contract attribute parameterization stage, the running opcode sequence RCode generated during the fuzz testing stage is traversed and matched with the arithmetic-related opcodes. The matched opcodes are used to obtain the contract source code statements using the mapping relationship graph SRCMap between the opcodes and the source code. If the statement modifies a contract attribute, the attribute is added to the function parameters that read and write the attribute to generate a new contract N-SCCode, and regular matching and static analysis are performed on the statement to obtain the value range of the attribute, which places certain restrictions on the mutation of the contract attribute parameter in the function later; for the construction of the dynamic cross-contract control flow graph, first, the contract static bytecode SCByte obtained in the preprocessing stage is decompiled into a static opcode sequence, and the control flow graph CFG of each contract is generated by traversing the static opcode sequence. Secondly, the static cross-contract control flow graph xCFG is generated by connecting the control flow graphs CFG through cross-contract function call statements. Then, the running opcode sequence RCode obtained in the fuzz testing stage is used to generate the dynamic cross-contract control flow graph in the same way. Finally, the two cross-contract control flow graphs are calculated, and the overlapping part is left; the dynamic cross-contract control flow graph is continuously repeated and improved. Vulnerability detection module: It is used for the detection and reporting of contract vulnerabilities; different vulnerability rule detectors are generated according to the characteristics of different vulnerability types. The running opcode sequence RCode obtained in the fuzz testing stage is traversed and used as input to enter the vulnerability rule detector for judgment. If it conforms to one of the vulnerability rules, the execution information of the test case and the vulnerability information are returned. If it is a cross-contract vulnerability, the suspicious cross-contract function call chain FunCC also needs to be output.

Images