Challenge

tomcr00se rooted the galaxy S5, but we need you to jailbreak the iPhone8!

nc chall.pwnable.tw 10104

We're also given a binary and libc shared executable.

Reversing

When reversing binaries, I usually run the binary and compare its execution alongside the disassemby+pseudocode. When we run the given binary, we're greeted by a menu with 6 options:

Challenge

Can you see anything?

Get a shell for me.

nc chall.pwnable.tw 10200

seethefile

libc.so

Background

_IO_FILE_plus

Files are internally represented using the _IO_FILE_plus struct in glibc:

struct _IO_FILE_plus
{
  _IO_FILE file;
  const struct _IO_jump_t *vtable;
};

Challenge

Make tcache great again !

nc chall.pwnable.tw 10207

tcache_tear

libc.so

Background

Per-thread cache (tcache) is an optimization enabled in versions of libc after 2.26. To increase heap performance, security checks are limited within the tcache implementation. Tcache is implemented using two important internal structures:

Challenge

Please kill the werewolf with silver bullet!

nc chall.pwnable.tw 10103

We are also provided a binary and the libc used on the server.

Solution

When running the binary, we can see that we have four options:

The provided binary was not stripped, so reversing was easy with Ghidra.

void create_bullet(bullet *bullet)
{
  size_t size;
  
  if (bullet->description[0] == '\0') {
    printf("Give me your description of bullet :",0);
    read_input((char *)bullet,0x30);
    size = strlen((char *)bullet);
    printf("Your power is : %u\n",size);
    bullet->power = size;
    puts("Good luck !!");
  }
  else {
    puts("You have been created the Bullet !");
  }
  return;
}

Challenge

A good Hacker should always take good notes!

nc chall.pwnable.tw 10102

We are also provided a binary and the libc used on the server.

Solution

When running the binary, we can see four options:

Understanding the binary

When reversing the binary, we can use the shown options to help identify functions used. I reversed the binary in Ghidra, and the following are the cleaned up decompilation output from the binary.

We are given a linux binary. To start off, lets run checksec on it:

Arch:     i386-32-little
RELRO:    No RELRO
Stack:    No canary found
NX:       NX disabled
PIE:      No PIE (0x8048000)

It looks like NX is disabled, so if needed, we can place and execute shell code from the stack. To understand how this binary works, I opened it with Ghidra. There are only two functions, _entry and _exit. Let's look at _entry first. Although the decompilation is mostly useless, the disassembly is more than enough.

We can see two int 0x80s that are syscalls. Looking at the value of eax and by referencing a 32-bit syscall table, we can identify them. The reversed syscalls are shown in comments in the above screenshot. It's also clear that we control EIP due to the large read syscall that will overflow into the save return address on the stack.

As we saw earlier, the NX bit is disabled, so we can jump to our shellcode. To do so, we need to leak a stack address to identify where to jump to. Using pwndbg, it's easy to watch the stack during execution.

Challenge

Read the flag from /home/orw/flag.

Only open read write syscall are allowed to use.

nc chall.pwnable.tw 10001

Solution

The binary simply reads in 200 bytes and then jumps to its address, after using prctl to prevent calling execve:

int main(void) {
  orw_seccomp();
  printf("Give my your shellcode:");
  read(0,shellcode,200);
  (*(code *)shellcode)();
  return 0;
}

By using strace, we see that orw_seccomp calls prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, {len = 12, filter = 0x400000020}).
Based on this and the challenge description, it is clear that we cannot use a execve shell code like in the previous challenge.

To assemble shellcode, I used an online x86 assembler rather than setting up nasm. We know that the flag is located in /home/orw/flag. Our shellcode needs to accomplish the following: