heap 0 - PicoGym

 This challenge, while technically a heap exploit is relatively easy. It is a simple buffer overflow in which the buffer that is supposedly "safe" is located directly after a user controlled buffer in the heap. Just like with a stack overflow, we can write past the bounds of our buffer and overwrite the "safe" buffer.

The files and other items for this challenge can be found at the PicoGym under the challenge named "heap 0". I started as I always do by running "checksec" on the binary (pwntools required).

 

Fortunately, the debugging info is left in which is convenient, but we have access to the source code anyway so its not super helpful. Unfortunately, the stack is not executable, and addresses are randomized, since we know from the name and description that this is a heap overflow challenge though that is not really too surprising.

While I can't really capture it in blog form, my next step was to read through and understand every line of the source code. I tend to skimp on this a lot of the time and it always results in the challenge taking longer than it would have if I would have just read the thing. After reading the source code, I ran a few "test laps" to both test my understanding and to see how everything works in practice. The big takeaway is that malloc is used twice, both times with a size of '5' to store the protected variable and the user input variable.

Next I created my first version of the exploit, which was set up to help me explore the heap and be sure everything was where I expected it to be.

 I let the exploit run, and within GDB explored around the heap. I could see from the executable output, that the malloc calls had returned addresses ending in '16b0' and '16d0'. In gdb, I used the examine command to view the data in place on the heap.

  

 Note that this printout was from before I sent the AAAA string to the binary.

In the red boxes above we can see both addresses and the strings they contain. There is the 0x21 between the payloads. This is metadata and flags which help to describe the memory allocation in the linked list that makes up the heap. For this challenge, we can overwrite it without issue.

Since we now know how our exploit should work, instead of sending four 'A' characters, we will send enough (33) to overflow the malloc chunk and overwrite the first character of the "safe" variable. That can be seen in the exploit below.

When executed, this successfully overwrites the file and gives my my local dummy flag. To get the real one, just use a remote connection in pwn tools and send the exploit to the server hosting the code.