A method, device, equipment and storage medium for detecting defects in NFT smart contracts

Abstract

The present invention discloses a method, apparatus, device and storage medium for detecting defects in NFT smart contracts, which are used to solve the technical problem that existing detection methods rely on the number of attack transactions generated, can only prevent the spread of attacks to a certain extent, and cannot prevent the occurrence of attacks from the beginning. The present invention includes: obtaining an NFT smart contract; compiling the NFT smart contract, collecting an abstract syntax tree, an instruction source code position mapping relationship and a contract bytecode; decompiling the contract bytecode to generate a disassembled opcode; constructing a source map using the disassembled opcode and the instruction source code position mapping relationship; determining the target function of the NFT smart contract based on the abstract syntax tree; performing symbolic execution on the target function and constructing a control flow graph in combination with the disassembled opcode; simulating the execution of the control flow graph in combination with the source map, and collecting program code information during the execution process; and performing defect detection on the NFT smart contract based on the program code information.

Description

Technical Field

[0001] The present invention relates to the field of smart contract technology, and in particular to an NFT smart contract defect detection method, device, equipment and storage medium. Background Art

[0002] Sleepcasting is a potential security vulnerability or malicious behavior associated with NFT (non-fungible token) smart contracts. It involves a deceptive method by which an attacker can temporarily send an NFT to a well-known wallet address (such as that of a celebrity or well-known artist) through the contract mechanism and then return the NFT to their own wallet. This behavior makes the NFT appear to have once belonged to a well-known owner, potentially increasing its value or attracting buyer interest. Sleepcasting requires two steps to work:

[0003] 1) Minting: The attacker mints the NFT directly into the target’s wallet address using the target’s public key.

[0004] 2) Transfer: Once the tokens are minted into the victim's wallet, the attacker can transfer them back to their own address or a pre-specified address through vulnerabilities (such as writing logic in the contract to "release" their own address to bypass checks). Because normally only the NFT owner can transfer their own NFT, these operations make it appear as if the victim first owned the NFT and then willingly transferred it to the attacker.

[0005] If these operations occur to famous NFT creators, attackers can use the celebrity's name to assign false values ​​to their NFTs and profit from them. This type of attack not only jeopardizes the integrity of NFT ownership, but also poses a significant risk to the broader credibility of blockchain-based digital assets.

[0006] Prior art proposes a prevention system to reduce the number of sleep casting attacks. This system analyzes transactions included in new blocks, detects transactions associated with sleep casting attacks, and tracks the addresses involved in these transactions. This involves tracking the addresses involved using a dictionary-like data structure, where the key is the address and the value serves as a counter of the number of times the address has participated in sleep casting. With this information, block-creating nodes can add another verification step before adding a transaction to a block: blocking the transaction if the number of times an address involved in a sleep casting attack exceeds a threshold.

[0007] The aforementioned prevention system detects sleep casting attacks based on transactions, blocking transactions only when the number of times an address appears in a sleep casting attack exceeds a threshold. However, this detection method relies on the number of attacking transactions generated, which can only prevent the spread of the attack to a certain extent, and cannot prevent the attack from occurring in the first place. Summary of the Invention

[0008] The present invention provides an NFT smart contract defect detection method, device, equipment and storage medium, which are used to solve the technical problem that the existing detection method depends on the number of attack transactions generated, can only prevent the spread of attacks to a certain extent, and cannot prevent the occurrence of attacks from the beginning.

[0009] The present invention provides a method for detecting defects in NFT smart contracts, comprising:

[0010] Get the NFT smart contract;

[0011] Compile the NFT smart contract and collect the abstract syntax tree, instruction source code location mapping, and contract bytecode;

[0012] Decompile the contract bytecode to generate disassembled opcode;

[0013] Constructing a source map using the mapping relationship between the disassembled opcode and the instruction source code position;

[0014] Determine the target function of the NFT smart contract according to the abstract syntax tree;

[0015] Performing symbolic execution on the target function and constructing a control flow graph in combination with the disassembled opcodes;

[0016] Simulating the execution of the control flow graph in combination with the source mapping to collect program code information during the execution process;

[0017] Perform defect detection on the NFT smart contract based on the program code information.

[0018] Optionally, the step of constructing a source map using the mapping relationship between the disassembled opcode and the instruction source code position includes:

[0019] According to the instruction source code position mapping relationship, the source code corresponding to each disassembled opcode is obtained;

[0020] A source map is generated using the disassembled opcodes and the source code.

[0021] Optionally, the step of determining the target function of the NFT smart contract according to the abstract syntax tree includes:

[0022] Obtain node information of each function of the NFT smart contract in the abstract syntax tree in sequence;

[0023] Determine whether the node information contains a target node or references a function containing the target node; the target node is a node representing the source code of the transfer event;

[0024] The function corresponding to the node information that contains the target node or references the function containing the target node is determined as the target function of the NFT smart contract.

[0025] Optionally, the program code information includes at least one of a From parameter, a storage variable, store operation information, execution event sending operation information, and owner information; and the step of simulating execution of the control flow graph in combination with the source mapping and collecting program code information during the execution process includes:

[0026] During the simulation execution of the control flow, when the CALLDATALOAD instruction is executed, the From parameter is obtained;

[0027] When the SLOAD instruction is executed, the storage variables are read from the contract storage space;

[0028] When the SSTROE instruction is detected, store operation information is generated;

[0029] When the LOG4 instruction is detected to be executed, an execution event is generated and the operation information is sent;

[0030] Get the owner information through the source map.

[0031] Optionally, the step of performing defect detection on the NFT smart contract according to the program code information includes:

[0032] When it is detected that the storage variable is equal to the contract caller address, it is determined that the NFT smart contract has a sleep casting vulnerability;

[0033] When it is detected that the From parameter and the owner information meet the preset constraints, it is determined that the NFT smart contract has a sleep casting vulnerability;

[0034] When store operation information is not generated before the execution event sending operation information is generated, it is determined that the NFT smart contract has a dormant casting risk.

[0035] The present invention also provides an NFT smart contract defect detection device, comprising:

[0036] NFT smart contract acquisition module, used to obtain NFT smart contracts;

[0037] A compilation module, used to compile the NFT smart contract and collect the abstract syntax tree, instruction source code location mapping relationship and contract bytecode;

[0038] A disassembly opcode generation module, used to decompile the contract bytecode to generate a disassembly opcode;

[0039] A source map construction module, configured to construct a source map using a mapping relationship between the disassembled opcode and the instruction source code position;

[0040] An objective function determination module, configured to determine an objective function of the NFT smart contract based on the abstract syntax tree;

[0041] A control flow graph construction module, configured to perform symbolic execution on the target function and construct a control flow graph in combination with the disassembled opcode;

[0042] A program code information collection module, configured to simulate execution of the control flow graph in combination with the source mapping, and collect program code information during the execution process;

[0043] A defect detection module is used to perform defect detection on the NFT smart contract based on the program code information.

[0044] Optionally, the source mapping construction module includes:

[0045] A source code acquisition submodule is used to obtain the source code corresponding to each disassembled opcode according to the instruction source code position mapping relationship;

[0046] The source map generation submodule is configured to generate a source map using the disassembly operation code and the source code.

[0047] Optionally, the objective function determination module includes:

[0048] A node information acquisition submodule, used to sequentially obtain the node information of each function of the NFT smart contract in the abstract syntax tree;

[0049] A judgment submodule, configured to judge whether the node information contains a target node or references a function containing the target node; the target node is a node representing the source code of the transfer event;

[0050] The target function determination submodule is used to determine the function corresponding to the node information that contains the target node or references the function containing the target node as the target function of the NFT smart contract.

[0051] The present invention further provides an electronic device, comprising a processor and a memory:

[0052] The memory is used to store program code and transmit the program code to the processor;

[0053] The processor is used to execute the NFT smart contract defect detection method as described in any one of the above items according to the instructions in the program code.

[0054] The present invention also provides a computer-readable storage medium, which is used to store program code, and the program code is used to execute the NFT smart contract defect detection method as described in any one of the above items.

[0055] It can be seen from the above technical solutions that the present invention has the following advantages: The present invention discloses a method for detecting defects in NFT smart contracts, and specifically discloses: obtaining an NFT smart contract; compiling an NFT smart contract, collecting an abstract syntax tree, an instruction source code position mapping relationship, and a contract bytecode; decompiling the contract bytecode to generate a disassembled opcode; constructing a source map using the disassembled opcode and the instruction source code position mapping relationship; determining the target function of the NFT smart contract based on the abstract syntax tree; symbolically executing the target function, and constructing a control flow graph in combination with the disassembled opcode; simulating the execution of the control flow graph in combination with the source map, and collecting program code information during the execution process; and performing defect detection on the NFT smart contract based on the program code information. Based on symbolic execution technology, the present invention detects and locates possible sleep casting vulnerabilities in NFT smart contracts according to the characteristics of the sleep casting vulnerability, thereby finding problems between deployed contracts and avoiding deploying problematic contracts on the chain to be exploited by attackers. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0057] Figure 1 A flowchart of the steps of a method for detecting defects in NFT smart contracts provided by an embodiment of the present invention;

[0058] Figure 2 A flowchart of a method for detecting an NFT smart contract according to another embodiment of the present invention;

[0059] Figure 3 An architectural diagram of an NFT smart contract defect detection method provided by an embodiment of the present invention;

[0060] Figure 4This is a structural block diagram of an NFT smart contract defect detection device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0061] The embodiments of the present invention provide an NFT smart contract defect detection method, apparatus, device and storage medium, which are used to solve the technical problem that the existing detection method depends on the number of attack transactions generated, can only prevent the spread of attacks to a certain extent, and cannot prevent the occurrence of attacks from the beginning.

[0062] In order to make the purpose, features, and advantages of the present invention more obvious and easy to understand, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described below are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0063] See also Figure 1 , Figure 1 A flowchart of the steps of an NFT smart contract defect detection method provided by an embodiment of the present invention.

[0064] The present invention provides an NFT smart contract defect detection method, which may specifically include:

[0065] Step 101, obtain the NFT smart contract;

[0066] NFTs (Non-Fungible Tokens) are digital assets based on blockchain technology that are unique and non-fungible. Each NFT represents a specific item or content, such as artwork, music, or gaming items, and can prove ownership and authenticity. Unlike traditional homogenous tokens, each NFT unit is unique and non-interchangeable.

[0067] Smart contracts: Smart contracts are a key feature of the Blockchain 2.0 era. By storing code on the blockchain and making it tamper-proof once deployed, they are Turing-complete and can execute code to complete predefined actions when certain conditions are met, including transferring funds, making decisions, and interacting with other contracts. Due to the nature of blockchain, the results of smart contracts are run and verified by a large number of computers to ensure reliability. Solidity is currently the most popular smart contract language. This method only targets the Solidity language and the EVM (Ethereum Virtual Machine) that supports Solidity smart contracts.

[0068] Step 102: Compile the NFT smart contract and collect the abstract syntax tree, instruction source code location mapping relationship, and contract bytecode;

[0069] Step 103: Decompile the contract bytecode to generate disassembled opcode;

[0070] An Abstract Syntax Tree (AST) is a tree representation of the abstract syntax structure of the source code. During the compilation process, the AST generated by the source code can provide semantic information of the idiom.

[0071] In this embodiment of the present invention, open source contracts on EtherScan or developer-written contract source code can be used as program input. The smart contract is compiled using the Solidity compiler, and the compilation outputs are collected: AST, instruction source code location mapping, and contract bytecode. The contract bytecode is then decompiled to obtain disassembled opcodes.

[0072] Step 104, constructing a source map using the mapping relationship between the disassembled opcode and the instruction source code position;

[0073] After generating the disassembled opcode, a source map can be constructed based on the instruction source code location mapping relationship.

[0074] In this embodiment of the present invention, the solc tool can be used. By calling the solc tool with "solc --combined-json asm", a "mapping relationship file of instruction source code locations" for the smart contract can be generated. This is a JSON file, part of which is as follows:

[0075]

[0076] The source code corresponding to this PUSH instruction is from characters 12388 to 20707 in the contract file. In order, each line of instruction will correspond to a block of such content in this JSON file.

[0077] A source map is a tool that maps bytecode instructions (i.e., disassembled opcodes) back to source code. To construct a source map, simply follow the instructions line by line in the disassembled opcode file and sequentially find the corresponding content blocks in the JSON file generated by the solc tool. This will allow you to find the begin and end of the source code corresponding to a particular instruction line in the contract file. These pairs of data are then organized to form the source map for the current contract. Later, when executing bytecode instructions, simply knowing the current instruction line allows you to map back to the source code.

[0078] Step 105: Determine the target function of the NFT smart contract based on the abstract syntax tree;

[0079] In actual scenarios, since the sleep casting vulnerability only occurs in functions related to NFT transfer operations in NFT smart contracts, it is possible to traverse the abstract syntax tree AST, analyze the structure of each function in the contract, and determine whether a function is related to token transfer, thereby filtering out the target functions that need to be checked this time, and improving inspection efficiency by avoiding the operation of checking the entire contract.

[0080] Step 106: symbolically execute the target function and construct a control flow graph in combination with the disassembled opcodes;

[0081] Symbolic execution is a program analysis technique that aims to systematically explore a program's execution paths by treating its inputs as symbolic variables rather than concrete values. The basic principle is that as the program runs, a symbolic execution engine traces each execution path and generates corresponding logical conditions that describe valid inputs to the program's state. By solving these conditions, analysis tools can identify which input combinations lead to specific program behaviors, including errors and security vulnerabilities.

[0082] The core of symbolic execution lies in creating a state tree, where each node represents a state of the program and each edge represents an execution step. When a symbolic execution engine encounters a conditional branch, it generates new conditions for each branch, thereby expanding the state tree. By solving the logical conditions along this path, researchers can identify the symbolic inputs that lead to specific outputs or errors. This process typically uses a satisfiability solver (SAT solver) to solve the generated logical formulas.

[0083] Symbolic execution is widely used in software testing, security analysis, and vulnerability detection. It effectively discovers security vulnerabilities in smart contracts, such as reentrancy attacks, overflow errors, and logic errors. By simulating all possible execution paths, symbolic execution can identify potential risks before contract deployment, helping developers optimize contract design.

[0084] A control flow graph is an abstract representation of a process or program. It is an abstract data structure used by compilers and maintained internally by the compiler. It represents all paths traversed during program execution. It graphically illustrates the possible execution flows of all basic blocks within a process and can also reflect the real-time execution of a process.

[0085] In an embodiment of the present invention, a complete control flow graph can be constructed in combination with disassembly opcodes during the symbolic execution process.

[0086] Step 107, simulate the execution of the control flow graph in combination with the source mapping, and collect program code information during the execution process;

[0087] In an embodiment of the present invention, program code information can be collected during the symbolic execution process to provide a basis for subsequent vulnerability analysis.

[0088] Step 108: Perform defect detection on the NFT smart contract based on the program code information.

[0089] In an embodiment of the present invention, the program code information can be analyzed by an analyzer to detect defects in the NFT smart contract.

[0090] In specific implementations, the analyzer can analyze the collected program code information according to pre-defined detection rules. If there is a conflict between the program code information and the rules, it is determined that the contract has a sleep casting vulnerability.

[0091] Based on symbolic execution technology, this invention detects and locates possible sleep casting vulnerabilities in NFT smart contracts according to the characteristics of sleep casting vulnerabilities, thereby finding problems between deployed contracts and avoiding deploying problematic contracts on the chain and being exploited by attackers.

[0092] See also Figure 2 , Figure 2 A flowchart of the steps of an NFT smart contract detection method provided in another embodiment of the present invention.

[0093] An embodiment of the present invention provides an NFT smart contract detection method, which may include the following steps:

[0094] Step 201, obtain the NFT smart contract;

[0095] Step 202: Compile the NFT smart contract and collect the abstract syntax tree, instruction source code location mapping, and contract bytecode.

[0096] Step 203: Decompile the contract bytecode to generate disassembled opcode;

[0097] Steps 201-203 are the same as steps 101-103. For details, please refer to the description of steps 101-103, which will not be repeated here.

[0098] Step 204: Obtain source code corresponding to each disassembled opcode based on the instruction source code location mapping relationship;

[0099] Step 205, generating a source map using the disassembled opcode and source code;

[0100] A source map is a tool that maps bytecode instructions (i.e., disassembled opcodes) back to source code. To construct a source map, simply follow the instructions line by line in the disassembled opcode file and sequentially find the corresponding content blocks in the JSON file generated by the solc tool. This will allow you to find the begin and end of the source code corresponding to a particular instruction line in the contract file. These pairs of data are then organized to form the source map for the current contract. Later, when executing bytecode instructions, simply knowing the current instruction line allows you to map back to the source code.

[0101] Step 206: Determine the target function of the NFT smart contract based on the abstract syntax tree;

[0102] In actual scenarios, since the sleep casting vulnerability only occurs in functions related to NFT transfer operations in NFT smart contracts, it is possible to traverse the abstract syntax tree AST, analyze the structure of each function in the contract, and determine whether a function is related to token transfer, thereby filtering out the target functions that need to be checked this time, and improving inspection efficiency by avoiding the operation of checking the entire contract.

[0103] In one example, step 206 may include the following sub-steps:

[0104] S61, sequentially obtain the node information of each function of the NFT smart contract in the abstract syntax tree;

[0105] S62, determining whether the node information contains a target node or a reference to a function containing a target node; the target node is a node representing the source code of the transfer event;

[0106] S63, determining the function corresponding to the node information that contains the target node or references the function containing the target node as the target function of the NFT smart contract.

