An Ethereum Phishing Scam Contract Detection Method Based on Transaction Simulation Execution

Abstract

The present invention discloses a method for detecting Ethereum phishing and fraud contracts based on transaction simulation execution. Taking the bytecode of an Ethereum smart contract as input, it identifies suspicious functions related to phishing and fraud behaviors by analyzing the bytecode, including identifying payable functions through function selectors and identifying batch call functions by analyzing the operation sequence of loading call data in the bytecode. Combining transaction simulation execution technology, it automatically generates transaction parameters and calls the suspicious functions, and determines whether the target contract is a phishing and fraud contract according to the results of the simulation execution. The present invention realizes accurate identification and marking of phishing and fraud contracts, can effectively detect common and highly harmful phishing and fraud contracts; the method is efficiently implemented, has a high degree of automation, is applicable to large-scale smart contract detection, and helps to improve the security and credibility of the blockchain smart contract ecosystem.

Description

Technical Field

[0001] The present invention relates to the field of computer networks, and particularly to a method for detecting Ethereum phishing fraud contracts based on transaction simulation execution. Background Art

[0002] With the continuous evolution of blockchain technology and the increasing richness of application scenarios, decentralized platforms such as Ethereum have become an important cornerstone in the blockchain field. As the most widely used smart contract platform globally, Ethereum has not only made breakthroughs in multiple fields such as decentralized finance, digital art, and gaming but also provided developers with a powerful infrastructure to support the construction and operation of decentralized applications. Its open-source, transparent, and permissionless characteristics enable any developer to publish smart contracts on the Ethereum network and interact with global users. However, it is precisely these open and decentralized characteristics that pose unprecedented challenges to regulation and security protection. Since the code of a smart contract cannot be modified once deployed on the blockchain, any defect or vulnerability in the code logic can be maliciously exploited, resulting in irreversible economic losses. In addition, the anonymity of the Ethereum network allows malicious attackers to easily hide their identities, and even if they successfully steal assets, it is very difficult to be traced and punished. These factors have led to the increasing prevalence of fraud in the blockchain ecosystem, especially the rapid spread of phishing scam contracts, which seriously threaten the security of user assets. Phishing scam contracts are a type of malicious contract with concealment and deception. They deceive users into performing specific operations through sophisticated function and transaction logics, thereby stealing users' digital assets. These digital assets include not only Ether (hereinafter referred to as ETH) but also tokens based on the ERC20 standard and digital collectibles based on non-fungible token (hereinafter referred to as NFT) technology. In practical applications, phishing scam contracts mainly steal users' assets through the following two modes: (1) Stealing ETH through empty Payable functions: The Payable function is a special function in Ethereum smart contracts used to receive ETH transfers; when a user calls a Payable function, an ETH transfer can be attached. Phishing scams usually design highly misleading function names such as "Claim", "Rewards", or "Bonus" to attract users to call; however, these functions actually do not perform any substantial operations except receiving the ETH transferred by users, and users will not receive any rewards; this mode takes advantage of users' expectation of rewards and has become one of the most common means in phishing scams. (2) Stealing ERC20 tokens and NFTs using the Multicall function: The Multicall function is an advanced call feature that allows multiple operations or function calls to be executed simultaneously in a single transaction. Phishing scams use the Multicall function to flexibly combine various call parameters to achieve the purpose of stealing ERC20 tokens or NFTs; for example, they may use the transfer permissions authorized by the victim to transfer ERC20 tokens or NFTs from the victim's account to an address controlled by the attacker.

[0003] The widespread existence of phishing scam contracts has brought many negative impacts to the entire Ethereum ecosystem, including the following aspects: ① User asset security is damaged: Due to the irreversibility of blockchain transactions, once a user authorizes or transfers funds to a phishing scam contract, the assets cannot be retrieved, causing serious losses to individual investors. ② Market trust declines: Frequent phishing scam incidents make new users skeptical about the security of blockchain technology, affecting the user growth of the entire ecosystem. ③ The decentralized finance ecosystem is impacted: Many decentralized finance (DeFi) protocols rely on smart contracts for asset management. After hackers obtain user authorization using phishing scam contracts, the entire protocol's fund pool may be attacked.

[0004] To evade supervision and detection, most phishing scams often do not upload the source code of the contract after deployment. This results in the public and developers being unable to directly view the specific implementation logic of the contract and can only analyze it by parsing the contract's bytecode. This behavior increases the difficulty of detecting malicious contracts and makes ordinary users more vulnerable to phishing scams. Traditional static analysis tools mainly rely on pattern matching of contract source code and bytecode analysis and are difficult to detect contracts without publicly disclosed source code. At the same time, many detection systems rely on blacklists of known malicious contract addresses, but attackers usually change addresses within a short period, significantly reducing the timeliness and effectiveness of the blacklists. To build a secure and trustworthy blockchain ecosystem, there is an urgent need to develop efficient, real-time, and scalable detection methods for phishing scam contracts. Summary of the Invention

[0005] Aiming at the deficiencies of the prior art, the present invention proposes an Ethereum phishing scam contract detection method based on transaction simulation execution.

[0006] The specific technical solution is as follows:

[0007] An Ethereum phishing scam contract detection method based on transaction simulation execution includes the following steps:

[0008] S1: For the Ethereum smart contract to be detected, analyze its bytecode and identify suspicious functions related to phishing scam behaviors; the suspicious functions include payable functions and batch call functions; the payable functions are identified through function selectors; the batch call functions are identified by analyzing the operation sequence of the bytecode for loading call data;

[0009] S2: Invoke the identified suspicious functions for transaction simulation execution;

[0010] S3: According to the transaction simulation execution results and preset determination rules, combined with the behavior patterns of the suspicious functions and the asset flow situation, determine whether the Ethereum smart contract to be detected is a phishing scam contract.

[0011] Further, in S1, the payable functions are identified through a function selector, which specifically includes the following sub-steps:

[0012] (1.1) Extract the function selector from the smart contract bytecode and identify all callable functions in the smart contract through the function selector;

[0013] (1.2) Traverse all callable functions and determine whether the function contains both CallValue and a rollback instruction. If not, it means the function has the ability to receive Ether and is a payable function, and step (1.3) is continued; if so, it means the function does not have the ability to receive Ether and the smart contract is not a phishing scam contract targeting Ether;

[0014] (1.3) Query the Ethereum signature database to determine whether the function selector is registered. If so, step (1.4) is continued; otherwise, the smart contract is not a phishing scam contract targeting Ether;

[0015] (1.4) Determine whether the function name contains suspicious keywords. If so, mark the payable function as suspicious; otherwise, the smart contract is not a phishing scam contract targeting Ether; the suspicious keywords include: claim, reward, receive tokens.

[0016] Further, in S1, the batch call functions are identified by analyzing the operation sequence of bytecode loading call data, and the specific operations are as follows:

[0017] Analyze the operation sequence of bytecode loading call data and determine whether the parameter type of the function is (address,bytes)[] or (address[],bytes[]). If so, the function is a Multicall function;

[0018] For the bytecode of the Multicall function with the parameter type of (address,bytes)[], the address, length, and byte data of the (address,bytes) array are loaded through CallDataLoad in sequence;

[0019] For the bytecode of the Multicall function with the parameter type of (address[],bytes[]), the address, length, address data of the address array, and the address, length, and byte data of the bytes array are loaded through CallDataLoad in sequence.

[0020] Further, for the payable functions, S2 is specifically implemented through the following sub-steps:

[0021] S2.1: Generate transaction parameters according to the payable function, randomly set the Ether value and contract caller of the transaction, and conduct the first transaction simulation;

[0022] S2.2: Determine whether the transaction simulation execution is successful. If successful, continue to execute S3; if failed, determine that the smart contract is not a phishing fraud contract targeting Ether.

[0023] Furthermore, for the batch call function, S2 is specifically implemented through the following sub-steps:

[0024] S2.1: Generate transaction parameters according to the batch call function, construct a phishing scenario and randomly set the contract caller, and conduct the first transaction simulation;

[0025] S2.2: Determine whether the transaction simulation execution is successful. If successful, continue to execute S3; if the failure causes the transaction to roll back, adjust the transaction parameters according to the reason for the transaction rollback, and re-conduct the transaction simulation and judgment;

[0026] For the reason of transaction rollback where the transaction simulation execution can only be successful when the caller address conforms to the pre-set phishing account address, extract and compare the operation parameters through the Debug_traceCall function of the local Geth node, obtain the phishing account address, and modify the transaction parameters accordingly, and re-conduct the transaction simulation and judgment.

[0027] Furthermore, in S3, for the payable function, if the transaction simulation execution result is that only the Ether sent by the user is received and no reward tokens are returned or no on-chain events are triggered, determine that the Ethereum smart contract to be detected is a phishing fraud contract;

[0028] For the batch call function, if the transaction simulation execution result is that the smart contract only allows specific phishing account addresses to be successfully called and the user assets are transferred after the successful call, determine that the Ethereum smart contract to be detected is a phishing fraud contract.

[0029] An Ethereum phishing fraud contract detection system based on transaction simulation execution, including: a suspicious function extraction module, a transaction simulation execution module, and a phishing fraud contract determination module;

[0030] The suspicious function extraction module is used to receive the bytecode of the Ethereum smart contract to be detected, analyze the bytecode, and identify the suspicious functions related to phishing fraud behavior in the smart contract; the suspicious functions include the payable function and the batch call function; the payable function is identified through the function selector; the batch call function is identified by analyzing the operation sequence of loading call data in the bytecode;

[0031] The transaction simulation execution module is used to generate transaction parameters according to suspicious functions and perform transaction simulation execution;

[0032] The phishing fraud contract determination module is used to determine whether the Ethereum smart contract to be detected is a phishing fraud contract according to the transaction simulation execution result and the preset determination rules, in combination with the behavior pattern of the suspicious function and the asset flow situation.

[0033] Further, in the suspicious function extraction module, payable functions are identified through function selectors. The specific operations are as follows:

[0034] (1.1) Extract the function selector in the smart contract bytecode and identify all callable functions in the smart contract through the function selector;

[0035] (1.2) Traverse all callable functions and determine whether the function contains both CallValue and a rollback instruction. If not, it means that the function has the ability to receive Ether and is a payable function, and then continue to execute step (1.3); if so, it means that the function does not have the ability to receive Ether and the smart contract is not a phishing fraud contract targeting Ether;

[0036] (1.3) Query the Ethereum signature database to determine whether the function selector is registered. If so, continue to execute step (1.4); otherwise, the smart contract is not a phishing fraud contract targeting Ether;

