A method and system for detecting vulnerabilities in smart contracts based on meta-operations

Abstract

The application discloses a kind of smart contract vulnerability detection method and system based on meta operation.First, smart contract is converted into intermediate representation, and the basic matching operation on the intermediate representation is defined as meta operation, as the basic detection logic unit of contract code vulnerability detection;Second, the detection rule of contract vulnerability is expressed as the logical operation expression of a group of meta operation, and the vulnerability detection script file is formed.The detection code of all meta operations is implemented in the contract vulnerability detection system, and the analysis execution code of contract vulnerability detection rule;Finally, the system judges whether the smart contract to be measured exists certain vulnerability characteristics by parsing vulnerability detection script file and executing matching operation.The application is suitable for the detection of different versions of smart contract vulnerability, and the reuse of meta operation reduces a lot of repeated vulnerability detection code writing work, and improves the scalability of contract vulnerability detection tool.

Description

Technical Field

[0001] This invention belongs to the field of smart contract security detection technology, specifically relating to a smart contract vulnerability detection method and system based on meta-operations. Background Technology

[0002] Smart contracts are Turing-complete programs that execute on blockchain infrastructure. Unlike traditional programs, once deployed, smart contracts cannot be patched for any vulnerabilities they expose. Static code analysis of smart contracts, as a method of vulnerability detection, has advantages such as fast detection speed and no need for actual code execution.

[0003] The following are open-source frameworks, patents, and papers related to smart contract vulnerability detection based on static analysis:

[0004] SmartCheck employs a vulnerability signature matching method for vulnerability detection. It converts the source code file of the smart contract under test into an XML intermediate representation through lexical and syntactic analysis. For each type of contract vulnerability, corresponding vulnerability scanning code is written, and vulnerability signatures are scanned and matched on the intermediate code representation to complete the contract vulnerability detection. Slither's detection method is similar to SmartCheck, except that Slither converts the source code file of the smart contract under test into a SlitherIR intermediate representation through lexical and syntactic analysis, and then performs vulnerability signature scanning and matching on the SlitherIR intermediate representation.

[0005] However, the aforementioned contract vulnerability detection and analysis tools embed vulnerability detection rules into the vulnerability detection code within their code implementation framework. For new vulnerabilities, corresponding vulnerability detection code needs to be written and added to the existing version of the vulnerability detection and analysis tool. The vulnerability detection rules are tightly coupled with the detection tool code, resulting in problems such as complex vulnerability detection tool code design and poor scalability, making it difficult to adapt to the trend of rapidly increasing contract vulnerabilities.

[0006] CN109492402A proposes a rule-based smart contract security evaluation method. This method converts smart contracts into contract syntax trees using a parser. For each type of contract vulnerability, corresponding vulnerability scanning code blocks are written and added to the vulnerability rule base as vulnerability rules. The vulnerability rule engine executes the vulnerability rule code and traverses the contract syntax tree to detect contract vulnerabilities. Unlike SmartCheck and SlitherIR, this method separates the vulnerability rule engine code from the vulnerability rule code, but still requires writing vulnerability detection code blocks for each type of vulnerability. This method suffers from the following problems: writing detection code corresponding to the vulnerability features of new contract vulnerabilities requires specialized contract language programming skills; furthermore, the vulnerability rule code contains a lot of repetitive feature matching operations. Writing corresponding vulnerability rule code for each vulnerability leads to a lot of repetitive coding work, which is costly and error-prone, affecting the maintainability and scalability of the detection tool.

[0007] In summary, to address the aforementioned issues, this invention proposes a smart contract vulnerability analysis and detection method based on meta-operations. It adopts a design philosophy that separates vulnerability detection rules from detection code. Basic matching operations for vulnerability features are defined as meta-operations, and vulnerability detection rules are described as logical expressions of a set of meta-operations. All types of vulnerability detection rules constitute the system vulnerability detection script file. The detection engine parses and executes the vulnerability detection rules to achieve contract vulnerability detection. This method achieves the reuse of meta-operations (basic feature matching operation code), separation of vulnerability detection rules from detection engine code, and improves the scalability and maintainability of the vulnerability detection tool. Summary of the Invention

[0008] To address the shortcomings of the aforementioned smart contract vulnerability detection methods, this invention proposes a smart contract vulnerability detection method and system based on meta-operations. First, the smart contract is converted into an intermediate representation, and the basic matching operations on this intermediate representation are defined as meta-operations, serving as the basic logical units for detecting contract code vulnerabilities. The detection rules for each type of contract vulnerability are represented as a set of logical expressions of meta-operations, forming a vulnerability detection script file. The system implements the detection code for all meta-operations and the parsing and execution code for the contract vulnerability detection rules. By parsing and executing the contract vulnerability detection rule script file, the system determines whether the smart contract under test possesses a certain vulnerability characteristic.

[0009] This invention proposes a smart contract vulnerability detection method based on meta-operations, comprising: a rule description stage, a rule parsing stage, and a rule execution stage;

[0010] A metaoperation is defined as an abstract function representation, which includes the metaoperation name, variable type, and variable name;

[0011] Define logical operators to describe the logical relationships between metaoperations;

[0012] Define vulnerability detection rules, which represent a form of vulnerability detection rule description;

[0013] Define a vulnerability detection script file, which represents a set of contract vulnerabilities to be detected;

[0014] Define a detection code unit as a code segment representing the specific detection logic of a meta-operation;

[0015] During the rule description phase, vulnerability detection script files are generated by using meta-operations and logical operators defined in the system. When using meta-operations to describe vulnerability detection, the corresponding type values ​​are passed in according to the input parameter types in the abstract function form.

[0016] In the intermediate representation (IR), the vulnerability characteristics of smart contract vulnerabilities are represented by vulnerability detection rules.

[0017] The vulnerability detection rules are listed sequentially in the script file;

[0018] The rule parsing phase includes:

[0019] By sequentially traversing the vulnerability detection rules in the vulnerability detection script file;

[0020] Analyze all meta-operations and input parameter values ​​in each vulnerability detection rule;

[0021] The system parses all logical operators in the vulnerability detection rules, adds the parsed code detection units to the priority queue according to the priority of the operators, and saves the logical operators that exist between the meta-operations.

[0022] The rule execution phase includes:

[0023] Iterate through the code detection units in the priority queue, execute the code detection units and perform path matching on the intermediate representation IR. If a corresponding detection path exists, return True; otherwise, return False.

[0024] And update the currently matched IR paths to the IRs to be matched;

[0025] The results of all code detection units in the priority queue are combined with the corresponding logical operators to form a logical operation expression;

[0026] The presence of specific vulnerabilities in the current smart contract is described by calculating the return value of the logical operation expression as True or False.

[0027] The following defines a vulnerability detection script specification for writing descriptive script files for smart contract vulnerabilities.

[0028] 1.1 Basic Specifications

[0029] 1.1.1 Yuan Operation

[0030] Meta-operations are the basic detection operation keywords in vulnerability detection description scripts, represented as abstract functions, and their formal description is as follows:

[0031] Meta_name(type name1,...,type name i ,...,type name k )

[0032] This function contains three elements: the meta-operation name "Meta_name", the input parameter variable type "type", and the input parameter variable name "name". i The function name can be a comma (""), where the subscript i ≥ 1. Metaoperation names can consist of numbers, letters, and underscores, with the first character being a capital letter. Multiple variables are allowed in the function representation, separated by commas.

[0033] The `meta.op` file contains the source code for meta-operations; all meta-operations supported by the system are described in the `meta.op` file. For example:

[0034] Use(String branch)

[0035] Verison(Int min, Int max)

[0036] ...

[0037] Where "Use" is the meta-operation name, "String" is the variable type, and "branch" is the variable name. Extensions to the meta-operations can be made by modifying the "meta.op" file.

[0038] 1.1.2 Variable Types and Variable Names

[0039] The variable type describes the type of the input parameters supported by the meta-operation. Some examples of the types are shown in Table 1.

[0040] Variable type describe Int Integer numeric type List List type, collection of parameters String String type Boolean Boolean type, only supports 'True / False'

[0041] Table 1

[0042] Variable names are placeholders used to name the input parameters supported by meta-operations. Variable names consist of letters and numbers and cannot be the same as meta-operation names. For example, in "Use(String branch)", "branch" is the variable name.

[0043] 1.1.3 value

[0044] When using meta-operations to describe vulnerability detection, the corresponding type value should be passed according to the input parameter type in its abstract function form. For example, numeric input parameters should be passed values ​​such as 0, 1, -2, etc.

[0045] 1.1.4 Logical Operators

[0046] Define the logical relationships between meta-operations to represent vulnerability detection rules, as shown in Table 2.

[0047] Operators describe && This indicates that the relationship between meta-operations is a parallel relationship. || The relationship between metaoperations is represented as an OR relation. ！ This indicates that the feature represented by the current meta-operation should not appear. () Prioritize

[0048] Table 2

[0049] 1.2 Description of Vulnerability Detection Rules

[0050] The vulnerability characteristics of smart contract vulnerabilities, as presented in the intermediate representation, can be represented using vulnerability detection rules. A vulnerability detection rule is described as a set of logical expressions of meta-operations, consisting of two parts: the meta-operation and its corresponding input parameter value; and the logical operator. It is described as follows:

[0051] Meta_x(a,b,...)ΩMeta_y(c,d,...)Ω...;

[0052] Meta_x and Meta_y are the names of the meta-operations; a, b, c, and d are the input parameters of the meta-operations; the symbol "Ω" is a logical operator; and the symbol ";" indicates the end of a vulnerability detection rule description.

[0053] 1.3 Description of Vulnerability Detection Script Files

[0054] The vulnerability detection script file is a collection of all vulnerability detection rules of the contract vulnerability detection system.

[0055] The vulnerability detection rules are listed sequentially in the script file. n rules in the script file represent n types of vulnerabilities to be detected. The vulnerability detection script file ends with ".meta".

[0056] 1.4 Mapping relationship between meta-operations and detection code units

[0057] Each meta-operation is mapped to a detection code unit in the vulnerability detection program. This mapping is stored in the "meta.op" file and represented by references between meta-operations and code units. This code unit is used for actual execution. The value in the meta-operation serves as the input parameter for this code unit. The return value of the code unit is a boolean value of True or False, representing whether a vulnerability feature has been detected.

[0058] 2. Vulnerability detection and processing method of the present invention

[0059] 2.1 Smart Contract Vulnerability Detection Logic

[0060] 2.1.1 Contract Conversion

[0061] In this invention, the contract source file is used as input to the program. During the contract conversion stage, it is transformed into an intermediate representation (IR tree structure, or "IR" for short), with each node distinguished by a Node. Subsequent scanning and matching are performed based on this IR.

[0062] 2.1.2 Meta-operation detection code unit

[0063] Metaoperations are mapped to code units in a program, and the formal function representation of a code unit is as follows:

[0064] Boolean Function(type name1,...,type name i ,...,type name k ){Body}

[0065] Where "Boolean" represents the return value of the code unit, which has two return values: True and False to represent the execution result of the code unit. "type" is the input parameter type defined in the meta-operation, "name"... i " is the variable name and the subscript i ≥ 1. "Body" represents the execution body of the code unit.

[0066] This code unit executes its internal logic to match whether a certain Node path exists on the IR. If a match is successful, it returns True and updates the IR tree structure to the current Node path. If a match fails, it returns False.

[0067] 2.1.3 Add detection code unit method

