KillaBoi/StealMyBitcoin-PoC

Worth a look if you want to study a full PHP memory-corruption exploit reproduced step by step; it is a teaching artifact tied to one specific challenge, not a general-purpose attack tool.

The problem

The Steal My Bitcoin challenge asks solvers to go from an ordinary HTTP endpoint to remote code execution on a PHP worker. Reading a write-up leaves out the awkward parts: how a request that fits in about 250 KiB on the wire can force a 128 MiB memory-limit fatal, why a worker's stale session state is reusable, and how leaked bytes become a heap base and a function pointer. This PoC runs those stages end to end from a single Python file, so you see the requests and responses that produced each value instead of only the final conclusion. The result is a self-contained lab where a solver can watch each leak be accepted or rejected.

What's different

The core mechanism is a forced memory-limit failure during PHP upload-progress parsing. PHP leaves behind state in a worker that is later reused, and the PoC shapes follow-up requests so pointer-looking bytes come back inside a PHPSESSID cookie. It will only accept a heap base when at least four candidate values agree on one aligned 2 MiB Zend heap region, and it requires exactly one agreed base across the pipelined consumers (stage details). The code-pointer stage similarly checks a page offset, 0x112930, as a fingerprint and derives zif_system from zval_ptr_dtor, then places a forged HashTable so the cleanup path calls zif_system (request walkthrough).

The practical benefit is strictness: a bad shape causes an early abort rather than a plausible-looking but wrong address. The trade-off is that those checks are baked to one binary layout. The README is explicit that a Debian php:8.4.26-fpm stack reports the same version string but has a different binary layout, and the run aborts at the code-leak stage; offsets are calibrated for Alpine PHP 8.4.26 on the built-in CLI server with four workers (lab requirements). Every run also writes the raw HTTP bytes to disk before validation, which makes a failed attempt inspectable, though it also means an aborted run still leaves request and response artifacts.

Who should try it

This fits security learners or CTF players who want to see the mechanics of PHP heap manipulation and worker reuse in a controlled lab, and who are willing to maintain the exact Alpine image the offsets target. It is a poor fit for someone looking for a general PHP exploit, a scanner, or anything to point at a production service; the README scopes it to the challenge lab behind nginx on loopback. It also poorly fits anyone who cannot reproduce the specified build, because a same-version but differently built PHP image will not pass the fingerprint check.

Requirements and limitations

Python 3.11+ and the standard library are enough to run the script itself, so setup on the client side is minimal (start here). The real constraint is the server side: the target must be Alpine PHP 8.4.26 running the built-in CLI server with four workers, matching the layout used to calibrate the offsets. A Debian FPM image with the same version string fails at the code-leak stage. The PoC also declares no license, which matters if you want to reuse its code rather than read it.

Ongoing upkeep is mostly about the build rather than the script: the leak checks are fingerprint-based, so a different PHP patch level or base image can invalidate the accepted offsets. The heap check also depends on timing and worker reuse, and the README's acceptance rules mean a run can abort mid-way. Output directories are timestamped, and using --output-dir against a new directory is the documented way to direct them.

HotRepo's take

HotRepo recorded the repository at #22 on its NEW-REPOSITORY board (not the overall Trending board), all languages, with 333 total stars on 2026-10-26. There is only one recorded board date, so this is a snapshot rather than a growth series; persistence cannot be judged from it. The HN thread that day drew 69 points and 13 comments, with one commenter arguing the challenge setup used the PHP development server proxied through nginx rather than the usual FPM or mod_php path (comment). Before relying on the PoC, verify that your target image actually matches the documented Alpine build rather than only the PHP version string.