[0107] In practice, the AST information of a smart contract can be obtained through the Solidity compiler's ast command. The AST information is in a structured JSON data format, and all information in the source code is presented in a key-value format within the JSON data structure. Specifically, for source code content, the contract's AST contains key-value pairs with nodeType as the key, which mark the intent and category of source code statements. All source code statements are represented as nodes within the AST's nodes key-value pairs. Therefore, simply by determining whether a function has a target node to which a transfer event sends source code, or whether a function with this target node is called, we can determine whether the function is the target function to be tested.

[0108] Step 207: symbolically execute the target function and construct a control flow graph in combination with the disassembled opcodes;

[0109] In an embodiment of the present invention, a complete control flow graph can be constructed in combination with disassembly opcodes during the symbolic execution process.

[0110] In practice, when analyzing a function / contract, we need to understand what happens during its execution. This requires converting the source code into corresponding low-level bytecode instructions, and then using some rules to construct this series of bytecode instructions into a control flow graph with a graph structure (with nodes and edges): each node is a set of bytecode instructions, and each edge represents the flow direction after the execution of the current node's instructions.

[0111] Step 208 , simulate the execution of the control flow graph in combination with the source mapping, and collect program code information during the execution process;

[0112] In an embodiment of the present invention, the program code information includes at least one of a From parameter, a storage variable, store operation information, execution event sending operation information, and owner information; and the step of simulating the execution of the control flow graph in combination with the source mapping and collecting the program code information during the execution process may include the following sub-steps:

[0113] S81, during the simulation execution of the control flow, when the CALLDATALOAD instruction is executed, obtaining the From parameter;

[0114] S82, when the SLOAD instruction is executed, the storage variables are read from the contract storage space;

[0115] S83, when the execution of the SSTROE instruction is detected, store operation information is generated;

[0116] S84, when the LOG4 instruction is detected to be executed, an execution event is generated and operation information is sent;

[0117] S85, obtain owner information through source mapping.

[0118] In a specific implementation, regarding the bytecode instructions involved in the information collection process, the embodiments of the present invention focus on the following four types:

[0119] CALLDATALOAD: The CALLDATALOAD instruction is executed at the beginning of the function and reads a function parameter of type (u)int256 from the message data. The ERC721 function transferFrom(from, to, tokenId) involving NFT transfers has three parameters. Each execution of the CALLDATALOAD instruction reads a parameter, so the parameter "from" can be obtained from the top of the stack after the first CALLDATALOAD is executed.

[0120] SLOAD: Executing this instruction will read a variable from the contract storage space, so the corresponding storage variable can be naturally collected at the branch of symbolic execution.

[0121] SSTORE: Executing this instruction will write data to the contract storage space. Whether a store operation occurs is determined by recording whether the function executes this instruction.

[0122] LOG4: This instruction corresponds to the sending of a transfer event. Executing this instruction means executing an event sending operation.

[0123] At the same time, the embodiment of the present invention relies on the source code to obtain the NFT owner "owner". According to the ERC721 standard, the owner of the NFT can be obtained by calling the function ownerOf(tokenId), and this function will finally execute the return statement "returnowner". When the function executes this code, the address of the owner will be pushed to the top of the stack. Therefore, during the symbolic execution process, source mapping can be used to monitor the source code corresponding to each instruction. When encountering the "return owner" statement, the "owner" at the top of the stack can be obtained. However, some contracts are not written strictly in accordance with the specifications, such as changing variable names. In order to deal with this situation, the embodiment of the present invention will find the node of the return statement of the ownerOf function through AST to dynamically determine the return statement and improve compatibility.

[0124] Step 209: Perform defect detection on the NFT smart contract based on the program code information.

[0125] In this embodiment of the present invention, step 209 may include the following sub-steps:

[0126] S91, when a constraint is detected that the storage variable is equal to the contract caller address, it is determined that the NFT smart contract has a sleep casting vulnerability;

[0127] S92: When it is detected that the From parameter and owner information meet the preset constraints, it is determined that the NFT smart contract has a sleep casting vulnerability;

[0128] S93: When the store operation information is not generated before the execution event sending operation information is generated, it is determined that the NFT smart contract has a dormant casting risk.

[0129] In this embodiment of the present invention, the endpoint of the program code information is defined as the event sent, namely the LOG4 instruction. This is because, according to the ERC721 standard, the transfer function sends a transfer event at the end. At this endpoint, the analyzer analyzes the collected program code information according to pre-defined detection rules. If there is a conflict between this program code information and the rules, the contract is determined to have a sleep casting vulnerability. For example, the most primitive form of a sleep casting vulnerability is to set a privileged address in the contract, allowing an attacker to freely transfer other people's NFTs using this privileged address. During the symbolic execution process, if a branch condition is encountered, the corresponding storage variable is read through the SLOAD instruction to construct a constraint, which is then collected by the constraint collector. Therefore, if a constraint is detected in the constraint collector at the endpoint of a possible path that indicates that a suspicious address (storage variable) is equal to the contract caller's address, it can be determined that a feasible path in this function allows an attacker to transfer other people's tokens through the privileged address, indicating that a sleep casting vulnerability exists.

[0130] Another example is an extended type of sleep casting: one that doesn't constrain the "From" parameter. In this type, the "From" parameter doesn't have to equal the NFT owner. This allows an attacker to manipulate the value of the "From" parameter (i.e., the transfer origin) when the final transfer event is sent to forge the transfer event. For example, an NFT that was actually transferred from A to B could be forged in a broadcast as "from C to B." This could easily mislead other blockchain users and lead to a misjudgment of the NFT's value. To address this type of sleep casting, the analyzer uses the collected "from" and "owner" data to construct a constraint that contradicts the specification, namely, "from != owner," and adds this constraint to the constraint collector. If the contract function correctly constrains the "From" parameter according to the specification, the corresponding constraint condition will be mutually exclusive with the newly constructed condition, rendering the constraint collector unsolvable. Conversely, if the constraint collector still finds a solution after adding the newly constructed constraint, it indicates that the function did not correctly constrain the "From" parameter on this path, leading to the sleep casting vulnerability.

[0131] Furthermore, if the detection endpoint (i.e., the sending of a transfer event) is reached without any store operations (SSTORE instructions) occurring during symbolic execution, this function is specifically used to broadcast NFT transfer information to blockchain users. If this information is manipulated by an attacker, resulting in the broadcast of an incorrect transfer information, sleep casting can also occur.

[0132] According to the above detection rules, the analyzer can well determine whether there is a sleep casting vulnerability based on the collected program code information.

[0133] After completing the vulnerability detection, the vulnerability detection results must be output through the vulnerability identifier.

[0134] Based on symbolic execution technology, this invention detects and locates possible sleep casting vulnerabilities in NFT smart contracts according to the characteristics of sleep casting vulnerabilities, thereby finding problems between deployed contracts and avoiding deploying problematic contracts on the chain and being exploited by attackers.

[0135] See also Figure 3 , Figure 3 This is an architectural diagram of an NFT smart contract defect detection method provided by an embodiment of the present invention. Specifically, it may include the following parts:

[0136] 1. Input Module: This module uses open-source contracts on EtherScan or developer-written contract source code as program input. It compiles the smart contract using the Solidity compiler and collects the compilation outputs: AST, instruction source code location mapping, and contract bytecode. It then constructs a source map using the instruction source code location mapping file, and decompiles the contract bytecode to generate disassembled opcodes.

[0137] 2. Target function selection module: Since the sleep casting vulnerability only occurs in functions related to NFT transfer operations in NFT contracts, this module traverses the AST generated by the input module, analyzes the structure of each function in the contract, and determines whether a function is related to token transfer, thereby filtering out the target functions that need to be checked this time, and improving the inspection efficiency by avoiding the operation of checking the entire contract.

[0138] 3. Control Flow Graph Generator: During the symbolic execution process, the complete control flow graph (CFG) is constructed by combining the opcode information.

[0139] 4. Information Collection: During symbolic execution, program code information is collected to provide a basis for subsequent vulnerability analysis. Key information includes: the owner (NFT owner), storage variables involved in the NFT transfer process, bytecode-level store (storage) and log (event sending) operations, and the "From" parameter passed in when the user externally calls the NFT contract transfer function, where "From" represents the starting address of the token transfer. This key information is associated with specific instructions in the opcode. Since symbolic execution is based on the opcode, this key information can be identified and collected during symbolic execution.

[0140] 5. Analyzer: In this embodiment of the present invention, the endpoint of "information collection" is defined as the event sending, namely the LOG4 instruction. This is because according to the ERC721 standard, the transfer function sends the transfer event at the end. At this endpoint, the analyzer analyzes the collected key information according to pre-defined detection rules. If this key information conflicts with the rules, the contract is determined to have a sleep casting vulnerability.

[0141] 6. Vulnerability Identifier: Outputs vulnerability detection results based on the analysis results completed by symbolic execution.

[0142] See also Figure 4 , Figure 4 This is a structural block diagram of an NFT smart contract defect detection device provided by an embodiment of the present invention.

[0143] An embodiment of the present invention provides an NFT smart contract defect detection device, comprising:

[0144] NFT smart contract acquisition module 401, used to obtain NFT smart contracts;

[0145] Compilation module 402, used to compile the NFT smart contract and collect the abstract syntax tree, instruction source code location mapping relationship and contract bytecode;

[0146] Disassembly opcode generation module 403, used to decompile contract bytecode to generate disassembly opcode;

[0147] A source map building module 404 is used to build a source map using a mapping relationship between disassembled opcodes and instruction source code locations;

[0148] An objective function determination module 405 is configured to determine an objective function of the NFT smart contract based on the abstract syntax tree;

[0149] A control flow graph construction module 406 is used to perform symbolic execution on the target function and construct a control flow graph in combination with the disassembled opcodes;

[0150] A program code information collection module 407 is used to simulate the execution of the control flow graph in combination with the source map and collect program code information during the execution process;

[0151] The defect detection module 408 is used to perform defect detection on the NFT smart contract based on program code information.

[0152] In this embodiment of the present invention, the source mapping construction module 404 includes:

[0153] The source code acquisition submodule is used to obtain the source code corresponding to each disassembled opcode based on the instruction source code position mapping relationship;

[0154] The source map generation submodule is used to generate source maps using disassembled opcodes and source code.

[0155] In this embodiment of the present invention, the objective function determination module 405 includes:

[0156] The node information acquisition submodule is used to sequentially obtain the node information of each function of the NFT smart contract in the abstract syntax tree;

[0157] The judgment submodule is used to judge whether there is a target node or a reference to a function containing a target node in the node information; the target node is a node representing the source code of the transfer event;

[0158] The target function determination submodule is used to determine the function corresponding to the node information that contains the target node or references the function containing the target node as the target function of the NFT smart contract.

[0159] In an embodiment of the present invention, the program code information includes at least one of a From parameter, a storage variable, store operation information, execution event sending operation information, and owner information; the program code information collection module 407 includes:

[0160] The From parameter acquisition submodule is used to obtain the From parameter when the CALLDATALOAD instruction is executed during the simulation execution of the control flow;

[0161] The storage variable reading submodule is used to read storage variables from the contract storage space when the SLOAD instruction is executed;

[0162] The store operation information generation submodule is used to generate store operation information when the SSTROE instruction is detected to be executed;

[0163] The execution event sending operation information generation submodule is used to generate the execution event sending operation information when the LOG4 instruction execution is detected;

[0164] The owner information acquisition submodule is used to obtain owner information through source mapping.

[0165] In this embodiment of the present invention, the defect detection module 408 includes:

[0166] The first determination submodule is used to determine that the NFT smart contract has a sleep casting vulnerability when a constraint that the storage variable is equal to the contract caller address is detected;

[0167] The second judgment submodule is used to determine that the NFT smart contract has a sleep casting vulnerability when it detects that the From parameter and owner information meet the preset constraints;

[0168] The third determination submodule is used to determine whether the NFT smart contract has a dormant casting risk when store operation information is not generated before the execution event sending operation information is generated.

[0169] The present invention further provides an electronic device, comprising a processor and a memory:

[0170] The memory is used to store program codes and transmit the program codes to the processor;

[0171] The processor is used to execute the NFT smart contract defect detection method of an embodiment of the present invention according to the instructions in the program code.

[0172] An embodiment of the present invention also provides a computer-readable storage medium, which is used to store program code, and the program code is used to execute the NFT smart contract defect detection method of an embodiment of the present invention.

[0173] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0174] 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.

[0175] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, apparatus, or computer program products. Thus, embodiments of the present invention may take the form of a fully hardware embodiment, a fully software embodiment, or an embodiment combining software and hardware. Furthermore, embodiments of the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0176] The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1A device that provides the functions specified in a block or multiple blocks.

[0177] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0178] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0179] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they become aware of the basic creative concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0180] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or terminal device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or terminal device that includes the element.

