+
+int main() {
+ // Allocate memory for three chunks
+ char *a = (char *)malloc(10);
+ char *b = (char *)malloc(10);
+ char *c = (char *)malloc(10);
+ char *d = (char *)malloc(10);
+ char *e = (char *)malloc(10);
+ char *f = (char *)malloc(10);
+ char *g = (char *)malloc(10);
+ char *h = (char *)malloc(10);
+ char *i = (char *)malloc(10);
+
+ // Print initial memory addresses
+ printf("Initial allocations:\n");
+ printf("a: %p\n", (void *)a);
+ printf("b: %p\n", (void *)b);
+ printf("c: %p\n", (void *)c);
+ printf("d: %p\n", (void *)d);
+ printf("e: %p\n", (void *)e);
+ printf("f: %p\n", (void *)f);
+ printf("g: %p\n", (void *)g);
+ printf("h: %p\n", (void *)h);
+ printf("i: %p\n", (void *)i);
+
+ // Fill tcache
+ free(a);
+ free(b);
+ free(c);
+ free(d);
+ free(e);
+ free(f);
+ free(g);
+
+ // Introduce double-free vulnerability in fast bin
+ free(h);
+ free(i);
+ free(h);
+
+
+ // Reallocate memory and print the addresses
+ char *a1 = (char *)malloc(10);
+ char *b1 = (char *)malloc(10);
+ char *c1 = (char *)malloc(10);
+ char *d1 = (char *)malloc(10);
+ char *e1 = (char *)malloc(10);
+ char *f1 = (char *)malloc(10);
+ char *g1 = (char *)malloc(10);
+ char *h1 = (char *)malloc(10);
+ char *i1 = (char *)malloc(10);
+ char *i2 = (char *)malloc(10);
+
+ // Print initial memory addresses
+ printf("After reallocations:\n");
+ printf("a1: %p\n", (void *)a1);
+ printf("b1: %p\n", (void *)b1);
+ printf("c1: %p\n", (void *)c1);
+ printf("d1: %p\n", (void *)d1);
+ printf("e1: %p\n", (void *)e1);
+ printf("f1: %p\n", (void *)f1);
+ printf("g1: %p\n", (void *)g1);
+ printf("h1: %p\n", (void *)h1);
+ printf("i1: %p\n", (void *)i1);
+ printf("i2: %p\n", (void *)i1);
+
+ return 0;
+}
+```
+
+In this example, after filling the tcache with several freed chunks, the code **frees chunk `h`, then chunk `i`, and then `h` again, causing a double-free error**. This opens the possibility of receiving overlapping memory addresses when reallocating, meaning two or more pointers can point to the same memory location. Manipulating data through one pointer can then affect the other, creating a critical security risk and potential for exploitation.
+
+Executing it, note how **`i1` and `i2` got the same address**:
+
+Initial allocations:
+a: 0xaaab0f0c22a0
+b: 0xaaab0f0c22c0
+c: 0xaaab0f0c22e0
+d: 0xaaab0f0c2300
+e: 0xaaab0f0c2320
+f: 0xaaab0f0c2340
+g: 0xaaab0f0c2360
+h: 0xaaab0f0c2380
+i: 0xaaab0f0c23a0
+After reallocations:
+a1: 0xaaab0f0c2360
+b1: 0xaaab0f0c2340
+c1: 0xaaab0f0c2320
+d1: 0xaaab0f0c2300
+e1: 0xaaab0f0c22e0
+f1: 0xaaab0f0c22c0
+g1: 0xaaab0f0c22a0
+h1: 0xaaab0f0c2380
+i1: 0xaaab0f0c23a0
+i2: 0xaaab0f0c23a0
+
+
+## References
+
+* [https://heap-exploitation.dhavalkapil.com/attacks/double\_free](https://heap-exploitation.dhavalkapil.com/attacks/double\_free)
+
+
+
+Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
+
+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.
+
+
diff --git a/binary-exploitation/heap/heap-functions-security-checks.md b/binary-exploitation/heap/heap-functions-security-checks.md
new file mode 100644
index 000000000..6ab156497
--- /dev/null
+++ b/binary-exploitation/heap/heap-functions-security-checks.md
@@ -0,0 +1,92 @@
+# Heap Functions Security Checks
+
+
+
+Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
+
+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.
+
+
+
+## unlink
+
+This function removes a chunk from a doubly linked list. Common checks ensure that the linked list structure remains consistent when unlinking chunks.
+
+* **Consistency Checks**:
+ * Check if `P->fd->bk == P` and `P->bk->fd == P`.
+ * Error message: `corrupted double-linked list`
+
+## \_int\_malloc
+
+This function is responsible for allocating memory from the heap. Checks here ensure memory is not corrupted during allocation.
+
+* **Fastbin Size Check**:
+ * When removing a chunk from a fastbin, ensure the chunk's size is within the fastbin range.
+ * Error message: `malloc(): memory corruption (fast)`
+* **Smallbin Consistency Check**:
+ * When removing a chunk from a smallbin, ensure the previous and next links in the doubly linked list are consistent.
+ * Error message: `malloc(): smallbin double linked list corrupted`
+* **Unsorted Bin Memory Range Check**:
+ * Ensure the size of chunks in the unsorted bin is within minimum and maximum limits.
+ * Error message: `malloc(): memory corruption`
+* **Unsorted Bin Consistency Check (First Scenario)**:
+ * When inserting a remainder chunk into the unsorted bin, check if `unsorted_chunks(av)->fd->bk == unsorted_chunks(av)`.
+ * Error message: `malloc(): corrupted unsorted chunks`
+* **Unsorted Bin Consistency Check (Second Scenario)**:
+ * Same as the previous check, but triggered when inserting after splitting a fast or small chunk.
+ * Error message: `malloc(): corrupted unsorted chunks 2`
+
+## \_int\_free
+
+This function frees previously allocated memory. The checks here help ensure proper memory deallocation and prevent memory corruption.
+
+* **Pointer Boundary Check**:
+ * Ensure the pointer being freed isn't wrapping around the memory.
+ * Error message: `free(): invalid pointer`
+* **Size Check**:
+ * Ensure the size of the chunk being freed is at least `MINSIZE` or a multiple of `MALLOC_ALIGNMENT`.
+ * Error message: `free(): invalid size`
+* **Fastbin Size Check**:
+ * For fastbin chunks, ensure the next chunk's size is within the minimum and maximum limits.
+ * Error message: `free(): invalid next size (fast)`
+* **Fastbin Double Free Check**:
+ * When inserting a chunk into a fastbin, ensure the chunk at the head isn't the same as the one being inserted.
+ * Error message: `double free or corruption (fasttop)`
+* **Fastbin Consistency Check**:
+ * When inserting into a fastbin, ensure the sizes of the head chunk and the chunk being inserted are the same.
+ * Error message: `invalid fastbin entry (free)`
+* **Top Chunk Consistency Check**:
+ * For non-fastbin chunks, ensure the chunk isn't the same as the top chunk.
+ * Error message: `double free or corruption (top)`
+* **Memory Boundaries Check**:
+ * Ensure the next chunk by memory is within the boundaries of the arena.
+ * Error message: `double free or corruption (out)`
+* **Prev\_inuse Bit Check**:
+ * Ensure the previous-in-use bit in the next chunk is marked.
+ * Error message: `double free or corruption (!prev)`
+* **Normal Size Check**:
+ * Ensure the size of the next chunk is within valid ranges.
+ * Error message: `free(): invalid next size (normal)`
+* **Unsorted Bin Consistency Check**:
+ * When inserting a coalesced chunk into the unsorted bin, check if `unsorted_chunks(av)->fd->bk == unsorted_chunks(av)`.
+ * Error message: `free(): corrupted unsorted chunks`
+
+
+
+Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
+
+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.
+
+
diff --git a/binary-exploitation/heap/heap-overflow.md b/binary-exploitation/heap/heap-overflow.md
index 453b5d5a7..c3bb718f1 100644
--- a/binary-exploitation/heap/heap-overflow.md
+++ b/binary-exploitation/heap/heap-overflow.md
@@ -24,6 +24,20 @@ In stack overflows we know that some registers like the instruction pointer or t
In order to find overflow offsets you can use the same patters as in [**stack overflows**](../stack-overflow/#finding-stack-overflows-offsets).
{% endhint %}
+### Stack Overflows vs Heap Overflows
+
+In stack overflows the arranging and data that is going to be present in the stack at the moment the vulnerability can be triggered is fairly reliable. This is because the stack is linear, always increasing in colliding memory, in **specific places of the program run the stack memory usually stores similar kind of data** and it has some specific structure with some pointers at the end of the stack part used by each function.
+
+However, in the case of a heap overflow, because the used memory isn’t linear but **allocated chunks of are usually in separated positions of memory** (not one next to the other) because of **bins and zones** separating allocations by size and because **previous freed memory is used** before allocating new chunks. It’s **complicated to know the object that is going to be colliding with the one vulnerable** to a heap overflow. So, when a heap overflow is found, it’s needed to find a **reliable way to make the desired object to be next in memory** from the one that can be overflowed.
+
+One of the techniques used for this is **Heap Grooming** which is used for example [**in this post**](https://azeria-labs.com/grooming-the-ios-kernel-heap/). In the post it’s explained how when in iOS kernel when a zone run out of memory to store chunks of memory, it expands it by a kernel page, and this page is splitted into chunks of the expected sizes which would be used in order (until iOS version 9.2, then these chunks are used in a randomised way to difficult the exploitation of these attacks).
+
+Therefore, in the previous post where a heap overflow is happening, in order to force the overflowed object to be colliding with a victim order, several **`kallocs` are forced by several threads to try to ensure that all the free chunks are filled and that a new page is created**.
+
+In order to force this filling with objects of a specific size, the **out-of-line allocation associated with an iOS mach port** is an ideal candidate. By crafting the size of the message, it’s possible to exactly specify the size of `kalloc` allocation and when the corresponding mach port is destroyed, the corresponding allocation will be immediately released back to `kfree`.
+
+Then, some of these placeholders can be **freed**. The **`kalloc.4096` free list releases elements in a last-in-first-out order**, which basically means that if some place holders are freed and the exploit try lo allocate several victim objects while trying to allocate the object vulnerable to overflow, it’s probable that this object will be followed by a victim object.
+
## Example ARM64
In the page [https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/](https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/) you can find a heap overflow example where a command that is going to be executed is stored in the following chunk from the overflowed chunk. So, it's possible to modify the executed command by overwriting it with an easy exploit such as:
diff --git a/binary-exploitation/heap/use-after-free.md b/binary-exploitation/heap/use-after-free/README.md
similarity index 83%
rename from binary-exploitation/heap/use-after-free.md
rename to binary-exploitation/heap/use-after-free/README.md
index fd0abec2a..0244f2488 100644
--- a/binary-exploitation/heap/use-after-free.md
+++ b/binary-exploitation/heap/use-after-free/README.md
@@ -20,10 +20,16 @@ As the name implies, this vulnerability occurs when a program **stores some spac
The problem here is that it's not ilegal (there **won't be errors**) when a **freed memory is accessed**. So, if the program (or the attacker) managed to **allocate the freed memory and store arbitrary data**, when the freed memory is accessed from the initial pointer that **data would be have been overwritten** causing a **vulnerability that will depends on the sensitivity of the data** that was stored original (if it was a pointer of a function that was going to be be called, an attacker could know control it).
-## Other References & Examples
+### First Fit attack
-* [https://8ksec.io/arm64-reversing-and-exploitation-part-2-use-after-free/](https://8ksec.io/arm64-reversing-and-exploitation-part-2-use-after-free/)
- * ARM64. Use after free: Generate a user, free it, reuse the same chunk **overwriting the position of user->password** from the previous one. Reuse the user to **bypass the password check**
+A first fit attack targets the way some memory allocators, like in glibc, manage freed memory. When you free a block of memory, it gets added to a list, and new memory requests pull from that list from the end. Attackers can use this behavior to manipulate **which memory blocks get reused, potentially gaining control over them**. This can lead to "use-after-free" issues, where an attacker could **change the contents of memory that gets reallocated**, creating a security risk.\
+Check more info in:
+
+{% content-ref url="first-fit.md" %}
+[first-fit.md](first-fit.md)
+{% endcontent-ref %}
+
+##
diff --git a/binary-exploitation/heap/use-after-free/first-fit.md b/binary-exploitation/heap/use-after-free/first-fit.md
new file mode 100644
index 000000000..fbebc9340
--- /dev/null
+++ b/binary-exploitation/heap/use-after-free/first-fit.md
@@ -0,0 +1,68 @@
+# First Fit
+
+
+
+Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
+
+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.
+
+
+
+## **First Fit**
+
+When you free memory in a program using glibc, different "bins" are used to manage the memory chunks. Here's a simplified explanation of two common scenarios: unsorted bins and fastbins.
+
+### Unsorted Bins
+
+When you free a memory chunk that's not a fast chunk, it goes to the unsorted bin. This bin acts like a list where new freed chunks are added to the front (the "head"). When you request a new chunk of memory, the allocator looks at the unsorted bin from the back (the "tail") to find a chunk that's big enough. If a chunk from the unsorted bin is bigger than what you need, it gets split, with the front part being returned and the remaining part staying in the bin.
+
+Example:
+
+* You allocate 300 bytes (`a`), then 250 bytes (`b`), the free `a` and request again 250 bytes (`c`).
+* When you free `a`, it goes to the unsorted bin.
+* If you then request 250 bytes again, the allocator finds `a` at the tail and splits it, returning the part that fits your request and keeping the rest in the bin.
+ * `c` will be pointing to the previous `a` and filled with the `a's`.
+
+```c
+char *a = malloc(300);
+char *b = malloc(250);
+free(a);
+char *c = malloc(250);
+```
+
+### Fastbins
+
+Fastbins are used for small memory chunks. Unlike unsorted bins, fastbins add new chunks to the head, creating a last-in-first-out (LIFO) behavior. If you request a small chunk of memory, the allocator will pull from the fastbin's head.
+
+Example:
+
+* You allocate four chunks of 20 bytes each (`a`, `b`, `c`, `d`).
+* When you free them in any order, the freed chunks are added to the fastbin's head.
+* If you then request a 20-byte chunk, the allocator will return the most recently freed chunk from the head of the fastbin.
+
+```c
+char *a = malloc(20);
+char *b = malloc(20);
+char *c = malloc(20);
+char *d = malloc(20);
+free(a);
+free(b);
+free(c);
+free(d);
+a = malloc(20); // d
+b = malloc(20); // c
+c = malloc(20); // b
+d = malloc(20); // a
+```
+
+## Other References & Examples
+
+* [https://heap-exploitation.dhavalkapil.com/attacks/first\_fit](https://heap-exploitation.dhavalkapil.com/attacks/first\_fit)
+* [https://8ksec.io/arm64-reversing-and-exploitation-part-2-use-after-free/](https://8ksec.io/arm64-reversing-and-exploitation-part-2-use-after-free/)
+ * ARM64. Use after free: Generate an user object, free it, generate an object that gets the freed chunk and allow to write to it, **overwriting the position of user->password** from the previous one. Reuse the user to **bypass the password check**
.png)
