NFT smart contract defect detection method, apparatus and device, and storage medium

Abstract

The invention discloses an NFT intelligent contract defect detection method, device and equipment and a storage medium, and is used for solving the technical problems that an existing detection method depends on the number of generated attack transactions, attack diffusion can only be prevented to a certain extent, and attack cannot be prevented from occurring at the beginning. The method comprises the following steps: acquiring an NFT smart contract; compiling an NFT smart contract, and collecting an abstract syntax tree, an instruction source code position mapping relation and a contract byte code; decompiling the contract byte code to generate a disassembling operation code; constructing source mapping by adopting a position mapping relation between a disassembling operation code and an instruction source code; determining a 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 diagram in combination with a disassembly operation code; performing simulation execution on the control flow diagram in combination with source mapping, and collecting program code information in the execution process; and performing defect detection on the NFT smart contract according to 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] Sleep casting is a potential security vulnerability or malicious behavior related to NFT (non-fungible token) smart contracts. It involves a deceptive way that an attacker can temporarily send an NFT to a famous wallet address (such as the address 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 as if it once belonged to a well-known owner, which may increase its value or attract buyer interest. Sleep casting requires two steps to work:

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

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

[0005] Once these operations occur to famous NFT makers, attackers can use the names of celebrities to give false values ​​to their NFTs and make profits. 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] The prior art proposes a prevention system to reduce the number of sleep casting attacks. The prevention system is based on analyzing transactions included in new blocks, detecting transactions related to sleep casting attacks and tracking the addresses involved in these transactions. The addresses involved can be tracked using a dictionary-like data structure, where the key is the address and the value acts as a counter of the number of times the address has participated in sleep casting. With this information, the block creation node can add another verification step before adding the transaction to the block, that is, blocking the transaction when the number of times the address involved has appeared in a sleep casting attack exceeds a threshold.

[0007] The above prevention system detects sleep casting issues from the perspective of transactions, and blocks related transactions only when the number of times the address involved appears in a sleep casting attack exceeds a threshold. However, this detection method relies on the number of attack transactions generated, and can only prevent the spread of attacks to a certain extent, and cannot prevent attacks from happening from the beginning. 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 an NFT smart contract, comprising:

[0010] Get the NFT smart contract;

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

[0012] Decompiling 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 objective 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;

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

[0018] Optionally, the step of constructing a source map by 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 objective 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 there is a target node or a reference to a function containing the target node in the node information; the target node is a node representing the source code of the transfer event;

[0024] The function corresponding to the node information that has a target node or references a 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, a store operation information, an execution event sending operation information, and an 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:

[0026] In the process of simulating the 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 to be executed, store operation information is generated;

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

[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, 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, used to construct a source map using the mapping relationship between the disassembled opcode and the instruction source code position;

[0040] An objective function determination module, used to determine the objective function of the NFT smart contract according to the abstract syntax tree;

[0041] A control flow graph construction module, used for symbolically executing the target function and constructing a control flow graph in combination with the disassembled opcode;

[0042] A program code information collection module, used to simulate the 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, used to acquire the source code corresponding to each disassembled opcode according to the instruction source code position mapping relationship;

[0046] The source map generation submodule is used 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 acquire the node information of each function of the NFT smart contract in the abstract syntax tree;

[0049] A judgment submodule, used to judge whether there is a target node or a reference to a function containing the target node in the node information; 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 also provides an electronic device, the 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 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 of the above items.

[0055] It can be seen from the above technical scheme 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 NFT smart contracts; compiling NFT smart contracts, collecting abstract syntax trees, instruction source code position mapping relationships, and contract bytecodes; decompiling contract bytecodes to generate disassembled opcodes; using disassembled opcodes and instruction source code position mapping relationships to construct source mappings; determining the target function of the NFT smart contract according to the abstract syntax tree; symbolically executing 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, and collecting program code information during the execution process; and performing defect detection on the NFT smart contract according to 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 sleep casting vulnerabilities, 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 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 some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

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

[0058] Figure 2 A flowchart of a method for detecting an NFT smart contract provided by 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 4A structural block diagram of an NFT smart contract defect detection device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0061] The embodiments of the present invention provide 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.

[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 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 in an embodiment of the present invention.

[0064] The present invention provides a method for detecting defects in an NFT smart contract, which may specifically include:

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

[0066] NFT (Non-Fungible Token): is a digital asset based on blockchain technology that is unique and irreplaceable. Each NFT represents a specific item or content, such as artwork, music, game props, etc., and can prove its ownership and authenticity. Unlike traditional homogeneous tokens, each unit of NFT is unique and cannot be interchanged.

[0067] Smart contracts: Smart contracts are a major feature of the blockchain 2.0 era. By storing code in the blockchain and being tamper-proof once deployed, smart contracts have Turing-complete features and can run code to complete pre-defined behaviors when certain conditions are met, including transfers, decision-making, and interaction with other contracts. Based on the characteristics of blockchain, the results of smart contracts are run and verified by a large number of computers to ensure credibility. Solidity is currently the most popular smart contract language. This method is only for the Solidity language and the EVM (Ethereum Virtual Machine) that supports the operation of Solidity smart contracts.

[0068] Step 102, compile the NFT smart contract, 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 abstract syntax tree generated by the source code can provide semantic information of the idiom.

[0071] In the embodiment of the present invention, the open source contract on EtherScan or the contract source code written by the developer can be used as the program input. The smart contract is compiled by the Solidity compiler, and the output of the compilation process is collected: AST, instruction source code location mapping relationship and contract bytecode. Then the contract bytecode is decompiled to obtain the disassembled opcode.

[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 in combination with the instruction source code location mapping relationship.

[0074] In the embodiment of the present invention, the solc tool can be used. By calling the solc tool with "solc --combined-json asm", the "instruction source code location mapping file" of 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 the 12388th to 20707th characters in the contract file. In order, each line of instruction will correspond to a piece of such content in this json file.

[0077] Source mapping is a tool that maps bytecode instructions (i.e., disassembled opcodes) back to source code. Therefore, to build a source map, you only need to find the corresponding content blocks in the json file generated by the solc tool in order according to the instructions line by line in the disassembled opcode file, and you can find the begin and end of the source code corresponding to a certain line of instruction in the contract file. Then, organize these pairs of data to form the source map of the current contract. When executing bytecode instructions later, as long as you know which line of instructions is currently, you can map it back to the source code.

[0078] Step 105, determining the target function of the NFT smart contract according to 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 of the contract, and determine whether a function is related to token transfer, thereby filtering out the target function that needs to be checked this time, and improving inspection efficiency by avoiding the operation of checking the entire contract.

[0080] Step 106, symbolically executing the target function and constructing a control flow graph in combination with the disassembled opcodes;

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

[0082] The core of symbolic execution is to create a state tree, where each node represents a state of the program and each edge represents an execution step. When the symbolic execution engine encounters a conditional branch, it generates new conditions for each branch, thereby expanding the state tree. By solving the logical conditions of this path, researchers can find the symbolic input that leads to a specific output or error. This process usually uses a satisfiability solver (SAT solver) to solve the generated logical formula.

[0083] Symbolic execution is widely used in software testing, security analysis, and vulnerability detection. It can effectively discover 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 in advance 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 in compilers and maintained internally by the compiler. It represents all the paths that a program will traverse during execution. It uses a graph to represent the possible flow of execution of all basic blocks within a process, and can also reflect the real-time execution of a process.

[0085] In the embodiment of the present invention, a complete control flow graph can be constructed in combination with the disassembly opcode 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 the 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 the specific implementation, the analyzer can analyze the collected program code information according to the pre-defined detection rules. If there is a conflict between the program code information and the rules, it is judged that the contract has a sleep casting vulnerability.

[0091] Based on symbolic execution technology, the present invention detects and locates possible sleep casting vulnerabilities in NFT smart contracts according to the characteristics of sleep casting vulnerabilities, so as to find problems between deployed contracts and avoid deploying problematic contracts on the chain to be 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 NFT smart contract detection method provided by an embodiment of the present invention may specifically include the following steps:

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

[0095] Step 202, compile the NFT smart contract, collect the abstract syntax tree, instruction source code location mapping relationship 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, obtaining source codes corresponding to each disassembled opcode according to the instruction source code position mapping relationship;

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

[0100] Source mapping is a tool that maps bytecode instructions (i.e., disassembled opcodes) back to source code. Therefore, to build a source map, you only need to find the corresponding content blocks in the json file generated by the solc tool in order according to the instructions line by line in the disassembled opcode file, and you can find the begin and end of the source code corresponding to a certain line of instruction in the contract file. Then, organize these pairs of data to form the source map of the current contract. When executing bytecode instructions later, as long as you know which line of instructions is currently, you can map it back to the source code.

[0101] Step 206, determining the target function of the NFT smart contract according to 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 of the contract, and determine whether a function is related to token transfer, thereby filtering out the target function that needs 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 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;

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

[0107] In the specific implementation, the AST information of the smart contract can be obtained through the ast instruction of the Solidity compiler. The AST information is in a structured json data format, and all the information in the source code will be displayed in the json data structure in the form of key-value. In particular, for the content in the source code, the AST of the contract has a key-value pair with nodeType as the key to mark the intent and category of the source code statement. All source code statements will be expressed in the form of nodes in the nodes key-value pair of AST. Therefore, as long as it is determined whether a function has a target node for sending the source code in a transfer event or whether a function with this target node is called, it can be determined whether this function is the target function to be detected.

[0108] Step 207, symbolically executing the target function and constructing a control flow graph in combination with the disassembled opcodes;

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

[0110] In the specific implementation, when analyzing a function / contract, we need to know what happens during their execution. This requires converting them from the source code into corresponding low-level bytecode instructions, and then constructing this series of bytecode instructions into a control flow graph with a graph structure (with nodes and edges) through some rules: each node is a set of bytecode instructions, and each edge represents the flow direction after the current node instruction is executed.

[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, a store operation information, an execution event sending operation information, and an 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, the From parameter is obtained;

[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 to send operation information;

[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 instruction CALLDATALOAD will be executed at the beginning of the function and read a function parameter of type (u)int256 from the message data. The function transferFrom(from, to, tokenId) involving NFT transfer in ERC721 has three parameters. Each time the CALLDATALOAD instruction is executed, a parameter will be read, 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. By recording whether the function executes this instruction, it can be determined whether there is a store operation.

[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 call the function ownerOf(tokenId) to obtain it, 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 the embodiment of the present invention, step 209 may include the following sub-steps:

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

[0127] S92: 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;

[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 an embodiment of the present invention, the end point of the program code information is defined at the event sending, i.e., the LOG4 instruction, because according to the ERC721 standard, the transfer function will send the transfer event at the end. At the end point, the analyzer will analyze the collected program code information according to the pre-established detection rules. If there is a conflict between these program information and the rules, it is determined that this contract has a sleep casting vulnerability. For example, the most primitive form of the sleep casting vulnerability is to set a privileged address in the contract, and the attacker can freely transfer other people's NFTs with this privileged address. In the process of symbolic execution, if a branch condition is encountered, the corresponding storage variable will be read through the SLOAD instruction to build a constraint, and this constraint will be collected by the constraint collector. Therefore, if a constraint that a suspicious address (storage variable) is equal to the contract caller address is detected in the constraint collector at the detection end point of a possible path, it can be determined that there is a feasible path for this function to allow attackers to transfer other people's tokens through the privileged address, that is, there is a sleep casting vulnerability.

[0130] Another example is an extended type of sleep casting: no constraint on the parameter "From". In this type, the parameter "From" does not have to be equal to the NFT owner, which means that when the final transfer event is sent, the attacker can forge the transfer event by controlling the value of the parameter "From" (i.e. the transfer starting point). In other words, the NFT that was actually transferred from A to B can be forged as "transferred from C to B" in the broadcast. Other blockchain users are likely to misunderstand this broadcast information and may misjudge the value of this NFT. For this type of sleep casting, the analyzer will use the collected "from" and "owner" to construct a constraint that is opposite to the specification, that is, "from != owner", and add this constraint to the constraint collector. If the contract function correctly constrains the parameter "From" according to the specification, the corresponding constraint condition will be mutually exclusive with the newly constructed condition of the analyzer, making the constraint collector unsolvable. On the contrary, if the constraint collector still has a solution after adding the newly constructed constraint, it means that the function did not correctly constrain the parameter "From" on this path, which will lead to the occurrence of the sleep casting vulnerability.

[0131] At the same time, if the detection endpoint (i.e. the sending of the transfer event) is reached without any store operation (SSTORE instruction) during symbolic execution, it means that this function is specifically used to broadcast NFT transfer information to blockchain users. If the content of this information is manipulated by an attacker and the wrong transfer information is broadcast, the consequences of sleep casting will 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, the present invention detects and locates possible sleep casting vulnerabilities in NFT smart contracts according to the characteristics of sleep casting vulnerabilities, so as to find problems between deployed contracts and avoid deploying problematic contracts on the chain to be exploited by attackers.

[0135] See also Figure 3 , Figure 3 This is an architecture 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: Use the open source contracts on EtherScan or the contract source code written by the developer as program input. Compile the smart contract through the Solidity compiler and collect the output of the compilation process: AST, the mapping relationship of the instruction source code position and the contract bytecode. Then use the mapping relationship file of the instruction source code position to build the source map, and use the contract bytecode to decompile to get the disassembled opcode.

[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 of the contract, and determines whether a function is related to token transfer, thereby filtering out the target function that needs 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 (Control Flow Graph) is constructed by combining the opcode information.

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

[0140] 5. Analyzer: In the embodiment of the present invention, the end point of "information collection" is defined at the event sending, i.e., the LOG4 instruction, because according to the ERC721 standard, the transfer function will send the transfer event at the end. At the end point, the analyzer will analyze the collected key information according to the pre-established detection rules. If these key information and rules conflict, it is determined that this contract has 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 A structural block diagram of an NFT smart contract defect detection device provided in an embodiment of the present invention.

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

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

[0145] Compilation module 402, used to compile NFT smart contracts, collect abstract syntax trees, instruction source code location mapping relationships and contract bytecodes;

[0146] The disassembly operation code generation module 403 is used to decompile the contract bytecode to generate the disassembly operation code;

[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 positions;

[0148] The target function determination module 405 is used to determine the target function of the NFT smart contract according to 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 mapping 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 the 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 according to 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 the 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] A 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 the embodiment of the present invention, the program code information includes at least one of a From parameter, a storage variable, a store operation information, an execution event sending operation information, and an 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 execution of the SSTROE instruction is detected;

[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 determination submodule is used to determine 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;

[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 also provides an electronic device, the device comprising a processor and a memory:

[0170] The memory is used to store the program code and transmit the program code 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 can 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] It will be appreciated by those skilled in the art that the embodiments of the present invention may be provided as methods, devices, or computer program products. Therefore, the embodiments of the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the 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 disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[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 generate 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 capable of directing 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 A 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 have learned the basic creative concept. 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 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 terminal 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 terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[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 aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may 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 relationship and contract bytecode; Decompiling 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 objective 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; Perform defect detection on the NFT smart contract based on the program code information.

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 objective function of the NFT smart contract according to the abstract syntax tree comprises: Obtain node information of each function of the NFT smart contract in the abstract syntax tree in sequence; Determine whether there is a target node or a reference to a function containing the target node in the node information; the target node is a node representing the source code of the transfer event; The function corresponding to the node information that has a target node or references a function containing the target node is determined as the target function of the NFT smart contract.

4. The method according to claim 1, characterized in that The program code information includes at least one of a From parameter, a storage variable, a store operation information, an execution event sending operation information, and an owner information; 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: In the process of simulating the execution of the control flow, 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 to be executed, store operation information is generated; When the LOG4 instruction is detected to be executed, an execution event is generated to send the operation information; Get the owner information through the source map.

5. The method according to claim 4, characterized in that The step of performing defect detection on the NFT smart contract according to 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.

6. 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, 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, used to construct a source map using the mapping relationship between the disassembled opcode and the instruction source code position; An objective function determination module, used to determine the objective function of the NFT smart contract according to the abstract syntax tree; A control flow graph construction module, used for symbolically executing the target function and constructing a control flow graph in combination with the disassembled opcode; A program code information collection module, used to simulate the 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 is used to perform defect detection on the NFT smart contract based on the program code information.

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

8. The device according to claim 6, characterized in that The objective function determination module comprises: A node information acquisition submodule, used to sequentially acquire the node information of each function of the NFT smart contract in the abstract syntax tree; A judgment submodule, used to judge whether there is a target node or a reference to a function containing the target node in the node information; 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.

9. An electronic device, characterized in that: The device comprises 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-5 according to the instructions in the program code.

10. 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-5.

Images