[0181] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that the technical solutions described in the above embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for detecting defects in NFT smart contracts, characterized in that: include: Get the NFT smart contract; Compile the NFT smart contract and collect the abstract syntax tree, instruction source code location mapping, and contract bytecode; Decompile the contract bytecode to generate disassembled opcode; Constructing a source map using the mapping relationship between the disassembled opcode and the instruction source code position; Determine the target function of the NFT smart contract according to the abstract syntax tree; Performing symbolic execution on the target function and constructing a control flow graph in combination with the disassembled opcodes; Simulating the execution of the control flow graph in combination with the source mapping to collect program code information during the execution process; Perform defect detection on the NFT smart contract based on the program code information; The program code information includes at least one of a From parameter, a storage variable, store operation information, execution event sending operation information, and owner information; and the step of simulating the execution of the control flow graph in combination with the source mapping and collecting the program code information during the execution process includes: During the simulation execution of the control flow graph, when the CALLDATALOAD instruction is executed, the From parameter is obtained; When the SLOAD instruction is executed, the storage variables are read from the contract storage space; When the SSTROE instruction is detected, store operation information is generated; When the LOG4 instruction is detected to be executed, an execution event is generated and the operation information is sent; Obtain owner information through the source mapping; The step of performing defect detection on the NFT smart contract based on the program code information includes: When it is detected that the storage variable is equal to the contract caller address, it is determined that the NFT smart contract has a sleep casting vulnerability; When it is detected that the From parameter and the owner information meet the preset constraints, it is determined that the NFT smart contract has a sleep casting vulnerability; When store operation information is not generated before the execution event sending operation information is generated, it is determined that the NFT smart contract has a dormant casting risk.

2. The method according to claim 1, characterized in that The step of constructing a source map using the mapping relationship between the disassembled opcode and the instruction source code position includes: According to the instruction source code position mapping relationship, the source code corresponding to each disassembled opcode is obtained; A source map is generated using the disassembled opcodes and the source code.

3. The method according to claim 1, characterized in that The step of determining the target function of the NFT smart contract according to the abstract syntax tree includes: Obtain node information of each function of the NFT smart contract in the abstract syntax tree in sequence; Determine whether the node information contains a target node or references a function containing the target node; the target node is a node representing the source code of the transfer event; The function corresponding to the node information that contains the target node or references the function containing the target node is determined as the target function of the NFT smart contract.

4. An NFT smart contract defect detection device, characterized in that: include: NFT smart contract acquisition module, used to obtain NFT smart contracts; A compilation module, used to compile the NFT smart contract and collect the abstract syntax tree, instruction source code location mapping relationship and contract bytecode; A disassembly opcode generation module, used to decompile the contract bytecode to generate a disassembly opcode; A source map construction module, configured to construct a source map using a mapping relationship between the disassembled opcode and the instruction source code position; An objective function determination module, configured to determine an objective function of the NFT smart contract based on the abstract syntax tree; A control flow graph construction module, configured to perform symbolic execution on the target function and construct a control flow graph in combination with the disassembled opcode; A program code information collection module, configured to simulate execution of the control flow graph in combination with the source mapping, and collect program code information during the execution process; A defect detection module, configured to perform defect detection on the NFT smart contract based on the program code information; The program code information includes at least one of a From parameter, a storage variable, store operation information, execution event sending operation information, and owner information; and the program code information collection module includes: The From parameter acquisition submodule is used to obtain the From parameter when the CALLDATALOAD instruction is executed during the simulation execution of the control flow graph; The storage variable reading submodule is used to read storage variables from the contract storage space when the SLOAD instruction is executed; The store operation information generation submodule is used to generate store operation information when the SSTROE instruction is detected to be executed; The execution event sending operation information generation submodule is used to generate the execution event sending operation information when the LOG4 instruction execution is detected; The owner information acquisition submodule is used to obtain owner information through source mapping; The defect detection module includes: The first determination submodule is used to determine that the NFT smart contract has a sleep casting vulnerability when a constraint that the storage variable is equal to the contract caller address is detected; The second judgment submodule is used to determine that the NFT smart contract has a sleep casting vulnerability when it detects that the From parameter and owner information meet the preset constraints; The third determination submodule is used to determine whether the NFT smart contract has a dormant casting risk when store operation information is not generated before the execution event sending operation information is generated.

5. The device according to claim 4, characterized in that The source map construction module includes: A source code acquisition submodule is used to obtain the source code corresponding to each disassembled opcode according to the instruction source code position mapping relationship; The source map generation submodule is configured to generate a source map using the disassembly operation code and the source code.

6. The device according to claim 4, characterized in that The objective function determination module includes: A node information acquisition submodule, used to sequentially obtain the node information of each function of the NFT smart contract in the abstract syntax tree; A judgment submodule, configured to judge whether the node information contains a target node or references a function containing the target node; the target node is a node representing the source code of the transfer event; The target function determination submodule is used to determine the function corresponding to the node information that contains the target node or references the function containing the target node as the target function of the NFT smart contract.

7. An electronic device, characterized in that: The device includes a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the NFT smart contract defect detection method described in any one of claims 1-3 according to the instructions in the program code.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium is used to store program code, and the program code is used to execute the NFT smart contract defect detection method described in any one of claims 1-3.

Images