Intelligent contract byte code vulnerability detection method and device based on large model simulation stack execution and storage medium

Abstract

The invention belongs to the technical field of security detection, and particularly relates to an intelligent contract byte code vulnerability detection method and device based on large model simulation stack execution, and a storage medium. The objective of the invention is to solve the problem of low vulnerability detection accuracy of an intelligent contract byte code vulnerability detection method. The invention provides an intelligent contract byte code vulnerability detection method based on large model simulation stack execution. The intelligent contract byte code vulnerability detection method comprises the following steps: acquiring an intelligent contract byte code to be detected; preprocessing a to-be-detected intelligent contract byte code to obtain a control flow graph (CFG); configuring expert identities for the large model to obtain a large model of the expert identities, inputting a control flow graph (CFG) into the large model of the expert identities for variable analysis processing to obtain an analysis result, and constructing a variable state transition graph according to the analysis result; and inputting the variable state transition graph into an oracle machine for vulnerability detection processing to obtain a vulnerability detection result. The problem that an intelligent contract byte code vulnerability detection method is low in vulnerability detection accuracy is solved.

Description

Technical Field

[0001] This invention belongs to the field of security detection technology, and in particular relates to a method, device and storage medium for detecting smart contract bytecode vulnerabilities based on large-scale model simulation of stack execution. Background Technology

[0002] Currently, blockchain, as an important emerging technology in the computer field, is undergoing in-depth development and gradually influencing all aspects of social development. In the blockchain ecosystem, smart contracts, as the core carrier of business logic and automatic transaction execution, are directly related to the stable operation of the entire system. Some malicious actors, seeking illegal profits, are constantly innovating their attack methods, exploiting design flaws and operational vulnerabilities in smart contracts. However, in the blockchain field, Ethereum has verified millions of contracts, resulting in countless attacks. Therefore, blockchain professionals both domestically and internationally are continuously investing in research on smart contract vulnerability detection, striving to improve the security of the blockchain ecosystem. Currently, smart contracts primarily exist in bytecode form, but they lack sufficient logical structure, making it difficult to deeply mine semantic information during detection. Deep learning-based smart contract vulnerability detection allows AI to "learn" vulnerability characteristics, becoming a "vulnerability identification expert," often achieving excellent results and leading to the invention of a large number of convenient and practical vulnerability detection tools. However, current mainstream methods (such as LSTM long short-term memory network training for classification and graph neural networks (GNN)) face three main problems: first, they rely on high-quality datasets, such as labeled vulnerability samples; second, they have poor interpretability, which hinders the effective explanation of the underlying principles of vulnerability formation and makes vulnerability remediation difficult; and third, they have weak generalization ability, with performance declining on new vulnerability types. Therefore, existing smart contract bytecode vulnerability detection methods suffer from low vulnerability detection accuracy. Summary of the Invention

[0003] The purpose of this invention is to address the problem of low accuracy in smart contract bytecode vulnerability detection methods. It provides a smart contract bytecode vulnerability detection method based on large-scale model-simulated stack execution, including:

[0004] Step 1: Obtain the bytecode of the smart contract to be tested;

[0005] Step 2: Preprocess the bytecode of the smart contract to be tested to obtain the control flow graph (CFG);

[0006] Step 3: Configure the variable analysis expert identity for the large model to obtain the large model with the variable analysis expert identity. Input the control flow graph (CFG) into the large model with the variable analysis expert identity to perform variable analysis processing and obtain the variable analysis results.

[0007] Step 4: Configure the data flow analysis expert identity for the large model to obtain the large model with the data flow analysis expert identity. Input the control flow graph (CFG) and variable analysis results into the large model with the data flow analysis expert identity for data flow analysis processing to obtain the data flow analysis results.

[0008] Step 5: Configure the control flow analysis expert identity for the large model to obtain the control flow analysis expert identity. Input the control flow graph (CFG) and variable analysis results into the large model with the control flow analysis expert identity for control flow analysis processing to obtain the control flow analysis results.

[0009] Step 6: Construct a variable state transition diagram based on the data flow analysis results and control flow analysis results;

[0010] Step 7: Input the variable state transition graph into the oracle for vulnerability detection and obtain the vulnerability detection results.

[0011] Preferably, in step two, the smart contract bytecode to be detected is preprocessed to obtain preprocessed smart contract bytecode information; the specific process is as follows:

[0012] Step 21: Convert the bytecode of the smart contract to be tested into assembly code;

[0013] Step 22: Divide the assembly code into A opcode blocks; A is a positive integer;

[0014] Steps 2 and 3: Define A opcode blocks as nodes of the control flow graph (CFG); define the control operation relationships between opcode blocks, such as branch jumps and function calls, as edges of the control flow graph (CFG); construct the control flow graph (CFG) based on the nodes and edges.

[0015] Preferably, in step three, a variable analysis expert identity is configured for the large model, resulting in a large model with a variable analysis expert identity. The control flow graph (CFG) is then input into the large model with the variable analysis expert identity for variable analysis processing to obtain the variable analysis results. The specific process is as follows:

[0016] Step 3: 1. Use Prompt to inject smart contract bytecode instruction set knowledge into the large model, configure the large model with variable analysis expert identity, and obtain the large model with variable analysis expert identity;

[0017] Step 3.2: Input the Control Flow Graph (CFG) into the large model with the variable analysis expert identity for variable analysis processing to obtain the variable analysis results. The specific process is as follows:

[0018] Step 321: The large model with expert identities undergoes stack operation simulation processing based on the control flow graph (CFG).

[0019] Step 322: Based on the instruction sequence, identify the set of all variables during the stack operations of the smart contract execution. ,

[0020] Step 3: Record the set of variables The variable type of each variable in the text,

[0021] Record variable collection The storage location of each variable in the file,