[0068] To enhance extensibility, detection code units can be added. First, a detection code unit is created by writing its logic and its reference is obtained; this reference is the path for the program to find the code unit. Then, the corresponding meta-operation is defined in the "meta.op" file, containing the meta-operation name, input parameter type, and input parameter name. Finally, adding detection code units is achieved by configuring the mapping between meta-operations and detection code unit references in the "meta.op" file.

[0069] 2.2 Execution Engine Implementation Logic

[0070] 2.2.1 Load the "meta.op" file

[0071] During this phase, the execution engine initializes by loading the "meta.op" file. It then locates the corresponding detection code unit using the reference paths in the file and establishes a mapping table in memory between meta-operations and that detection code unit.

[0072] 2.2.2 Vulnerability Detection Script Analysis

[0073] This phase uses the vulnerability detection script file written by the user in the first part as input, and obtains the meta-operations, meta-operation input parameter values ​​and logical operators in the script file through lexical analysis and syntax analysis.

[0074] The parsing process sequentially parses each vulnerability detection rule in the vulnerability detection script file.

[0075] 2.2.3 Meta-operation mapping and execution

[0076] First, the meta-operations obtained in 2.2.2 are mapped to detection code units by accessing the mapping table generated in 2.2.1, and the input parameter values ​​of the meta-operations obtained in 2.2.2 are used as the input parameters of the code units.

[0077] Secondly, the code unit mapped by the meta-operation is executed. During execution, this code unit performs a matching operation on the IR tree structure generated by the contract transformation in section 2.1.1 to determine whether the Node path contained in the execution logic of this code unit exists in the IR tree structure. It returns True or False and updates the IR tree structure.

[0078] Finally, after executing all the meta-operations defined in the vulnerability detection rules, the results of all meta-operations are logically combined and calculated, and information such as True or False and code snippet line number is returned to explain whether the current contract has the vulnerability defined by the vulnerability detection rules.

[0079] This invention also proposes a smart contract vulnerability detection system based on meta-operations, including: a contract conversion module: using the Slither tool to compile the smart contract source code, generating an intermediate representation (IR) through lexical analysis and syntax analysis, which serves as the object to be scanned in subsequent code execution;

[0080] Parsing module: Parses the mapping relationship of source code files into the mapping relationship between meta-operations in memory and specific detection code units. It parses vulnerability detection script files to obtain the meta-operations contained in each detection rule, the priority between meta-operations, and the logical relationship between each meta-operation.

[0081] Execution module: Based on the mapping relationship between the meta-operations parsed in the parsing module and the detection code units, it executes each meta-operation sequentially and records its return value; it combines all return values ​​through logical relationships and calculates the results to determine whether there are any vulnerabilities in the contract;

[0082] Extension Module: Used to register detection code units and reference the registered detection code units, implementing the append mapping relationship of the parsing module. Users can write detection code units, register them through the extender, and obtain a reference to the detection code unit. Then, users extend the meta-operations in "meta.op" and configure the mapping between the meta-operations and the detection code unit references to complete the extension of meta-operations.

[0083] The parsing module first parses the mapping relationship in the "meta.op" file into a mapping relationship between meta-operations in memory and specific detection code units. Then, it parses the vulnerability detection script file written by the user, and parses out the meta-operations contained in each detection rule, the priority between meta-operations, and the logical relationship between each meta-operation.

[0084] The application of the extension module includes: First, users can write detection code units, create a detection code unit by writing its logic, and obtain its reference. This reference is the path for the program to find the code unit. Then, the corresponding meta-operations are defined in the "meta.op" file, which includes the meta-operation name, input parameter type, and input parameter name. Finally, the mapping between meta-operations and detection code unit references is configured in the "meta.op" file to add detection code units.

[0085] This invention reduces the amount of repetitive vulnerability detection code writing work by reusing meta-operations, thereby improving the maintainability of the detection code. By separating vulnerability detection rules from the detection engine code, new vulnerabilities generally only require writing vulnerability rule description scripts, without modifying the detection engine code, which reduces the difficulty of writing new vulnerability rules and improves the scalability of the vulnerability detection tool. Attached Figure Description

[0086] Figure 1 This is a schematic diagram of the overall process of the smart contract vulnerability detection method based on meta-operations of the present invention;

[0087] Figure 2 This diagram illustrates the definition of meta-operations in the smart contract vulnerability detection method based on meta-operations of the present invention.

[0088] Figure 3 This is a description of the "meta.op" file in the smart contract vulnerability detection method based on meta-operations of this invention;

[0089] Figure 4 This is an example of vulnerability detection rules for the smart contract vulnerability detection method based on meta-operations of the present invention;

[0090] Figure 5 This is a flowchart of the execution engine of the smart contract vulnerability detection method based on meta-operations of the present invention;

[0091] Figure 6 This is a flowchart of the rule parsing stage of the smart contract vulnerability detection method based on meta-operations of the present invention. Detailed Implementation

[0092] The technical solution of the present invention will be further described in detail below through specific embodiments and in conjunction with the accompanying drawings.

[0093] Example 1

[0094] like Figures 1 to 6 The method for analyzing and detecting smart contract vulnerabilities based on meta-operations is shown. The overall steps are divided into two parts: vulnerability detection script description and vulnerability detection processing method.

[0095] 1. Description of the vulnerability detection script of this invention

[0096] Based on the vulnerability detection script specification defined in this invention, a description of smart contract vulnerabilities is written.

[0097] 1.1 Basic Specifications

[0098] 1.1.1 Yuan Operation

[0099] Meta-operations are keywords in vulnerability detection scripts, representing an abstract function. Their formal description is:

[0100] Meta_name(type name1,...,type name i ,...,type name k )

[0101] Specific explanations are as follows: Figure 2As shown, any meta-operation consists of three parts: the meta-operation name, the type of the input parameter variable, and the name of the input parameter variable. The meta-operation name is unique and cannot be repeated.

[0102] Preferably, the extension of meta-operations can be accomplished by modifying the "meta.op" file. The "meta.op" file is described as follows: Figure 3 As shown, it is divided into two parts. The first is the abstract function representation of the metaoperation; the second is the reference to the code unit that the current metaoperation maps to in the code. Therefore, the extension of metaoperations can be achieved by adding metaoperations and their code unit references.

[0103] Preferably, meta-operations can be named using numbers, letters, and underscores, with the first character being a letter and uppercase.

[0104] Preferably, the abstract function representation allows multiple variables to exist and are separated by commas.

[0105] 1.1.2 Variable Types and Variable Names

[0106] The variable type describes the type of the input parameters supported by the meta-operation. The variable name is a placeholder used to name the input parameters supported by the meta-operation. Variable names consist of letters and numbers and cannot be the same as the meta-operation name. Examples of some variable types and their descriptions are shown below:

[0107] Variable type describe Int Integer numeric type List List type, collection of parameters String String type Boolean Boolean type, only supports 'True / False'

[0108] 1.1.3 value

[0109] When using meta-operations to describe vulnerabilities, the corresponding type value should be passed according to the input parameter type in its abstract function form. For example, integer numeric type input parameters should be passed numbers such as 0, 1, -2, etc.

[0110] 1.1.4 Logical Operators

[0111] To define the logical relationships between metaoperations, logical operators are used to describe these relationships. Some examples are as follows:

[0112] Operators describe && This indicates that the relationship between meta-operations is a parallel relationship. || The relationship between metaoperations is represented as an OR relation. ！ This indicates that the feature represented by the current meta-operation should not appear. () Prioritize

[0113] 1.2 Description of Vulnerability Detection Rules

[0114] Each vulnerability in a smart contract is represented by a vulnerability detection rule. A vulnerability detection rule is a logical expression consisting of two parts: a meta-operation and its input parameters, and a logical operator. Formalized as:

[0115] Meta_x(a,b,...)ΩMeta_y(c,d,...)Ω...;

[0116] In this context, Meta_x and Meta_y represent the meta-operation names; a, b, c, and d represent the input parameters of the meta-operations; the symbol "Ω" represents a logical operator; and the symbol ";" represents the end of the vulnerability detection rule. A specific example is shown below. Figure 4 As shown, this vulnerability detection rule is used to scan for the statement "block.timestamp" in "if" or "require" branches.

[0117] Preferably, this form of expression is one implementation method and does not represent a limitation of the present invention.

[0118] 1.3 Description of Vulnerability Detection Script Files

[0119] A vulnerability detection script file is a collection of vulnerability detection rules, listed sequentially. n rules in a script file represent n different vulnerabilities to be detected. Vulnerability detection script files have the ".meta" extension.

[0120] The filename of the vulnerability detection script is a form of representation and is not limited to the ".meta" suffix.

[0121] 1.4 Yuan Operation Detection Code Unit

[0122] Each meta-operation maps to a code unit in the program, which is used for specific execution. The value in the meta-operation serves as the input parameter for that code unit. The code unit returns a boolean value of True or False, representing whether the vulnerability signature has been hit.

[0123] 2. Vulnerability detection and processing method of the present invention

[0124] like Figure 1 As shown, the smart contract vulnerability detection method and system based on meta-operations mainly consists of two parts: the conversion of contract files and the parsing and execution of vulnerability detection script files.

[0125] 2.1 Smart Contract Vulnerability Detection Logic

[0126] 2.1.1 Contract Conversion

[0127] In this invention, the contract source file is used as input to the program. During the contract conversion stage, it is transformed into an intermediate representation (IR tree structure), with each node distinguished by its Node component. Subsequent scanning and matching are then performed based on this IR.

[0128] This invention is based on the Slither tool, and the intermediate representation adopts the Slither IR representation form in the Slither tool.

[0129] 2.1.2 Execution of the Meta-Operation Detection Code Unit

[0130] Metaoperations are mapped to code units in a program, and the formal function representation of a code unit is as follows:

[0131] Boolean Function(type name1,...,type name i ,...,type name k ){Body}

[0132] Where "Boolean" represents the return value of the code unit, which has two return values: True and False to represent the execution result of the code unit. "type" is the input parameter type defined in the meta-operation, "name"... i " is the variable name and the subscript i ≥ 1. "Body" represents the execution body of the code unit.

[0133] This code unit executes its internal logic to match whether a certain Node path exists on the IR. If a match is successful, it returns True and updates the IR tree structure to the current Node path. If a match fails, it returns False.

[0134] 2.1.3 Add detection code unit method

[0135] To enhance extensibility, detection code units can be added. First, a detection code unit is created by writing its logic and its reference is obtained; this reference is the path for the program to find the code unit. Then, the corresponding meta-operation is defined in the "meta.op" file, containing the meta-operation name, input parameter type, and input parameter name. Finally, adding detection code units is achieved by configuring the mapping between meta-operations and detection code unit references in the "meta.op" file.

[0136] 2.2 Execution Engine Implementation Logic

[0137] 2.2.1 Load the "meta.op" file

[0138] During this phase, the execution engine initializes by loading the "meta.op" file. It then locates the corresponding detection code unit using the reference paths in the file and establishes a mapping table in memory between meta-operations and that detection code unit.

[0139] 2.2.2 Vulnerability Detection Script Analysis

[0140] This phase uses the vulnerability detection script written by the user in the first part as input. Lexical and syntax analysis are used to obtain meta-operations, meta-operation parameter values, and logical operators in the script file. Lexical and syntax analysis are performed automatically using the Antlr framework. The priorities of the meta-operations are analyzed and placed into a priority queue, which describes the order in which each code unit is executed.

