Merge pull request #2466 from HackTricks-wiki/research_update_src_binary-exploitation_rop-return-oriented-programing_srop-sigreturn-oriented-programming_srop-arm64_20260704_134603

Research Update Enhanced src/binary-exploitation/rop-return-...

Author: carlospolop

src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md

@@ -142,7 +142,7 @@ int main(int argc, char **argv) {
 
 ## Exploit
 
-In the section **`vdso`** it's possible to find a call to **`sigreturn`** in the offset **`0x7b0`**:
+In the **example vDSO dump shown below**, it's possible to find a call to **`sigreturn`** at offset **`0x7b0`**:
 
 <figure><img src="../../../images/image (17) (1).png" alt="" width="563"><figcaption></figcaption></figure>
 
@@ -193,21 +193,33 @@ And to bypass the address of `/bin/sh` you could create several env variables po
 
 ---
 
-## Finding `sigreturn` gadgets automatically (2023-2025)
+## Locating `rt_sigreturn` on ARM64 (2023-2025)
 
-On modern distributions the `sigreturn` trampoline is still exported by the **vDSO** page but the exact offset may vary across kernel versions and build flags such as BTI (`+branch-protection`) or PAC.  Automating its discovery prevents hard-coding offsets:
+On Linux/**AArch64** the most convenient SROP gadget is usually the **vDSO** trampoline exported as **`__kernel_rt_sigreturn`**. In current kernels the interesting sequence is intentionally tiny:
+
+```armasm
+nop                // unwinder marker
+__kernel_rt_sigreturn:
+    mov x8, #0x8b  // __NR_rt_sigreturn
+    svc #0
+```
+
+Do **not** hard-code an offset such as `0x7b0` unless you already dumped the exact target **vDSO**. The offset varies across kernel builds, so the reliable workflow is: recover the **vDSO** base, dump that mapping, and resolve `__kernel_rt_sigreturn` inside the dump.
 
 ```bash
-# With ROPgadget ≥ 7.4
-python3 -m ROPGadget --binary /proc/$(pgrep srop)/mem --only "svc #0" 2>/dev/null | grep -i sigreturn
+# 1) Find the vDSO mapping
+cat /proc/<pid>/maps | grep '\[vdso\]'
 
-# With rp++ ≥ 1.0.9 (arm64 support)
-rp++ -f ./binary --unique -r | grep "mov\s\+x8, #0x8b"   # 0x8b = __NR_rt_sigreturn
-```
+# 2) Dump it (replace base/size with the values from maps)
+dd if=/proc/<pid>/mem of=vdso bs=1 skip=$((0xBASE)) count=$((0xSIZE))
 
-Both tools understand **AArch64** encodings and will list candidate `mov x8, 0x8b ; svc #0` sequences that can be used as the *SROP gadget*.
+# 3) Resolve the trampoline
+readelf -Ws vdso | grep rt_sigreturn
+objdump -d vdso | sed -n '/__kernel_rt_sigreturn/,+4p'
+ROPgadget --binary vdso --only 'svc'
+```
 
-> Note: When binaries are compiled with **BTI** the first instruction of every valid indirect branch target is `bti c`.  `sigreturn` trampolines placed by the linker already include the correct BTI landing pad so the gadget remains usable from unprivileged code.
+This is much more reliable than grepping the main binary because on ARM64 the **SROP entry point usually lives in the vDSO**, not in the target ELF itself.
 
 ## Chaining SROP with ROP (pivot via `mprotect`)
 
@@ -225,23 +237,37 @@ frame.pc = svc_call                # will re-enter kernel
 
 After sending the frame you can send a second stage containing raw shell-code at `0x400000+0x100`.  Because **AArch64** uses *PC-relative* addressing this is often more convenient than building large ROP chains.
 
-## Kernel validation, PAC & Shadow-Stacks
+### Quick debugging note for `pwntools` users
+
+If you are using the stock **AArch64** `SigreturnFrame()` from modern `pwntools`, the serialized frame is **600 bytes** long. Useful offsets when debugging corrupted payloads are:
+
+* `x8` (syscall number): `0x178`
+* `sp`: `0x230`
+* `pc`: `0x238`
+
+If your payload reaches the `svc #0` but the kernel rejects the frame, checking these offsets in a hexdump is often faster than single-stepping the whole chain.
+
+## Modern kernel parsing and branch-protection caveats
 
-Linux 5.16 introduced stricter validation of userspace signal frames (commit `36f5a6c73096`).  The kernel now checks:
+Recent **arm64** kernels are stricter than many old SROP writeups assume. When you hand-craft a frame, keep in mind that:
 
-* `uc_flags` must contain `UC_FP_XSTATE` when `extra_context` is present.
-* The reserved word in `struct rt_sigframe` must be zero.
-* Every pointer in the *extra_context* record is aligned and points inside the user address space.
+* `sigcontext.__reserved` parsing is **16-byte aligned**.
+* Only **one** `extra_context` record is accepted.
+* If `extra_context` is used, its `datap` pointer must point exactly to the extra data area and the total extra size must stay inside the accepted signal-frame limits.
+* `fpsimd_context` is still **mandatory** on systems that support FPSIMD, even if you only care about controlling `x0-x30`, `sp`, and `pc`.
+* If you include `sve_context`/`za_context`, the kernel validates their sizes and **current vector length**. In practice, `rt_sigreturn` is not a clean way to change VL mid-exploit.
+* On newer kernels there are even more optional records such as **GCS**, **POE**, and **FPMR** contexts, which is another reason to prefer the smallest valid frame possible.
 
-`pwntools>=4.10` crafts compliant frames automatically, but if you build them manually make sure to zero‐initialize *reserved* and omit the SVE record unless you really need it—otherwise `rt_sigreturn` will deliver `SIGSEGV` instead of returning.
+Therefore, the most reliable offensive strategy is usually to keep the frame **minimal**: use the default `SigreturnFrame()` layout and avoid adding SVE/SME records unless you explicitly need them.
 
-Starting with mainstream Android 14 and Fedora 38, userland is compiled with **PAC** (*Pointer Authentication*) and **BTI** enabled by default (`-mbranch-protection=standard`).  *SROP* itself is unaffected because the kernel overwrites `PC` directly from the crafted frame, bypassing the authenticated LR saved on the stack; however, any **subsequent ROP chain** that performs indirect branches must jump to BTI-enabled instructions or PACed addresses.  Keep that in mind when choosing gadgets.
+For hardened userlands, also keep in mind:
 
-Shadow-Call-Stacks introduced in ARMv8.9 (and already enabled on ChromeOS 1.27+) are a compiler-level mitigation and *do not* interfere with SROP because no return instructions are executed—the flow of control is transferred by the kernel.
+* With **PAC** (`paciasp` / `autiasp`), a plain saved-`x30` overwrite may die before you ever reach the SROP trampoline if the function epilogue authenticates `LR`.
+* With **BTI**, indirect `br` / `blr` targets must land on a valid landing pad. The arm64 **vDSO** `__kernel_rt_sigreturn` trampoline intentionally omits `bti c` because the kernel expects it to be reached from a `ret`. So returning to it is fine, but jumping to it with a BTI-checked branch gadget can fault.
 
 ## References
 
-* [Linux arm64 signal handling documentation](https://docs.kernel.org/arch/arm64/signal.html)
-* [LWN – "AArch64 branch protection comes to GCC and glibc" (2023)](https://lwn.net/Articles/915041/)
+* [Linux arm64 vDSO `__kernel_rt_sigreturn` source](https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/vdso/sigreturn.S)
+* [Linux arm64 signal-frame parsing (`signal.c`)](https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/signal.c)
 
 {{#include ../../../banners/hacktricks-training.md}}