Feel free to copy, edit, and expand each section with the concrete information you gather while solving the challenge. | Field | Value (to be filled) | |----------------------|----------------------| | Challenge Name | hunta‑694 | | Category | (e.g., Pwn / Web / Crypto / Reverse / Forensics) | | Points | (e.g., 200) | | Provided Files | hunta-694 (binary / zip / source code), README , Dockerfile , etc. | | Connection Details | nc huntu.ctf.example.com 1337 (if remote) | | Goal | Retrieve the flag in the format CTF... | Quick Summary “hunta‑694” is a (type) challenge that revolves around (brief description of the core mechanic – e.g., a buffer overflow in a custom network service, a hidden SQL injection, a flawed RSA implementation, etc.). The solution consists of (high‑level steps). 2. Recon / Information Gathering 2.1. File Inspection $ file hunta-694 $ ldd hunta-694 # for binaries $ strings hunta-694 | head $ binwalk hunta-694 # for embedded data Note: Record the architecture (x86‑64, ARM, etc.), linked libraries, and any obvious strings that hint at functionality (e.g., “Enter password”, “Welcome”, “debug”). 2.2. Static Analysis | Tool | Command | What to look for | |------|---------|------------------| | Ghidra / IDA | Open the binary | Function names, main , suspicious strcpy , gets , system calls | | objdump | objdump -d -M intel hunta-694 | Disassembly for gadgets or vulnerable patterns | | radare2 | r2 -A hunta-694 → aaa | Auto‑analysis, function list ( afl ), cross‑references ( axt ) | | readelf | readelf -a hunta-694 | Section permissions ( .got , .plt ), NX/PIE/ASLR status | | nm | nm -D hunta-694 | Exported symbols (if any) | | checksec | checksec --file=hunta-694 | Stack canaries, RELRO, PIE, NX | 2.3. Dynamic Analysis | Tool | Command | Purpose | |------|---------|---------| | gdb | gdb ./hunta-694 → set breakpoints, run | Observe program flow, locate crash points | | pwndbg / gef | Load as GDB plugin | Helpful visualizations for stack/heap | | ltrace / strace | ltrace ./hunta-694 / strace ./hunta-694 | System calls, library calls | | valgrind | valgrind ./hunta-694 | Detect memory errors | | qemu‑user (if different arch) | qemu-x86_64 ./hunta-694 | Run non‑native binaries |
# Receive and parse leak leaked_puts = u64(io.recvline().strip().ljust(8, b'\x00')) log.success(f'Leaked puts@GLIBC: hex(leaked_puts)')
Because the exact nature of the challenge (binary, web, crypto, pwn, rev, etc.) isn’t known from the name alone, the write‑up is organized in a modular way so you can fill in the details that are specific to the actual task.
# ---------------------------------------------------------------------- # Exploit # ---------------------------------------------------------------------- def main(): io = start()
Feel free to copy, edit, and expand each section with the concrete information you gather while solving the challenge. | Field | Value (to be filled) | |----------------------|----------------------| | Challenge Name | hunta‑694 | | Category | (e.g., Pwn / Web / Crypto / Reverse / Forensics) | | Points | (e.g., 200) | | Provided Files | hunta-694 (binary / zip / source code), README , Dockerfile , etc. | | Connection Details | nc huntu.ctf.example.com 1337 (if remote) | | Goal | Retrieve the flag in the format CTF... | Quick Summary “hunta‑694” is a (type) challenge that revolves around (brief description of the core mechanic – e.g., a buffer overflow in a custom network service, a hidden SQL injection, a flawed RSA implementation, etc.). The solution consists of (high‑level steps). 2. Recon / Information Gathering 2.1. File Inspection $ file hunta-694 $ ldd hunta-694 # for binaries $ strings hunta-694 | head $ binwalk hunta-694 # for embedded data Note: Record the architecture (x86‑64, ARM, etc.), linked libraries, and any obvious strings that hint at functionality (e.g., “Enter password”, “Welcome”, “debug”). 2.2. Static Analysis | Tool | Command | What to look for | |------|---------|------------------| | Ghidra / IDA | Open the binary | Function names, main , suspicious strcpy , gets , system calls | | objdump | objdump -d -M intel hunta-694 | Disassembly for gadgets or vulnerable patterns | | radare2 | r2 -A hunta-694 → aaa | Auto‑analysis, function list ( afl ), cross‑references ( axt ) | | readelf | readelf -a hunta-694 | Section permissions ( .got , .plt ), NX/PIE/ASLR status | | nm | nm -D hunta-694 | Exported symbols (if any) | | checksec | checksec --file=hunta-694 | Stack canaries, RELRO, PIE, NX | 2.3. Dynamic Analysis | Tool | Command | Purpose | |------|---------|---------| | gdb | gdb ./hunta-694 → set breakpoints, run | Observe program flow, locate crash points | | pwndbg / gef | Load as GDB plugin | Helpful visualizations for stack/heap | | ltrace / strace | ltrace ./hunta-694 / strace ./hunta-694 | System calls, library calls | | valgrind | valgrind ./hunta-694 | Detect memory errors | | qemu‑user (if different arch) | qemu-x86_64 ./hunta-694 | Run non‑native binaries |
# Receive and parse leak leaked_puts = u64(io.recvline().strip().ljust(8, b'\x00')) log.success(f'Leaked puts@GLIBC: hex(leaked_puts)') hunta-694
Because the exact nature of the challenge (binary, web, crypto, pwn, rev, etc.) isn’t known from the name alone, the write‑up is organized in a modular way so you can fill in the details that are specific to the actual task. Feel free to copy, edit, and expand each
# ---------------------------------------------------------------------- # Exploit # ---------------------------------------------------------------------- def main(): io = start() | Quick Summary “hunta‑694” is a (type) challenge