Adversarial Exploit Discovery

Security auditing and red teaming are different activities with different goals. An audit asks: does this contract conform to its specification and avoid known vulnerability classes? Red teaming asks: if I wanted to steal everything in this contract, how would I do it?

The distinction matters because the second question is open-ended. An audit checks for reentrancy, oracle manipulation, access control failures, and the other catalogued vulnerability classes. A red team exercise also checks for those — but then continues into territory where there is no checklist. The attacker who exploited Euler Finance in March 2023 for approximately $197 million did not use a technique from any existing taxonomy. They found a novel interaction between the donateToReserves function and the health check logic that created a liquidation path the protocol’s auditors had not considered.

This article describes a systematic methodology for approaching smart contract security from the adversarial perspective. The techniques apply to EVM, SVM, and ZK runtimes, though the examples here focus on EVM Solidity contracts for concreteness.

The Adversarial Mindset

The fundamental shift from defensive to offensive analysis is in what you consider a finding. A defensive tool classifies code against known vulnerability patterns. An offensive methodology asks a different set of questions:

• What happens if this function is called in an unexpected order?
• What happens if the caller holds an unusual combination of tokens or positions?
• What happens when two protocols that individually behave correctly interact through a shared state dependency?
• Which implicit assumptions in this code are not enforced by explicit checks?

Every smart contract encodes assumptions about its operating environment. The contract assumes callers will interact through the intended UI flow. It assumes token balances will change only through its own transfer logic. It assumes the oracle will return prices within a reasonable range. The adversarial methodology systematically identifies and violates these assumptions.

Methodology Overview

The red team workflow proceeds through four phases: reconnaissance, hypothesis generation, validation, and exploitation. Each phase uses different tools and techniques, and the output of each feeds the next.

flowchart TD
    classDef process fill:#1a2233,stroke:#7ea8d4,stroke-width:2px,color:#c0d8f0
    classDef data fill:#332a1a,stroke:#d4b870,stroke-width:2px,color:#f0e0c0
    classDef highlight fill:#332519,stroke:#e8a87c,stroke-width:2px,color:#f0d8c0
    classDef success fill:#1a331a,stroke:#a8c686,stroke-width:2px,color:#c8e8b0
    classDef attack fill:#331a1a,stroke:#d97777,stroke-width:2px,color:#f0c0c0

    R1["Reconnaissance\nBytecode recovery, call graph\nconstruction, state mapping"]:::process
    R2["Hypothesis Generation\nAssumption identification,\nattack surface enumeration"]:::highlight
    R3["Validation\nFuzzing, symbolic execution,\nconstraint solving"]:::process
    R4["Exploitation\nPoC synthesis, transaction\nsequence construction"]:::attack
    R5["Novel Finding\nNew vulnerability class\nor variant documented"]:::success

    R1 --> R2 --> R3 --> R4 --> R5
    R3 -- "hypothesis\ndisproved" --> R2
    R4 -- "exploit\nblocked" --> R3

Phase 1: Reconnaissance

Reconnaissance starts from bytecode, not source. This is deliberate. Source code, when available, tells you what the developer intended. Bytecode tells you what actually executes. The difference between these — compiler optimizations, inlining, storage layout decisions — is frequently where vulnerabilities hide.

Bytecode-first reconnaissance produces:

• Function signature recovery: Mapping selector bytes to known function signatures. Functions that do not match any known signature are potentially undocumented administrative functions — a common source of access control vulnerabilities.
• Cross-contract call graph: Every CALL, DELEGATECALL, and STATICCALL target, resolved where possible. The call graph reveals which external contracts are trusted and how deeply.
• Storage layout mapping: Which storage slots are read and written by each function. Shared storage slots between functions are the basis of reentrancy and state inconsistency bugs.
• Access control model: Which functions check msg.sender, what roles exist, and whether there are unprotected state-modifying functions.

The critical output from this phase is the trust boundary map: a directed graph showing which contracts trust which other contracts, through what interfaces, and with what level of validation.

Phase 2: Hypothesis Generation

With the trust boundary map established, hypothesis generation systematically identifies implicit assumptions the contract makes. Each assumption that is not enforced by an explicit check is a candidate vulnerability hypothesis.

Common hypothesis categories:

Ordering assumptions: The contract assumes functions will be called in a particular sequence (deposit before withdraw, initialize before use). What happens if an attacker calls them out of order?

Atomicity assumptions: The contract assumes that certain state changes will not be observed mid-execution. Flash loans, reentrancy, and callback mechanisms all violate this assumption.

Value range assumptions: The contract assumes oracle prices, token amounts, or computed ratios will fall within expected bounds. What happens at extreme values?

Identity assumptions: The contract assumes msg.sender represents a specific type of entity (an EOA, a specific protocol contract). What happens when a contract calls the function instead?