[0022] The variable type This includes: stored variables (variables that are persistently stored in the contract's storage area), global variables (variables that can be accessed across functions), and data retrieval variables (variables that come from external calls or CALLDATA).

[0023] Storage locations include: (storage area, memory, call data, stack, or environment variables).

[0024] Step 324: Map all variables identified in Step 322 to high-level semantics, and extract the high-level semantics of each variable. (e.g., variable function type)

[0025] Steps 3, 2, and 4: Based on the set of all variables The variable type, storage location, and high-level semantics of each variable are used to generate variable analysis results.

[0026] In step four, a data flow analysis expert identity is configured for the large model, resulting in a large model with the data flow analysis expert identity. The control flow graph (CFG) and variable analysis results are then input into the large model with the data flow analysis expert identity for data flow analysis processing to obtain the data flow analysis results. The specific process is as follows:

[0027] Step 41: Use Prompt to configure the data flow analysis expert identity for the large model, and obtain the large model with the data flow analysis expert identity.

[0028] Step 4.2: The large-scale model of the data flow analysis expert's identity. Based on the control flow graph (CFG) and variable analysis results, the data flow relationships between variables are identified; the set of all data flow relationships constitutes the data flow analysis result; the specific process is as follows:

[0029] Step 421: The large model of the data flow analysis expert identity, based on the control flow graph (CFG) and variable analysis results, traverses all opcode blocks and all opcode sequences to identify data change-related instructions;

[0030] Step 422: Analyze the data flow relationships between variables based on the data change-related instructions; the collection of all data flow relationships constitutes the data flow analysis results;

[0031] A computer storage medium, characterized in that the storage medium stores at least one instruction, which is loaded and executed by a processor to implement the smart contract bytecode vulnerability detection method based on large model simulated stack execution.

[0032] A smart contract bytecode vulnerability detection device based on large model simulated stack execution is characterized in that the device includes a processor and a memory, the memory stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the smart contract bytecode vulnerability detection method based on large model simulated stack execution.

[0033] The beneficial effects of this invention are as follows:

[0034] First, a smart contract bytecode analysis framework that integrates the expert capabilities of large models with stack execution simulation is proposed. By configuring smart contract bytecode analysis expert attributes for large models, the complex information processing capabilities are used to overcome the problem of the complexity of bytecode instruction sequences, effectively reducing the dependence on the quality of training datasets and the pre-training time cost.

[0035] Secondly, a dual-dimensional analysis system of data flow and control flow with variables as the core is established, clarifying the definition of control flow as variable constraint state (including scenarios such as condition judgment) and data flow as variable migration state (including scenarios such as assignment operation), and combining stack execution simulation to achieve full variable extraction, accurately capturing the dynamic evolution law of variables from the underlying execution principle level;

[0036] Third, we innovatively construct a variable state transition graph based on control flow and data flow, providing a visual and traceable variable evolution carrier for vulnerability analysis. We also design dedicated judgment rules adapted to target vulnerabilities through oracle technology, enabling automated and accurate vulnerability detection.

[0037] Fourth, this technical solution has strong generalization ability and can be adapted to various smart contract vulnerability detection scenarios. Moreover, it explains the vulnerability formation mechanism based on the underlying principles, providing a clear technical basis for vulnerability repair, and significantly improving the practicality and operability of smart contract security analysis. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the overall process of the smart contract bytecode vulnerability detection method based on stack simulation of the present invention.

[0039] Figure 2 This is a schematic diagram of the data flow analysis structure of the present invention;

[0040] Figure 3 This is a schematic diagram of the control flow analysis structure of the present invention;

[0041] Figure 4 This is a schematic diagram of the variable state transition in this invention. Detailed Implementation

[0042] Specific implementation method one: Combining Figure 1-3 This invention is described;

[0043] Step 1: Obtain the bytecode of the smart contract to be tested;

[0044] The term "smart contract" is a well-known name and core concept in the blockchain field.

[0045] Smart contracts are a widely recognized and used standard term in blockchain technology. Since platforms like Ethereum promoted them as a core function, they have become a common technical concept in blockchain application development, DeFi, NFTs, and other fields. This name enjoys clear consensus and is free from ambiguity or confusion.

[0046] The basic definition of a smart contract is a contract clause written in code that is automatically executed on the blockchain. Smart contracts are characterized by being immutable and decentralized in execution.

[0047] Smart contract bytecode refers to the compiled bytecode deployed on the blockchain. The source code of smart contracts is not necessarily public, so vulnerability detection is required through bytecode.

[0048] Bytecode is EVM executable code in hexadecimal format;

[0049] During the experimental verification process of this invention, a dataset of vulnerability-free contract bytecode and a dataset of vulnerability contract bytecode were obtained to verify the effectiveness of this invention. The experimental results verified that this invention has a good detection effect.

[0050] Among them, the vulnerability types include reentrancy attacks and integer overflows, ensuring the diversity and representativeness of the dataset, thereby proving that the invention has broad applicability and strong generalization ability.

[0051] The smart contract bytecode dataset used in the experiment comes from smart contract bytecode datasets from multiple application scenarios such as DeFi, NFT, and DAO.

[0052] DeFi (Decentralized Finance) involves fund operations and has the highest security requirements; NFT (Non-fungible Tokens) involves asset ownership; DAO (Decentralized Autonomous Organization) involves governance and fund management; each application scenario has smart contract bytecode datasets with both vulnerability-free and vulnerability-prone contracts (i.e., each application scenario has both normal and vulnerable versions).

[0053] Vulnerable contracts typically include: reentrancy vulnerability contracts (where a malicious contract repeatedly enters a function call, resulting in multiple withdrawals of funds); integer overflow vulnerability contracts (where numerical calculations exceed the range, leading to logical errors); and access control flaw vulnerability contracts (where caller permissions are not properly verified, resulting in unauthorized operations).

[0054] Step 2: Preprocess the bytecode of the smart contract to be tested to obtain the control flow graph (CFG);

[0055] The preprocessed smart contract bytecode information is a control flow graph (CFG); the control flow graph (CFG) is a graph model used to represent all possible paths during program execution.

[0056] In the context of smart contracts, since the source code may not be available, we need to directly analyze its compiled bytecode. CFG becomes our "navigation map" for understanding the logical structure of the bytecode.

[0057] Step 3: Use the domain-specific Prompt project to configure the variable analysis expert identity for the large model, obtain the large model with the variable analysis expert identity, input the control flow graph (CFG) into the large model with the variable analysis expert identity for variable analysis processing, and obtain the variable analysis results.

[0058] The variable analysis results are the contract's variable set and attribute information;

[0059] The large models mentioned above (including GPT series, LLaMA, Claude, etc.) are large language models with strong language understanding and logical reasoning capabilities, but lack in-depth knowledge of the specific field of smart contract security.

[0060] Domain-specific Prompt projects are carefully designed and constructed series of prompts for large language models to meet the task requirements of specific professional domains (in this invention, smart contract bytecode analysis). These prompts guide and constrain the behavior of general-purpose large models, ensuring that their output conforms to the professional standards of that domain, and is accurate and structured. This is well-known to those skilled in the art.

[0061] For example: "Role setting: You are an expert with more than 5 years of experience in smart contract auditing and are familiar with common vulnerability patterns (such as reentrancy attacks, integer overflows, lack of access control, etc.).

[0062] Step 4: Use the domain-specific Prompt project to configure the data flow analysis expert identity for the large model, obtain the large model with the data flow analysis expert identity, input the control flow graph (CFG) and variable analysis results into the large model with the data flow analysis expert identity for data flow analysis processing, and obtain the data flow analysis results.

[0063] Step 5: Use the domain-specific Prompt project to configure the control flow analysis expert identity for the large model, obtain the large model with the control flow analysis expert identity, input the control flow graph (CFG) and variable analysis results into the large model with the control flow analysis expert identity for control flow analysis processing, and obtain the control flow analysis results;

[0064] Step 6: Construct a variable state transition diagram based on the data flow analysis results and control flow analysis results;

[0065] Step 7: Input the variable state transition graph into the oracle for vulnerability detection and obtain the vulnerability detection results.

[0066] Specific Implementation Method Two: The difference between this implementation method and Specific Implementation Method One is that:

[0067] In step two, the bytecode of the smart contract to be detected is preprocessed to obtain preprocessed smart contract bytecode information; the specific process is as follows:

[0068] Step 21: Convert the bytecode of the smart contract to be tested into assembly code;

[0069] The preferred process for converting the bytecode of the smart contract to be tested into assembly code is as follows: using the open-source security analysis framework Octopus (adapted to the WebAssembly module and blockchain smart contracts), the collected smart contract bytecode is converted into an assembly representation.

[0070] The smart contract bytecode to be tested is a hexadecimal encoded sequence of machine instructions (such as 0x60806040...), which is the final form that a computer can execute directly or through a virtual machine;

[0071] Assembly code is a human-readable sequence of low-level mnemonic instructions (such as PUSH1 0x80, PUSH1 0x40, MSTORE...), which is a human-readable version of bytecode. Developers or analysts can read and analyze it;

[0072] Step 22: Divide the assembly code into A opcode blocks according to preset rules; A is a positive integer;

[0073] The preferred preset rules are (i.e., a sequence of opcodes executed consecutively without branching or jumping constitutes an opcode block); 1) The program entry point is the beginning of the opcode block; 2) The target address of the jump instruction is the beginning of the next opcode block; 3) The address immediately following the jump instruction is the beginning of the opcode block; 4) The opcode block ends when it encounters a jump instruction or a stop instruction.

[0074] Steps 2 and 3: Define A opcode blocks as nodes of the control flow graph (CFG), and define the control operation relationships such as branch jumps and function calls between opcode blocks as edges of the control flow graph (CFG).

[0075] Construct the control flow graph (CFG) based on the nodes and edges of the control flow graph (CFG);

[0076] The structural information of the CFG (including block identifiers, block opcode sequences, edge relationships, and block execution order) is stored as a dictionary-formatted JSON file. This file serves as the unified input data for subsequent large-scale model analysis, ensuring the parsability of the data format. Other steps and parameters are the same as in Specific Implementation Method 1.

[0077] Specific Implementation Method Three: The difference between this implementation method and Specific Implementation Methods One and Two is that:

[0078] In step three, a domain-specific Prompt project is used to configure a variable analysis expert identity for the large model, resulting in a large model with a variable analysis expert identity. The control flow graph (CFG) is then input into this large model to perform variable analysis, yielding the results. The specific process is as follows:

[0079] Step 3: 1. Use the Prompt project to inject smart contract bytecode instruction set knowledge into the large model, configure the variable analysis expert identity for the large model, and obtain the large model with the variable analysis expert identity;

[0080] The knowledge of smart contract bytecode instruction sets includes: EVM instruction semantics, stack operation rules, and variable identification rules, clarifying that it needs to complete the core tasks of "stack execution simulation - variable extraction - storage location - high-level semantic mapping".

[0081] Step 3.2: Input the Control Flow Graph (CFG) into the large model with the variable analysis expert identity for variable analysis processing to obtain the variable analysis results. The specific process is as follows:

[0082] Step 321: The large-scale model of the expert's identity in variable analysis performs stack operation simulation processing based on the control flow graph (CFG). Based on the instruction sequence, it identifies the set of all variables involved in the stack operations during smart contract execution. ,

[0083]

[0084] in, This represents the i-th variable identified (i=1,2,3...).

[0085] (PUSH, POP operations) simulate the stack execution process block by block, tracing the execution status of each bytecode instruction.

[0086] In the case of static analysis (without actually running the contract), the stack operation behavior of the Ethereum Virtual Machine (EVM) when executing smart contract bytecode is simulated by an algorithm;

[0087] The core data structure of EVM is a Last-In-First-Out (LIFO) stack, used to temporarily store intermediate values, function parameters, etc.

[0088] It doesn't actually execute the contract (which doesn't consume gas), but rather uses program logic to deduce the impact of each instruction on the stack;

[0089] By simulating stack changes, we can deduce which data the instructions operate on and how the data flows.

[0090] Tracking the execution status of each instruction specifically includes: the stack state before instruction execution, the stack state after instruction execution, what data the instruction operated on (e.g., how many values ​​were popped from the top of the stack, what values ​​were pushed), whether memory or storage was accessed, etc.

[0091] Step 3.2.2 Variable Analysis: Large Model Recording Variable Set of Expert Identity The variable type of each variable in the text,

[0092] Record variable collection The storage location of each variable in the file,

[0093] Record variable collection The high-level semantics of each variable in the text

[0094] The variable type This includes: stored variables (variables that are persistently stored in the contract's storage area), global variables (variables that can be accessed across functions), and data retrieval variables (variables that come from external calls or CALLDATA).

[0095] Storage locations include: (storage area, memory, call data, stack, or environment variables).

[0096] High-level semantics refers to the semantics of the variables themselves in a smart contract.

[0097] For example, `uint balance` refers to a specific balance data.

[0098] The "address owner" refers to the address of the contract owner, but its semantics can only be discerned directly from the source code.

[0099] The method of this invention only takes bytecode as input and cannot directly derive high-level semantics. The large model of variable analysis expert identity attempts to analyze and derive high-level semantics of variables by integrating information from the control flow graph (CFG) (such as block identifiers, opcode sequences, edge relationships, etc.).

[0100] Step 3: Variable Analysis - The Large Model of Expert Identity Based on All Variable Sets The variable type, storage location, and high-level semantics of each variable are used to generate variable analysis results.

[0101] The variable analysis results are presented as "Variable Identifier - Variable Type - Storage Location - Semantic Features". The dictionary-formatted JSON file is used as the result of variable analysis; T represents the variable type, L represents the storage location, and F represents the high-level semantics; other steps and parameters are the same as in one of the specific implementation methods one or two.

[0102] Specific Implementation Method Four: This implementation method differs from Specific Implementation Methods One to Three in that:

[0103] In step four, a domain-specific Prompt project is used to configure a data flow analysis expert identity for the large model, resulting in a large model with a data flow analysis expert identity. The control flow graph (CFG) and variable analysis results are then input into the large model with the data flow analysis expert identity for data flow analysis processing to obtain the data flow analysis results. The specific process is as follows:

[0104] Step 41: Use the Prompt project to configure the data flow analysis expert identity for the large model, and obtain the large model with the data flow analysis expert identity.

[0105] Once the expert role of the large model is clearly defined, the large model will automatically retrieve relevant knowledge.

[0106] The big model for the identity of a data flow analysis expert needs to be based on CFG and variable analysis results, track data changes such as variable assignment, reading, and modification, and analyze the data status of variables (including variable values, types, dependencies, etc.).

[0107] Step 4.2: The large-scale model of the data flow analysis expert's identity. Based on the control flow graph (CFG) and variable analysis results, the data flow relationships between variables are identified; the set of all data flow relationships constitutes the data flow analysis result; the specific process is as follows:

[0108] Step 421: The large model of the data flow analysis expert identity, based on the control flow graph (CFG) and variable analysis results, traverses all opcode sequences of all opcode blocks to identify data change-related instructions;

[0109] The data change-related instructions include: data source, assignment type, and data stream type.

[0110] Step 422: The large model of the data flow analysis expert's identity analyzes the data flow relationships between variables based on data change-related instructions; the collection of all data flow relationships constitutes the data flow analysis result;

[0111]

[0112] in, Representing variables and The data flow relationship between them

[0113] When the data stream type is an assignment instruction, the data flow relationship is... This can be expressed as a formula:

[0114]

[0115] In the formula, Represents source variables, Representing the target variable, Indicates data stream type, Indicates the assignment type, Indicates the source of the data,

[0116] Data source This includes: (storage area, memory, call data, stack, or environment variables);

[0117] Assignment type This includes: (direct assignment, post-calculation assignment, conditional assignment, and external input assignment);

[0118] Data Stream Type Including: (assignment type, type conversion type);

[0119] When the data stream type is a type conversion instruction, the data flow relationship is... This can be expressed as a formula:

[0120]

[0121] In the formula, Indicates data stream type, Variables that have undergone type conversion Indicates the type of the variable before the conversion (e.g., uint256). Indicates the type of the variable after conversion (e.g., int256). Indicates a change of scene;

[0122] Change scene This includes: (arithmetic operations, address translation, storage operations, or logical judgments);

[0123] Data stream type:

[0124] ,

[0125] This indicates an assignment instruction. This indicates a type conversion instruction; other steps and parameters are the same as in one of the specific implementation methods one to three.

[0126] Specific Implementation Method Five: The difference between this implementation method and Specific Implementation Methods One to Four is that:

[0127] In step five, a domain-specific Prompt project is used to configure a control flow analysis expert identity for the large model, resulting in a large model with a control flow analysis expert identity. The control flow graph (CFG) and variable analysis results are then input into the large model with the control flow analysis expert identity for control flow analysis processing to obtain the control flow analysis results. The specific process is as follows:

[0128] Step 51: Use the Prompt project to configure the control flow analysis expert identity for the large model, and obtain the large model with the control flow analysis expert identity.

[0129] The large-scale model for control flow analysis experts needs to be based on CFG and variable analysis results, focusing on control structures such as condition judgment, initialization, and result storage, and analyzing the control state of variables (including variable lifecycle, scope changes, constraints, etc.).

[0130] Step 5.2: The large model for identifying data flow analysis experts uses the control flow graph (CFG) and variable analysis results to identify control flow analysis results; the specific process is as follows:

[0131] Step 521: The large model of the data flow analysis expert's identity. Based on the control flow graph (CFG) and variable analysis results, traverse all nodes and edges in the CFG to identify the instruction sequence corresponding to the control structure.

[0132] Step 522: The large model of the data flow analysis expert records the control state of the associated variables according to the instruction sequence corresponding to the control structure;

[0133] Certain instruction sequences can cause a change in the control state of certain variables; these affected variables are called correlated variables; this is well known to those skilled in the art.

[0134] Step 523: The large model of the data flow analysis expert identity generates control flow analysis results based on the control state of the associated variables; the control flow analysis results are expressed by the formula:

[0135]

[0136] In the formula, Indicates control conditions. The sequence of instructions indicating the new control state. Characteristics representing instruction sequences, Indicates the identifier of the related variable, The variable represents the control state transition mode, and the reason represents the source code-level operation interpretation corresponding to the control state change. Indicates the type of control operation; Then indicates the actual control flow behavior and state change that occur after the control conditions are met;

[0137] Characteristics of instruction sequences It is a high-level semantic that the large model attempts to derive from analyzing instruction sequences during control flow expert analysis, describing the characteristics of the instruction sequence;

[0138] The control state transition pattern of the variable (such as "scope: within a function → across functions", "constraint state: no constraint → numerical range constraint") should be filled in the "control pattern" field;

[0139] The source code-level operation explanation corresponding to the change in control state (such as "the scope of the variable is expanded to the called function due to the function call instruction") should be filled in the "reason" field;

[0140] Control operation type (Such as various conditional judgment operations, initialization operations, result storage operations, etc.) are filled into the type field. Finally, a JSON file in the control flow analysis dictionary format is generated.

[0141] The other steps and parameters are the same as those in one of the specific implementation methods one to four.

[0142] Specific Implementation Method Six: The difference between this implementation method and Specific Implementation Methods One through Five is that:

[0143] In step six, a variable state transition diagram is constructed based on the data flow analysis results and control flow analysis results; the specific process is as follows:

[0144] Step 61: Use the target smart contract name as the root node of the variable state transition graph.

[0145] The target smart contract name can be replaced with the contract name, since the smart contract name is not included in the information given to the large model, therefore it is omitted at this step;

[0146] Step 62: Based on the data flow analysis and control flow analysis results, all variables identified by the variable analysis are designated as first-level independent variable nodes under the root node, with each variable serving as a first-level independent variable node.

[0147] Each first-level independent variable node records the variable type of the corresponding variable. Storage location and semantic features Information such as;

[0148] Step 63: Construct the main branches of the variable state transition graph based on the data flow analysis results. The core of this graph carries the data flow relationships between variables. The main branches refer to the data flow analysis results, i.e., the relationships between variable nodes, represented by edges (connecting variable nodes). Information is stored on each edge according to its type (different types store different information). Therefore, the starting point and ending point of the main branches are both first-level independent variable nodes. However, not every variable node corresponds to a main branch.

[0149] The specific process is as follows:

[0150] Based on the structured information in the data flow analysis results, such as source variables, target variables, assignment types, and data sources, and using data state change behaviors such as variable assignment and type conversion as the connection basis, data flow edges connecting each node are constructed as the main branches of the variable state transition graph. The specific process is as follows:

[0151] First, based on the records Select record and or , and This information forms the main connection link that connects different variable nodes, accurately presenting the data migration path between variables;

[0152] The main branch represents the data flow analysis results, which come in two types: assignment type and type conversion type.

[0153] Assignment type refers to the transfer of data from one variable to another, so it's a pointer from one variable node to another. Type conversion, on the other hand, changes the data type of a variable, causing it to point to itself. Different types of data streams will store different information on their edges. The interconnected links here refer to these data stream edges (main branches).

[0154] Step 64: Construct the fine branches of the variable state transition diagram based on the control flow analysis results. The specific process is as follows: each fine branch corresponds one-to-one with each variable node.

[0155] Based on the instruction sequence and control operation information in the control flow analysis results, the links are structured with the instruction sequence and its characteristics as fine branches, and with control operation type as the main component. For nodes that are fine branches, the complete record of the control state transition process of the corresponding variable during execution is recorded;

[0156] Each control flow analysis result is divided into two parts. The first part stores a series of instruction sequences Ei and edge Ec with the characteristics of the instruction sequences. These instruction sequences will cause the control state of a certain variable to change. The information of these changes (including control operations Nc) is stored to form a new node.

[0157] In this way, an edge is followed by a node for connection. As long as there are other control flow analysis results for this variable in these control flow analysis results, the link will be continuously extended. This is the branch.

[0158] Step 65: Finally, the data-level association of each variable is realized through the main branch, and the control state record of each individual variable is completed through the sub-branches, forming an integrated tree diagram structure of "root node (smart contract name) - first-level variable node (name of each variable and other information) - main branch (data flow between variables) - sub-branches (single variable control state transition)". Based on the root node, first-level independent variable node, main branch, and sub-branch of the variable state transition diagram, the variable state transition diagram is constructed.

[0159] The variable state transition diagram is a tree diagram structure, which can be expressed by the following formula:

[0160]

[0161] In the formula, V represents the node set and E represents the edge set;

[0162] The node set includes the root node, the set of first-level variable nodes, and the set of control flow operation nodes;

[0163] The edge set includes the edge set connecting the root node to each first-level variable node, the data flow edge set, and the control flow instruction sequence edge set;

[0164]

[0165]

[0166] In the formula, Indicates the target smart contract name; other steps and parameters are the same as in one of the specific implementation methods one to five.

[0167] Specific Implementation Method Seven: The difference between this implementation method and Specific Implementation Methods One through Six is ​​that:

[0168] The oracle in step seven includes: an input layer, a rule layer, a core processing layer, and an output layer;

[0169] The core processing layer includes a feature extraction module and a rule matching module. A set of rules for judging multiple types of smart contract vulnerabilities is preset in the oracle. These rules are formulated based on variable state transition characteristics, and the rule set is stored in the oracle's rule layer in the format of "state transition mode - vulnerability type - judgment condition".

[0170] The rules layer is a vulnerability rule set management module. This module is used to store and maintain preset rule sets for judging various types of smart contract vulnerabilities. These rule sets are stored in a structured format of "state transition mode - vulnerability type - judgment condition," wherein:

[0171] The state transition pattern is a description of the variable state transition characteristics corresponding to the vulnerability trigger, that is, the transition pattern of the variable at the data state and control state levels.

[0172] Vulnerability types include smart contract vulnerabilities such as access control flaws, integer overflows, and denial-of-service attacks;

[0173] The criteria for determining a vulnerability include a set of necessary conditions for triggering the vulnerability. These conditions must be fully aligned with the feature dimensions of the variable state transition graph, and all criteria must be met simultaneously for the vulnerability to be identified.

[0174] All symbols are directly mapped to specific fields in the graph structure:

[0175] The process of inputting the variable state transition diagram into the oracle for vulnerability detection and obtaining the vulnerability detection results is as follows:

[0176] Step 71: Input the variable state transition diagram into the input layer for standardization processing to obtain the standardized variable state transition diagram;

[0177] Step 72: Input the standardized variable state transition graph into the feature extraction module. The oracle traverses the nodes and edges in the graph to extract the state transition features of the variables.

[0178] Step 73: Input the state transition features of the extracted variables into the rule matching module for matching processing to obtain the matching results;

[0179] Step 74: The output layer outputs the matching results as vulnerability detection results;

[0180] The output layer is the detection report generation module. This module receives the vulnerability matching results output by the core processing layer and generates a structured detection report in the format of "vulnerability type - triggering variable - state transition path - vulnerability cause".

[0181] The other steps and parameters are the same as those in any of the specific implementation methods one to six.

[0182] Specific Implementation Method Eight: The difference between this implementation method and Specific Implementation Methods One through Seven is that:

[0183] In step seven-three, the state transition features of the extracted variables are input into the rule matching module for matching processing to obtain the matching results; the specific process is as follows:

[0184] The state transition features of the extracted variables are matched with the preset vulnerability rule set in the rule layer.

[0185] If any feature among the state transition features of the extracted variables meets the criteria for a certain type of vulnerability, then the contract is marked as having a vulnerability of the corresponding type, and the first matching result is output.

[0186] The first matching result includes: vulnerability type, triggering variable, state transition path, and vulnerability cause;

[0187] If none of the features in the state transition features of the extracted variables meet the judgment criteria for a certain type of vulnerability, then the output is "No smart contract vulnerability detected".

[0188] The preset vulnerability rule set in the rule layer includes: access control defect vulnerability detection rules, integer overflow vulnerability detection rules, and denial-of-service vulnerability detection rules;

[0189] Below are some examples of rules for different vulnerability types:

[0190] Access control deficiencies:

[0191] The core logic is that the trigger variable for critical operations was not validated with permissions, allowing unauthorized accounts to modify the variable through data flow and thus execute critical operations. Therefore, the vulnerability is identified by the existence of a variable node whose function type is a critical operation trigger type.

[0192] The fine-branch control operation nodes associated with this variable node do not include permission verification control operations; the data flow edges connecting this variable node originate from unauthorized accounts or roles, meaning that the trigger source for the variable state change is an external account without relevant operation permissions; the fine-branch operation code sequence edges corresponding to this variable node contain operation codes corresponding to the execution of critical operations, ensuring that the variable triggers actual sensitive business operations.

[0193] The symbolic representation of the graph structure derived from the analysis of this type of smart contract vulnerability is:

[0194]

[0195] in, It is the high-level semantics derived from variable analysis, and in this case, it is the variable function type (used to identify core functions such as key operation triggers and permission associations). It is a key operation trigger variable. This is a permission verification operation. It is an unauthorized account / role (an unauthorized external ordinary account). These are critical operation execution codes (such as core operations like transfers, contract upgrades, and fund withdrawals).

[0196] Integer overflow:

[0197] The core logic is that post-calculation assignment lacks numerical validation, causing variable values ​​to exceed the legal range of their data types. Therefore, the vulnerability is identified by the following criteria: a variable node exists; the data flow edge connecting this variable is of the post-calculation assignment type (i.e., the variable value is assigned after arithmetic operations); the fine-grained control operation nodes associated with this variable node do not include numerical range validation control operations (no maximum / minimum value limits, overflow checks, etc.); and the variable's value (based on the extractable pre- and post-assignment states in the graph) exceeds the legal value range of its corresponding data type.

[0198] The symbolic representation of the graph structure derived from the smart contract analysis of this vulnerability is as follows:

[0199]

[0200] in, It is a calculation followed by assignment. This is a numerical range verification control operation. It is the legal value range of the variable data type.

[0201] Refusal of service:

[0202] The core logic is that external input variables are directly passed into the loop logic without validation, and the loop has no termination condition, causing the contract execution to get stuck in an infinite loop, exhausting gas resources and making it impossible to provide services normally.

[0203] The vulnerability is identified by the following criteria: the existence of a stored variable node located in "storage"; modification of this variable's state affects the global business logic of the contract; the fine-branch opcode sequence edges associated with this variable node contain opcode sequences related to infinite loops, such as FOR and LOOP opcodes without explicit termination logic; and the corresponding fine-branch control operation nodes lack loop termination control operations and control behaviors to prevent infinite loops, such as loop count limits and threshold checks.

[0204] The value of the variable exceeds the reasonable range of values ​​in its business scenario, such as excessive loop count or abnormal value causing logical blockage; the data flow edge connecting the variable node has an external input assignment type, that is, the variable value is directly input by an external account without effective validation.

[0205] The symbolic representation of the graph structure derived from the analysis of this type of smart contract vulnerability is:

[0206]

[0207] in, It is an infinitely looping opcode sequence. It is a loop termination control operation (such as loop count limit, threshold verification, etc.). It is the reasonable range of values ​​for variables (the normal numerical range preset based on the business scenario). It is an external input assignment.

[0208] The other steps and parameters are the same as those in any of the specific implementation methods one to seven.

[0209] Specific Implementation Method Nine: This implementation method is a computer storage medium that stores at least one instruction. The at least one instruction is loaded and executed by a processor to implement the smart contract bytecode vulnerability detection method based on large model simulated stack execution.

[0210] It should be understood that the instructions include computer program products, software, or computerized methods corresponding to any method described in this invention; the instructions can be used to program computer systems or other electronic devices. Computer storage media may include readable media on which instructions are stored, and may include, but are not limited to, magnetic storage media, optical storage media; magneto-optical storage media include read-only memory (ROM), random access memory (RAM), erasable programmable memory (e.g., EPROM and EEPROM), and flash memory layers, or other types of media suitable for storing electronic instructions.

[0211] Specific Implementation Method 10: This implementation method is a smart contract bytecode vulnerability detection device based on large model simulation stack execution. The device includes a processor and a memory. It should be understood that it includes any device including a processor and a memory described in this invention. The device may also include other units and modules that perform display, interaction, processing, control and other functions through signals or instructions.

[0212] The memory stores at least one instruction, which is loaded and executed by the processor to implement the smart contract bytecode vulnerability detection method based on large model simulated stack execution.

[0213] Those skilled in the art will understand that at least one stored instruction constitutes a computer program product corresponding to a method or system. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The solutions in the embodiments of this application can be implemented using various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.

[0214] This application is described with reference to flowchart illustrations and / or block diagrams of methods, systems, and computer program products according to embodiments of this application, and can also be used with corresponding devices. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0215] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0216] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1The steps of the functions specified in one or more boxes. The above description is only a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the specific embodiments described above. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the technical solution of the present invention. Any simple modifications, equivalent substitutions, and improvements made to the above embodiments without departing from the content of the technical solution of the present invention, based on the technical essence of the present invention, and within the spirit and principles of the present invention, shall still fall within the protection scope of the technical solution of the present invention.

Claims

1. A method for detecting smart contract bytecode vulnerabilities based on large-scale model-simulated stack execution, characterized in that, include: Step 1: Obtain the bytecode of the smart contract to be tested; Step 2: Preprocess the bytecode of the smart contract to be tested to obtain the control flow graph (CFG); Step 3: Configure the variable analysis expert identity for the large model to obtain the large model with the variable analysis expert identity. Input the control flow graph (CFG) into the large model with the variable analysis expert identity to perform variable analysis processing and obtain the variable analysis results. Step 4: Configure the data flow analysis expert identity for the large model to obtain the large model with the data flow analysis expert identity. Input the control flow graph (CFG) and variable analysis results into the large model with the data flow analysis expert identity for data flow analysis processing to obtain the data flow analysis results. Step 5: Configure the control flow analysis expert identity for the large model to obtain the control flow analysis expert identity. Input the control flow graph (CFG) and variable analysis results into the large model with the control flow analysis expert identity for control flow analysis processing to obtain the control flow analysis results. Step 6: Construct a variable state transition diagram based on the data flow analysis results and control flow analysis results; Step 7: Input the variable state transition graph into the oracle for vulnerability detection and obtain the vulnerability detection results.

2. The smart contract bytecode vulnerability detection method based on large model simulated stack execution according to claim 1, characterized in that, In step two, the bytecode of the smart contract to be detected is preprocessed to obtain preprocessed smart contract bytecode information; the specific process is as follows: Step 21: Convert the bytecode of the smart contract to be tested into assembly code; Step 22: Divide the assembly code into A opcode blocks; A is a positive integer; Steps 2 and 3: Define A opcode blocks as nodes of the control flow graph (CFG), and define the control operation relationships such as branch jumps and function calls between opcode blocks as edges of the control flow graph (CFG). Construct a control flow graph (CFG) based on the nodes and edges of the CFG.

