CTF Blockchain Challenges

This repository collects blockchain challenges in CTFs and wargames.

These challenges are categorized by topic, not by difficulty or recommendation. Some of them include personal writeups and solutions (e.g., Paradigm CTF 2022). Please be aware that these contain spoilers.

---

Table of Contents

• CTF List
• Ethereum
  • Smart contract basics
  • EVM puzzles
  • Misuse of tx.origin
  • Weak sources of randomness from chain attributes
  • ERC-20 basics
  • Storage overwrite by delegatecall
  • Context mismatch in delegatecall
  • Integer overflow
  • Ether transfer failures for non-payable contracts
  • Forced Ether transfers to non-payable contracts via selfdestruct
  • Large gas consumption by contract callees
  • Forgetting to set view/pure to interface and abstract contract functions
  • Missing success flag checks in low-level calls
  • view functions that do not always return same values
  • Mistakes in setting storage and memory
  • Tracing transactions
  • Reversing states
  • Reversing transactions
  • Reversing EVM bytecodes
  • EVM assembly logic bugs
  • EVM bytecode golf
  • Jump-oriented programming
  • Gas optimization
  • Collisions when using abi.encodePacked with variable length arguments
  • Bypassing verifications with zero iteration loops
  • Reentrancy attacks
  • Flash loan basics
  • Governance attacks by executing flash loans during snapshots
  • Bypassing repayments of push architecture flash loans
  • Bugs in AMM price calculation algorithm
  • Attacks using custom tokens
  • Oracle manipulation attacks without flash loans
  • Oracle manipulation attacks with flash loans
  • Sandwich attacks
  • Recoveries of private keys by same-nonce attacks
  • ECDSA signature malleability attacks
  • Brute-forcing addresses
  • Recoveries of public keys
  • ecrecover returns address(0) for invalid signatures
  • Encryption and decryption in secp256k1
  • Bypassing bots and taking ERC-20 tokens owned by wallets with known private keys
  • Claimable intermediate nodes of Merkle trees
  • Precompiled contracts
  • Faking errors
  • Foundry cheatcodes
  • Front-running
  • Back-running
  • EIP-7702
  • Head overflow bugs in calldata tuple ABI-reencoding (< Solidity 0.8.16)
  • Overwriting storage slots via local storage variables (< Solidity 0.8.1)
  • Overwriting arbitrary storage slots by setting array lengths to 2^256-1 (< Solidity 0.6.0)
  • Constructors that is just functions by typos (< Solidity 0.5.0)
  • Overwriting storage slots via uninitialized storage pointer (< Solidity 0.5.0)
  • Other ad-hoc vulnerabilities and methods
• Bitcoin
  • Bitcoin basics
  • Recoveries of private keys by same-nonce attacks
  • Bypassing PoW of other applications using Bitcoin's PoW database
• Solana
• Cosmos
  • CosmWasm
  • Application-specific blockchain
• Move
• Cairo
• Other Blockchain-Related

---

CTF List

🔗: External link

Always-on CTFs / Practice CTFs

Scheduled CTFs

---

Ethereum

Note:

• If an attack is only valid for a particular version of Solidity and not for the latest version, the version is noted at the end of the heading.
• To avoid notation fluctuations, EVM terms are avoided as much as possible and Solidity terms are used.

Smart contract basics

• These challenges can be solved if you know the basic mechanics of Ethereum, the basic language specification of Solidity, and the basic operation of contracts.

EVM puzzles

• Puzzle challenges that can be solved by understanding the EVM specifications.
• No vulnerabilities are used to solve these challenges.

Misuse of tx.origin

• tx.origin refers to the address of the transaction publisher and should not be used as the address of the contract caller msg.sender.

Weak sources of randomness from chain attributes

• Since contract bytecodes are publicly available, it is easy to predict pseudorandom numbers whose generation is completed on-chain (using only states, not off-chain data).
• It is equivalent to having all the parameters of a pseudorandom number generator exposed.
• If you want to use random numbers that are unpredictable to anyone, use a decentralized oracle with a random number function.
  • For example, Chainlink VRF, which implements Verifiable Random Function (VRF).

ERC-20 basics

• These challenges can be solved with an understanding of the ERC-20 token standard.

Storage overwrite by delegatecall

• delegatecall is a potential source of vulnerability because the storage of the delegatecall caller contract can be overwritten by the called contract.

Context mismatch in delegatecall

• Contracts called by delegatecall are executed in the context of the delegatecall caller contract.
• If the function does not carefully consider the context, a bug will be created.

Integer overflow

• For example, subtracting 1 from the value of a variable of uint type when the value is 0 causes an arithmetic overflow.
• Arithmetic overflow has been detected and reverted state since Solidity v0.8.0.
• Contracts written in earlier versions can be checked by using the SafeMath library.

Ether transfer failures for non-payable contracts

• Do not create a contract on the assumption that normal Ether transfer (.send() or .transfer()) can always be executed.
• If a destination is a contract and there is no receive Ether function or payable fallback function, Ether cannot be transferred.
• However, instead of the normal transfer functions, the selfdestruct described in the next section can be used to force such a contract to transfer Ether.

Forced Ether transfers to non-payable contracts via selfdestruct

• If a contract does not have a receive Ether function and a payable fallback function, it is not guaranteed that Ether will not be received.
• When a contract executes selfdestruct, it can transfer its Ether to another contract or EOA, and this selfdestruct transfer can be forced even if the destination contract does not have the receive Ether function and the payable fallback function.
• If the application is built on the assumption that the Ether is 0, it could be a bug.

Large gas consumption by contract callees

• A large amount of gas can be consumed by loops and recursion in call, and there may not be enough gas for the rest of the process.
• Until Solidity v0.8.0, zero division and assert(false) could consume a lot of gas.

Forgetting to set view/pure to interface and abstract contract functions

• If you forget to set view or pure for a function and design your application under the assumption that the state will not change, it will be a bug.

Missing success flag checks in low-level calls

• If a contract performs low-level calls (such as call, delegatecall, or staticcall) without checking the returned success flag, it may mistakenly assume the call succeeded, potentially leading to vulnerabilities.

view functions that do not always return same values

• Since view functions can read state, they can be conditionally branched based on state and do not necessarily return the same value.

Mistakes in setting storage and memory

• If storage and memory are not set properly, old values may be referenced, or overwriting may not occur, resulting in vulnerability.

Tracing transactions

• Various information can be obtained just by following the flow of transaction processing.
• Blockchain explorers such as Etherscan are useful.

Reversing states

• Since the state and the bytecodes of contracts are public, all variables, including private variables, are readable.
• Private variables are only guaranteed not to be directly readable by other contracts, but we, as an entity outside the blockchain, can read them.

Reversing transactions

• Reversing the contents of a transaction or how the state has been changed by the transaction.

Reversing EVM bytecodes

• Reversing a contract for which code is not given in whole or in part.
• evm.codes is very useful.
• Use a decompiler (e.g., Dedaub Decompiler, heimdall).
• Use a disassembler (e.g., ByteGraph, ethersplay).
• Use a debugger (e.g., Foundry Debugger).

EVM assembly logic bugs

• Logic bugs in assemblies such as Yul

EVM bytecode golf

• These challenges have a limit on the length of the bytecode to be created.

Jump-oriented programming

• Jump-Oriented Programming (JOP)

Gas optimization

• These challenges have a limit on the gas to be consumed.

Collisions when using abi.encodePacked with variable length arguments

Bypassing verifications with zero iteration loops

Reentrancy attacks

• In case a function of contract A contains interaction with another contract B or Ether transfer to B, the control is temporarily transferred to B.
• Since B can call A in this control, it will be a bug if the design is based on the assumption that A is not called in the middle of the execution of that function.
• For example, when B executes the withdraw function to withdraw Ether deposited in A, the Ether transfer triggers a control shift to B, and during the withdraw function, B executes A's withdraw function again. Even if the withdraw function is designed to prevent withdrawal of more than the limit if it is simply called twice, if the withdraw function is executed in the middle of the withdraw function, it may be designed to bypass the limit check.
• To prevent reentrancy attacks, use the Checks-Effects-Interactions pattern.

Flash loan basics

• Flash loans are uncollateralized loans that allow the borrowing of an asset, as long as the borrowed assets are returned before the end of the transaction. The borrower can deal with the borrowed assets any way they want within the transaction.
• By making large asset moves, attacks can be made to snatch funds from DeFi applications or to gain large amounts of votes for participation in governance.
• A solution to attacks that use flash loans to corrupt oracle values is to use a decentralized oracle.

Governance attacks by executing flash loans during snapshots

• If the algorithm distributes some kind of rights using the token balance at the time of a snapshot, and if a malicious user transaction can trigger a snapshot, a flash loan can be used to obtain massive rights.
• A period of time to lock the token will avoid this attack.

Bypassing repayments of push architecture flash loans

• There are two architectures of flash loans: push and pull, with push architectures represented by Uniswap and Aave v1 and pull architectures by Aave v2 and dYdX.
• The proposed flash loan in EIP-3156: Flash Loans is a pull architecture.

Bugs in AMM price calculation algorithm

• A bug in the Automated Market Maker (AMM) price calculation algorithm allows a simple combination of trades to drain funds.

Attacks using custom tokens

• The ability of a protocol to use arbitrary tokens is not in itself a bad thing, but it can be an attack vector.
• In addition, bugs in the whitelist design, which assumes that arbitrary tokens are not available, could cause funds to drain.