Consider this contract pattern:

contract LendingPool {
    mapping(address => uint256) public deposits;
    mapping(address => uint256) public borrows;
    IOracle public oracle;

    function liquidate(address borrower) external {
        uint256 collateralValue = oracle.getPrice(collateralToken)
            * deposits[borrower] / 1e18;
        uint256 debtValue = oracle.getPrice(debtToken)
            * borrows[borrower] / 1e18;

        require(debtValue > collateralValue * liquidationThreshold / 100,
            "not undercollateralized");

        // Transfer collateral to liquidator
        deposits[borrower] -= deposits[borrower];
        IERC20(collateralToken).transfer(msg.sender,
            deposits[borrower]);
    }
}

A defensive scan checks for reentrancy (the transfer call after state modification — but state is already zeroed, so classic reentrancy is blocked) and access control (the function is public, which is intended for liquidations). An adversarial analysis generates different hypotheses:

• The oracle price is read within the same transaction. Can it be manipulated via a flash loan to force a healthy position into liquidation?
• The liquidation transfers all collateral regardless of debt size. Is the liquidation bonus unbounded?
• What happens if deposits[borrower] is zero when this function is called — does the require check still hold?

Each hypothesis becomes a target for the validation phase.

Phase 3: Validation Through Fuzzing

Hypotheses are tested through coverage-guided fuzzing with domain-specific mutation strategies. The fuzzer is configured to explore the hypothesis by targeting specific code paths.

For each hypothesis, the fuzzer constructs a campaign — a set of initial conditions, a sequence of transactions to execute, and an invariant to check for violation.

flowchart TD
    classDef process fill:#1a2233,stroke:#7ea8d4,stroke-width:2px,color:#c0d8f0
    classDef data fill:#332a1a,stroke:#d4b870,stroke-width:2px,color:#f0e0c0
    classDef highlight fill:#332519,stroke:#e8a87c,stroke-width:2px,color:#f0d8c0
    classDef success fill:#1a331a,stroke:#a8c686,stroke-width:2px,color:#c8e8b0
    classDef attack fill:#331a1a,stroke:#d97777,stroke-width:2px,color:#f0c0c0

    H["Hypothesis\n(e.g., oracle price\ncan be manipulated)"]:::data
    C["Campaign Construction\nInitial state, tx sequence\ntemplate, invariant"]:::process
    M["Mutation Engine\nValue, sequence, and\nstate mutations"]:::process
    E["Execution\nFork mainnet state,\nrun tx sequence"]:::process
    T["Taint Tracking\nPropagate attacker-controlled\ndata through execution"]:::highlight
    CS["Constraint Solving\nSolve for inputs that\nreach target paths"]:::process
    V{"Invariant\nViolated?"}:::data
    Y["Confirmed\nVulnerability"]:::attack
    N["Increase Coverage\nMutate inputs, vary\ninitial state"]:::process

    H --> C --> M --> E --> T --> V
    V -- "yes" --> Y
    V -- "no" --> CS --> N --> M

Three fuzzing techniques are combined:

Coverage-guided mutation tracks which basic blocks, edges, and state configurations each input reaches. Inputs that reach new coverage are retained and mutated. This systematically explores the contract’s execution space without requiring the operator to manually craft inputs.

Taint tracking follows attacker-controlled values through execution. When the fuzzer generates an input, every byte of that input is marked as tainted. As execution proceeds, taint propagates through arithmetic operations, memory copies, and storage reads that depend on tainted values. When a tainted value reaches a security-sensitive operation — a comparison in a require statement, a value in a transfer call, a storage write — the fuzzer records the dependency chain. This identifies which attacker-controlled inputs influence which critical operations.

Symbolic constraint solving handles hard constraints that random mutation cannot satisfy. When execution reaches a branch that depends on a specific relationship between inputs and state (e.g., require(amount <= balance) where balance is a storage value), the solver constructs a constraint system and finds satisfying inputs. This prevents the fuzzer from wasting cycles on paths it cannot reach through mutation alone.

Multi-Transaction Sequences

Single-transaction fuzzing misses the majority of real exploits. The Beanstalk governance attack required multiple transactions in a single block: acquiring voting tokens, proposing a governance action, voting, and executing — all atomically. The Euler Finance exploit required a specific sequence of deposits, borrows, and donations that individually looked benign but collectively created an exploitable state.

The fuzzer generates multi-transaction sequences by:

1. Starting with a single-transaction baseline
2. Inserting additional transactions before, between, and after the initial sequence
3. Varying the caller address between transactions (attacker EOA, attacker contract, victim contract, third-party contracts)
4. Varying block numbers and timestamps between transactions
5. Inserting flash loan acquire/repay pairs that wrap subsequences

