physrw = đọc/ghi directly vào physical memory addresses. Đây là primitive mạnh nhất — bypass mọi virtual memory protection, kernel permission checks, và (trên older iOS) thậm chí PPL.


Tại Sao physrw Mạnh Nhất

Virtual R/W (kread/kwrite):
  ✓ Đọc/ghi kernel virtual addresses
  ✗ Bị giới hạn bởi page table permissions
  ✗ Không modify được PPL-protected pages
  ✗ Không modify được page tables trực tiếp

Physical R/W (physrw):
  ✓ Đọc/ghi BẤT KỲ physical address
  ✓ Bypass page table permissions
  ✓ Có thể modify page tables → thay đổi mappings
  ✓ Có thể map MMIO registers → access hardware
  ✓ Pre-SPTM: có thể modify PPL-protected pages

Cách Đạt Được physrw

Via Physical Use-After-Free (PUAF)

Bước 1: Trigger PUAF
  - Exploit VM bug → physical page P freed nhưng vẫn mapped vào process
  - Process vẫn có virtual mapping VA → PA_P

Bước 2: Controlled reallocation
  - Kernel reallocates PA_P cho mục đích khác
  - Nếu PA_P trở thành L3 page table:
    └── Process đọc/ghi VA = đọc/ghi page table entries!

Bước 3: Page table manipulation
  - Ghi PTE mới trỏ đến arbitrary physical address
  - Access qua new virtual mapping → physrw!

  VA_exploit ──→ PA_P (now L3 page table)
                   │
                   ├── Modify PTE[0] → PA_target
                   │
                   └── Access VA_new → PA_target (arbitrary physical access)

PUAF Methods (from kfd)

Method Mechanism iOS versions
physpuppet Exploit physical page lifecycle bug iOS 14-15
smith Exploit VM copy-on-write bug iOS 14-16
landa Exploit VM subsystem race iOS 15-16

Via Kernel Virtual R/W + Page Table Walk

Nếu có kread/kwrite (nhưng không physrw):
  1. kread TTBR1_EL1 value (hoặc known kernel symbol)
  2. Walk L1 → L2 → L3 page tables bằng kread
  3. Modify L3 PTE bằng kwrite → add new mapping
  4. Access new mapping → physrw

Nhưng PPL/SPTM ngăn modify page tables qua kwrite:
  - PPL: page table pages nằm trong PPL-protected region
  - SPTM: page table modifications phải qua SPTM (EL2)
  → Cần PPL/SPTM bypass trước

physrw Workflow Chi Tiết

Step 1: Identify Physical Memory Layout

Dùng physrw đọc:
  - iBoot parameters → physical memory ranges
  - Device tree → hardware layout
  - Kernel static region → kernel code/data physical addresses

Step 2: Map All Interesting Regions

Create PTE entries for:
  - Entire DRAM → full physical memory access
  - MMIO registers → hardware control
  - Kernel page tables → modify any mapping

Step 3: From physrw to Full Control

physrw + page table control:
  ├── Modify kernel code protection → write to __TEXT
  │     (blocked by KTRR/CTRR on modern devices)
  ├── Modify kernel data → same as kwrite but unconstrained
  ├── Access hardware registers → direct hardware control
  └── Modify TrustCache → code signing bypass

SPTM Impact (iOS 17+)

Pre-SPTM (iOS ≤16):
  PUAF → physrw → modify page tables → full control
  ✓ Works on all devices

Post-SPTM (iOS 17+, A15+):
  PUAF still possible nhưng:
  ✗ User pages CANNOT become kernel pages (until reboot)
  ✗ Page table modifications MUST go through SPTM (EL2)
  ✗ SPTM tracks page types → prevents type changes

  → PUAF only useful for user→user attacks (less powerful)
  → Need SPTM vulnerability for full physrw

Tài Nguyên