Hunta-694 [verified] -

| Category | Typical Indicator | How it manifested in hunta‑694 | |----------|-------------------|-------------------------------| | | gets , strcpy , unchecked read / recv | e.g., gets(buf) in vuln() | | Format string | printf(user_input) | e.g., printf(user_input); | | Use‑after‑free / Double free | free(ptr); … free(ptr); | Observed in heap manipulation | | Integer overflow | malloc(size * elem) without checks | Triggered by large input | | Command injection | system(user_input) | Allows arbitrary shell | | SQL / NoSQL injection | Direct string concatenation in query | SELECT * FROM users WHERE name=' + input | | Crypto weakness | Small RSA modulus, fixed IV, ECB mode | RSA modulus 256‑bit | | Logic flaw | Bypass authentication via magic value | Accepts "admin" after certain condition | | File inclusion | include($_GET['page']) | Remote file inclusion (RFI) | | Web‑specific | Missing CSRF tokens, open redirects | Redirect to http://attacker/... |

context.binary = ELF context.terminal = ['tmux', 'splitw', '-h'] hunta-694

# Receive and parse leak leaked_puts = u64(io.recvline().strip().ljust(8, b'\x00')) log.success(f'Leaked puts@GLIBC: hex(leaked_puts)') | Category | Typical Indicator | How it

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. | Field | Value (to be filled) |

def leak_address(io, payload): io.sendlineafter(b'Input:', payload) io.recvuntil(b'Leaked: ') leak = io.recvline().strip() return u64(leak.ljust(8, b'\x00'))

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 |

$ ./exploit.py | tee flag.txt or within the interactive session: