Void - HackTheBox

Description

64-bit ELF binary with a simple buffer overflow vulnerability. The challenge is that there are no output functions (puts/printf/write) in the binary - only read(). This makes traditional libc leaking impossible.

Binary properties:

• 64-bit ELF
• No PIE (fixed addresses)
• No canary
• Partial RELRO (GOT is writable)
• NX enabled

Analysis

The vulnerable function is trivial:

void vuln() {
  char data[64];
  read(0, data, 200);  // reads 200 bytes into 64-byte buffer
}

Offset calculation:

• Buffer: 64 bytes
• Saved RBP: 8 bytes
• Return address at offset: 72 bytes

The problem: Without output functions, we cannot leak libc addresses for a traditional ret2libc attack.

Failed Approaches

1. ret2csu + partial GOT overwrite to system() - Tried overwriting read@got with system using 3-byte partial overwrite. Theoretically should work but failed after 300+ attempts due to ASLR randomization.

2. ret2csu + one-gadget (0xc9611) - One-gadget constraints weren't satisfied in the execution context.

3. SROP - Too complex for this challenge, requires specific register setup.

Solution: ret2dlresolve

ret2dlresolve is the perfect technique when:

• No libc leak is possible (no output functions)
• Partial RELRO (GOT is writable)
• Have read() to write arbitrary data to memory
• No PIE (fixed addresses for structures)

How ret2dlresolve works

The dynamic linker resolves function addresses lazily. When a function is called for the first time, it goes through PLT -> GOT -> _dl_runtime_resolve(). We can craft fake structures (Elf64_Sym, Elf64_Rela) that tell the linker to resolve system instead of a legitimate function.

Exploit Strategy

1. Use buffer overflow to execute ROP chain
2. ROP chain calls read(0, bss_area) to write our crafted dlresolve structures
3. Trigger ret2dlresolve to resolve system("/bin/sh")

Working Exploit

...