3. The smart contract bytecode vulnerability detection method based on large model simulated stack execution according to claim 2, characterized in that, In step three, a variable analysis expert identity is configured for the large model, resulting in a large model with a variable analysis expert identity. The control flow graph (CFG) is then input into this large model to perform variable analysis, yielding the results. The specific process is as follows: Step 3:

1. Use the Prompt project to inject smart contract bytecode instruction set knowledge into the large model, configure the variable analysis expert identity for the large model, and obtain the large model with the variable analysis expert identity; Step 3.2: Input the Control Flow Graph (CFG) into the large model with the variable analysis expert identity for variable analysis processing to obtain the variable analysis results. The specific process is as follows: Step 321: The large-scale model of the expert's identity in variable analysis performs stack operation simulation processing based on the control flow graph (CFG). Based on the instruction sequence, it identifies the set of all variables involved in the stack operations during smart contract execution. , in, This represents the i-th variable identified (i=1,2,3...). Step 3.2.2 Variable Analysis: Large Model Recording Variable Set of Expert Identity The variable type of each variable in the text, Record variable collection The storage location of each variable in the file, Record variable collection The high-level semantics of each variable in the text Step 3: Variable Analysis - The Large Model of Expert Identity Based on All Variable Sets The variable analysis results are generated by specifying the variable type, storage location, and high-level semantics of each variable.

4. The smart contract bytecode vulnerability detection method based on large model simulated stack execution according to claim 3, characterized in that, In step four, a data flow analysis expert identity is configured for the large model, resulting in a large model with the data flow analysis expert identity. The control flow graph (CFG) and variable analysis results are then input into the large model with the data flow analysis expert identity for data flow analysis processing to obtain the data flow analysis results. The specific process is as follows: Step 41: Use the Prompt project to configure the data flow analysis expert identity for the large model, and obtain the large model with the data flow analysis expert identity. Step 4.2: The large-scale model of the data flow analysis expert's identity. Based on the control flow graph (CFG) and variable analysis results, the data flow relationships between variables are identified; the set of all data flow relationships constitutes the data flow analysis result; the specific process is as follows: Step 421: The large model of the data flow analysis expert identity, based on the control flow graph (CFG) and variable analysis results, traverses all opcode sequences of all opcode blocks to identify data change-related instructions; The data change-related instructions include: data source, assignment type, and data stream type. Step 422: The large model of the data flow analysis expert's identity analyzes the data flow relationships between variables based on data change-related instructions; the collection of all data flow relationships constitutes the data flow analysis result; in, Representing variables and The data flow relationship between them When the data stream type is an assignment instruction, the data flow relationship is... This can be expressed as a formula: In the formula, Indicates data stream type, Represents source variables, Representing the target variable, Indicates the assignment type, Indicates the source of the data, When the data stream type is a type conversion instruction, the data flow relationship is... This can be expressed as a formula: In the formula, Indicates data stream type, Variables that have undergone type conversion Indicates the type of the variable before the conversion. Indicates the type of the variable after conversion. This indicates a change of scene.

