GITBOOK-4351: No subject

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

@@ -178,6 +178,8 @@ Basically, what happens here is that the header (the pointer to the first chunk
 * When a new chunk is allocated of that size, the header is pointing to a free chunk to use. As this free chunk is pointing to the next one to use, this address is stored in the header so the next allocation knows where to get ana available chunk
 * When a chunk is freed, the free chunk will save the address to the current available chunk and the address to this newly freed chunk will be put in the header
 
+The maximum size of a linked list is `0x80` and they are organized so a chunk of size `0x20-0x2f` will be in index `0`, a chunk of size `0x30-0x3f` would bi in `idx` `1`...
+
 {% hint style="danger" %}
 Chunks in fast bins aren't set as available so they are keep as fast bin chunks for some time instead of being able to merge with other free chunks surrounding them.
 {% endhint %}

binary-exploitation/heap/heap-overflow.md

@@ -38,7 +38,15 @@ In order to force this filling with objects of a specific size, the **out-of-lin
 
 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
+### Example libc
+
+[**In this page**](https://guyinatuxedo.github.io/27-edit\_free\_chunk/heap\_consolidation\_explanation/index.html) it's possible to find a basic Heap overflow emulation that shows how overwriting the prev in use bit of the next chunk and the position of the prev size it's possible to **consolidate a used chunk** (by making it thing it's unused) and **then allocate it again** being able to overwrite data that is being used in a different pointer also.
+
+Another example from [**protostar heap 0**](https://guyinatuxedo.github.io/24-heap\_overflow/protostar\_heap0/index.html) shows a very basic example of a CTF where a **heap overflow** can be abused to call the winner function to **get the flag**.
+
+In the [**protostar heap 1**](https://guyinatuxedo.github.io/24-heap\_overflow/protostar\_heap1/index.html) example it's possible to see how abusing a buffer overflow it's possible to **overwrite in a near chunk an address** where **arbitrary data from the user** is going to be written to.
+
+### 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:
 

binary-exploitation/heap/unlink-attack.md

@@ -91,7 +91,7 @@ int main() {
 
 </details>
 
-* Attack doesn't work if tcaches are used
+* Attack doesn't work if tcaches are used (after 2.26)
 
 ### Goal
 
@@ -119,12 +119,17 @@ int main() {
 * Previously it was made that `fake_chunk->fd->bk` and `fake_chunk->fd->bk` point to the same place (the location in the stack where `chunk1` was stored, so it was a valid linked list). As **both are pointing to the same location** only the last one (`fake_chunk->bk->fd = fake_chunk->fd`) will take **effect**.
 * This will **overwrite the pointer to chunk1 in the stack to the address (or bytes) stored 3 addresses before in the stack**.
   * Therefore, if an attacker could control the content of the chunk1 again, he will be able to **write inside the stack** being able to potentially overwrite the return address skipping the canary and modify the values and points of local variables. Even modifying again the address of chunk1 stored in the stack to a different location where if the attacker could control again the content of chunk1 he will be able to write anywhere.
+  * Note that this was possible because the **addresses are stored in the stack**. The risk and exploitation might depend on **where are the addresses to the fake chunk being stored**.
 
 <figure><img src="../../.gitbook/assets/image (1246).png" alt=""><figcaption><p><a href="https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit">https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit</a></p></figcaption></figure>
 
 ## References
 
 * [https://heap-exploitation.dhavalkapil.com/attacks/unlink\_exploit](https://heap-exploitation.dhavalkapil.com/attacks/unlink\_exploit)
+* Although it would be weird to find an unlink attack even in a CTF here you have some writeups where this attack was used:
+  * CTF example: [https://guyinatuxedo.github.io/30-unlink/hitcon14\_stkof/index.html](https://guyinatuxedo.github.io/30-unlink/hitcon14\_stkof/index.html)
+    * In this example, instead of the stack there is an array of malloc'ed addresses. The unlink attack is performed to be able to allocate a chunk here, therefore being able to control the pointers of the array of malloc'ed addresses. Then, there is another functionality that allows to modify the content of chunks in these addresses, which allows to point addresses to the GOT, modify function addresses to egt leaks and RCE.
+    *
 
 <details>
 

binary-exploitation/heap/use-after-free/README.md

@@ -29,8 +29,6 @@ Check more info in:
 [first-fit.md](first-fit.md)
 {% endcontent-ref %}
 
-##
-
 <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>