[0037] (1.4) Determine whether the function name contains suspicious keywords. If so, mark the payable function as suspicious; otherwise, the smart contract is not a phishing fraud contract targeting Ether; The suspicious keywords include: claim, reward, receive tokens;

[0038] The batch call function is identified by analyzing the operation sequence of loading call data in the bytecode. The specific operations are as follows:

[0039] Analyze the operation sequence of loading call data in the bytecode and determine whether the parameter type of the function is (address,bytes)[] or (address[],bytes[]). If so, the function is a Multicall function;

[0040] For the bytecode of the Multicall function with the parameter type of (address,bytes)[], the length, address, and byte data of the (address,bytes) array are loaded through CallDataLoad in sequence;

[0041] The bytecode of the Multicall function with the (address[],bytes[]) parameter type loads the address, length, address data of the address array, and the address, length, and byte data of the bytes array through CallDataLoad in sequence.

[0042] Further, in the transaction simulation execution module, the transaction simulation execution of the payable function is specifically as follows: according to the payable function, generate transaction parameters, randomly set the Ether value and contract caller of the transaction, and perform the first transaction simulation; determine whether the transaction simulation execution is successful. If successful, call the phishing fraud contract determination module; if failed, determine that the smart contract is not a phishing fraud contract for Ether.

[0043] The transaction simulation execution of the batch call function is specifically as follows: according to the batch call function, generate transaction parameters, construct a phishing scenario and randomly set the contract caller, and perform the first transaction simulation; determine whether the transaction simulation execution is successful. If successful, call the phishing fraud contract determination module; if the failure causes the transaction to roll back, adjust the transaction parameters according to the transaction rollback reason, and re-perform the transaction simulation and judgment.

[0044] For the transaction rollback reason that the transaction simulation execution can only be successful when the caller address conforms to the pre-set phishing account address, through the Debug_traceCall function of the local Geth node, extract and compare the operation parameters, obtain the phishing account address, and modify the transaction parameters accordingly, and re-perform the transaction simulation and judgment.

[0045] Further, in the phishing fraud contract determination module, for the payable function, if the transaction simulation execution result is that only the Ether sent by the user is received and no reward tokens are returned or no on-chain events are triggered, then determine that the Ethereum smart contract to be detected is a phishing fraud contract.

[0046] For the batch call function, if the transaction simulation execution result is that the smart contract only allows specific phishing account addresses to be successfully called, and the user assets are transferred after the successful call, then determine that the Ethereum smart contract to be detected is a phishing fraud contract.

[0047] The beneficial effects of the present invention are:

[0048] (1) High detection accuracy: The present invention combines a dual verification mechanism of function feature matching and transaction simulation execution to ensure the accuracy of the detection results. By deeply analyzing the contract logic and simulating different transaction scenarios, it can effectively identify complex phishing fraud contracts and prevent missed detections or misjudgments.

[0049] (2) Strong adaptability: The method of the present invention can adapt to various types of smart contracts and diverse phishing scam scenarios. Whether it is a simple phishing for Payable functions or a phishing for Multicall functions, the present invention can provide effective solutions.

[0050] (3) Risk-free: All operations of the present invention are completed in a local environment without involving any transfer or operation of real assets; through simulated execution, the detection task can be completed without compromising the security of user assets, thereby avoiding the risk of real asset losses.

[0051] (4) Automation: The detection process of the present invention has achieved a high degree of automation, reducing the need for manual intervention. The entire detection process, from the analysis of contract bytecode to the simulated execution of transactions and then to the final contract determination, is automatically completed by the system, significantly improving the detection efficiency and reducing the cost of manual detection. Description of the Drawings

[0052] Figure 1 is a flowchart of the method for detecting Ethereum phishing scam contracts based on simulated execution of transactions in an embodiment of the present invention.

[0053] Figure 2 is a flowchart of the method for detecting Ethereum phishing scam contracts for Payable functions in an embodiment of the present invention.

[0054] Figure 3 is a flowchart of the method for detecting Ethereum phishing scam contracts for Multicall functions in an embodiment of the present invention.

[0055] Figure 4 is a schematic diagram of the system for detecting Ethereum phishing scam contracts based on simulated execution of transactions in an embodiment of the present invention. Detailed Embodiment

[0056] The present invention will be described in detail below according to the drawings and preferred embodiments. The purpose and effects of the present invention will become more apparent. The present invention will be further described in detail below in conjunction with the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0057] Before further elaborating on the embodiments of the present invention, the nouns and terms involved in the embodiments of the present invention are described. The nouns and terms involved in the embodiments of the present invention are applicable to the following explanations.

[0058] (1) ETH, the native cryptocurrency of the Ethereum network, also known as Ether, is not only a medium of exchange between users but also serves as the means to pay for network transaction fees (Gas) in the Ethereum network. It is also the cost unit required for executing smart contracts. This dual nature makes ETH the core asset of the Ethereum ecosystem.

[0059] The ERC20 standard is a technical standard used to build and issue tokens on the Ethereum blockchain. It defines a set of common rules, including functions such as token transfer, balance query, and authorization operations, thus enabling compatibility and interoperability among different decentralized applications (hereinafter referred to as DApps). ERC20 tokens are widely used in DeFi, gaming, and crowdfunding projects and are an important part of the Ethereum ecosystem.

