A typical CTF heap setup

This sort of framework makes a sort of minimum viable menu to let the user make memory in wacky ways:

This sort of state-machine menu is classic CTF exploit stuff, and is actually surprisingly easy to inspect/debug/work with.

Run this with pwndbg and use run then just use the menu a while and hit cntl+c to bust out into console and type bins

Linked lists

OK let's look at what happens as I make and free several chunks.

Recall that the heap is ALL ABOUT dynamic memory, recycling, and defragmentation all while trying to be fast.

• When you make NEW chunks they get made top to bottom
• You can FREE chunks in any order
• If someone wants a chunk of the same size as an old chunk you should REUSE it
• How can we keep track of where those chunks are? A simple singly-linked list.

Run that program and make 4 chunks of size 24, then free the first 3, now inspect the bins. What order are they in?

Continue that run and ask for 3 new chunks of size 24, but inspect the bins after each one.

Here is what you'll see:

Which is really the following "stack" implemented as a singly linked list:

So if we understand correctly we should see things come out in reverse order.

Use-After-Free

Our first heap vulnerability

OK, this program does NOT clear it's pointers after giving them to you.

So... that means that you can continue to work with a pointer after it has been free'd.

NEVER LET SOMEONE USE A POINTER AFTER IT HAS BEEN FREE-ED.

Generate a leak of a (well... an almost) heap address.

TODAY's PCP: Generate a leak of a (well... an almost) glibc address.