Intelligent contract vulnerability detection method, apparatus and device, and mobile storage medium

Abstract

The invention discloses a smart contract vulnerability detection method, apparatus and device, and a removable storage medium. The method comprises the steps of obtaining a to-be-applied smart contract original code and performing preprocessing; performing code completion on the preprocessed original code of the smart contract by using an LLM model and a GPT model to generate a smart contract completion code; extracting an abstract syntax tree in the intelligent contract completion code, and constructing a control flow graph; and trimming the control flow graph according to the smart contract original code and the abstract syntax tree, and performing mode matching on the trimmed control flow graph based on a preset vulnerability specific mode to generate a vulnerability recognition result. According to the method, firstly, the code snippets are intelligently complemented by utilizing the language model, the complete context information of the code snippets is recovered, and then vulnerabilities possibly existing in the complemented codes are deeply detected in combination with a symbolic execution technology, so that the security of the code snippets can be accurately evaluated, and the security of the code snippets is improved. And the security risk caused by multiplexing the code snippets with vulnerabilities is avoided.

Description

Technical Field

[0001] The present application relates to the field of smart contracts, and more specifically, to a smart contract vulnerability detection method, device, equipment and removable storage medium. Background Art

[0002] In the field of smart contract development, online Q&A platforms play a vital role, where developers exchange experiences, share knowledge, and seek answers to programming problems. However, when it comes to security-sensitive code snippets, the information on these platforms often poses potential risks.

[0003] For example, a developer posts a question about Solidity programming on it and quickly receives a seemingly perfect answer containing a code snippet. This code snippet may immediately solve his problem and allow him to move forward with his project. However, if this code snippet hides a subtle denial of service vulnerability, the consequences will be catastrophic. Once this vulnerability is discovered and exploited by a malicious attacker, it may paralyze the entire smart contract system, prevent the execution of legitimate transactions, and even allow the attacker to steal funds or data.

[0004] The problem is that these code snippets are usually fragmented and lack complete context and compilation environment. Traditional smart contract vulnerability detection tools require complete, compilable smart contract code as input, so they cannot be directly applied to these fragmented code snippets. Existing technologies have obvious deficiencies in processing smart contract code snippets.

[0005] Based on the above situation, this application proposes a smart contract vulnerability detection solution to fill this gap and ensure the robust operation and security of the smart contract system. Summary of the invention

[0006] In view of this, the present application provides a smart contract vulnerability detection method, apparatus, device and removable storage medium. First, a language model is used to intelligently complete code snippets and restore their complete context information. Then, refined symbolic execution technology is combined to deeply detect possible vulnerabilities in the completed code, thereby accurately evaluating the security of code snippets and avoiding security risks caused by reusing code snippets with vulnerabilities.

[0007] A smart contract vulnerability detection method, comprising:

[0008] Obtain the original code of the smart contract to be applied and preprocess it;

[0009] Using the LLM model and the GPT model to complete the preprocessed original code of the smart contract to generate a smart contract completion code;

[0010] Extracting an abstract syntax tree from the smart contract completion code and constructing a control flow graph;

[0011] The control flow graph is pruned according to the original code of the smart contract and the abstract syntax tree, and pattern matching is performed on the pruned control flow graph based on a preset vulnerability specific pattern to generate a vulnerability identification result.

[0012] Optionally, the preprocessed original smart contract code is completed using the LLM model and the GPT model to generate a smart contract completion code, including:

[0013] Using the LLM model to complete the preprocessed original code of the smart contract to generate a first completed code;

[0014] Detect and identify defective codes in the original code of the smart contract that have not been completed by the LLM model, and use the GPT model to complete the defective codes to generate a second completed code;

[0015] The first completion code and the second completion code are combined to obtain a smart contract completion code.

[0016] Optionally, the control flow graph is pruned according to the original code of the smart contract and the abstract syntax tree, and pattern matching is performed on the pruned control flow graph based on a preset vulnerability specific pattern to generate a vulnerability identification result, including:

[0017] By traversing the abstract syntax tree analysis to identify code parts in the original code of the smart contract that are not related to vulnerability detection, an AST analysis result is generated;

[0018] According to the AST analysis result, pruning the basic blocks and basic edges in the control flow graph that are not related to vulnerability detection;

[0019] The pruned control flow graph is pattern matched based on a preset vulnerability specific pattern, and a vulnerability identification result is determined according to the pattern matching result.

[0020] Optionally, the preprocessed original code of the smart contract is completed using the LLM model to generate a first completed code, including:

[0021] Using the structure completion network in the LLM model, based on preset structure completion requirements, the preprocessed original code of the smart contract is structure completed to generate a structure completion code;

[0022] The version adaptation network in the LLM model is used to perform version adaptation processing on the structure completion code based on a preset version adaptation requirement to generate a first completion code.

[0023] Optionally, extracting an abstract syntax tree in the smart contract completion code and constructing a control flow graph includes:

[0024] Parsing the smart contract completion code, and converting the parsed source code into an abstract syntax tree;

