Skip to content

Commit a8108da

Browse files
authored
Merge pull request #1548 from HackTricks-wiki/update_Defeating_KASLR_by_Doing_Nothing_at_All_20251103_185218
Defeating KASLR by Doing Nothing at All
2 parents f8732c5 + 2a4a6d3 commit a8108da

File tree

1 file changed

+53
-4
lines changed
  • src/binary-exploitation/common-binary-protections-and-bypasses/aslr

1 file changed

+53
-4
lines changed

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

Lines changed: 53 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -106,6 +106,9 @@ int main() {
106106
}
107107
```
108108

109+
<details>
110+
<summary>Python brute-force stack NOP detection</summary>
111+
109112
```python
110113
import subprocess
111114
import traceback
@@ -157,6 +160,8 @@ while True:
157160
pass
158161
```
159162

163+
</details>
164+
160165
<figure><img src="../../../images/image (1214).png" alt="" width="563"><figcaption></figcaption></figure>
161166

162167
### Local Information (`/proc/[pid]/stat`)
@@ -181,6 +186,9 @@ Therefore, if the attacker is in the same computer as the binary being exploited
181186

182187
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):
183188

189+
<details>
190+
<summary>Python exploit with given libc leak</summary>
191+
184192
```python
185193
from pwn import *
186194

@@ -206,6 +214,8 @@ p.sendline(payload)
206214
p.interactive()
207215
```
208216

217+
</details>
218+
209219
- **ret2plt**
210220

211221
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
255265

256266
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.
257267

258-
```
268+
<details>
269+
<summary>Example vmmap/vsyscall and gadget lookup</summary>
270+
271+
```text
259272
ef➤ vmmap
260273
Start End Offset Perm Path
261274
0x0000555555554000 0x0000555555556000 0x0000000000000000 r-x /Hackery/pod/modules/partial_overwrite/hacklu15_stackstuff/stackstuff
262275
0x0000555555755000 0x0000555555756000 0x0000000000001000 rw- /Hackery/pod/modules/partial_overwrite/hacklu15_stackstuff/stackstuff
263276
0x0000555555756000 0x0000555555777000 0x0000000000000000 rw- [heap]
264277
0x00007ffff7dcc000 0x00007ffff7df1000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
265-
0x00007ffff7df1000 0x00007ffff7f64000 0x0000000000025000 r-x /usr/lib/x86_64-linux-gnu/libc-2.29.so
278+
0x00007ffff7df1000 0x00007ffff7f64000 0x0000000000000000 r-x /usr/lib/x86_64-linux-gnu/libc-2.29.so
266279
0x00007ffff7f64000 0x00007ffff7fad000 0x0000000000198000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
267280
0x00007ffff7fad000 0x00007ffff7fb0000 0x00000000001e0000 r-- /usr/lib/x86_64-linux-gnu/libc-2.29.so
268281
0x00007ffff7fb0000 0x00007ffff7fb3000 0x00000000001e3000 rw- /usr/lib/x86_64-linux-gnu/libc-2.29.so
@@ -271,7 +284,7 @@ Start End Offset Perm Path
271284
0x00007ffff7fd1000 0x00007ffff7fd2000 0x0000000000000000 r-x [vdso]
272285
0x00007ffff7fd2000 0x00007ffff7fd3000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
273286
0x00007ffff7fd3000 0x00007ffff7ff4000 0x0000000000001000 r-x /usr/lib/x86_64-linux-gnu/ld-2.29.so
274-
0x00007ffff7ff4000 0x00007ffff7ffc000 0x0000000000022000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
287+
0x00007ffff7ff4000 0x00007ffff7ffc000 0x0000000000000000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
275288
0x00007ffff7ffc000 0x00007ffff7ffd000 0x0000000000029000 r-- /usr/lib/x86_64-linux-gnu/ld-2.29.so
276289
0x00007ffff7ffd000 0x00007ffff7ffe000 0x000000000002a000 rw- /usr/lib/x86_64-linux-gnu/ld-2.29.so
277290
0x00007ffff7ffe000 0x00007ffff7fff000 0x0000000000000000 rw-
@@ -296,6 +309,8 @@ gef➤ x/4i 0xffffffffff600800
296309
0xffffffffff60080a: int3
297310
```
298311

312+
</details>
313+
299314
### vDSO
300315

301316
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,40 @@ Note therefore how it might be possible to **bypass ASLR abusing the vdso** if t
305320
../../rop-return-oriented-programing/ret2vdso.md
306321
{{#endref}}
307322

308-
{{#include ../../../banners/hacktricks-training.md}}
323+
### KASLR on ARM64 (Android): bypass via fixed linear map
309324

325+
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.
310326

327+
- For CONFIG_ARM64_VA_BITS=39 (4 KiB pages, 3-level paging):
328+
- PAGE_OFFSET = 0xffffff8000000000
329+
- PHYS_OFFSET = memstart_addr (exported symbol)
330+
- Translation: `virt = ((phys - PHYS_OFFSET) | PAGE_OFFSET)`
331+
332+
**Leaking PHYS_OFFSET (rooted or with a kernel read primitive)**
333+
- `grep memstart /proc/kallsyms` to find `memstart_addr`
334+
- Read 8 bytes at that address (LE) using any kernel read (e.g., tracing-BPF helper calling `BPF_FUNC_probe_read_kernel`)
335+
- Compute direct-map VAs: `virt = ((phys - PHYS_OFFSET) | 0xffffff8000000000)`
336+
337+
**Exploitation impact**
338+
- 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).
339+
- Simplifies reliable arbitrary R/W and targeting of kernel data on arm64 Android.
340+
341+
**Reproduction summary**
342+
1) `grep memstart /proc/kallsyms` -> address of `memstart_addr`
343+
2) Kernel read -> decode 8 bytes LE -> `PHYS_OFFSET`
344+
3) Use `virt = ((phys - PHYS_OFFSET) | PAGE_OFFSET)` with `PAGE_OFFSET=0xffffff8000000000`
345+
346+
> [!NOTE]
347+
> Access to tracing-BPF helpers requires sufficient privileges; any kernel read primitive or info leak suffices to obtain `PHYS_OFFSET`.
348+
349+
**How it’s fixed**
350+
- Limited kernel VA space plus CONFIG_MEMORY_HOTPLUG reserves VA for future hotplug, pushing the linear map to the lowest VA (fixed base).
351+
- Upstream arm64 removed linear-map randomization (commit `1db780bafa4c`).
352+
-
353+
## References
354+
355+
- [Defeating KASLR by Doing Nothing at All (Project Zero)](https://googleprojectzero.blogspot.com/2025/11/defeating-kaslr-by-doing-nothing-at-all.html)
356+
- [arm64: remove linear map randomization (commit 1db780bafa4c)](https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=1db780bafa4c)
357+
- [Tracing BPF arbitrary read helper (Project Zero issue 434208461)](https://project-zero.issues.chromium.org/issues/434208461)
358+
359+
{{#include ../../../banners/hacktricks-training.md}}

0 commit comments

Comments
 (0)