🔐 Phase 4 — Security & Auditing (Days 56–75)

// ATTACK VECTOR:
// Attacker contract has fallback() that calls back into victim.withdraw()
// State not updated before external call -> attacker drains repeatedly
 
contract Attack {
    Victim victim;
    function attack() external payable {
        victim.deposit{value: 1 ether}();
        victim.withdraw(1 ether);
    }
    fallback() external payable {
        if (address(victim).balance >= 1 ether) {
            victim.withdraw(1 ether);  // re-enters before state update
        }
    }
}
 
// CROSS-FUNCTION REENTRANCY: re-enter a DIFFERENT function
// Read-only reentrancy: re-enter a view function while state is inconsistent
// ERC-777 reentrancy: transfer hooks trigger before state updates
 
// DEFENCES:
// 1. CEI pattern (primary)
// 2. nonReentrant modifier (secondary)
// 3. Never assume external code is safe

// Missing auth: function should be onlyOwner but isn't
// Wrong auth: checks msg.sender but should check tx.origin (or vice versa)
// Initialiser not protected: initialize() callable by anyone (proxy pattern bug)
 
// tx.origin attack:
// User calls MaliciousContract, which calls Victim using tx.origin check
// tx.origin = User (who is authorised). Victim thinks User called it directly.
// NEVER use tx.origin for authorisation. Always use msg.sender.
 
// Real exploit: Parity Multisig hack ($30M) - unprotected initWallet function
// Anyone could call initWallet and become the owner of any Parity wallet

// Solidity 0.8+: overflow/underflow reverts automatically
// But: unchecked blocks, type casting, and division can still cause issues
 
// Type casting precision loss:
uint256 a = 300;
uint8 b = uint8(a);  // b = 44 (300 % 256). No revert. Silent truncation.
 
// Division rounding:
// 1 / 2 = 0 in Solidity (always rounds down)
// This can cause dust accumulation or protocol insolvency over many operations
 
// Multiplication overflow in unchecked:
unchecked {
    uint256 x = type(uint256).max;
    uint256 y = x * 2;  // silently overflows to a smaller number
}

Attack pattern:
1. Flash loan $100M of token X
2. Deposit X into a protocol (moves price or passes governance threshold)
3. Exploit the protocol (liquidate positions at wrong price, pass malicious proposal)
4. Withdraw X
5. Repay flash loan + fee
6. Profit: everything extracted in step 3
 
Defences:
- Use time-weighted prices (TWAP) not spot prices for critical operations
- Use governance snapshots (token balance at proposal block, not current block)
- Require a delay between deposit and any privileged action

Scenario: you submit a profitable arbitrage transaction
MEV searcher sees it in mempool, copies it with higher gas
MEV transaction executes first, takes your profit
 
Sandwich attack:
1. Bot sees your large swap: 1000 ETH for USDC
2. Bot buys ETH (pushing price up) - frontrun
3. Your swap executes at worse price
4. Bot sells ETH - backrun. Profit from your slippage.
 
Defences:
- Set tight slippage tolerances (amountOutMinimum)
- Use Flashbots Protect or private RPC for sensitive transactions
- Commit-reveal for randomness and auctions

// ERC-20 tokens: some return false instead of reverting on failure
// If you don't check the return value, the transfer silently fails
 
// WRONG:
token.transfer(recipient, amount);  // if transfer returns false, we don't know
 
// CORRECT:
require(token.transfer(recipient, amount), "Transfer failed");
// OR:
token.safeTransfer(recipient, amount);  // OpenZeppelin handles this
 
// Low-level calls always return (bool success, bytes memory data)
(bool success,) = recipient.call{value: amount}("");
require(success, "ETH transfer failed");

// block.timestamp: validators can manipulate by up to ~12 seconds in PoS
// Never use for precise timing of financial operations
// Use block numbers for rough timing. Use off-chain systems for precise timing.
 
// ACCEPTABLE: time-based vesting with multi-minute granularity
require(block.timestamp >= vestingStart + 365 days);
 
// DANGEROUS: using timestamp as randomness source
uint256 random = uint256(keccak256(abi.encodePacked(block.timestamp, msg.sender)));
// Validator can choose which timestamp to use within the valid range

// If you use ecrecover for authorisation, an attacker can replay the signature
// on a different chain, different contract, or for a different operation
 
// ALWAYS include in your signed hash:
// 1. chainId (prevents cross-chain replay)
// 2. contract address (prevents cross-contract replay)
// 3. nonce (prevents same-contract replay)
// 4. expiry (prevents stale signature use)
 
// EIP-712 structured data signing handles all of this:
bytes32 domainSeparator = keccak256(abi.encode(
    keccak256("EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"),
    keccak256(bytes(name)),
    keccak256(bytes("1")),
    block.chainid,
    address(this)
));

# Slither: static analysis
slither . --detect all
slither . --detect reentrancy-eth,reentrancy-no-eth
slither . --detect arbitrary-send-eth
 
# Mythril: symbolic execution
myth analyze src/Contract.sol --execution-timeout 300
 
# Echidna: fuzzing
# Write property functions (invariants) that should never be false
# Echidna tries to find inputs that break them
function echidna_balance_invariant() public returns (bool) {
    return totalSupply == sumOfAllBalances();
}
 
# Foundry fuzzing:
function testFuzz_Invariant(uint256 amount) public {
    amount = bound(amount, 1, type(uint128).max);
    // property that should always hold
}

// If share price = totalAssets() / totalShares
// and totalAssets() reads token.balanceOf(address(this))
// attacker can donate tokens directly to inflate share price
// New depositors get fewer shares than expected -> effectively robbed
 
// Fix: track totalAssets internally, don't rely on balanceOf

1. Attacker is first LP: deposits 1 wei, receives 1 share
2. Attacker donates 1000e18 tokens directly (not through deposit)
3. Now: 1 share represents 1000e18 + 1 wei of assets
4. Victim deposits 1999e18 tokens: receives floor(1999e18 * 1 / (1000e18 + 1)) = 1 share
5. Attacker withdraws 1 share: gets half of all assets
6. Attacker stole ~500e18 from the victim
 
Fix: Virtual shares/assets (add 1000 to both numerator and denominator)

// Transparent proxy stores admin at slot:
// keccak256("eip1967.proxy.admin") - 1 = 0xb53127...
 
// If implementation has a mapping at slot 0 and a user's key hashes
// to the same slot as the admin storage -> they can overwrite the admin
 
// EIP-1967: standardised storage slots for proxy variables
// Always use EIP-1967 slots for proxy variables
bytes32 constant IMPLEMENTATION_SLOT =
    0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

# Run all detectors:
slither . 
 
# Most important detectors:
# reentrancy-eth: reentrancy with ETH transfer
# arbitrary-send-eth: unprotected ETH send
# controlled-delegatecall: delegatecall with untrusted data
# msg-value-loop: msg.value in a loop (always a bug)
# tx-origin: tx.origin for authentication
# suicidal: anyone can call selfdestruct
 
# Print human-readable contract summary:
slither . --print human-summary
slither . --print call-graph
slither . --print data-dependency

// echidna_* functions are properties that must always return true
// Echidna generates random sequences of function calls trying to break them
 
contract VaultTest is Vault {
    address echidna_caller = address(0x1234);
 
    function echidna_solvency() public view returns (bool) {
        // Total assets must always equal sum of all deposits
        return totalAssets() >= totalDeposited;
    }
 
    function echidna_no_free_shares() public view returns (bool) {
        // You cannot get shares without depositing
        return balanceOf[echidna_caller] <= deposited[echidna_caller];
    }
}