Each mutation of the sequence is evaluated for coverage. Sequences that reach new code paths or state configurations are retained for further mutation.

Bytecode-Level Attack Surface Analysis

Working from bytecode rather than source reveals attack surface that source-level review misses.

Compiler-Introduced Vulnerabilities

The Solidity compiler makes decisions that are invisible at the source level but affect security:

Storage packing: The compiler packs multiple variables into a single 256-bit storage slot. When variables are packed together, a write to one variable’s bits can interact with adjacent bits if the masking is incorrect. Bytecode analysis directly inspects the AND, OR, and shift operations that implement packing, rather than relying on the compiler to get them right.

Function dispatch: The compiler-generated dispatcher routes calls by selector. In some compiler versions and optimization settings, the fallback function may be reachable through unexpected paths. Bytecode analysis maps the complete dispatch logic, including edge cases where no selector matches.

Proxy patterns: Transparent proxies, UUPS proxies, and diamond proxies all involve DELEGATECALL forwarding. The interaction between the proxy’s storage layout and the implementation’s storage layout is a bytecode-level concern — source code shows two separate contracts, but they share a single storage space at runtime. Bytecode analysis identifies storage slot collisions between proxy and implementation.

Undocumented Functions

Contracts occasionally contain functions that do not appear in the public ABI. These may be debugging functions left in by developers, administrative backdoors, or compiler artifacts. Bytecode analysis recovers every reachable function selector, including those not in the ABI JSON. Unknown selectors with state-modifying behavior are high-priority targets for access control analysis.

Exploit Synthesis

When validation confirms a vulnerability hypothesis, the next step is constructing a working proof-of-concept. This serves two purposes: confirming the finding is real (not a false positive from static analysis) and quantifying the impact (how much value is extractable).

The synthesis process constructs a Solidity exploit contract and a Foundry test that:

1. Forks mainnet state at a specific block
2. Deploys the attacker contract
3. Executes the attack transaction sequence
4. Asserts that value was transferred to the attacker
5. Reports the extracted amount

For the lending pool example above, an oracle manipulation exploit might look like:

contract OracleManipulationExploit {
    ILendingPool pool;
    IUniswapV2Pair pair;
    IERC20 collateralToken;

    function attack() external {
        // Step 1: Flash loan a large amount of the debt token
        pair.swap(flashAmount, 0, address(this), abi.encode(0));
    }

    function uniswapV2Call(
        address,
        uint256 amount,
        uint256,
        bytes calldata
    ) external {
        // Step 2: Dump debt tokens into the AMM pool
        // to crash the debt token price
        collateralToken.transfer(address(pair), amount);

        // Step 3: Liquidate a healthy position
        // whose collateral now appears undercollateralized
        // because the oracle reads the manipulated spot price
        pool.liquidate(targetBorrower);

        // Step 4: Repay flash loan
        // Profit = seized collateral - flash loan repayment
        IERC20(debtToken).transfer(address(pair),
            amount * 1000 / 997 + 1);
    }
}

The synthesis engine generates this structure by selecting from exploit templates matched to the vulnerability class:

Vulnerability Class	Exploit Template	Key Components
Oracle manipulation	Flash loan + price distortion + victim call	Flash loan source, AMM pair, distortion direction
Reentrancy	Callback contract + re-entrant call	Callback hook, re-entry function, extraction call
Access control	Direct call to unprotected function	Caller setup, function selector, parameters
Flash loan governance	Token acquisition + proposal + execution	Governance interface, proposal encoding, timing
Delegatecall hijack	Proxy storage collision exploitation	Implementation slot, storage layout mapping
Integer overflow	Boundary value inputs	Overflow direction, affected computation

After template selection, the engine fills in concrete values: contract addresses, token amounts, function parameters, and transaction ordering. These values come from the reconnaissance phase (contract addresses, storage values) and the fuzzing phase (input values that trigger the vulnerability).

Discovering Novel Vulnerability Classes

The methodology described above handles known vulnerability classes systematically. Discovering genuinely new classes — patterns that do not match any existing template — requires a different approach.

Novel vulnerability classes typically emerge from one of three sources:

New protocol primitives: When DeFi introduced flash loans in 2020, the immediate consequence was a new class of oracle manipulation attacks. When ERC-4626 vaults standardized yield-bearing tokens, the interaction between vault share pricing and external integrations created new rounding and donation attack surfaces. Each new primitive creates new assumption violations to explore.

Cross-protocol composition: Two protocols that are individually correct may be collectively vulnerable when composed. A lending protocol that uses a DEX’s spot price as an oracle creates a vulnerability that exists in neither protocol alone. The combinatorial explosion of protocol interactions means that new vulnerability classes emerge from new compositions, not necessarily from new code.

