CTF-Writeups

HuntMe1 — Writeup

Challenge: HuntMe1
Author: N!L
Type: Reverse Engineering / Basic Forensics
File: HuntMe1 (Linux ELF)
Flag: nexus{h1dd3n_1n_7h3_f0r357_4t_n1gh7}

---

Summary

Running the binary prints story text but doesn’t ask for input and never outputs a flag.
The flag is stored as a plaintext constant in the binary’s read-only data section (.rodata) under the symbol hidden_payload.

---

1) Identify the file

file HuntMe1

Example output:

HuntMe1: ELF 64-bit LSB pie executable, x86-64, dynamically linked, ... , not stripped

Key points:

• ELF 64-bit: Linux executable
• PIE: position-independent executable (normal on modern systems)
• not stripped: symbols are present (helpful)

---

2) Run the program

./HuntMe1

The program prints atmospheric “forest at night” text and exits.

• No prompt
• No arguments required
• No visible branch/interaction

This matches the challenge hint: “Nothing reacts. Nothing responds. Yet something is there.”

---

3) Look for embedded strings

A fast way to find hidden plaintext is strings.

strings -n 4 HuntMe1 | grep 'nexus{'

Output:

nexus{h1dd3n_1n_7h3_f0r357_4t_n1gh7}

At this point, the flag is already recovered.

---

4) (Optional) Confirm where it lives — symbol + .rodata

Because the binary is not stripped, we can check symbols:

nm -C HuntMe1 | grep -i hidden

Output:

0000000000002020 R hidden_payload

• The R indicates a read-only symbol (typically .rodata)
• The address (0x2020) is where the payload starts

Dump .rodata to verify:

objdump -s -j .rodata HuntMe1 | less

You’ll see the ASCII for the flag in the dump around that address.

---

Flag

nexus{h1dd3n_1n_7h3_f0r357_4t_n1gh7}