Dream Diary: Chapter 1

Overview

Dream Diary: Chapter 1 (known as DD1) was an insane pwn challenge. It is one of the few heap challenges on HackTheBox and, while it took a great deal of time to understand, was probably one of the most satisfying challenges I've done.

There were two (main) ways to solve this challenge: utilising an unlink exploit and overlapping chunks then performing a fastbin attack. I'll detail both of these, but first we'll identify the bug and what it allows us to do.

Analysis

Let's have a look at what we can do.

ironstone@ubuntu:~/Desktop/hackthebox/chapter1$ ./chapter1 

+------------------------------+
|         Dream Diary          |
+------------------------------+
| [1] Allocate                 |
| [2] Edit                     |
| [3] Delete                   |
| [4] Exit                     |
+------------------------------+
>> 1

Size: 20
Data: ye
Success!
[...]

So at first look we can create, edit and delete chunks. Fairly standard heap challenge.

Decompilation

Now we'll check out the binary in more detail.

Many of the functions are bloated. If there is a chunk of irrelevant code, I'll just replace it with a comment that explains what it does (or in the case of canaries just remove altogether). I'll also remove convoluted multi-step code, so the types may be off, but it's much more readable.

Allocate

Very simplified, but it takes in a size and then calls malloc() to assign a chunk of that size and reads that much data into the chunk.

Edit

Again, quite simplified. Calls strlen() on the data there, reads that many bytes in.

Delete

Finding the bug

The delete() function is secure, so it's clearly not an issue with the way the chunk is freed. Now we can check the functions that write data, allocate() and edit().

allocate() only ever inputs how much it allocates, so it's secure. The bug is in edit():

Remember that strlen() stops at a null byte. If we completely fill up our buffer the first time we allocate, there are no null bytes there. Instead, we will continue into the size field of the next chunk.

Chunk 1's data is right up against Chunk 2's size field

Provided the size field is greater than 0x0 - which is will be - strlen() will interpret it as part of the string. That only gives us an overflow of one or two bytes.

But what can we do with that? The last 3 bits of the size field are taken up by the flags, the important one for this being the prev_in_use bit. If it is not set (i.e. 0) then we can use PREV_SIZE to calculate the size of the previous chunk. If we overwrite P to be 0, we can fake PREV_SIZE as it's originally part of the previous chunk's data.

How we can utilise this will be detailed in the subpages.

Scripting

Some helper functions to automate the actions.

Last updated

Was this helpful?