[0025] Performing symbolic execution processing on the bytecode obtained by decompiling the smart contract completion code to construct basic blocks, and analyzing the control flow relationship between the basic blocks;

[0026] A control flow graph is constructed according to the constructed basic blocks and the control flow relationship.

[0027] Optionally, pattern matching is performed on the pruned control flow graph based on a preset vulnerability specific pattern, and a vulnerability identification result is determined according to the pattern matching result, including:

[0028] Using symbolic execution technology to perform symbolic execution detection on the pruned control flow graph to obtain corresponding execution logic;

[0029] The executed logic is pattern matched according to the preset vulnerability specific pattern, the vulnerability type of the original code of the smart contract is determined according to the pattern matching result, and a vulnerability identification result is generated.

[0030] Optionally, the using symbolic execution technology to perform symbolic execution detection on the pruned control flow graph to obtain corresponding execution logic includes:

[0031] Completing vulnerability detection information on the pruned control flow graph to generate a completed control flow graph;

[0032] Using a Z3 solver to perform constraint solving on the pruned control flow graph to generate a path selection result;

[0033] The completed control flow graph and the path selection result are integrated and analyzed to obtain execution logic corresponding to the pruned control flow graph.

[0034] A smart contract vulnerability detection device, comprising:

[0035] A code acquisition unit, used to acquire the original code of the smart contract to be applied and perform preprocessing;

[0036] A contract completion unit, used to complete the pre-processed original smart contract code using the LLM model and the GPT model to generate a smart contract completion code;

[0037] A control flow graph unit, used to extract an abstract syntax tree in the smart contract completion code and construct a control flow graph;

[0038] A vulnerability identification unit is used to prune the control flow graph according to the original code of the smart contract and the abstract syntax tree, and perform pattern matching on the pruned control flow graph based on a preset vulnerability specific pattern to generate a vulnerability identification result.

[0039] A smart contract vulnerability detection device, comprising a memory and a processor;

[0040] The memory is used to store programs;

[0041] The processor is used to execute the program to implement each step of the smart contract vulnerability detection method as described in any one of the above items.

[0042] A readable storage medium having a computer program stored thereon, characterized in that when the computer program is executed by a processor, each step of the smart contract vulnerability detection method as described in any one of the above items is implemented.

[0043] It can be seen from the above technical solutions that the embodiment of the present application provides a smart contract vulnerability detection method, device, equipment and removable storage medium, which obtains the original code of the smart contract to be applied and performs preprocessing. First, the preprocessed original code of the smart contract is completed using the LLM model and the GPT model to generate a smart contract completion code. Then, the abstract syntax tree in the smart contract completion code is extracted, and a control flow graph is constructed. The control flow graph is pruned according to the original code of the smart contract and the abstract syntax tree, and the pruned control flow graph is pattern matched based on a preset vulnerability specific pattern to generate a vulnerability identification result.

[0044] This application uses a large language model to intelligently complete fragmented smart contract code snippets, effectively restoring the complete context information of the code, making code snippets that were originally impossible to analyze directly analyzable, and greatly improving the accuracy of subsequent vulnerability detection. On the basis of code completion, this application uses symbolic execution to deeply detect possible smart contract vulnerabilities in the completed code, discover potential logical errors and security vulnerabilities, so as to accurately evaluate the security of code snippets and avoid security risks caused by reusing code snippets with vulnerabilities. In addition, this application can adapt to different types of smart contract code snippets and different types of vulnerabilities. With the continuous advancement of technology and the continuous emergence of new vulnerabilities, this application can maintain the advancement and effectiveness of detection capabilities by updating and optimizing preset vulnerability-specific modes. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0046] Figure 1 A flowchart of a smart contract vulnerability detection method disclosed in an embodiment of the present application;

[0047] Figure 2 A schematic diagram of a smart contract vulnerability detection method disclosed in an embodiment of the present application;

[0048] Figure 3 Another schematic diagram of a smart contract vulnerability detection method disclosed in an embodiment of the present application;

[0049] Figure 4 A schematic diagram of a smart contract vulnerability detection device disclosed in an embodiment of the present application;

[0050] Figure 5 This is a hardware structure block diagram of the smart contract vulnerability detection device disclosed in the embodiment of the present application. DETAILED DESCRIPTION

[0051] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0052] The present application can be used in many general or special computing device environments or configurations, such as personal computers, server computers, handheld or portable devices, tablet devices, multi-processor devices, distributed computing environments including any of the above devices or equipment, etc.

[0053] An embodiment of the present application provides a smart contract vulnerability detection method, which can be applied to various smart contract editing platforms or smart contract detection systems, and can also be applied to various computer terminals or smart terminals. The execution subject can be a processor or server of the computer terminal or smart terminal.

[0054] Next, the present application scheme is introduced. The present application proposes the following technical scheme, please see below for details.

[0055] Figure 1 This is a flowchart of a smart contract vulnerability detection method disclosed in an embodiment of the present application.

[0056] Figure 2 A schematic diagram of a smart contract vulnerability detection method disclosed in an embodiment of the present application.

[0057] like Figure 1 and Figure 2 As shown, the method may include:

[0058] Step S1: Obtain the original code of the smart contract to be applied and perform preprocessing.

[0059] Specifically, due to the distributed nature of blockchain and the complexity of smart contracts, the original code of smart contracts often exists in a fragmented form. The preprocessing process can include collecting, integrating and formatting the fragmented smart contract code fragments, as well as syntax checking, logic analysis and security auditing of the code. Through these steps, the smart contract can be initially improved, providing strong support for subsequent vulnerability detection work.

[0060] Step S2: Use the LLM model and the GPT model to complete the preprocessed original smart contract code to generate a smart contract completion code.

[0061] Specifically, in the critical stage of smart contract development, in order to ensure the integrity and security of the code, we use advanced LLM models (large language models) and GPT models (generative pre-training models) to perform in-depth code completion on the pre-processed original smart contract code. This process is specifically divided into the following three steps:

[0062] Step S21: Use the LLM model to complete the preprocessed original code of the smart contract to generate a first completed code.

[0063] Specifically include:

[0064] ① Using the structure completion network in the LLM model, based on the preset structure completion requirements, the preprocessed original code of the smart contract is structure completed to generate a structure completion code;

[0065] ② Using the version adaptation network in the LLM model, perform version adaptation processing on the structure completion code based on preset version adaptation requirements to generate a first completion code.

[0066] First, the LLM model is used to perform the first code completion on the preprocessed original smart contract code to ensure that the smart contract code has a complete and correct structural framework. In this step, based on the preset structural completion requirements (such as function definition, event declaration, state variables, etc.), the structural completion network in the LLM model will analyze the preprocessed original smart contract code, identify the missing structural elements, and automatically fill in the corresponding code snippets to generate structural completion code. Subsequently, in order to ensure that the code is compatible with a specific version of Solidity or the Ethereum network, the structural completion code is further adjusted and optimized according to the preset version adaptation requirements (such as differences in Solidity syntax versions, changes in specific APIs, etc.), and finally the first completion code is generated.

[0067] Step S22: Detect and identify defective codes in the original code of the smart contract that have not been completed by the LLM model, and use the GPT model to complete the defective code to generate a second completed code.

[0068] Although the LLM model has provided relatively complete code completion, there may still be defective codes that have not been identified or resolved. In order to further improve the code quality, the GPT model is used to perform fine-grained completion on these defective codes. By detecting and identifying code defects that the LLM model has not been fully resolved, such as through static code analysis, symbolic execution or other technical means, the possible logical errors, syntax defects or security vulnerabilities in the first completion code are detected. These code fragments that are not fully resolved by the LLM model are marked as defective codes. The GPT model uses its powerful contextual understanding and generation capabilities to provide a logically reasonable completion solution that complies with the Solidity syntax for these defective codes, and generates a logically reasonable code fragment that complies with the Solidity syntax specification, namely the second completion code.

[0069] Step S23: Merge the first completion code and the second completion code to obtain a smart contract completion code.

[0070] Merge the first completion code generated by the LLM model with the second completion code generated by the GPT model. During the merging process, you can use code merging tools or manual review to ensure that the two completion code snippets are logically consistent and eliminate any possible duplication or conflict. This step will yield the final smart contract completion code, which is not only structurally complete and version compatible, but has also been refined by the dual models, effectively improving the quality and security of the code.

[0071] Step S3: extract the abstract syntax tree in the smart contract completion code and construct a control flow graph.

[0072] Specifically, in the further analysis stage of smart contracts, extracting the abstract syntax tree (AST) in the smart contract completion code and constructing the control flow graph (CFG) are key steps in the static analysis of smart contracts, aiming to deeply understand the execution process and structure of the contract in order to conduct a more in-depth security and functional evaluation. This step is specifically divided into the following three sub-steps:

[0073] Step S31, parsing the smart contract completion code, and converting the parsed source code into an abstract syntax tree;

[0074] Step S32: performing symbolic execution processing on the bytecode obtained by decompiling the smart contract completion code to construct basic blocks, and analyzing the control flow relationship between the basic blocks;

[0075] Step S33: construct a control flow graph according to the constructed basic blocks and the control flow relationship.

[0076] Abstract Syntax Tree (AST) is a tree representation of the grammatical structure of the source code. It clearly expresses the grammatical structure in the source code in the form of a tree, reflecting the structural hierarchy of the program source code. AST is generated after the source code is lexically analyzed and parsed, and is used for further code generation or code optimization. Each node represents a construct in the source code, such as a declaration, expression, statement, etc.

[0077] First, the smart contract completion code is deeply parsed. The parser reads the code line by line, identifies the syntax elements (such as variable declarations, function calls, conditional statements, etc.), and organizes these elements according to their syntax structure and hierarchical relationship to form an abstract syntax tree (AST). The abstract syntax tree clearly represents the logical structure and syntax components of the code in a tree structure, providing a solid foundation for subsequent analysis.

