head-dump

Platform: PicoCTF Category: Web Exploitation Environment: Standalone

Goal: a blog application documents its own diagnostic endpoints. One of them writes out the server’s memory, and the flag is sitting inside it.

Approach

The site carries a link to its API Documentation, which turns out to be a Swagger interface at /api-docs/: a rendered, interactive list of every route the application exposes, including the ones nobody was meant to call. Under a Diagnosing section is a GET route that returns a heap snapshot, with a Try it out button that unlocks Execute, which runs it and offers the result as a download.

Read the path carefully before typing it. The challenge is called head-dump, but the route is /heapdump, and the title is a pun on the mechanism rather than a spelling of it.

The snapshot is megabytes of JSON, so opening it in an editor is the wrong move. Copy the download link and search it in place.

Bash

┌──(Idan@Kali)-[~/head-dump]
└─> curl -s "http://verbal-sleep.picoctf.net:64531/heapdump" | grep "picoCTF{.*}" --color=none
<flag>

Flag picoCTF{Pat!3nt_15_Th3_K3y_f1179e46} Reveal

Why it works

A V8 heap snapshot is a JSON serialisation of every object still live in the Node process at the moment it was taken. The objects and their references are stored as flat arrays of integers, and every piece of text they point at is collected into one deduplicated string table, which is why grep finds a value the application only ever held in a variable and never rendered to a page. It works cleanly here because the flag is short, plain ASCII, and stored as a single flat string. That table escapes anything non-ASCII and truncates each entry at 1024 characters, so a longer secret, or one assembled by concatenation at runtime, would not survive in a form grep could match.

The endpoint is not itself a mistake: writing a heap snapshot is how you diagnose a memory leak in production. Serving it without authentication, and then advertising it in public documentation, is.