[0141] Preferably, the parsing process sequentially parses each vulnerability detection rule in the vulnerability detection script file.

[0142] The pseudocode for the current stage is as follows:

[0143]

[0144] 2.2.2 Meta-operation mapping and execution

[0145] The execution flow chart of the execution engine is as follows: Figure 5 As shown.

[0146] First, the meta-operations obtained in 2.2.2 are mapped to detection code units by accessing the mapping table generated in 2.2.1, and the input parameter values ​​of the meta-operations obtained in 2.2.2 are used as the input parameters of the code units.

[0147] Secondly, the code unit mapped by the meta-operation is executed. During execution, this code unit performs a matching operation on the IR tree structure generated by the contract transformation in section 2.1.1 to determine whether the Node path contained in the execution logic of this code unit exists in the IR tree structure. It returns True or False and executes the remaining code units mapped by meta-operations that have a logical relationship with the current meta-operation.

[0148] Finally, after executing all the meta-operations defined in the vulnerability detection rules, the results of all meta-operations are logically combined and calculated, and information such as True or False and code snippet line number is returned to explain whether the current contract has the vulnerability defined by the vulnerability detection rules.

[0149] The pseudocode for the current stage is as follows:

[0150]

Claims

1. A smart contract vulnerability detection method based on meta-operations, characterized in that, include: The rule description phase, rule parsing phase, and rule execution phase; A metaoperation is defined as an abstract function representation, which includes the metaoperation name, variable type, and variable name; Define logical operators to describe the logical relationships between metaoperations; Define vulnerability detection rules, which represent a form of vulnerability detection rule description; Define a vulnerability detection script file, which represents a set of contract vulnerabilities to be detected; Define a detection code unit as a code segment representing the specific detection logic of a meta-operation; During the rule description phase, vulnerability detection script files are generated by using meta-operations and logical operators defined in the system. When using meta-operations to describe vulnerability detection, the corresponding type values ​​are passed in according to the input parameter types in the abstract function form. In the intermediate representation (IR), the vulnerability characteristics of smart contract vulnerabilities are represented by vulnerability detection rules. The vulnerability detection rules are listed sequentially in the script file; The rule parsing phase includes: By sequentially traversing the vulnerability detection rules in the vulnerability detection script file; Analyze all meta-operations and input parameter values ​​in each vulnerability detection rule; The system parses all logical operators in the vulnerability detection rules, adds the parsed code detection units to the priority queue according to the priority of the operators, and saves the logical operators that exist between the meta-operations. The rule execution phase includes: Iterate through the code detection units in the priority queue, execute the code detection units and perform path matching on the intermediate representation IR. If a corresponding detection path exists, return True; otherwise, return False. And update the currently matched IR paths to the IRs to be matched; The results of all code detection units in the priority queue are combined with the corresponding logical operators to form a logical operation expression; The presence of specific vulnerabilities in the current smart contract is described by calculating the return value of the logical operation expression as True or False.

2. A smart contract vulnerability detection system based on meta-operations, characterized in that, include: Contract Transformation Module: Uses the Slither tool to compile the smart contract source code, and generates an intermediate representation (IR) through lexical and syntactic analysis, which serves as the object to be scanned in subsequent code execution; Parsing module: Parses the mapping relationship of the meta-operation source code file into the mapping relationship between the meta-operations in memory and the specific detection code unit. It parses the vulnerability detection script file to obtain the meta-operations contained in each detection rule, the priority between meta-operations, and the logical relationship between each meta-operation. Execution module: Based on the mapping relationship between the meta-operations parsed in the parsing module and the detection code units, execute each meta-operation sequentially and record its return value; By combining all return values ​​through logical relationships and calculating the results, it is possible to determine whether there are any vulnerabilities in the contract. Extension module: Used to register detection code units and reference the registered detection code units, thereby enabling the parsing module to append mapping relationships.

Images