Surviving in Dark Forest: Towards Evading the Attacks from Front-Running Bots in Application Layer

Surviving in Dark Forest: Towards Evading the Attacks from Front-Running Bots in Application Layer

Speakers: Zuchao Ma

Conference: USENIX Security

YouTube: https://www.youtube.com/watch?v=qnyShY9-aKo

Overview

This talk, "Surviving in Dark Forest: Towards Evading the Attacks from Front-Running Bots in Application Layer," delves into the critical challenge of front-running attacks within blockchain ecosystems, specifically focusing on smart contracts at the application layer. Presented by Zuchao Ma, the research explores how smart contracts can effectively evade these sophisticated bot-driven attacks, which aim to profit by having an attacker's transaction confirmed faster than a victim's. The talk highlights the significant financial impact of front-running, which has led to hundreds of millions of USD in losses on platforms like Ethereum, underscoring the urgency of developing robust defensive strategies.

The importance of this work is multi-faceted. It not only evaluates the resilience of current Web3 application ecosystems but also pinpoints areas ripe for enhancement, offering vital insights for developers. Furthermore, the research unveils novel evasion strategies observed in real-world scenarios, providing practical guidance for Web3 developers to construct more resilient defenses against economically motivated attackers. By systematically identifying, analyzing, and categorizing these evasion techniques, the paper lays a crucial foundation for understanding and combating one of the most persistent and damaging threats in decentralized finance.

Background

▶ Watch: Introduction to Front-Running Attacks and Economic Impact (0:00)

Front-running attacks are a pervasive and financially destructive phenomenon in blockchain environments, particularly within decentralized finance (DeFi). The core mechanism involves an attacker, typically an automated bot, observing a pending, profitable transaction from a victim on the blockchain's public mempool. Upon identifying such a transaction (e.g., TX1), the bot swiftly creates its own transaction (TXA) designed to imitate or exploit the victim's intended action. This malicious transaction is then submitted through a faster transmission channel, such as a private mining pool or a high-speed physical network, ensuring it gets confirmed on the blockchain before the victim's transaction. Consequently, the bot seizes the profit that was intended for the victim, leaving the victim with financial losses.

The economic impact of these attacks is staggering. On Ethereum alone, losses attributed to front-running exceeded $600 million USD before September 2022. Alarmingly, an additional $600 million USD was lost from that month to July 2023, demonstrating the escalating nature and persistent threat of front-running. This immense financial drain underscores the critical need for effective countermeasures, particularly at the application layer where smart contracts operate.

The research presented addresses the fundamental problem: "How do Web3 applications evade front-running attacks, especially at the application layer?" Tackling this question comes with significant challenges. The first is leaking ground truth, where the full scope of existing evasion strategies is unknown, making it difficult to systematically summarize deterministic patterns for detection. The second challenge is the high analysis bar, as evading strategies often involve complex contract execution, a difficulty compounded when contracts are not open source.

To overcome these challenges, the researchers refined their scope by leveraging insights from security conferences and smart contract auditors like SlowMist and BlockSec. They adopted a hybrid detection approach, using preset rules for known evasion patterns and machine learning to identify unknown ones. For the analytical complexity, they employed dynamic binary analysis to compel smart contracts to expose their protection mechanisms. They also designed control data flow profit delivery analysis to deeply understand contract behaviors and used trace slicing to extract relevant code snippets for clustering models, thereby learning the semantics of these intricate evasion strategies.

Key Findings

▶ Watch: System Architecture: EV Detector and Cluster (3:40)

The research, leveraging a comprehensive analysis of over 6 million arbitrage transactions and 71 significant real-world attack transactions on both Ethereum and Binance Smart Chain, successfully uncovered 32 refined evasion strategies. These strategies are categorized into four primary types: assess control, profit control, execution split, and code obfuscation, each designed to thwart different stages of a front-running bot's attack process.

Specifically, the findings detailed:

• 14 assess control strategies: These verify the transaction caller using various methods, including constant values, fixed storage slots, mapping values, and values within specified bytecode offsets. Notably, authentication operations were observed using not only equality checks but also subtraction and XOR operations, often preceded by value conversions like shift left and XOR, making the logic harder for bots to decipher. Some authentications even targeted call value instead of the caller.
• 10 profit control strategies: These specify profit gainers through constant arguments, fixed storage slots, mapping return values, values in bytecode offsets, and newly created accounts. Similar to assess control, value conversions (XOR, addition) were used to generate profit gainers, increasing bypass difficulty. An additional defense observed was conditional loading of profit gainers into EVM memory, dependent on specific call value conditions.
• An impactful execution split strategy: Demonstrated by transaction 93AE on Binance Smart Chain, which caused a loss of over $40,000 USD. This attack was split into two transactions (930A and 93AE) within the same block. 930A set a contract variable, which 93AE subsequently read. If a bot inspected 93AE without first executing 930A in its testnet, 93AE would revert due to a failed read, effectively hiding the attack's true profitability.
• 7 code obfuscation strategies: These prevent bot analysis by dynamically specifying jump addresses using core arguments, memory values, or storage values, hindering static control flow analysis. Some contracts generated jump addresses only when executed on the mainnet (by checking chain ID) or when a specific call value was provided. Attackers also frequently hid their attack logic within contract constructors, which execute only once upon deployment, making them difficult to analyze from runtime code.

Beyond these categorizations, the study revealed interesting platform-specific trends: hardcoding solutions were more prevalent on Ethereum, while storage-based solutions were more common and effective on Binance Smart Chain due to their increased bypass difficulty. Furthermore, some developers maintained specific bytecode layouts, storing crucial values at particular offsets, to achieve code integrity protection. Any bot modification to bypass protection would disrupt this layout, invalidating functionality. The use of arguments to hide jump addresses was also a preferred method to prevent static control flow analysis.

Finally, the research introduced EV-Scope, a novel framework that significantly outperforms a straw man approach (employing decompilation and code search) in detecting these evasion strategies. EV-Scope, which utilizes dynamic binary analysis and machine learning, achieved a higher F1 score on a verification dataset of 400 samples, proving the limitations of static analysis in unraveling complex, obfuscated evasion techniques.

Technical Deep Dive

▶ Watch: Overview of Four Application Layer Evasion Strategies (5:50)

The research began by formulating an advanced bot attack model to understand the adversary's capabilities. This model describes a sophisticated bot's workflow:

1. Local Testnet Execution: A bot executes transactions from the public mempool in its local testnet environment to observe their execution outcomes.
2. Profit Observation: If a transaction yields profit for a specified account, the bot proceeds to advanced analysis.
3. Advanced Analysis: The bot conducts control flow and data flow analysis on the invoked contract (Contract C) to understand precisely how the profit is generated and delivered to the original account.
4. Contract Modification: The bot constructs its own malicious contract (Contract CA) by modifying Contract C, specifically replacing the profit gainer embedded within C's logic to redirect profit to the bot's address.
5. Deployment and Front-Running: Contract CA is then deployed to the mainnet, and the bot executes its front-running transaction to intercept and gain the profit intended for the victim.

Given this attack model, the study defined the evasion scope to focus on application-layer defenses. This specifically excludes network-layer defenses (preventing the last step of front-running transaction confirmation), concentrating instead on strategies that:

• Prevent bots from omitting a profitable transaction.
• Prevent bots from analyzing the contract's logic.
• Prevent bots from successfully modifying the contract to redirect profit.

Based on this scope, four primary evading strategies were identified:

1. Execution Split: This strategy involves dividing a single profitable operation into multiple, interdependent transactions. The goal is to disguise the profitable transaction as a failed one when a bot attempts to execute it in isolation within its testnet. For example, a victim submits TX1 and TX2. TX2 is only profitable if TX1 has been executed beforehand. A bot, observing TX2 in the mempool, might execute it in its testnet without TX1. If TX1 isn't executed first, TX2 fails, misleading the bot into believing TX2 is not profitable and causing it to omit the front-running attempt.

1. Code Obfuscation: This technique aims to thwart bots' program analysis capabilities.

• Control Flow Obfuscation: Smart contract developers can obfuscate the control flow, making it challenging for bots to perform static analysis, decompilation, and understand the program's logic.
• Constructor-Based Obfuscation: Critical profit-gaining logic can be hidden within the contract's constructor. Since constructor code executes only once upon deployment and is then discarded, bots analyzing the runtime bytecode will not find this logic, preventing them from understanding the profit-gaining mechanism.