[0078] After that, the bytecode obtained by decompiling the smart contract completion code is symbolically executed. A basic block refers to a piece of code that is executed sequentially, without branches or loops, and has only one entry point and one exit point. During the symbolic execution process, by parsing and converting the bytecode, all basic blocks can be identified and the control flow relationships between them can be analyzed. These relationships include sequential execution, conditional branches, loop jumps, etc., which together constitute the control flow structure of the smart contract.

[0079] Finally, based on the recognition results of the basic blocks and the analysis of the control flow relationship, we can construct the control flow graph (CFG) of the smart contract. The control flow graph is a graphical representation method that uses nodes to represent basic blocks and directed edges to represent the control flow relationship between basic blocks. Through the control flow graph, you can intuitively see the execution process of the smart contract, including various conditional branches and loop structures, which is of great significance for understanding the logic of the contract and discovering potential logical errors or security vulnerabilities.

[0080] Step S4: prune the control flow graph according to the original code of the smart contract and the abstract syntax tree, and perform pattern matching on the pruned control flow graph based on a preset vulnerability specific pattern to generate a vulnerability identification result.

[0081] Specifically, the control flow graph is pruned and optimized based on the original code and abstract syntax tree of the smart contract. This process aims to ensure that the control flow graph accurately reflects the actual execution path of the smart contract, while removing redundant or erroneous edges that may be introduced by code refactoring or optimization.

[0082] Specific methods for pruning the control flow graph may include but are not limited to: checking and removing unreachable code blocks (dead code), adjusting the direction of edges according to the actual logic of conditional statements, and ensuring the correct representation of loop structures, etc. Through this series of operations, we get a more accurate and efficient CFG that accurately reflects the runtime behavior of smart contracts.

[0083] The pruned control flow graph is then pattern matched using preset vulnerability-specific patterns, which are usually summarized based on past security incidents and common vulnerability types. Potential security issues are identified by comparing the similarity of the structure and behavior patterns in the CFG with known vulnerability patterns. The pattern matching algorithm may traverse all nodes and edges in the CFG to find subgraphs or sequences that match a specific vulnerability pattern.

[0084] Once a match is successful, the system generates vulnerability identification results. These results usually indicate the specific location, type, and possible impact of potential vulnerabilities, providing developers or security auditors with important basis for repairing or strengthening smart contracts. In this way, we can discover and resolve potential security risks as early as possible before the deployment of smart contracts, and ensure the reliability and security of smart contracts.

[0085] It can be seen from the above technical solutions that the embodiment of the present application provides a smart contract vulnerability detection method, device, equipment and removable storage medium, which obtains the original code of the smart contract to be applied and performs preprocessing. First, the preprocessed original code of the smart contract is completed using the LLM model and the GPT model to generate a smart contract completion code. Then, the abstract syntax tree in the smart contract completion code is extracted, and a control flow graph is constructed. The control flow graph is pruned according to the original code of the smart contract and the abstract syntax tree, and the pruned control flow graph is pattern matched based on a preset vulnerability specific pattern to generate a vulnerability identification result.

[0086] This application uses a large language model to intelligently complete fragmented smart contract code snippets, effectively restoring the complete context information of the code, making code snippets that were originally impossible to analyze directly analyzable, and greatly improving the accuracy of subsequent vulnerability detection. On the basis of code completion, this application uses symbolic execution to deeply detect possible smart contract vulnerabilities in the completed code, discover potential logical errors and security vulnerabilities, so as to accurately evaluate the security of code snippets and avoid security risks caused by reusing code snippets with vulnerabilities. In addition, this application can adapt to different types of smart contract code snippets and different types of vulnerabilities. With the continuous advancement of technology and the continuous emergence of new vulnerabilities, this application can maintain the advancement and effectiveness of detection capabilities by updating and optimizing preset vulnerability-specific modes.

[0087] Figure 3 Another schematic diagram of a smart contract vulnerability detection method disclosed in an embodiment of the present application.

[0088] In some embodiments of the present application, Figure 3 The process of step S4, pruning the control flow graph according to the original code of the smart contract and the abstract syntax tree, and performing pattern matching on the pruned control flow graph based on a preset vulnerability specific pattern to generate a vulnerability identification result is introduced, which may specifically include:

[0089] Step S41: traverse the abstract syntax tree to analyze and identify the code parts in the original code of the smart contract that are not related to vulnerability detection, and generate an AST analysis result.

[0090] Step S42: According to the AST analysis result, prune basic blocks and basic edges in the control flow graph that are not related to vulnerability detection.

[0091] Specifically, first, by traversing the abstract syntax tree (AST) of the smart contract, its structure is deeply analyzed to identify code parts that are not directly related to vulnerability detection. This process excludes code segments that do not contribute to security analysis or have little impact, such as comments, unused variables or functions. The AST analysis results generated by the system explain which parts need to be focused on for vulnerability detection and which can be ignored. Next, based on the AST analysis results, the system prunes the initially constructed control flow graph (CFG). This step removes basic blocks (code blocks) and basic edges (control flow edges) that are not related to vulnerability detection to ensure the simplicity and efficiency of the CFG. Through pruning, the CFG can more accurately reflect the execution paths in the smart contract that are directly related to security, providing clearer and more accurate input for subsequent pattern matching.