5. The smart contract bytecode vulnerability detection method based on large model simulated stack execution according to claim 4, characterized in that, In step five, a control flow analysis expert identity is configured for the large model, resulting in a large model with a control flow analysis expert identity. The control flow graph (CFG) and variable analysis results are then input into the large model with the control flow analysis expert identity for control flow analysis processing to obtain the control flow analysis results. The specific process is as follows: Step 51: Use the Prompt project to configure the control flow analysis expert identity for the large model, and obtain the large model with the control flow analysis expert identity. Step 5.2: The large model for identifying data flow analysis experts uses the control flow graph (CFG) and variable analysis results to identify control flow analysis results; the specific process is as follows: Step 521: The large model of the data flow analysis expert's identity. Based on the control flow graph (CFG) and variable analysis results, traverse all nodes and edges in the CFG to identify the instruction sequence corresponding to the control structure. Step 522: The large model of the data flow analysis expert records the control state of the associated variables according to the instruction sequence corresponding to the control structure; Step 523: The large model of the data flow analysis expert identity generates control flow analysis results based on the control state of the associated variables; the control flow analysis results are expressed by the formula: In the formula, Indicates control conditions. The sequence of instructions indicating the new control state. Characteristics representing instruction sequences, Indicates the identifier of the related variable, The variable represents the control state transition mode, and the reason represents the source code-level operation interpretation corresponding to the control state change. Indicates the type of control operation; Then indicates the actual control flow behavior and state change that occur after the control conditions are met.

6. The method for detecting smart contract bytecode vulnerabilities based on large-model simulated stack execution as described in claim 5, characterized in that, In step six, a variable state transition diagram is constructed based on the data flow analysis results and control flow analysis results; the specific process is as follows: Step 61: Use the target smart contract name as the root node of the variable state transition graph. Step 62: Based on the data flow analysis and control flow analysis results, all variables identified by the variable analysis are designated as first-level independent variable nodes under the root node, with each variable serving as a first-level independent variable node. Step 63: Construct the main branches of the variable state transition diagram based on the data flow analysis results. Step 64: Construct the fine branches of the variable state transition diagram based on the control flow analysis results. Step 65: Construct the variable state transition diagram based on the root node, first-level independent variable nodes, main branches, and minor branches of the variable state transition diagram.

7. The method for detecting smart contract bytecode vulnerabilities based on large-model simulated stack execution as described in claim 6, characterized in that, The oracle in step seven includes: an input layer, a rule layer, a core processing layer, and an output layer; The core processing layer includes: a feature extraction module and a rule matching module; The process of inputting the variable state transition diagram into the oracle for vulnerability detection and obtaining the vulnerability detection results is as follows: Step 71: Input the variable state transition diagram into the input layer for standardization processing to obtain the standardized variable state transition diagram; Step 72: Input the standardized variable state transition graph into the feature extraction module. The oracle traverses the nodes and edges in the graph to extract the state transition features of the variables. Step 73: Input the state transition features of the extracted variables into the rule matching module for matching processing to obtain the matching results; Step 74: The output layer outputs the matching results as vulnerability detection results.

8. The method for detecting smart contract bytecode vulnerabilities based on large-model simulated stack execution as described in claim 7, characterized in that, In step seven-three, the state transition features of the extracted variables are input into the rule matching module for matching processing to obtain the matching results; the specific process is as follows: The state transition features of the extracted variables are matched with the preset vulnerability rule set in the rule layer. If any feature among the state transition features of the extracted variables meets the criteria for a certain type of vulnerability, then the contract is marked as having a vulnerability of the corresponding type, and the first matching result is output. The first matching result includes: vulnerability type, triggering variable, state transition path, and vulnerability cause; If none of the features in the state transition features of the extracted variables meet the judgment criteria for a certain type of vulnerability, then the output is "No smart contract vulnerability detected". The preset vulnerability rule set in the rule layer includes: access control defect vulnerability detection rules, integer overflow vulnerability detection rules, and denial-of-service vulnerability detection rules.

9. A computer storage medium, characterized in that, The storage medium stores at least one instruction, which is loaded and executed by a processor to implement the smart contract bytecode vulnerability detection method based on large model simulated stack execution as described in any one of claims 1 to 8.

10. A smart contract bytecode vulnerability detection device based on large-scale model simulation of stack execution, characterized in that, The device includes a processor and a memory, the memory storing at least one instruction, which is loaded and executed by the processor to implement the smart contract bytecode vulnerability detection method based on large model simulated stack execution as described in any one of claims 1 to 8.

Images