[0060] NFT is a unique digital asset based on blockchain technology. Different from the fungibility of ERC20 tokens, each unit of NFT is unique and irreplaceable. Therefore, it is often used as proof of ownership for digital artworks, virtual land, and game items. Due to its uniqueness and high-value characteristics, NFT has attracted wide attention in recent years but has also become an important target for phishing scams.

[0061] (2) Function Selector: In an Ethereum smart contract, the function selector is a unique identifier used to identify a specific function in the Ethereum smart contract. The function selector is obtained by taking the first 4 bytes after hashing the function signature. In the bytecode implementation of an Ethereum smart contract, the smart contract will select the function signature in the parameters that matches the function selector in the existing code and then jump to the specified function entry point.

[0062] (3) Ethereum Signature Database: The Ethereum Signature Database is a public, community-maintained database used to store and query the signatures of Ethereum smart contract functions. When a user signs a transaction or a message in a wallet (such as MetaMask, TrustWallet, etc.), the wallet needs to parse the transaction data to display readable information to the user. The Ethereum Signature Database plays a crucial role in this process, helping the wallet resolve the function selector in the transaction into a readable function name.

[0063] (4) CallValue, an opcode in the Ethereum Virtual Machine, is used to obtain the amount of Ether (or other cryptocurrencies) passed to a smart contract function when the function is called.

[0064] (5)Revert is a rollback operation in smart contracts. It is used to undo all state changes that have occurred when an error or unexpected condition is encountered during the execution of a transaction and mark the transaction as failed. This is usually to ensure the robustness of the smart contract and the consistency of data. When the "Revert" operation is executed, all the gas (transaction fees) that have been consumed will be refunded, but the transaction itself will be regarded as failed and no state on the blockchain will be changed.

[0065] (6)The EQ operation can be translated as "comparison operation" in the Ethereum Virtual Machine. It is a basic arithmetic operation instruction used to compare whether two numbers are equal.

[0066] (7)The front-end UI (User Interface) is the visual interface through which users interact with software systems, devices, or web pages. It includes all visible interface elements (such as buttons, icons, forms, navigation bars, etc.) and their layout designs. Its core goal is to optimize human-computer interaction and ensure that users can complete tasks intuitively and efficiently.

[0067] As Figures 1 - 3 shown, an Ethereum phishing scam contract detection method based on transaction simulation execution includes the following steps:

[0068] S1: For each Ethereum smart contract (i.e., the target contract), analyze its bytecode and identify suspicious functions that may be related to phishing scam behaviors; the suspicious functions include payable functions (Payable functions) and batch call functions (Multicall functions). This is specifically achieved through the following two parts:

[0069] (1)Identify payable functions that may be used for phishing through the function selector Selector. Specifically, it includes the following steps:

[0070] (1.1)Extract the function selector from the contract bytecode and identify all callable functions in the contract through the function selector.

[0071] (1.2) In Ethereum smart contracts, msg.value represents the amount of ETH attached to the call transaction, and CallValue is an opcode in the Ethereum virtual machine that is used to obtain the amount of ETH attached to the current call transaction. In the Ethereum EVM bytecode, the Payable function is usually expressed as: using CallValue to obtain msg.value, indicating that the function can process ETH. Therefore, we can check whether there is a CallValue check in the function implementation to screen out potential fraudulent transaction functions. Specifically, analyze whether all callable functions contain both CallValue and Revert operation instructions to confirm whether the function has the ability to receive ETH; if not, it means that the function has the ability to receive ETH, and the next step of screening is to execute step (1.3); if so, it means that the function cannot receive ETH, and it is believed that the contract is not a phishing fraud contract for ETH, and only the judgment based on the Multicall function is performed in the future. Among them, the CallValue operation is used to obtain the current ETH input, and the Revert operation is used to implement conditional failure rollback.

[0072] (1.3) Query the Ethereum signature database to determine whether the function selector has been registered. If not, it is considered that the contract is not a phishing contract for ETH, and the judgment based on the Payable function is not continued. Only the judgment based on the Multicall function is performed later. If it has been registered, continue to determine whether the function name contains suspicious keywords, that is, execute step (1.4).

[0073] (1.4) Analyze and determine whether the function name contains or is similar to suspicious keywords, including: Claim, Reward, GetTokens, etc.; if so, mark the function as suspicious; if not, it is considered that the contract is not a phishing scam contract for ETH, and subsequent judgments are only based on the Multicall function.

[0074] In summary, when a function in a contract satisfies the following conditions at the same time: it does not contain both CallValue and Revert operation instructions, the corresponding function selector has been registered, and it contains suspicious keywords, the Payable function will be marked as suspicious.

[0075] (2) By analyzing the operation sequence of bytecode loading call data (Calldata), determine whether the parameter type of the function is (address, bytes)[] or (address[], bytes[]); if so, the function is a Multicall function, otherwise it is not.

[0076] The Multicall function is a function that executes multiple contract calls in batch, allowing different function calls of multiple smart contracts to be executed in a single transaction, thereby improving execution efficiency and reducing Gas fees. It is commonly used in DeFi applications, such as querying the status of multiple contracts and executing batch transactions. For the Multicall function, its parameters are usually of type (address, bytes)[] or (address[], bytes[]).

