GITBOOK-4340: No subject

SUMMARY.md

@@ -733,11 +733,15 @@
   * [Unlink Attack](binary-exploitation/heap/unlink-attack.md)
   * [Fast Bin Attack](binary-exploitation/heap/fast-bin-attack.md)
   * [Unsorted Bin Attack](binary-exploitation/heap/unsorted-bin-attack.md)
+  * [Large Bin Attack](binary-exploitation/heap/large-bin-attack.md)
   * [Off by one overflow](binary-exploitation/heap/off-by-one-overflow.md)
   * [House of Spirit](binary-exploitation/heap/house-of-spirit.md)
   * [House of Lore](binary-exploitation/heap/house-of-lore.md)
   * [House of Einherjar](binary-exploitation/heap/house-of-einherjar.md)
   * [House of Force](binary-exploitation/heap/house-of-force.md)
+  * [House of Orange](binary-exploitation/heap/house-of-orange.md)
+  * [House of Rabbit](binary-exploitation/heap/house-of-rabbit.md)
+  * [House of Roman](binary-exploitation/heap/house-of-roman.md)
   * [Heap Overflow](binary-exploitation/heap/heap-overflow.md)
 * [Common Binary Exploitation Protections & Bypasses](binary-exploitation/common-binary-protections-and-bypasses/README.md)
   * [ASLR](binary-exploitation/common-binary-protections-and-bypasses/aslr/README.md)

binary-exploitation/heap/bins-and-memory-allocations.md

@@ -441,7 +441,11 @@ There are:
 * 8bins of 4096B range (part collide with small bins)
 * 4bins of 32768B range
 * 2bins of 262144B range
-* 1bins of for reminding sizes
+* 1bin for reminding sizes
+
+<details>
+
+<summary>Large bin sizes code</summary>
 
 ```c
 // From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
@@ -479,6 +483,8 @@ There are:
    : largebin_index_32 (sz))
 ```
 
+</details>
+
 <details>
 
 <summary>Add a large chunk example</summary>

binary-exploitation/heap/house-of-einherjar.md

@@ -33,18 +33,22 @@ Other ways to support HackTricks:
 ### Attack
 
 * `A` fake chunk is created inside a chunk controlled by the attacker pointing with `fd` and `bk` to the original chunk to bypass protections
-* 2 other chunks (`B` and `C`) are created.
+* 2 other chunks (`B` and `C`) are created
-* Abusing the off by one in the `B` one the `prev in use` bit is cleaned and the `prev_size` data is overwritten with the difference between the place where the `C` chunk is allocated, to the fake `A` chunk generated before.
+* Abusing the off by one in the `B` one the `prev in use` bit is cleaned and the `prev_size` data is overwritten with the difference between the place where the `C` chunk is allocated, to the fake `A` chunk generated before
   * This `prev_size` and the size of the fake chunk `A` must be the same to bypass checks.
-* Then, the Tcache is filled
+* Then, the tcache is filled
 * Then, `C` is freed so it consolidates with the fake chunk `A`
 * Then, a new chunk `D` is created which will be starting in the fake `A` chunk and covering `B` chunk
-* Then, `B` is freed and it's `fd` is overwritten to the target address making it point to the target address abusing the `D` chunk that contains it.
+* Then, `B`'s `fd` is overwritten making it point to the target address abusing the `D` chunk (as it contains `B` inside) and `B` is freed to add the target to the fast bin
-* Then, 2 mallocs are done because the second one if going to be containing the target address
+  * This is the common fast bin attack
+* Then, 2 mallocs are done and the second one id going to be allocating the target address
 
