Defeating KASLR by Doing Nothing at All

src/binary-exploitation/common-binary-protections-and-bypasses/aslr/README.md

@@ -106,6 +106,9 @@ int main() {
 }
 ```
 
+<details>
+<summary>Python brute-force stack NOP detection</summary>
+
 ```python
 import subprocess
 import traceback
@@ -157,6 +160,8 @@ while True:
         pass
 ```
 
+</details>
+
 <figure><img src="../../../images/image (1214).png" alt="" width="563"><figcaption></figcaption></figure>
 
 ### Local Information (`/proc/[pid]/stat`)
@@ -181,6 +186,9 @@ Therefore, if the attacker is in the same computer as the binary being exploited
 
 If you are given a leak (easy CTF challenges), you can calculate offsets from it (supposing for example that you know the exact libc version that is used in the system you are exploiting). This example exploit is extract from the [**example from here**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/aslr-bypass-with-given-leak) (check that page for more details):
 
+<details>
+<summary>Python exploit with given libc leak</summary>
+
 ```python
 from pwn import *
 
@@ -206,6 +214,8 @@ p.sendline(payload)
 p.interactive()
 ```
 
+</details>
+
 - **ret2plt**
 
 Abusing a buffer overflow it would be possible to exploit a **ret2plt** to exfiltrate an address of a function from the libc. Check:
@@ -255,14 +265,17 @@ However, no super interesting gadgets will be find here (although for example it
 
 For instance, an attacker might use the address `0xffffffffff600800` within an exploit. While attempting to jump directly to a `ret` instruction might lead to instability or crashes after executing a couple of gadgets, jumping to the start of a `syscall` provided by the **vsyscall** section can prove successful. By carefully placing a **ROP** gadget that leads execution to this **vsyscall** address, an attacker can achieve code execution without needing to bypass **ASLR** for this part of the exploit.
 
-```
+<details>
+<summary>Example vmmap/vsyscall and gadget lookup</summary>
+
+```text
 ef➤  vmmap
 Start              End                Offset             Perm Path
 0x0000555555554000 0x0000555555556000 0x0000000000000000 r-x /Hackery/pod/modules/partial_overwrite/hacklu15_stackstuff/stackstuff
 0x0000555555755000 0x0000555555756000 0x0000000000001000 rw- /Hackery/pod/modules/partial_overwrite/hacklu15_stackstuff/stackstuff
 0x0000555555756000 0x0000555555777000 0x0000000000000000 rw- [heap]
 0x00007ffff7dcc000 0x00007ffff7df1000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
-0x00007ffff7df1000 0x00007ffff7f64000 0x0000000000025000 r-x /usr/lib/x86_64-linux-gnu/libc-2.29.so
+0x00007ffff7df1000 0x00007ffff7f64000 0x0000000000000000 r-x /usr/lib/x86_64-linux-gnu/libc-2.29.so
 0x00007ffff7f64000 0x00007ffff7fad000 0x0000000000198000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
 0x00007ffff7fad000 0x00007ffff7fb0000 0x00000000001e0000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
 0x00007ffff7fb0000 0x00007ffff7fb3000 0x00000000001e3000 rw- /usr/lib/x86_64-linux-gnu/libc-2.29.so
@@ -271,7 +284,7 @@ Start              End                Offset             Perm Path
 0x00007ffff7fd1000 0x00007ffff7fd2000 0x0000000000000000 r-x [vdso]
 0x00007ffff7fd2000 0x00007ffff7fd3000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
 0x00007ffff7fd3000 0x00007ffff7ff4000 0x0000000000001000 r-x /usr/lib/x86_64-linux-gnu/ld-2.29.so
-0x00007ffff7ff4000 0x00007ffff7ffc000 0x0000000000022000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
+0x00007ffff7ff4000 0x00007ffff7ffc000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
 0x00007ffff7ffc000 0x00007ffff7ffd000 0x0000000000029000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
 0x00007ffff7ffd000 0x00007ffff7ffe000 0x000000000002a000 rw- /usr/lib/x86_64-linux-gnu/ld-2.29.so
 0x00007ffff7ffe000 0x00007ffff7fff000 0x0000000000000000 rw-
@@ -296,6 +309,8 @@ gef➤  x/4i 0xffffffffff600800
    0xffffffffff60080a:    int3
 ```
 