EVM-level mechanics: Some vulnerability classes arise from properties of the execution environment rather than application logic. The SELFDESTRUCT opcode forcing ETH into a contract that does not expect it. The CREATE2 opcode enabling address prediction for front-running. Block-level properties like block.timestamp and block.basefee that miners or validators can influence. These produce vulnerability classes that are invisible at the application level.

The systematic approach to discovering novel classes is to enumerate protocol assumptions against each of these sources:

flowchart LR
    classDef process fill:#1a2233,stroke:#7ea8d4,stroke-width:2px,color:#c0d8f0
    classDef data fill:#332a1a,stroke:#d4b870,stroke-width:2px,color:#f0e0c0
    classDef highlight fill:#332519,stroke:#e8a87c,stroke-width:2px,color:#f0d8c0
    classDef success fill:#1a331a,stroke:#a8c686,stroke-width:2px,color:#c8e8b0
    classDef attack fill:#331a1a,stroke:#d97777,stroke-width:2px,color:#f0c0c0

    A["Protocol\nAssumptions"]:::data
    B["New Primitives\n(flash loans, vaults,\nrestaking, hooks)"]:::highlight
    C["Cross-Protocol\nComposition\n(DEX+lending,\noracle+vault)"]:::highlight
    D["EVM Mechanics\n(CREATE2, SELFDESTRUCT,\ntransient storage)"]:::highlight
    E["Assumption\nViolation\nMatrix"]:::process
    F["Fuzzing\nCampaigns"]:::process
    G["Novel Class\nDiscovery"]:::attack

    A --> E
    B --> E
    C --> E
    D --> E
    E --> F --> G

For each cell in the matrix — each combination of protocol assumption and violation source — the fuzzer constructs a targeted campaign. Most cells produce no results. The ones that do are new vulnerability classes.

The Arms Race

Adversarial methodology is not static. As defenses improve, attack techniques evolve. Several trends shape the current landscape:

Reentrancy guards are now standard, but they protect individual functions, not cross-function or cross-contract reentrancy. The attack surface has shifted from “call before state update” to “state inconsistency observable through view functions during execution.”

Oracle manipulation defenses have moved from spot prices to TWAPs, but TWAP manipulation over multiple blocks is feasible for well-capitalized attackers. The defense and attack have both increased in complexity.

Formal verification covers specific properties but requires those properties to be specified. A contract that is formally verified to never allow unauthorized withdrawals may still be vulnerable to an oracle manipulation that makes authorized withdrawals underpriced. The gap between what is specified and what matters is the red team’s operating space.

MEV and transaction ordering add a new dimension. Even when a contract is not vulnerable in isolation, the ability to reorder, front-run, or sandwich transactions creates extraction opportunities that depend on the mempool environment rather than the contract’s logic.

The practical consequence for red team methodology is that the reconnaissance and hypothesis generation phases must continuously expand to cover new attack surfaces as they emerge. A static checklist of known vulnerabilities will always lag behind the attacker’s current toolkit.

Conclusion

Red team methodology for smart contracts follows the same principles as adversarial security research in any domain: understand the system deeply, identify assumptions, violate them systematically, and confirm findings through concrete execution. The specific techniques — bytecode analysis for reconnaissance, coverage-guided fuzzing with taint tracking for validation, and template-based exploit synthesis for confirmation — are implementations of those principles for the smart contract domain.

The approach produces two categories of output. First, confirmed vulnerabilities in specific contracts with working proof-of-concept exploits — the direct security value. Second, and potentially more valuable, the discovery of new vulnerability classes that feed back into detector development and expand the scope of automated analysis. The adversarial perspective is how the field’s understanding of smart contract security grows.

References

1. Luu, L., Chu, D.-H., Olickel, H., Saxena, P., & Hobor, A. (2016). Making Smart Contracts Smarter. Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. https://doi.org/10.1145/2976749.2978309
2. Rodler, M., Li, W., Karame, G.O., & Davi, L. (2019). Sereum: Protecting Existing Smart Contracts Against Re-Entrancy Attacks. Proceedings of the 26th Network and Distributed System Security Symposium. https://doi.org/10.14722/ndss.2019.23413
3. EIP-4626: Tokenized Vault Standard. https://eips.ethereum.org/EIPS/eip-4626
4. SWC Registry: Smart Contract Weakness Classification. https://swcregistry.io/
5. Zhou, L., Qin, K., Torres, C.F., Le, D.V., & Gervais, A. (2021). High-Frequency Trading on Decentralized On-Chain Exchanges. 2021 IEEE Symposium on Security and Privacy. https://doi.org/10.1109/SP40001.2021.00027
6. Qin, K., Zhou, L., & Gervais, A. (2022). Quantifying Blockchain Extractable Value: How dark is the forest? 2022 IEEE Symposium on Security and Privacy. https://doi.org/10.1109/SP46214.2022.9833734