[0092] Step S43: performing pattern matching on the pruned control flow graph based on a preset vulnerability specific pattern, and determining a vulnerability identification result according to the pattern matching result.

[0093] Specifically, the pruned control flow graph is pattern matched using the preset vulnerability-specific patterns. The pattern matching algorithm traverses each node and edge in the CFG to find a subgraph or sequence that matches the specific vulnerability pattern. Once a match is found, the system determines the specific type, location, and possible impact range of the vulnerability based on the matching results, and generates a corresponding vulnerability identification report. This report provides an important reference for developers or security auditors to repair or reinforce smart contracts. Step S43 can be specifically divided into the following steps:

[0094] Step S431: Use symbolic execution technology to perform symbolic execution detection on the pruned control flow graph to obtain corresponding execution logic.

[0095] Through symbolic execution technology, we can deeply explore the potential execution paths of the pruned control flow graph (CFG) to obtain a more comprehensive execution logic. The specific process includes:

[0096] ① Completing vulnerability detection information on the pruned control flow graph to generate a completed control flow graph;

[0097] ② Using the Z3 solver to perform constraint solving on the pruned control flow graph to generate a path selection result;

[0098] ③ Integrate and analyze the completed control flow graph and the path selection result to obtain the execution logic corresponding to the pruned control flow graph.

[0099] First, the vulnerability detection information is completed for the pruned CFG to ensure that various potential vulnerability scenarios can be fully considered during the symbolic execution process. The completed control flow graph contains more information required for vulnerability detection. Then, the Z3 solver is used to perform constraint solving on the completed CFG. This step simulates the execution process of the smart contract under different input conditions and generates possible execution path selection results. These results reveal the behavior patterns of the smart contract in different scenarios. Finally, the completed control flow graph and the path selection results are integrated and analyzed to obtain the execution logic that accurately corresponds to the pruned CFG.

[0100] Step S432: perform pattern matching on the executed logic according to the preset vulnerability specific pattern, determine the vulnerability type of the original code of the smart contract according to the pattern matching result, and generate a vulnerability identification result.

[0101] After obtaining the execution logic, the execution logic can be pattern matched according to the preset vulnerability specific patterns. This process aims to identify possible security vulnerabilities in the smart contract by comparing the specific structure in the execution logic with the preset vulnerability patterns.

[0102] Vulnerability specific patterns can include reentrancy, access control, arithmetic problems, unchecked call return values, denial of service, pseudo-randomness, front-end transactions, time manipulation, short address attacks, etc. The following is a detailed description of the detection methods for each vulnerability:

[0103] Reentrancy: Detect reentrancy attacks that may be caused by CALL instructions in smart contracts, focusing on the impact of unauthorized payable transfer functions and SSTORE instructions on CALL path selection.

[0104] First, filter whether there is a payable transfer function in the contract through the AST syntax tree function information. If not, skip it directly. If yes, proceed to the next step. After building the CFG, check whether the block has a CALL instruction. If not, skip it directly. If yes, check whether there is permission control for entering the block. If yes, skip it. If no, proceed to the next step. Get all subsequent paths of the block by traversing the CFG. If these subsequent path blocks do not contain the SSTORE instruction, skip it. If yes, proceed to the next step. Get the value saved by the SSTORE instruction through the Storage information, and check whether the value participates in the path selection to enter the CALL block. If yes, it is considered to be a reentry.

[0105] Access control: Check the use of SELFDESTRUCT and ORIGIN instructions in the contract to ensure that key operations are controlled by appropriate permissions to prevent unauthorized access or abuse.

[0106] Access control focuses on detecting the abuse of unprotected critical instructions (SELFDESTRUCT) and proxy instructions (ORIGIN). For the former, first use the AST syntax tree to filter whether there is a self-destruct function in the contract, and then traverse the block after the CFG is built to find whether the block contains the SELFDESTRUCT instruction. If not, skip it. If it does, proceed to the next step; check whether the path selection to enter the block has permission control (whether there is a comparison of memory information and caller address). If yes, skip it. If not, it is considered to be. For the latter, mainly check whether the left and right operands of the EQ instruction in the process of building CFG are the proxy address and caller address introduced by the ORIGIN instruction respectively. If yes, it is considered to be an abuse of ORIGIN.

[0107] Arithmetic issues: Identify integer overflow / underflow issues in contracts, especially overflow vulnerabilities caused by the lack of bounds checking when arithmetic operations such as ADD and SUB are involved.

[0108] The ADD instruction corresponds to integer overflow, and the SUB instruction corresponds to integer underflow. The detection process is similar, so let's talk about integer overflow here. First, check whether the left and right operands contain real numbers. If they do, skip it; combine the memory information to check whether the left and right operand expressions contain hash operations. If they do, skip it; finally, check whether the corresponding constraints are met. The ADD instruction corresponds to UGT (first, result) and the SUB instruction corresponds to UGT (second, first). If the above conditions are met, it is considered an arithmetic problem vulnerability.