-## References
+## References and other examples
 
 * [https://github.com/shellphish/how2heap/blob/master/glibc\_2.35/house\_of\_einherjar.c](https://github.com/shellphish/how2heap/blob/master/glibc\_2.35/house\_of\_einherjar.c)
+* [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_einherjar/#2016-seccon-tinypad](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_einherjar/#2016-seccon-tinypad)
+  * After freeing pointers their aren't nullified, so it's still possible to access their data. Therefore a chunk is placed in the unsorted bin and leaked the pointers it contains (libc leak) and then a new heap is places on the unsorted bin and leaked a heap address from the pointer it gets.
+  *
 
 <details>
 

binary-exploitation/heap/house-of-force.md

@@ -33,13 +33,42 @@ Other ways to support HackTricks:
 
 ### Attack
 
-If an attacker wants to have a chunk in the address P, having overwritten the size of the top chunk with -1. first of all is needed a malloc of (\&top\_chunk - P). Note that this pointer can be before or after the top\_chunk as any size will be less than -1 (0xFFFFFFFFFFFFFFFF). Then, after allocating this initial chunk, the top chunk will be moved to the desired P address and the next chunk will be from that address.
+If an attacker wants to allocate a chunk in the address P to overwrite a value here, he can start by overwriting the top chunk size with `-1`. This ensures that malloc won't be using mmap for any allocation as the Top chunk will always have enough space.
 
-### References
+Then, calculate the distance between the address of the top chunk and the target space to allocate. This is because a malloc with that size will be performed in order to move the top chunk to that position. This is how the difference/size can be easily calculated:
+
+```c
+// From https://github.com/shellphish/how2heap/blob/master/glibc_2.27/house_of_force.c#L59C2-L67C5
+/*
+ * The evil_size is calulcated as (nb is the number of bytes requested + space for metadata):
+ * new_top = old_top + nb
+ * nb = new_top - old_top
+ * req + 2sizeof(long) = new_top - old_top
+ * req = new_top - old_top - 2sizeof(long)
+ * req = target - 2sizeof(long) - old_top - 2sizeof(long)
+ * req = target - old_top - 4*sizeof(long)
+ */
+```
+
+Therefore, allocing a size of `target - old_top - 4*sizeof(long)` (the 4 longs are because of the metadata of the top chunk and of the new chunk when alloced) will move the top chunk to the address we want to overwrite.\
+Then, do another malloc to get a chunk containing the at the beginning of the data to write the target address.
+
+### References & Other Examples
 
 * [https://github.com/shellphish/how2heap/tree/master](https://github.com/shellphish/how2heap/tree/master?tab=readme-ov-file)
 * [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_force/](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_force/)
 * [https://heap-exploitation.dhavalkapil.com/attacks/house\_of\_force](https://heap-exploitation.dhavalkapil.com/attacks/house\_of\_force)
+* [https://github.com/shellphish/how2heap/blob/master/glibc\_2.27/house\_of\_force.c](https://github.com/shellphish/how2heap/blob/master/glibc\_2.27/house\_of\_force.c)
+* [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_force/#hitcon-training-lab-11](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_force/#hitcon-training-lab-11)
+  * The goal of this scenario is a ret2win where we need to modify the address of a function that is going to be called by the address of the ret2win function
+  * The binary has an overflow that can be abused to modify the top chunk size, which is modified to -1 or p64(0xffffffffffffffff)
+  * Then, it's calculated the address to the place where the pointer to overwrite exists, and the difference from the current position of the top chunk to there is alloced with `malloc`
+  * Finally a new chunk is alloced which will contain this desired target inside which is overwritten by the ret2win function
+* [https://shift--crops-hatenablog-com.translate.goog/entry/2016/03/21/171249?\_x\_tr\_sl=es&\_x\_tr\_tl=en&\_x\_tr\_hl=en&\_x\_tr\_pto=wapp](https://shift--crops-hatenablog-com.translate.goog/entry/2016/03/21/171249?\_x\_tr\_sl=es&\_x\_tr\_tl=en&\_x\_tr\_hl=en&\_x\_tr\_pto=wapp)
+  * In the `Input your name:` there is an initial vulnerability that allows to leak an address from the heap
+  * Then in the `Org:` and `Host:` functionality its possible to fill the 64B of the `s` pointer when asked for the **org name**, which in the stack is followed by the address of v2, which is then followed by the indicated **host name**. As then, strcpy is going to be copying the contents of s to a chunk of size 64B, it's possible to **overwrite the size of the top chunk** with the data put inside the **host name**.
+  * Now that arbitrary write it possible, the `atoi`'s GOT was overwritten to the address of printf. the it as possible to leak the address of `IO_2_1_stderr` _with_ `%24$p`. And with this libc leak it was possible to overwrite `atoi`'s GOT again with the address to `system` and call it passing as param `/bin/sh`
+    * An alternative method [proposed in this other writeup](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_force/#2016-bctf-bcloud), is to overwrite `free` with `puts`, and then add the address of `atoi@got`,  in the pointer that will be later freed so it's leaked and with this leak overwrite again `atoi@got` with `system` and call it with `/bin/sh`.
 
 <details>
 

binary-exploitation/heap/house-of-lore.md

@@ -18,9 +18,11 @@ Other ways to support HackTricks:
 
 ### Code
 
-* This isn't working
 * Check the one from [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_lore/](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_lore/)
+  * This isn't working
 * Or: [https://github.com/shellphish/how2heap/blob/master/glibc\_2.39/house\_of\_lore.c](https://github.com/shellphish/how2heap/blob/master/glibc\_2.39/house\_of\_lore.c)
+  * This isn't working even if tries to bypass the checks getting the error: `malloc(): unaligned tcache chunk detected` which might mean that the fake free list should be aligned
+  * This could be bypassed aligning properly that list of fixing the second fake chunk to point to the arena (need a leak). However, it looks like this attack have too many requisites and few benefits.
 
 ### Goal
 
@@ -36,10 +38,12 @@ Other ways to support HackTricks:
 
 * A victim small chunk is allocated
 * An attacker generates a couple of fake small chunks, and makes the first fake chunk `fd` point to a real chunk and the `bk` point to the second fake chunk. Also make the second fake chunk `bk` point the first one.
-* Then, a new large chunk is allocated to prevent the first one to being merge in the top chunk when freed
+  * The `bk` of the second should also point to the fake freelist to prevent a crash when small bin chunks are tried to be allocated in the tcache.
+* Then, a new large chunk is allocated to prevent the first one to being consolidate in the top chunk when freed
 * Then, the initial pointer is freed and a second pointer of a bigger size is allocated so the freed initial small chunk is placed in the small bin.
-* The real small chunk is modified so it’s `bk` pointer points to the fake one and.
+* Vulnerability: The real small chunk freed is modified so it’s `bk` pointer points to the first fake chunk.
 * Then, when 2 chunks of this size are allocated they get the valid chunk first and then the invalid chunk somehow controlled by the attacker.
+  * In the how2heap example the fake chunks are inside the stack so we would be getting a chunk from the stack, where it might be possible to write a ROP or something.
 
 ## References
 

binary-exploitation/heap/house-of-orange.md

@@ -0,0 +1,90 @@
+# House of Orange
+
+<details>
+
+<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
+
+Other ways to support HackTricks:
+
+* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
+* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
+* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
+* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
+
+</details>
+
+## Basic Information
+
+### Code
+
+* Find an example in [https://github.com/shellphish/how2heap/blob/master/glibc\_2.23/house\_of\_orange.c](https://github.com/shellphish/how2heap/blob/master/glibc\_2.23/house\_of\_orange.c)
+  * The exploitation technique was fixed in this [patch](https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=stdlib/abort.c;h=117a507ff88d862445551f2c07abb6e45a716b75;hp=19882f3e3dc1ab830431506329c94dcf1d7cc252;hb=91e7cf982d0104f0e71770f5ae8e3faf352dea9f;hpb=0c25125780083cbba22ed627756548efe282d1a0) so this is no longer working
+
+### Goal
+
+* Abuse `malloc_printerr` function
+
+### Requirements
+
+* Overwrite the top chunk size
+* Libc and heap leaks
+
+### Attack
+
+The attack starts by managing to get the **top chunk** inside the **unsorted bin**. This is achieved by calling `malloc` with a size greater than the current top chunk size but smaller than **`mmp_.mmap_threshold`** (default is 128K), which would otherwise trigger `mmap` allocation. Whenever the top chunk size is modified, it's important to ensure that the **top chunk + its size** is page-aligned and that the **prev\_inuse** bit of the top chunk is always set.
+
+To get the top chunk inside the unsorted bin, allocate a chunk to create the top chunk, change the top chunk size so that **top chunk + size** is page-aligned with the **prev\_inuse** bit set. Then allocate a chunk larger than the new top chunk size. Note that `free` is never called to get the top chunk into the unsorted bin.
+
+The old top chunk is now in the unsorted bin. Assuming we can read data inside it (possibly due to a vulnerability that also caused the overflow), it’s possible to leak libc addresses from it and get the address of **\_IO\_list\_all**.
+
+An unsorted bin attack is performed by abusing the overflow to write `topChunk->bk->fwd = _IO_list_all - 0x10`. When a new chunk is allocated, the old top chunk will be split, and a pointer to the unsorted bin will be written into **\_IO\_list\_all**.
+
+The next step involves shrinking the size of the old top chunk to fit into a small bin, specifically setting its size to **0x61**. This serves two purposes:
+
+1. **Insertion into Small Bin 4**: When `malloc` scans through the unsorted bin and sees this chunk, it will try to insert it into small bin 4 due to its small size. This makes the chunk end up at the head of the small bin 4 list, facilitating the manipulation of the forward and backward pointers.
+2. **Triggering a Malloc Check**: This chunk size manipulation will cause `malloc` to perform internal checks. When it checks the size of the false forward chunk, which will be zero, it triggers an error and calls `malloc_printerr`.
+
+The manipulation of the small bin will allow you to control the forward pointer of the chunk. The overlap with **\_IO\_list\_all** is used to forge a fake **\_IO\_FILE** structure. The structure is carefully crafted to include key fields like `_IO_write_base` and `_IO_write_ptr` set to values that pass internal checks in libc. Additionally, a jump table is created within the fake structure, where an instruction pointer is set to the address where arbitrary code (e.g., the `system` function) can be executed.
+
+To summarize the remaining part of the technique:
+
+* **Shrink the Old Top Chunk**: Adjust the size of the old top chunk to **0x61** to fit it into a small bin.
+* **Set Up the Fake \_IO\_FILE Structure**: Overlap the old top chunk with the fake **\_IO\_FILE** structure and set fields appropriately to hijack execution flow.
+
+The next step involves forging a fake **\_IO\_FILE** structure that overlaps with the old top chunk currently in the unsorted bin. The first bytes of this structure are crafted carefully to include a pointer to a command (e.g., "/bin/sh") that will be executed.
+
+Key fields in the fake **\_IO\_FILE** structure, such as `_IO_write_base` and `_IO_write_ptr`, are set to values that pass internal checks in libc. Additionally, a jump table is created within the fake structure, where an instruction pointer is set to the address where arbitrary code can be executed. Typically, this would be the address of the `system` function or another function that can execute shell commands.
+
+The attack culminates when a call to `malloc` triggers the execution of the code through the manipulated **\_IO\_FILE** structure. This effectively allows arbitrary code execution, typically resulting in a shell being spawned or another malicious payload being executed.
+
+**Summary of the Attack:**
+
+1. **Set up the top chunk**: Allocate a chunk and modify the top chunk size.
+2. **Force the top chunk into the unsorted bin**: Allocate a larger chunk.
+3. **Leak libc addresses**: Use the vulnerability to read from the unsorted bin.
+4. **Perform the unsorted bin attack**: Write to **\_IO\_list\_all** using an overflow.
+5. **Shrink the old top chunk**: Adjust its size to fit into a small bin.
+6. **Set up a fake \_IO\_FILE structure**: Forge a fake file structure to hijack control flow.
+7. **Trigger code execution**: Allocate a chunk to execute the attack and run arbitrary code.
+
+This approach exploits heap management mechanisms, libc information leaks, and heap overflows to achieve code execution without directly calling `free`. By carefully crafting the fake **\_IO\_FILE** structure and placing it in the right location, the attack can hijack the control flow during standard memory allocation operations. This enables the execution of arbitrary code, potentially resulting in a shell or other malicious activities.
+
+## References
+
+* [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_orange/](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_orange/)
+* [https://guyinatuxedo.github.io/43-house\_of\_orange/house\_orange\_exp/index.html](https://guyinatuxedo.github.io/43-house\_of\_orange/house\_orange\_exp/index.html)
+
+<details>
+
+<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
+
+Other ways to support HackTricks:
+
+* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
+* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
+* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
+* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
+
+</details>

binary-exploitation/heap/house-of-rabbit.md

@@ -0,0 +1,135 @@
+# House of Rabbit
+
+<details>
+
+<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
+
+Other ways to support HackTricks:
+
+* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
+* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
+* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
+* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
+
+</details>
+
+### Requirements
+
+1. **Ability to Modify Fastbin fd Pointer or Size**: This means you can change the forward pointer of a chunk in the fastbin or its size.
+2. **Ability to Trigger `malloc_consolidate`**: This can be done by either allocating a large chunk or merging the top chunk, which forces the heap to consolidate chunks.
+
+### Goals
+
+1. **Create Overlapping Chunks**: To have one chunk overlap with another, allowing for further heap manipulations.
+2. **Forge Fake Chunks**: To trick the allocator into treating a fake chunk as a legitimate chunk during heap operations.
+
+## Steps of the Attack
+
+### POC 1: Modify the Size of a Fastbin Chunk
+
+**Objective**: Create an overlapping chunk by manipulating the size of a fastbin chunk.
+
+* **Step 1: Allocate Chunks**
+
+```cpp
+unsigned long* chunk1 = malloc(0x40);  // Allocates a chunk of 0x40 bytes at 0x602000
+unsigned long* chunk2 = malloc(0x40);  // Allocates another chunk of 0x40 bytes at 0x602050
+malloc(0x10);                          // Allocates a small chunk to change the fastbin state
+```
+
+We allocate two chunks of 0x40 bytes each. These chunks will be placed in the fastbin list once freed.
+
+* **Step 2: Free Chunks**
+
+```cpp
+free(chunk1);  // Frees the chunk at 0x602000
+free(chunk2);  // Frees the chunk at 0x602050
+```
+
+We free both chunks, adding them to the fastbin list.
+
+* **Step 3: Modify Chunk Size**
+
+```cpp
+chunk1[-1] = 0xa1;  // Modify the size of chunk1 to 0xa1 (stored just before the chunk at chunk1[-1])
+```
+
+We change the size metadata of `chunk1` to 0xa1. This is a crucial step to trick the allocator during consolidation.
+
+* **Step 4: Trigger `malloc_consolidate`**
+
+```cpp
+malloc(0x1000);  // Allocate a large chunk to trigger heap consolidation
+```
+
+Allocating a large chunk triggers the `malloc_consolidate` function, merging small chunks in the fastbin. The manipulated size of `chunk1` causes it to overlap with `chunk2`.
+
+After consolidation, `chunk1` overlaps with `chunk2`, allowing for further exploitation.
+
+### POC 2: Modify the FD Pointer
+
+**Objective**: Create a fake chunk by manipulating the fastbin fd pointer.
+
+* **Step 1: Allocate Chunks**
+
+```cpp
+unsigned long* chunk1 = malloc(0x40);  // Allocates a chunk of 0x40 bytes at 0x602000
+unsigned long* chunk2 = malloc(0x100); // Allocates a chunk of 0x100 bytes at 0x602050
+```
+
+**Explanation**: We allocate two chunks, one smaller and one larger, to set up the heap for the fake chunk.
+
+* **Step 2: Create Fake Chunk**
+
+```cpp
+chunk2[1] = 0x31;  // Fake chunk size 0x30
+chunk2[7] = 0x21;  // Next fake chunk
+chunk2[11] = 0x21; // Next-next fake chunk
+```
+
+We write fake chunk metadata into `chunk2` to simulate smaller chunks.
+
+* **Step 3: Free Chunk1**
+
+```cpp
+free(chunk1);  // Frees the chunk at 0x602000
+```
+
+**Explanation**: We free `chunk1`, adding it to the fastbin list.
+
+* **Step 4: Modify FD of Chunk1**
+
+```cpp
+chunk1[0] = 0x602060;  // Modify the fd of chunk1 to point to the fake chunk within chunk2
+```
+
+**Explanation**: We change the forward pointer (fd) of `chunk1` to point to our fake chunk inside `chunk2`.
+
+* **Step 5: Trigger `malloc_consolidate`**
+
+```cpp
+malloc(5000);  // Allocate a large chunk to trigger heap consolidation
+```
+
+Allocating a large chunk again triggers `malloc_consolidate`, which processes the fake chunk.
+
+The fake chunk becomes part of the fastbin list, making it a legitimate chunk for further exploitation.
+
+### Summary
+
+The **House of Rabbit** technique involves either modifying the size of a fastbin chunk to create overlapping chunks or manipulating the fd pointer to create fake chunks. This allows attackers to forge legitimate chunks in the heap, enabling various forms of exploitation. Understanding and practicing these steps will enhance your heap exploitation skills.
+
+<details>
+
+<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
+
+Other ways to support HackTricks:
+
+* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
+* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
+* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
+* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
+
+</details>

binary-exploitation/heap/house-of-roman.md

@@ -0,0 +1,143 @@
+# House of Roman
+
+<details>
+
+<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
+
+Other ways to support HackTricks:
+
+* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
+* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
+* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
+* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
+
+</details>
+
+## Basic Information
+
+This was a very interesting technique that allowed for RCE without leaks via fake fastbins, the unsorted\_bin attack and relative overwrites. However it has ben [**patched**](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b90ddd08f6dd688e651df9ee89ca3a69ff88cd0c).
+
+### Code
+
+* You can find an example in [https://github.com/shellphish/how2heap/blob/master/glibc\_2.23/house\_of\_roman.c](https://github.com/shellphish/how2heap/blob/master/glibc\_2.23/house\_of\_roman.c)
+
+### Goal
+
+* RCE by abusing relative pointers
+
+### Requirements
+
+* Edit fastbin and unsorted bin pointers
+* 12 bits of randomness must be brute forced (0.02% chance) of working
+
+## Attack Steps
+
+### Part 1: Fastbin Chunk points to \_\_malloc\_hook
+
+Create several chunks:
+
+* `fastbin_victim` (0x60, offset 0): UAF chunk later to edit the heap pointer later to point to the LibC value.
+* `chunk2` (0x80, offset 0x70): For good alignment
+* `main_arena_use` (0x80, offset 0x100)
+* `relative_offset_heap` (0x60, offset 0x190): relative offset on the 'main\_arena\_use' chunk
+
+Then `free(main_arena_use)` which will place this chunk in the unsorted list and will get a pointer to `main_arena + 0x68` in both the `fd` and `bk` pointers.
+
+Now it's allocated a new chunk `fake_libc_chunk(0x60)` because it'll contain the pointers to `main_arena + 0x68` in `fd` and `bk`.
+
+Then `relative_offset_heap`  and `fastbin_victim` are freed.
+
+```c
+/*
+Current heap layout: 
+	0x0:   fastbin_victim       - size 0x70 
+	0x70:  alignment_filler     - size 0x90
+	0x100: fake_libc_chunk      - size 0x70 (contains a fd ptr to main_arena + 0x68)
+	0x170: leftover_main        - size 0x20
+	0x190: relative_offset_heap - size 0x70 
+
+	bin layout: 
+			fastbin:  fastbin_victim -> relative_offset_heap
+			unsorted: leftover_main
+*/
+```
+
+* &#x20;`fastbin_victim` has a `fd` pointing to `relative_offset_heap`
+* &#x20;`relative_offset_heap` is an offset of distance from `fake_libc_chunk`, which contains a pointer to `main_arena + 0x68`
+* Just changing the last byte of `fastbin_victim.fd` it's possible to make `fastbin_victim points` to `main_arena + 0x68`
+
+For the previous actions, the attacker needs to be capable of modifying the fd pointer of `fastbin_victim`.
+
+Then, `main_arena + 0x68` is not that interesting, so lets modify it so the pointer points to **`__malloc_hook`**.
+
+Note that `__memalign_hook` usually starts with `0x7f` and zeros before it, then it's possible to fake it as a value in the `0x70` fast bin. Because the last 4 bits of the address are **random** there are `2^4=16` possibilities for the value to end pointing where are interested. So a BF attack is performed here so the chunk ends like: **`0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23)`.**
+
+(For more info about the rest of the bytes check the explanation in the [how2heap](https://github.com/shellphish/how2heap/blob/master/glibc\_2.23/house\_of\_roman.c)[ example](https://github.com/shellphish/how2heap/blob/master/glibc\_2.23/house\_of\_roman.c)). If the BF don't work the program just crashes (so start gain until it works).
+
+Then, 2 mallocs are performed to remove the 2 initial fast bin chunks and the a third one is alloced to get a chunk in the **`__malloc_hook:`**
+
+```c
+malloc(0x60);
+malloc(0x60);
+uint8_t* malloc_hook_chunk = malloc(0x60);
+```
+
+### Part 2: Unsorted\_bin attack
+
+For more info you can check:
+
+{% content-ref url="unsorted-bin-attack.md" %}
+[unsorted-bin-attack.md](unsorted-bin-attack.md)
+{% endcontent-ref %}
+
+But basically it allows to write `main_arena + 0x68` to any location by specified in `chunk->bk`. And for the attack we choose `__malloc_hook`. Then, after overwriting it we will use a relative overwrite) to point to a `one_gadget`.
+
+For this we start getting a chunk and putting it into the **unsorted bin**:
+
+```c
+uint8_t* unsorted_bin_ptr = malloc(0x80);	
+malloc(0x30); // Don't want to consolidate
+
+puts("Put chunk into unsorted_bin\n");
+// Free the chunk to create the UAF
+free(unsorted_bin_ptr);
+```
+
+Use an UAF in this chunk to point `unsorted_bin_ptr->bk` to the address of `__malloc_hook` (we brute forced this previously).
+
+{% hint style="danger" %}
+Note that this attack corrupts the unsorted bin (hence small and large too). So we can only **use allocations from the fast bin now** (a more complex program might do other allocations and crash), and to trigger this we must **alloc the same size or the program will crash.**
+{% endhint %}
+
+So, to trigger the write of `main_arena + 0x68` in `__malloc_hook` we perform after setting `__malloc_hook` in `unsorted_bin_ptr->bk` we just need to do: **`malloc(0x80)`**
+
+### Step 3: Set \_\_malloc\_hook to system
+
+In the step one we ended controlling a chunk containing `__malloc_hook` (in the variable `malloc_hook_chunk`) and in the second step we managed to write `main_arena + 0x68` in here.
+
+Now, we abuse a partial overwrite in `malloc_hook_chunk` to use the libc address we wrote there(`main_arena + 0x68`) to **point a `one_gadget` address**.
+
+Here is where it's needed to **bruteforce 12 bits of randomness** (more info in the [how2heap](https://github.com/shellphish/how2heap/blob/master/glibc\_2.23/house\_of\_roman.c)[ example](https://github.com/shellphish/how2heap/blob/master/glibc\_2.23/house\_of\_roman.c)).
+
+Finally, one the correct address is overwritten, **call `malloc` and trigger the `one_gadget`**.
+
+## References
+
+* [https://github.com/shellphish/how2heap](https://github.com/shellphish/how2heap)
+* [https://github.com/shellphish/how2heap/blob/master/glibc\_2.23/house\_of\_roman.c](https://github.com/shellphish/how2heap/blob/master/glibc\_2.23/house\_of\_roman.c)
+* [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_roman/](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_roman/)
+
+<details>
+
+<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
+
+Other ways to support HackTricks:
+
+* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
+* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
+* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
+* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
+
+</details>

binary-exploitation/heap/large-bin-attack.md

@@ -0,0 +1,63 @@
+# Large Bin Attack
+
+<details>
+
+<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
+
+Other ways to support HackTricks:
+
+* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
+* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
+* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
+* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
+
+</details>
+
+## Basic Information
+
+It's possible to find a great example in [**how2heap - large bin attack**](https://github.com/shellphish/how2heap/blob/master/glibc\_2.35/large\_bin\_attack.c).
+
+Basically here you can see how, in the latest "current" version of glibc (2.35), it's not checked: `P->bk_nextsize` allowing to modify an arbitrary address with the value of a large bin chunk if certain conditions are met.
+
+In that example you can find the following conditions:
+
+* A large chunk is allocated
+* A large chunk smaller than the first one but in the same index is allocated
+* (A chunk to prevent merging with the top chunk is created)
+* Then, the first large chunk is freed and a new chunk bigger than it is allocated -> Chunk1 goes to the large bin
+* Then, the second large chunk is freed
+* Now, the vulnerability: The attacker can modify `chunk1->bk_nextsize` to `[target-0x20]`
+* Then, a larger chunk than chunk 2 is allocated, so chunk2 is inserted in the large bin overwriting the address `chunk1->bk_nextsize->fd_nextsize` with the address of  chunk2
+
+This is the code (and the reason why chunk2 must be smaller than chunk1). Comments have been added to understand betetr how the address was overwritten:
+
+```c
+/* if smaller than smallest, bypass loop below */
+assert (chunk_main_arena (bck->bk));
+if ((unsigned long) (size) < (unsigned long) chunksize_nomask (bck->bk))
+  {
+    fwd = bck; // fwd = p1
+    bck = bck->bk; // bck = p1->bk 
+
+    victim->fd_nextsize = fwd->fd; // p2->fd_nextsize = p1->fd (Note that p1->fd is p1 as it's the only chunk)
+    victim->bk_nextsize = fwd->fd->bk_nextsize; // p2->bk_nextsize = p1->fd->bk_nextsize
+    fwd->fd->bk_nextsize = victim->bk_nextsize->fd_nextsize = victim; // p1->fd->bk_nextsize->fd_nextsize = p2
+  }
+```
+
+This could be used to **overwrite the `global_max_fast` global variable** of libc to then exploit a fast bin attack with larger chunks.
+
+<details>
+
+<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
+
+Other ways to support HackTricks:
+
+* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
+* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
+* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
+* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
+
+</details>

binary-exploitation/heap/unsorted-bin-attack.md

@@ -24,6 +24,10 @@ Taking a look to the example provided in [https://ctf-wiki.mahaloz.re/pwn/linux/
 Therefore, this unsorted bin attack now (among other checks) also requires to be able to fix the doubled linked list so this is bypassed `victim->bck->fd == victim` or not `victim->fd == av (arena)`. Which means that the address were we want to right must have the address of the fake chunk in its `fd` position and that the fake chunk `fd` is pointing to the arena.
 {% endhint %}
 
+{% hint style="danger" %}
+Note that this attack corrupts the unsorted bin (hence small and large too). So we can only **use allocations from the fast bin now** (a more complex program might do other allocations and crash), and to trigger this we must **alloc the same size or the program will crash.**
+{% endhint %}
+
 ## References & Other examples
 
 * [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#hitcon-training-lab14-magic-heap)