[0077] Specifically, for (address, bytes)[], where address (20 bytes) is used to store the target contract address. Since the storage space is divided in 32-byte chunks, for a 20-byte address, the first 12 bytes are filled with 0. Bytes is used to store the function data to be called. The bytecode of the Multicall function of this parameter type will successively load the address, length, and byte data of the (address, bytes) array through the CallDataLoad instruction; the specific manifestation of the bytecode is usually as shown in Table 1 below.

[0078] Table 1 Bytecode manifestation corresponding to the (address, bytes)[] parameter type

[0079]

[0080] For (address[], bytes[]), the bytecode will first parse the address[] array and then the bytes[] array. The bytecode of the Multicall function of this parameter type will successively load the address, length, address data of the address array and the address, length, and byte data of the bytes array through CallDataLoad; the specific manifestation of the bytecode is usually as shown in Table 2 below.

[0081] Table 2 Bytecode manifestation corresponding to the (address, bytes)[] parameter type

[0082]

[0083] S2: Call the identified suspicious function to perform a transaction simulation execution. This is specifically implemented through the following sub-steps:

[0084] S2.1: Automatically generate transaction parameters based on the detected suspicious function and perform the first transaction simulation. This process requires corresponding strategy design according to different types of functions.

[0085] For the Payable function, its purpose is to allow the contract to receive ETH. When generating a transaction, the ETH value of the transaction and the contract caller are randomly set to simulate transactions of different amounts being sent to the target contract. These transactions may trigger the callback function or other conditions of the target contract, thereby detecting whether the target contract performs malicious behavior.

[0086] For the Multicall function, a phishing scenario is constructed and the contract caller is randomly set. For example, after authorizing the USDT token in the ERC20 token, the Multicall function is called to transfer the token. The parameters of this Multicall function include the official contract address of USDT and the specific parameters for calling the TransferFrom function to transfer the user's token.

[0087] S2.2: Determine whether the transaction simulation execution is successful. If successful, continue to the next step S3 for judgment. If failed, adjust the transaction parameters and then conduct the transaction simulation again, and repeat the judgment until the transaction simulation execution is successful; this judgment also needs to be discussed according to different types of functions.

[0088] For the Payable function, since it does not verify the caller address and can be called with a random address, there is basically no situation where the transaction simulation fails. If it fails, it means that the target contract is not a phishing scam contract targeting ETH. If successful, continue to the next step S3 for judgment.

[0089] For the Multicall function, if the transaction simulation execution fails and the transaction is rolled back, further adjust the transaction parameters according to the reason for the transaction rollback and conduct the transaction simulation again. The common reasons for transaction rollback are: when conducting the first transaction simulation, the contract caller is often randomly set, and some phishing scam contracts strictly verify the caller address, requiring the caller to be a marked phishing account. If the randomly set caller does not meet this requirement, the transaction simulation execution will fail; for example, if the caller address does not meet the expectation, the transaction may be rolled back.

[0090] Specifically, if the transaction rollback is caused by the failure of the caller address verification, the detailed debugging information can be obtained through the Debug_traceCall function of the deployed local Geth node, including the specific error message when the transaction fails, the parameters of the relevant operations, and the reason for the rollback. By parsing this debugging information, extract the potential phishing account address, and after adjusting the transaction parameters according to this debugging information, conduct the transaction simulation again to pass the contract's identity verification and permission check and make the transaction simulation execution successful.

[0091] S3: According to the transaction simulation execution result and the preset determination rules, combined with the behavior pattern of the function and the asset flow situation, determine whether the target contract is a phishing fraud contract. The specific determination rules are as follows:

[0092] For a suspicious Payable function, in Ethereum, an on-chain event refers to an event triggered and recorded by a smart contract in the blockchain network. Different from off-chain events, on-chain events are actively emitted by the smart contract during execution and are stored in a special way in the blockchain log. These on-chain events are usually used to interact with or notify external applications (such as front-end user interfaces, wallets, or other contracts), providing information about contract state changes to external applications. A legitimate contract will generate corresponding on-chain events based on various user behaviors. Based on the above principle, if the simulated transaction only receives ETH sent by the user without returning any reward tokens or triggering on-chain events (such as payment records, etc.), then it is determined that the target contract is a phishing fraud contract; otherwise, it is considered that the target contract is not a phishing fraud contract targeting ETH.

[0093] For the Multicall function, if during the transaction simulation execution process, the contract only allows specific addresses (usually the phishing account addresses marked in the Ethereum browser (Etherscan)) to successfully call, and the user's assets are transferred after the successful call, then it is determined that the target contract is a phishing fraud contract; otherwise, it is considered that the target contract is not a phishing fraud contract targeting ERC20 tokens and NFTs. The principle of this determination is that the attacker uses an address verification mechanism in the contract to ensure that only the phishing accounts they control can trigger the contract to perform transfer or other asset flow operations, thereby stealing the user's assets.

[0094] To implement the above Ethereum phishing fraud contract detection method based on transaction simulation execution, this embodiment also proposes an Ethereum phishing fraud contract detection system based on transaction simulation execution. This system efficiently collaborates through multiple core modules to ensure that potential phishing fraud contracts can be detected in a timely and accurate manner in a complex blockchain environment. Specifically, this system includes: a suspicious function extraction module, a transaction simulation execution module, and a phishing fraud contract determination module.

