head-dump picoCTF 2025 Solution

Description

1. Step 1

   Hit the hidden endpoint

   Observation

   I noticed the challenge description explicitly mentioned a /heapdump endpoint listed in the API reference, which suggested that downloading the binary JVM snapshot from that Spring Boot Actuator route was the first required action.

   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:63972/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 HPROF file hundreds of megabytes in size. Printing it raw to the terminal garbles the shell, floods stdout, and prevents the file from being saved for grep. The -o flag is required to write the file to disk so subsequent search commands can work on it.

   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 2

   Search the dump

   Observation

   I noticed the downloaded file was identified as a Java HPROF binary, and the flag format picoCTF is a plain ASCII string, which suggested using grep -a to force text-mode scanning across the raw binary 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 auto-detects the HPROF file as binary and emits only 'Binary file heapdump matches' or nothing at all, depending on the version. No matching text is printed, so the flag appears absent. The -a flag is required to force text-mode scanning across the entire binary stream.

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

   A several-hundred-megabyte binary file causes most text editors to either crash, hang, or display only escape sequences and null bytes. The tool cannot render HPROF structure as searchable text. grep -a or strings are the correct command-line tools for extracting ASCII sequences from binary files of 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.