[0109] Unchecked call return value: Check whether the smart contract performs necessary checks on the return value of the external CALL instruction to avoid unsafe behaviors caused by ignoring error states.

[0110] First, filter whether there is a payable transfer function in the contract through the AST syntax tree function information. If not, skip it directly. If yes, proceed to the next step. After building CFG, check whether the block has a CALL instruction. If not, skip it directly. Traverse CFG to get all subsequent paths of the block. Check whether the return value of the CALL instruction participates in the path selection of the block for each block in the path. If yes, skip it directly. If not, proceed to the next step. Check whether the block has an ISZERO instruction, and check whether the return value of the CALL instruction participates in the operation of the ISZERO instruction as an operand. If yes, skip it. If all the above conditions are met, it is considered a vulnerability that does not check the return value of low-level calls.

[0111] Denial of service: Analyze whether there are loop jump structures in the contract, especially loops containing CALL instructions, which may lead to denial of service attacks.

[0112] First, filter whether there is a payable transfer function in the contract through the AST syntax tree function information. If not, skip it directly. If yes, go to the next step. After building the CFG, check whether there is a loop between the jumps between blocks through topological sorting. If not, skip it. If yes, go to the next step. Extract the ring nodes in the topological sorting sequence obtained before through depth-first search, and then check whether the corresponding ring node block contains CALL instructions. If yes, it is considered a denial of service vulnerability.

[0113] Pseudo-randomness: Check the use of hash functions (such as keccak256) in the contract to ensure that predictable data such as block time and difficulty are not used as input to prevent pseudo-randomness vulnerabilities.

[0114] First, filter whether there is a kecak256 hash function in the contract through the AST syntax tree function information. If not, skip it directly. If yes, go to the next step. The SHA3 instruction calculates the hash by reading data from the Memory, so the data with key information must be accurately stored and identified through MSTORE and MLOAD. The Memory segmentation mode is adopted here. The triplet {start, end, symbol variable} is used to identify and remember a section of symbol memory. The starting position and length popped from the top of the SHA3 instruction stack are used to read the covered triplet data. If the symbol variable expression read contains data introduced by the IMESTAMP, NUMBER, and DIFFICULTY instructions, it is considered a pseudo-random vulnerability.

[0115] Fronting transactions: Analyze the money flow path in the smart contract to identify whether there are different paths but the funds flow to the same direction, which may be a sign of a fronting transaction vulnerability.

[0116] In the process of building CFG, the fund flows of different paths are constructed through the transfer amount and transfer address returned by the CALL instruction. After the CFG is built, each fund flow is compared to detect whether there are different paths but exactly the same fund flows. If not, it is skipped. If so, it is considered to be a pre-transaction vulnerability.

[0117] Time Manipulation: Detect whether the path selection expression involves variables introduced by time-related instructions (such as TIMESTAMP, NUMBER, DIFFICULTY), thereby evaluating whether it may lead to a time manipulation attack.

[0118] During the CFG construction process, check whether the GT, LT, and EQ instructions contain symbolic variables introduced by the TIMESTAMP, NUMBER, and DIFFICULTY instructions. After the CFG is built, check whether all paths and conditions contain symbolic variables introduced by the TIMESTAMP, NUMBER, and DIFFICULTY instructions. If neither of them is found, skip it. If one of them is found, it is considered a time manipulation vulnerability.

[0119] Short address attack: Scan the contract text to detect whether an ERC20 short address with less than 20 characters is used. Such addresses may be used by malicious users to steal funds.

[0120] Scan the text to check if there is any information that meets the ERC20 short address but is less than 20 characters. If not, skip it. If yes, consider it a short address attack.

[0121] A smart contract vulnerability detection device provided in an embodiment of the present application is described below. The smart contract vulnerability detection device described below and the smart contract vulnerability detection method described above can refer to each other.

[0122] See also Figure 4 , Figure 4 A schematic diagram of a smart contract vulnerability detection device disclosed in an embodiment of the present application.

[0123] like Figure 4 As shown, the smart contract vulnerability detection device may include:

[0124] The code acquisition unit 110 is used to acquire the original code of the smart contract to be applied and perform preprocessing;

[0125] The contract completion unit 120 is used to complete the pre-processed original smart contract code using the LLM model and the GPT model to generate a smart contract completion code;

[0126] A control flow graph unit 130, used to extract an abstract syntax tree in the smart contract completion code and construct a control flow graph;

[0127] The vulnerability identification unit 140 is used to prune the control flow graph according to the original code of the smart contract and the abstract syntax tree, and perform pattern matching on the pruned control flow graph based on a preset vulnerability specific pattern to generate a vulnerability identification result.

[0128] It can be seen from the above technical solutions that the embodiment of the present application provides a smart contract vulnerability detection method, device, equipment and removable storage medium, which obtains the original code of the smart contract to be applied and performs preprocessing. First, the preprocessed original code of the smart contract is completed using the LLM model and the GPT model to generate a smart contract completion code. Then, the abstract syntax tree in the smart contract completion code is extracted, and a control flow graph is constructed. The control flow graph is pruned according to the original code of the smart contract and the abstract syntax tree, and the pruned control flow graph is pattern matched based on a preset vulnerability specific pattern to generate a vulnerability identification result.