[0095] Suspicious function extraction module: This module receives the bytecode of the Ethereum smart contract as input. First, it parses the bytecode to extract the suspicious functions in the contract that may be related to phishing fraud behaviors. Specifically, by identifying the function selector Selector and Calldata operation sequences in the bytecode, it can determine which functions may have malicious behaviors and identify the suspicious Payable functions and Multicall functions. Through these extracted suspicious functions, the system can further simulate and analyze transaction behaviors through other modules to identify potential risks.

[0096] Transaction Simulation Execution Module: According to the extracted suspicious functions, it automatically generates possible transaction parameters and simulates the execution of these transactions. This module not only generates logical transaction data but also simulates various transaction behaviors that may occur in a real environment. Through transaction simulation execution, the system can observe the actual performance of the contract to further confirm whether there are abnormal behaviors.

[0097] Phishing Scam Contract Judgment Module: For the simulation results generated by the transaction simulation execution module, this module is responsible for comprehensively analyzing the results of the simulated transactions (including: return values of function executions, changes in transaction status, and whether there are abnormal asset transfers, etc.), and judging whether the target contract is a phishing scam contract based on preset judgment rules. If the simulated transaction only receives ETH but does not trigger the expected reward tokens or on-chain events, or it is found in the Multicall function that it can only be called by a specified phishing account, this module will finally determine that the contract is a phishing scam contract based on this information and provide detailed execution logs and execution path analysis.

[0098] After determining the phishing scam contract using the above method, the following information will be used as the output result of the system:

[0099] (1) Address and bytecode features of the phishing scam contract. Bytecode features include: function selectors of the contract, bytecode operation sequences, and special instructions related to phishing behaviors. These bytecode features help to further verify the malicious behaviors of the phishing scam contract and provide preventive suggestions for developers.

[0100] (2) Contract deployment account address of the phishing contract: The system will also list the contract deployment account addresses associated with this phishing scam contract (i.e., phishing account addresses). These addresses are usually controlled by attackers and are used to collect assets illegally transferred through the phishing scam contract. Marking these addresses helps to trace the source of the phishing attack and provide risk warnings for victims.

[0101] (3) Function type and description of suspicious behaviors: For each suspicious function, the system will record its suspicious nature in detail according to its function and behavior description. For example, the Payable function will be marked as "only receives ETH but does not return reward tokens and has no on-chain event trigger", and the Multicall function will be marked as "only allows phishing accounts to call and successfully transfer assets". These descriptions help developers and security personnel understand how the phishing scam contract operates and how it is designed to bypass conventional security detections.

[0102] To more intuitively verify the detection effect of the method and system proposed by the present invention, we will analyze two specific embodiments below. These embodiments are from actual Ethereum phishing fraud contracts, which use the two suspicious functions mentioned above to induce users to sign fraudulent transactions, resulting in asset losses. During the actual detection process of phishing fraud contracts, analysis and identification are carried out based on the contract bytecode. For ease of understanding, the source code of the relevant contract is manually reversed in this embodiment, and its logic is simplified to help demonstrate its phishing characteristics and fraud techniques.

[0103] Embodiment 1

[0104] A smart contract with the address 0x00008f1149168c1d2fa1eba1ad3e9cd644510000 contains a payable function named Claim. Its apparent logic seems to allow users to claim rewards, but in fact, the only purpose of this function is to induce users to send ETH without returning any tokens or other valuable on-chain assets. The specific code of this smart contract is as follows:

[0105] contract ClaimReward {

[0106] address private owner; / / The account address currently owning the contract;

[0107] constructor() public {

[0108] owner = msg.sender;

[0109] }

[0110] function withdraw() public {

[0111] require(msg.sender == owner);

[0112] msg.sender.transfer(address(this).balance);

[0113] }

[0114] function Claim() public payable {

[0115] }

[0116] function getBalance() public nonPayable {

[0117] return this.balance;

[0118] }

[0119] }

[0120] Specifically, the Claim function has the following suspicious features: (1) The function is declared as Payable: This means that users can send ETH to the function, but the function itself does not involve any subsequent reward distribution or meaningful on-chain operations. (2) The function implementation lacks transfer, send, or call behavior: That is, the function does not send any ETH or tokens back to the user, but only receives the user's ETH. (3) No on-chain events are triggered: Legitimate contracts usually trigger events during important state changes (such as receiving rewards, token transfers, etc.), but this contract does not contain any such events, making it impossible for users to track the normal transaction execution process on the blockchain browser. (4) The function logic is simple but misleading: The front-end UI will prompt to call the Claim function, but the actual contract code only receives the user's ETH and does not return anything.

[0121] By using the method and system of the present invention, through bytecode parsing of the target smart contract, extraction of suspicious functions, simulation execution of transactions, and result analysis, it is finally possible to accurately identify phishing scam contracts, accurately locate suspicious Payable functions, and the final output results are as follows:

[0122] (base)bowen@bowen-OptiPlex-7000:~ / phishing / PCScope$ python detect_phishing_contract.py 0x00008f1149168c1d2fa1eba1ad3e9cd644510000

[0123] 0x00008f1149168c1d2fa1eba1ad3e9cd644510000 is a payable phishingcontract

[0124] The phishing function selector is 0x3158952e

[0125] Function name is Claim( )

[0126] Example 2