1. Access Control: Developers implement various access control mechanisms to prevent bots from successfully modifying the contract to execute it.

• Hardcoded Access Control: Only a specific, hardcoded account is permitted to execute certain contract functions. Bots need to locate this account's value in the contract's bytecode and modify it to their own address to bypass it.
• Storage-Based Access Control: The authorized account is stored in the contract's storage. Bypassing this is more difficult, as bots must modify the value stored in the contract's state, rather than just a static bytecode value.

1. Profit Control: These strategies hinder bots from modifying the contract to redirect profits.

• Hardcoded Profit Control: A specific, hardcoded account is designated to receive profits. Bots must find and replace this account in the bytecode.
• Argument-Based Profit Control: The profit-gaining account is specified as an argument to a function.
• Storage-Based Profit Control: The profit-gaining account is stored in contract storage, making it more challenging for bots to modify.

To systematically identify these strategies, the researchers developed data lock rules. Examples include:

• AC constant ADDR: Hardcoded access control, verification at instruction address ADDR.
• AC storage ADDR: Storage-based access control, verification at instruction address ADDR.
• PC constant X: Hardcoded profit control, X is the constant profit gainer.
• PC arguments X: Argument-based profit control.
• PC storage: Storage-based profit control.
• OB memory: Memory-based obfuscation, where jump address (JNP) is generated from memory.
• OB argument: Argument-based obfuscation.

To uncover unknown evading strategies, a workflow combining iterative learning and code clustering was designed. The process involves:

1. Dynamic Analysis: Leveraging dynamic analysis to collect the specific code sequences that trigger evasion strategies. This significantly reduces the length and noise of raw opcode sequences.
2. Back-Taint Analysis & Code Slicing: From the strategy's trigger point, back-taint analysis and code slicing are applied to extract only the opcodes directly relevant to triggering the strategy, further removing irrelevant noise.
3. Iterative Learning: The cleaned opcode sequences are used as input for clustering. Iterative learning continuously updates code embeddings during the clustering process, enhancing effectiveness.
4. Code Clustering: Automatically groups code clusters sharing similar patterns, which are then manually verified to identify representative and novel evasion strategies, refining the evasion scope.

The overarching framework, EV-Scope, takes contract bytecode and historic transactions as input. The EV Detector performs dynamic binary analysis based on preset rules, generating reports for both known and unknown patterns. For unknown patterns, the EV Cluster component takes the output, clusters strategies by learning their semantics, and after manual verification, new strategies are identified to further refine the understanding of evasion techniques.

Demo / Proof of Concept

▶ Watch: Strategy 1: Execution Split Explained (6:10)

While the talk did not feature a live, interactive demonstration, it effectively presented real-world examples and empirical evidence that serve as a powerful proof of concept for both the existence and effectiveness of these evasion strategies. The most prominent example provided was an "impactful and interesting attack delivery execution strategy" observed on the Binance Smart Chain, involving transactions 930A and 93AE.

This specific incident, which resulted in a loss of over $40,000 USD, perfectly illustrated the execution split evasion technique. The attack was orchestrated across two transactions within the same block (34506417). Transaction 930A was designed to set a specific contract variable. Subsequently, transaction 93AE would read this variable to proceed with its profitable execution. The critical defensive mechanism was that if 930A was not executed before 93AE within the same block, 93AE would revert due to a failed read operation.

This setup effectively tricked front-running bots. When a bot, monitoring the mempool, encountered 93AE, it would likely execute it in its local testnet without the context of 930A having already run. In this isolated test environment, 93AE would consistently revert, leading the bot to incorrectly classify it as a failed, unprofitable transaction. Consequently, the bot would omit front-running 93AE, allowing the actual attacker (the victim in the front-running context) to successfully execute their profitable operation on the mainnet, circumventing the bot's attempt to intercept profit. This real-world event demonstrated the practical success of execution split as an evasion strategy.

Furthermore, the research validated the efficacy of the EV-Scope framework itself by comparing its performance against a straw man approach. The straw man method relied on traditional decompilation and code search techniques to detect evasion strategies. In contrast, EV-Scope utilized dynamic binary analysis and machine learning. On a verification dataset comprising 400 samples, EV-Scope significantly outperformed the straw man, achieving the highest F1 score. This empirical comparison served as a crucial proof of concept for EV-Scope's ability to overcome the limitations of static analysis in deciphering complex, often obfuscated, smart contract evasion logic.

Defensive Implications

▶ Watch: Strategies 3 & 4: Access and Profit Control (8:00)

The research provides crucial insights for Web3 developers and security practitioners seeking to enhance defenses against front-running bots. Based on the identified evasion strategies and the limitations exposed in bot analysis, three primary suggestions emerge for bolstering smart contract security:

1. Avoid Exposing Secrets in Contract Bytecode: Developers should refrain from hardcoding sensitive information directly into the contract's bytecode. This includes accounts used for verification (e.g., legitimate callers) or profit gainers (accounts designated to receive profits). As observed in the research, bots are adept at disassembling bytecode, locating these constant values, and then modifying them to bypass access or profit controls. Instead, more dynamic or secure storage mechanisms, like contract storage variables (as seen in the more effective storage-based solutions on Binance Smart Chain), should be utilized, making it significantly harder for bots to locate and alter these critical values.

1. Maintain Specific Bytecode Layout for Code Integrity Protection: A powerful, albeit subtle, defensive technique is to design smart contracts with a specific bytecode layout. This involves strategically storing crucial data, such as profit gainer addresses or critical configuration parameters, at predefined offsets within the contract's bytecode. When a bot attempts to modify the bytecode (e.g., to change a profit gainer address), it often disrupts this intended layout. If the contract's internal logic then relies on loading values from these specific, expected offsets using EVM instructions, any modification by the bot will cause the data to be loaded incorrectly or to be missing, leading to execution failure. This method effectively acts as a code integrity check, preventing bots from executing a modified contract successfully.

1. Design Code to Check the Runtime Environment: Developers can embed checks within their smart contracts that verify the execution environment. This prevents bots from successfully executing the contract in their controlled, isolated test environments (e.g., local forks or simulated blockchains) without triggering the evasion logic. Examples of such checks include:

• Detecting chain ID: A contract can verify msg.chainid to ensure it's running on the intended mainnet (e.g., Ethereum mainnet ID 1, Binance Smart Chain ID 56) rather than a testnet or a bot's private fork.
• Verifying block height: Checks against block.number or block.timestamp can introduce time-sensitive dependencies that are difficult for bots to perfectly replicate or predict in a test environment.
• Checking block.difficulty or other environmental variables: While less common, any unique or difficult-to-spoof environmental variable can serve as a deterrent.

By implementing these suggestions, developers can significantly increase the complexity and cost for front-running bots, forcing them to expend more resources or leading to detection and failure. The findings emphasize a shift from easily detectable static patterns to dynamic, context-aware, and integrity-protected contract designs.

Key Takeaways

• Front-running remains a severe and costly threat in Web3, causing hundreds of millions of dollars in losses on major blockchains like Ethereum and Binance Smart Chain.
• Application-layer evasion strategies are evolving and crucial for protecting smart contracts and users from profit-seeking bots, shifting the defense to the contract's internal logic.
• The EV-Scope framework provides a robust solution for uncovering these complex evasion strategies, leveraging dynamic binary analysis, machine learning, and trace slicing to overcome limitations of static analysis.
• 32 distinct evasion strategies were identified, categorized into execution split, code obfuscation, access control, and profit control, showcasing the diverse approaches developers employ.
• Developers should avoid hardcoding secrets (like legitimate caller or gainer accounts) directly into bytecode, as bots can easily identify and modify them. Storage-based solutions offer greater resilience.
• Implementing bytecode layout protection and runtime environment checks are effective defensive measures to maintain code integrity and prevent bots from successfully executing modified contracts in their test environments.

About the Speaker(s)

Zuchao Ma is a researcher who presented the paper "Surviving in Dark Forest: Towards Evading the Attacks from Front-Running Bots in Application Layer" at USENIX Security. His work focuses on smart contract security, specifically investigating how smart contracts can evade sophisticated front-running attacks by automated bots on blockchain platforms. The presentation indicates his expertise in analyzing complex contract execution, identifying vulnerabilities, and developing novel defensive strategies within the Web3 ecosystem. The detailed technical nature of the research suggests a background in computer science, cybersecurity, or a related field, with a specialization in blockchain security and decentralized applications.