[0129] This application uses a large language model to intelligently complete fragmented smart contract code snippets, effectively restoring the complete context information of the code, making code snippets that were originally impossible to analyze directly analyzable, and greatly improving the accuracy of subsequent vulnerability detection. On the basis of code completion, this application uses symbolic execution to deeply detect possible smart contract vulnerabilities in the completed code, discover potential logical errors and security vulnerabilities, so as to accurately evaluate the security of code snippets and avoid security risks caused by reusing code snippets with vulnerabilities. In addition, this application can adapt to different types of smart contract code snippets and different types of vulnerabilities. With the continuous advancement of technology and the continuous emergence of new vulnerabilities, this application can maintain the advancement and effectiveness of detection capabilities by updating and optimizing preset vulnerability-specific modes.

[0130] Optionally, the contract completion unit may include:

[0131] A first completion unit, used to complete the preprocessed original code of the smart contract using the LLM model to generate a first completion code;

[0132] A second completion unit, used to detect and identify defective codes in the original code of the smart contract that have not been completed by the LLM model, and use the GPT model to complete the defective code to generate a second completion code;

[0133] A completion merging unit is used to merge the first completion code and the second completion code to obtain a smart contract completion code.

[0134] Optionally, the vulnerability identification unit may include:

[0135] An AST analysis unit is used to identify code parts in the original code of the smart contract that are not related to vulnerability detection by traversing the abstract syntax tree analysis, and generate an AST analysis result;

[0136] A flow graph pruning unit, used for pruning basic blocks and basic edges in the control flow graph that are not related to vulnerability detection according to the AST analysis result;

[0137] The pattern matching unit is used to perform pattern matching on the pruned control flow graph based on a preset vulnerability specific pattern, and determine the vulnerability identification result according to the pattern matching result.

[0138] Optionally, the first completion unit may include:

[0139] A structure completion unit, used to utilize the structure completion network in the LLM model to perform structure completion processing on the preprocessed original code of the smart contract based on preset structure completion requirements, and generate structure completion code;

[0140] The version adaptation unit is used to utilize the version adaptation network in the LLM model to perform version adaptation processing on the structure completion code based on a preset version adaptation requirement to generate a first completion code.

[0141] Optionally, the control flow graph unit may include:

[0142] A code parsing unit, used to parse the smart contract completion code and convert the parsed source code into an abstract syntax tree;

[0143] A relationship identification unit, configured to perform symbolic execution processing on the bytecode obtained by decompiling the smart contract completion code to construct basic blocks, and analyze the control flow relationship between the basic blocks;

[0144] A flow graph construction unit is used to construct a control flow graph according to the constructed basic blocks and the control flow relationship.

[0145] Optionally, the pattern matching unit may include:

[0146] An execution logic unit, used to perform symbolic execution detection on the pruned control flow graph using symbolic execution technology to obtain corresponding execution logic;

[0147] The matching detection unit is used to perform pattern matching on the executed logic according to the preset vulnerability specific pattern, determine the vulnerability type of the original code of the smart contract according to the pattern matching result, and generate a vulnerability identification result.

[0148] Optionally, the execution logic unit may include:

[0149] An information completion unit, used to complete vulnerability detection information on the pruned control flow graph to generate a completed control flow graph;

[0150] A constraint solving unit, used for performing constraint solving on the pruned control flow graph using a Z3 solver to generate a path selection result;

[0151] An integration and analysis unit is used to integrate and analyze the completed control flow graph and the path selection result to obtain an execution logic corresponding to the pruned control flow graph.

[0152] The smart contract vulnerability detection device provided in the embodiment of the present application can be applied to smart contract vulnerability detection equipment. Figure 5 The hardware structure diagram of the smart contract vulnerability detection device is shown in FIG. Figure 5 ,The hardware structure of the smart contract vulnerability detection device may include: at least one processor 1, at least one communication interface 2, at least one memory 3 and at least one communication bus 4;

[0153] In the embodiment of the present application, the number of the processor 1, the communication interface 2, the memory 3, and the communication bus 4 is at least one, and the processor 1, the communication interface 2, and the memory 3 communicate with each other through the communication bus 4;

[0154] The processor 1 may be a central processing unit CPU, or an application-specific integrated circuit ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of the present invention, etc.;

[0155] The memory 3 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), etc., such as at least one disk memory;

[0156] The memory stores a program, and the processor can call the program stored in the memory, wherein the program is used to:

[0157] Obtain the original code of the smart contract to be applied and preprocess it;

[0158] Using the LLM model and the GPT model to complete the preprocessed original code of the smart contract to generate a smart contract completion code;

[0159] Extracting an abstract syntax tree from the smart contract completion code and constructing a control flow graph;

[0160] The control flow graph is pruned according to the original code of the smart contract and the abstract syntax tree, and pattern matching is performed on the pruned control flow graph based on a preset vulnerability specific pattern to generate a vulnerability identification result.

[0161] Optionally, the detailed functions and extended functions of the program may refer to the above description.

[0162] The embodiment of the present application further provides a readable storage medium, which may store a program suitable for execution by a processor, wherein the program is used to:

[0163] Obtain the original code of the smart contract to be applied and preprocess it;

[0164] Using the LLM model and the GPT model to complete the preprocessed original code of the smart contract to generate a smart contract completion code;

[0165] Extracting an abstract syntax tree from the smart contract completion code and constructing a control flow graph;

[0166] The control flow graph is pruned according to the original code of the smart contract and the abstract syntax tree, and pattern matching is performed on the pruned control flow graph based on a preset vulnerability specific pattern to generate a vulnerability identification result.

[0167] Optionally, the detailed functions and extended functions of the program may refer to the above description.

[0168] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0169] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0170] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A smart contract vulnerability detection method, characterized in that: include: Obtain the original code of the smart contract to be applied and preprocess it; Using the LLM model and the GPT model to complete the preprocessed original code of the smart contract to generate a smart contract completion code; Extracting an abstract syntax tree from the smart contract completion code and constructing a control flow graph; The control flow graph is pruned according to the original code of the smart contract and the abstract syntax tree, and pattern matching is performed on the pruned control flow graph based on a preset vulnerability specific pattern to generate a vulnerability identification result.

2. The method according to claim 1, characterized in that The LLM model and the GPT model are used to complete the preprocessed original smart contract code to generate a smart contract completion code, including: Using the LLM model to complete the preprocessed original code of the smart contract to generate a first completed code; Detect and identify defective codes in the original code of the smart contract that have not been completed by the LLM model, and use the GPT model to complete the defective codes to generate a second completed code; The first completion code and the second completion code are combined to obtain a smart contract completion code.

3. The method according to claim 1, characterized in that The control flow graph is pruned according to the original code of the smart contract and the abstract syntax tree, and pattern matching is performed on the pruned control flow graph based on a preset vulnerability specific pattern to generate a vulnerability identification result, including: By traversing the abstract syntax tree analysis to identify code parts in the original code of the smart contract that are not related to vulnerability detection, an AST analysis result is generated; According to the AST analysis result, pruning the basic blocks and basic edges in the control flow graph that are not related to vulnerability detection; The pruned control flow graph is pattern matched based on a preset vulnerability specific pattern, and a vulnerability identification result is determined according to the pattern matching result.

4. The method according to claim 2, characterized in that: The LLM model is used to complete the preprocessed original code of the smart contract to generate a first completed code, including: Using the structure completion network in the LLM model, based on preset structure completion requirements, the preprocessed original code of the smart contract is structure completed to generate a structure completion code; The version adaptation network in the LLM model is used to perform version adaptation processing on the structure completion code based on a preset version adaptation requirement to generate a first completion code.

5. The method according to claim 1, characterized in that Extract the abstract syntax tree in the smart contract completion code and construct a control flow graph, including: Parsing the smart contract completion code, and converting the parsed source code into an abstract syntax tree; Performing symbolic execution processing on the bytecode obtained by decompiling the smart contract completion code to construct basic blocks, and analyzing the control flow relationship between the basic blocks; A control flow graph is constructed according to the constructed basic blocks and the control flow relationship.

6. The method according to claim 3, characterized in that Performing pattern matching on the pruned control flow graph based on a preset vulnerability specific pattern, and determining a vulnerability identification result according to the pattern matching result, including: Using symbolic execution technology to perform symbolic execution detection on the pruned control flow graph to obtain corresponding execution logic; The executed logic is pattern matched according to the preset vulnerability specific pattern, the vulnerability type of the original code of the smart contract is determined according to the pattern matching result, and a vulnerability identification result is generated.

7. The method according to claim 6, characterized in that The using of symbolic execution technology to perform symbolic execution detection on the pruned control flow graph to obtain corresponding execution logic includes: Completing vulnerability detection information on the pruned control flow graph to generate a completed control flow graph; Using a Z3 solver to perform constraint solving on the pruned control flow graph to generate a path selection result; The completed control flow graph and the path selection result are integrated and analyzed to obtain execution logic corresponding to the pruned control flow graph.

8. A smart contract vulnerability detection device, characterized in that: include: A code acquisition unit, used to acquire the original code of the smart contract to be applied and perform preprocessing; A contract completion unit, used to complete the pre-processed original smart contract code using the LLM model and the GPT model to generate a smart contract completion code; A control flow graph unit, used to extract an abstract syntax tree in the smart contract completion code and construct a control flow graph; A vulnerability identification unit is used to prune the control flow graph according to the original code of the smart contract and the abstract syntax tree, and perform pattern matching on the pruned control flow graph based on a preset vulnerability specific pattern to generate a vulnerability identification result.

9. A smart contract vulnerability detection device, characterized in that: including memory and processor; The memory is used to store programs; The processor is used to execute the program to implement each step of the smart contract vulnerability detection method as described in any one of claims 1 to 7.

10. A readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, each step of the smart contract vulnerability detection method as described in any one of claims 1 to 7 is implemented.

Images