[0127] The Multicall function in a contract at the address 0x0000fd803b84d314439996f56b517cd92ffa0000 is a malicious function designed to specifically steal users' ERC-20 tokens and NFT assets. This function only allows specific phishing scam accounts to call it. After obtaining the user's authorization permission for the tokens, it can quickly call the corresponding contract interfaces to transfer the user's assets to the address controlled by the scammer (i.e., the phishing account). The specific code of this smart contract is as follows:

[0128] contract MulticallPhishing {

[0129] address private owner;

[0130] constructor() public {

[0131] owner = msg.sender;

[0132] }

[0133] function Multicall (CallData [] calls) public {

[0134] require(owner == msg.sender);

[0135] for(uint i = 0; i < calls.length; i++){

[0136] calls[i].contract.call(calls[i].Bytes);

[0137] }

[0138] }

[0139] }

[0140] By using the method and system of the present invention, through bytecode parsing of the target smart contract, extraction of suspicious functions, transaction simulation execution, and result analysis, it is finally possible to accurately identify phishing scam contracts, accurately locate the suspicious Multicall function, and the final output results are as follows:

[0141] (base)bowen@bowen-OptiPlex-7000:~ / phishing / PCScope$ python detect_phishing_contract.py 0x0000fd803b84d314439996f56b517cd92ffa0000

[0142] 0x0000fd803b84d314439996f56b517cd92ffa0000 is a multicall phishingcontract

[0143] The multicall function selector is 0x63fb0b96

[0144] Through the Ethereum phishing fraud contract detection system based on transaction simulation execution of the present invention, the security of the blockchain ecosystem, especially Ethereum smart contracts, has been greatly improved. This system can not only effectively reduce the threat of phishing fraud to users' assets, but also continuously monitor and detect potential security hazards under fully automatic operation, thus ensuring the healthy development of the entire blockchain ecosystem and the security of users' assets. The application of this technology will greatly improve the credibility of the blockchain platform and provide a safer and more reliable digital asset trading environment for users.

[0145] Those of ordinary skill in the art can understand that the above are only preferred examples of the invention and are not used to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, for those skilled in the art, they can still modify the technical solutions described in the foregoing examples, or perform equivalent replacements for some of the technical features. Any modifications, equivalent replacements, etc. made within the spirit and principle of the invention shall be included within the protection scope of the invention.

Claims

1. A method for detecting Ethereum phishing scam contracts based on transaction simulation execution, characterized in that, It includes the following steps: S1: For the Ethereum smart contract to be detected, analyze its bytecode and identify suspicious functions related to phishing fraud behaviors; the suspicious functions include payable functions and batch call functions; the payable functions are identified through function selectors; the batch call functions are identified by analyzing the operation sequence of loading call data in the bytecode; S2: Call the identified suspicious functions to perform transaction simulation execution; S3: According to the transaction simulation execution result and the preset determination rules, combined with the behavior patterns of the suspicious functions and the asset flow situation, judge whether the Ethereum smart contract to be detected is a phishing fraud contract; In the above S1, identifying the payable functions through function selectors specifically includes the following sub-steps: (1.1) Extract the function selectors in the smart contract bytecode and identify all callable functions in the smart contract through the function selectors; (1.2) Traverse all callable functions and judge whether the function contains both CallValue and revert instructions at the same time. If not, it means that the function has the ability to receive Ether and is a payable function, and then continue to execute step (1.3); if so, it means that the function does not have the ability to receive Ether and the smart contract is not a phishing fraud contract targeting Ether; (1.3) Query the Ethereum signature database to judge whether the function selector has been registered. If so, then continue to execute step (1.4); otherwise, the smart contract is not a phishing fraud contract targeting Ether; (1.4) Judge whether the function name contains suspicious keywords. If so, mark the payable function as suspicious; Otherwise, the smart contract is not a phishing fraud contract targeting Ether; the suspicious keywords include: claim, reward, receive tokens.

2. The method for detecting Ethereum phishing fraud contracts based on transaction simulation execution according to claim 1, wherein In the above S1, identifying the batch call functions by analyzing the operation sequence of loading call data in the bytecode, the specific operations are as follows: Analyze the operation sequence of loading call data in the bytecode and judge whether the parameter type of the function is (address,bytes)[] or (address[],bytes[]). If so, the function is a Multicall function; For the bytecode of the Multicall function with the parameter type of (address,bytes)[], the address, length, and byte data of the (address,bytes) array are loaded through CallDataLoad in sequence; For the bytecode of the Multicall function with the parameter type of (address[],bytes[]), the address, length, the address data of the address array, and the address, length, and byte data of the bytes array are loaded through CallDataLoad in sequence.

3. The method for detecting Ethereum phishing fraud contracts based on transaction simulation execution according to claim 1, wherein, For the payable functions, the above S2 is specifically implemented through the following sub-steps: S2.1: Generate transaction parameters according to the payable function, randomly set the Ether value of the transaction and the contract caller, and perform the first transaction simulation; S2.2: Judge whether the transaction simulation execution is successful. If successful, then continue to execute S3; If it fails, it is determined that the smart contract is not a phishing fraud contract targeting Ether.

4. The method for detecting Ethereum phishing fraud contracts based on transaction simulation execution according to claim 1, wherein, For the batch call function, step S2 is specifically implemented through the following sub-steps: S2.1: Generate transaction parameters according to the batch call function, construct a phishing scenario, randomly set a contract caller, and perform the first transaction simulation; S2.2: Determine whether the transaction simulation execution is successful. If it is successful, continue to execute S3; if it fails and causes a transaction rollback, adjust the transaction parameters according to the reason for the transaction rollback, and re-perform the transaction simulation and judgment; For the reason of transaction rollback where the transaction simulation execution can only be successful when the caller address conforms to the pre-set phishing account address, extract and compare operation parameters through the Debug_traceCall function of the local Geth node, obtain the phishing account address, and modify the transaction parameters accordingly, and re-perform the transaction simulation and judgment.

5. The method for detecting Ethereum phishing fraud contracts based on transaction simulation execution according to claim 1, wherein In step S3, for a payable function, if the result of the transaction simulation execution is that only the Ether sent by the user is received, and no reward tokens are returned or no on-chain events are triggered, then it is determined that the Ethereum smart contract to be detected is a phishing scam contract; For the batch call function, if the result of the transaction simulation execution is that the smart contract only allows a specific phishing account address to be successfully called, and the user's assets are transferred after the call is successful, then it is determined that the Ethereum smart contract to be detected is a phishing scam contract.

6. An Ethereum phishing scam contract detection system based on transaction simulation execution, characterized in that, Including: A suspicious function extraction module, a transaction simulation execution module, and a phishing scam contract determination module; The suspicious function extraction module is used to receive the bytecode of the Ethereum smart contract to be detected, analyze the bytecode, and identify suspicious functions related to phishing scam behaviors in the smart contract; the suspicious functions include payable functions and batch call functions; the payable functions are identified through function selectors; the batch call functions are identified by analyzing the operation sequence of loading call data in the bytecode; In the suspicious function extraction module, the payable functions are identified through function selectors, and the specific operations are as follows: (1.1) Extract the function selectors in the bytecode of the smart contract, and identify all callable functions in the smart contract through the function selectors; (1.2) Traverse all callable functions, and determine whether the function contains both CallValue and a rollback instruction at the same time. If not, it means that the function has the ability to receive Ether and is a payable function, and continue to execute step (1.3); if so, it means that the function does not have the ability to receive Ether, and this smart contract is not a phishing scam contract targeting Ether; (1.3) Query the Ethereum signature database to determine whether the function selector is registered. If so, continue to execute step (1.4); otherwise, this smart contract is not a phishing scam contract targeting Ether; (1.4) Determine whether the function name contains suspicious keywords. If so, mark the payable function as suspicious; Otherwise, this smart contract is not a phishing scam contract targeting Ether; the suspicious keywords include: claim, reward, receive tokens; The transaction simulation execution module is used to generate transaction parameters according to the suspicious functions and perform transaction simulation execution; The phishing fraud contract determination module is used to determine whether the Ethereum smart contract to be detected is a phishing fraud contract according to the transaction simulation execution result and the preset determination rules, in combination with the behavior pattern of the suspicious function and the asset flow situation.

7. The Ethereum phishing fraud contract detection system based on transaction simulation execution according to claim 6, wherein, The batch call function is identified by analyzing the operation sequence of the bytecode loading call data. The specific operations are as follows: Analyze the operation sequence of the bytecode loading call data, and determine whether the parameter type of the function is (address,bytes)[] or (address[],bytes[]). If so, the function is a Multicall function; For the bytecode of the Multicall function with the parameter type of (address,bytes)[], the length, address, and byte data of the (address,bytes) array are loaded through CallDataLoad in sequence; For the bytecode of the Multicall function with the parameter type of (address[],bytes[]), the addresses, lengths, address data of the address array and the addresses, lengths, and byte data of the bytes array are loaded through CallDataLoad in sequence.

8. The Ethereum phishing fraud contract detection system based on transaction simulation execution according to claim 6, characterized in that In the transaction simulation execution module, the payable function is simulated and executed for transactions. Specifically: according to the payable function, generate transaction parameters, randomly set the Ether value and contract caller of the transaction, and perform the first transaction simulation; determine whether the transaction simulation execution is successful. If successful, call the phishing fraud contract determination module; if failed, determine that the smart contract is not a phishing fraud contract targeting Ether. The batch call function is simulated and executed for transactions. Specifically: according to the batch call function, generate transaction parameters, construct a phishing scenario and randomly set the contract caller, and perform the first transaction simulation; determine whether the transaction simulation execution is successful. If successful, call the phishing fraud contract determination module; If the failure causes a transaction rollback, adjust the transaction parameters according to the transaction rollback reason, and re-perform the transaction simulation and judgment; For the transaction rollback reason where the transaction simulation execution can only be successful when the caller address meets the pre-set phishing account address, extract and compare the operation parameters through the Debug_traceCall function of the local Geth node, obtain the phishing account address, and modify the transaction parameters accordingly, and re-perform the transaction simulation and judgment.

9. The Ethereum phishing fraud contract detection system based on transaction simulation execution according to claim 6, characterized in that, In the phishing fraud contract determination module, for the payable function, if the transaction simulation execution result is that only the Ether sent by the user is received, and no reward tokens are returned or no on-chain events are triggered, then determine that the Ethereum smart contract to be detected is a phishing fraud contract; For the batch call function, if the transaction simulation execution result is that the smart contract only allows a specific phishing account address to be successfully called, and the user assets are transferred after the successful call, then determine that the Ethereum smart contract to be detected is a phishing fraud contract.

Images