+</details>
+
 ### vDSO
 
 Note therefore how it might be possible to **bypass ASLR abusing the vdso** if the kernel is compiled with CONFIG_COMPAT_VDSO as the vdso address won't be randomized. For more info check:
@@ -305,6 +320,39 @@ Note therefore how it might be possible to **bypass ASLR abusing the vdso** if t
 ../../rop-return-oriented-programing/ret2vdso.md
 {{#endref}}
 
-{{#include ../../../banners/hacktricks-training.md}}
+### KASLR on ARM64 (Android): bypass via fixed linear map
+
+On many arm64 Android kernels the kernel linear map (direct map) base is fixed across boots. Kernel VAs for physical pages become predictable, breaking KASLR for targets reachable via the direct map.
+
+- For CONFIG_ARM64_VA_BITS=39 (4 KiB pages, 3-level paging):
+  - PAGE_OFFSET = 0xffffff8000000000
+  - PHYS_OFFSET = memstart_addr (exported symbol)
+  - Translation: `virt = ((phys - PHYS_OFFSET) | PAGE_OFFSET)`
+
+Why it’s fixed
+- Limited kernel VA space plus CONFIG_MEMORY_HOTPLUG reserves VA for future hotplug, pushing the linear map to the lowest VA (fixed base).
+- Upstream arm64 removed linear-map randomization (commit `1db780bafa4c`).
+
+Leaking PHYS_OFFSET (rooted or with a kernel read primitive)
+- `grep memstart /proc/kallsyms` to find `memstart_addr`
+- Read 8 bytes at that address (LE) using any kernel read (e.g., tracing-BPF helper calling `BPF_FUNC_probe_read_kernel`)
+- Compute direct-map VAs: `virt = ((phys - PHYS_OFFSET) | 0xffffff8000000000)`
+
+Exploitation impact
+- No separate KASLR leak needed if the target is in/reachable via the direct map (e.g., page tables, kernel objects on physical pages you can influence/observe).
+- Simplifies reliable arbitrary R/W and targeting of kernel data on arm64 Android.
+
+Reproduction summary
+1) `grep memstart /proc/kallsyms` -> address of `memstart_addr`
+2) Kernel read -> decode 8 bytes LE -> `PHYS_OFFSET`
+3) Use `virt = ((phys - PHYS_OFFSET) | PAGE_OFFSET)` with `PAGE_OFFSET=0xffffff8000000000`
+
+> [!NOTE]
+> Access to tracing-BPF helpers requires sufficient privileges; any kernel read primitive or info leak suffices to obtain `PHYS_OFFSET`.
+## References
 
+- [Defeating KASLR by Doing Nothing at All (Project Zero)](https://googleprojectzero.blogspot.com/2025/11/defeating-kaslr-by-doing-nothing-at-all.html)
+- [arm64: remove linear map randomization (commit 1db780bafa4c)](https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=1db780bafa4c)
+- [Tracing BPF arbitrary read helper (Project Zero issue 434208461)](https://project-zero.issues.chromium.org/issues/434208461)
 
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-web/xs-search/css-injection/less-code-injection.md

@@ -1,4 +1,6 @@
-## LESS Code Injection leading to SSRF & Local File Read
+# LESS Code Injection leading to SSRF & Local File Read
+
+{{#include ../../../banners/hacktricks-training.md}}
 
 LESS is a popular CSS pre-processor that adds variables, mixins, functions and the powerful `@import` directive.  During compilation the LESS engine will **fetch the resources referenced in `@import`** statements and embed ("inline") their contents into the resulting CSS when the `(inline)` option is used.
 
@@ -59,4 +61,5 @@ curl -sk "${TARGET}rest/v10/css/preview?baseUrl=1&lm=${INJ}" | \
 
 * [SugarCRM ≤ 14.0.0 (css/preview) LESS Code Injection Vulnerability](https://karmainsecurity.com/KIS-2025-04)
 * [SugarCRM Security Advisory SA-2024-059](https://support.sugarcrm.com/resources/security/sugarcrm-sa-2024-059/)
-* [CVE-2024-58258](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-58258)
+* [CVE-2024-58258](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-58258)
+{{#include ../../../banners/hacktricks-training.md}}