Oracle manipulation attacks without flash loans

• It corrupts the value of the oracle and drains the funds of applications that refer to that oracle.

Oracle manipulation attacks with flash loans

• The use of flash loans distorts the value of the oracle and drains the funds of the protocols that reference that oracle.
• The ability to move large amounts of funds through a flash loan makes it easy to distort the oracle and cause more damage.

Sandwich attacks

• For example, if there is a transaction by another party to sell token A and buy B, the attacker can put in a transaction to sell A and buy B before the transaction, and later put in a transaction to sell the same amount of B and buy A, thereby ultimately increasing the amount of A at a profit.
• In general, such "revenue earned by selecting, inserting, and reordering transactions contained in a block generated by a miner" is referred to as Miner Extractable Value (MEV). Recently, it is also called Maximal Extractable Value.

Recoveries of private keys by same-nonce attacks

• In general, a same-nonce attack is possible when the same nonce is used for different messages in the elliptic curve DSA (ECDSA), and the secret key can be calculated.
• In Ethereum, if nonces used to sign transactions are the same, this attack is feasible.

ECDSA signature malleability attacks

• ECDSA signatures have a property called malleability, where for a given message and signature (v, r, s), there exists another valid signature (v', r, -s mod n) for the same message.
• This can be exploited in systems that track used signatures, as the alternative signature may not be recognized as already used.
• In Ethereum's secp256k1 curve, this property can be used to bypass signature verification mechanisms.

Brute-forcing addresses

• Brute force can make a part of an address a specific value.

Recoveries of public keys

• The address is the public key applied to a keccak256 hash, and the public key cannot be recovered from the address.
• If even one transaction has been sent, the public key can be back-calculated from it.
• Specifically, it can be recovered from the Recursive Length Prefix (RLP)-encoded data [nonce, gas_price, gas, to, value, data, chain_id, 0, 0] and the signature (v,r,s).

ecrecover returns address(0) for invalid signatures

• The ecrecover precompile returns address(0) when the signature is invalid or malformed.
• This behavior can be exploited if contracts don't properly validate the return value of ecrecover.

Encryption and decryption in secp256k1

Bypassing bots and taking ERC-20 tokens owned by wallets with known private keys

• If a wallet with a known private key has an ERC-20 token but no Ether, it is usually necessary to first send Ether to the wallet and then transfer the ERC-20 token to get the ERC-20 token.
• However, if a bot that immediately takes the Ether sent at this time is running, the Ether will be stolen when the Ether is simply sent.
• In this situation, we can use Flashbots bundled transactions or just permit and transferFrom if the token is EIP-2612 permit friendly.

Claimable intermediate nodes of Merkle trees

Precompiled contracts

Faking errors

Foundry cheatcodes

Front-running

Back-running

• MEV-Share can be used to create bundled transactions to back-run.

EIP-7702

Head overflow bugs in calldata tuple ABI-reencoding (< Solidity 0.8.16)

• See: https://blog.soliditylang.org/2022/08/08/calldata-tuple-reencoding-head-overflow-bug/

Overwriting storage slots via local storage variables (< Solidity 0.8.1)

• In Foo storage foo;, the local variable foo points to slot 0.

Overwriting arbitrary storage slots by setting array lengths to 2^256-1 (< Solidity 0.6.0)

• For example, any storage variable can be overwritten by negatively arithmetic overflowing the length of an array to 2^256-1.
• It need not be due to overflow.
• The length property has been read-only since v0.6.0.

Constructors that is just functions by typos (< Solidity 0.5.0)

• In versions before v0.4.22, the constructor is defined as a function with the same name as the contract, so a typo of the constructor name could cause it to become just a function, resulting in a bug.
• Since v0.5.0, this specification is removed and the constructor keyword must be used.

Overwriting storage slots via uninitialized storage pointer (< Solidity 0.5.0)

• Since v0.5.0, uninitialized storage variables are forbidden, so this bug cannot occur.

Other ad-hoc vulnerabilities and methods

Bitcoin

Note

• This section includes challenges of Bitcoin variants whose transaction model is Unspent Transaction Output (UTXO).

Bitcoin basics

Recoveries of private keys by same-nonce attacks

• There was a bug and it has been fixed using RFC6979.
• https://github.com/daedalus/bitcoin-recover-privkey

Bypassing PoW of other applications using Bitcoin's PoW database

• Bitcoin uses a series of leading zeros in the SHA-256 hash value as a Proof of Work (PoW), but if other applications are designed in the same way, its PoW time can be significantly reduced by choosing one that matches the conditions from Bitcoin's past PoW results

Solana

Cosmos

CosmWasm

Application-specific blockchain

Move

Cairo

Other Blockchain-Related

• Things that are not directly related to blockchains but are part of the ecosystems.