head-dump picoCTF 2025 Solution

Description

1. Step 1Hit the hidden endpoint

   Observation

   The API reference lists a /heapdump endpoint. That is a Spring Boot Actuator route serving a binary JVM snapshot, so download it.

   The Swagger UI at /api-docs lists all API routes, including /heapdump under the Diagnosing section. That endpoint returns a binary JVM snapshot - hundreds of megabytes of every live object, including any String fields the app holds.

   bash

   curl http://verbal-sleep.picoctf.net:<PORT_FROM_INSTANCE>/heapdump -o heapdump

   Copied!

   bash

   file heapdump
   # Expected: 'heapdump: Java HPROF profile data, JAVA PROFILE 1.0.2'
   
   xxd heapdump | head -1
   # Expected first 12 bytes: 4a 41 56 41 20 50 52 4f 46 49 4c 45  ('JAVA PROFILE')

   Copied!

   What didn't work first

   Tried: Browse every article on the blog manually looking for a flag or hidden link instead of checking the API docs.

   The blog articles contain no flag and no direct link to the dump. The endpoint is only listed in the Swagger UI at /api-docs, which is linked from the API Documentation article. Skipping the API docs page means never discovering /heapdump exists.

   Tried: Request /heapdump without -o and let curl print the binary to the terminal.

   The dump is a binary file hundreds of megabytes long. Printing it to the terminal garbles the shell and saves nothing for grep to work on. Write it to disk with -o.

   Learn more

   Spring Boot Actuator is a production monitoring module that exposes management endpoints over HTTP. When misconfigured, it can leak sensitive runtime information. The /heapdump endpoint triggers a full JVM heap snapshot and streams it as a binary HPROF file, often hundreds of megabytes containing every live object in memory. The application stores the flag in a String variable, and Java String objects live on the heap until the garbage collector reclaims them, so anything held in memory at dump time ends up in the file.

   Actuator endpoints were publicly exposed by default before Spring Boot 2.0. Even after the default was changed, misconfigurations remain extremely common: thousands of production services still expose /env, /beans, /heapdump, and /trace without any authentication. The Spring Boot guidance is unambiguous: /heapdump should never be reachable from the public internet. CVE-2017-8046 (a Spring Data REST PATCH RCE) is a related but separate Spring data leak class worth knowing as background.

   Proper hardening involves moving actuator endpoints to a different port with firewall rules, enabling Spring Security authentication on the management interface, and selectively exposing only the endpoints needed (e.g., just /health for load balancer checks). The management.endpoints.web.exposure.include property controls which endpoints are available.

2. Step 2Search the dump

   Observation

   The file is a Java HPROF binary, and the flag is plain ASCII. Force text-mode scanning with grep -a across the raw bytes.

   grep -a forces text mode so the regex actually matches. Without -a, grep auto-detects the file as binary and exits with no output, which looks like an empty result.

   bash

   grep -a picoCTF heapdump

   Copied!

   bash

   grep -aB5 -A5 'picoCTF{' heapdump

   Copied!

   bash

   # Equivalent with strings:

   Copied!

   bash

   strings heapdump | grep picoCTF

   Copied!

   Expected output

   picoCTF{Pat!3nt_15_Th3_K3y_ad7e...}

   What didn't work first

   Tried: Run grep picoCTF heapdump without the -a flag.

   Without -a, grep sees a binary file and prints only that it matched, or nothing at all depending on version. No matching text appears, so the flag looks absent. -a forces text-mode scanning over the whole stream.

   Tried: Open the heap dump in a text editor like nano or less to search for the flag visually.

   A few hundred megabytes of binary will crash or hang most text editors, and what does render is escape sequences and null bytes. grep -a and strings are the right tools for pulling ASCII out of a file this size.

   Learn more

   Heap dumps contain the raw bytes of every object alive in the JVM at the moment the dump was triggered. This includes strings, byte arrays, configuration objects, database credentials, session tokens, API keys, and any other in-memory data - all in plaintext. The -a flag in grep tells it to treat the binary file as text so regular pattern matching still works.

   The strings command is an equally effective alternative: it scans any binary for sequences of printable ASCII characters above a minimum length. Both tools are standard in forensic investigation and incident response for extracting readable artifacts from memory images, core dumps, and crash files. Tools like Eclipse Memory Analyzer (MAT) and VisualVM provide GUI-based heap analysis with object graphs, reference chains, and leak suspects.

   From a security standpoint, the key lesson is that anything stored in memory - even temporarily - can be recovered from a heap dump. This is why sensitive values like private keys and passwords should be stored in char[] (which can be zeroed) rather than String (which is immutable and persists until GC collection) in Java applications.

Flag

Truncated for site policy; the actual flag continues past the redaction. No authentication or decoding needed - just download and search the dump.