Physical Read/Write (physrw)

physrw = reading/writing directly to physical memory addresses. This is the most powerful primitive – it bypasses all virtual memory protections, kernel permission checks, and (on older iOS) even PPL.

Why physrw Is the Most Powerful

Virtual R/W (kread/kwrite):
  ✓ Read/write kernel virtual addresses
  ✗ Limited by page table permissions
  ✗ Cannot modify PPL-protected pages
  ✗ Cannot modify page tables directly

Physical R/W (physrw):
  ✓ Read/write ANY physical address
  ✓ Bypass page table permissions
  ✓ Can modify page tables → change mappings
  ✓ Can map MMIO registers → access hardware
  ✓ Pre-SPTM: can modify PPL-protected pages

How to Achieve physrw

Via Physical Use-After-Free (PUAF)

Step 1: Trigger PUAF
  - Exploit a VM bug → physical page P freed but still mapped into the process
  - Process still has virtual mapping VA → PA_P

Step 2: Controlled reallocation
  - Kernel reallocates PA_P for another purpose
  - If PA_P becomes an L3 page table:
    └── Process reading/writing VA = reading/writing page table entries!

Step 3: Page table manipulation
  - Write new PTEs pointing to arbitrary physical addresses
  - Access via new virtual mappings → 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

If you have kread/kwrite (but not physrw):
  1. kread the TTBR1_EL1 value (or a known kernel symbol)
  2. Walk L1 → L2 → L3 page tables using kread
  3. Modify L3 PTE using kwrite → add a new mapping
  4. Access the new mapping → physrw

But PPL/SPTM prevents modifying page tables via kwrite:
  - PPL: page table pages are in a PPL-protected region
  - SPTM: page table modifications must go through SPTM (EL2)
  → Need a PPL/SPTM bypass first

Detailed physrw Workflow

Step 1: Identify Physical Memory Layout

Use physrw to read:
  - 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 but:
  ✗ 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 an SPTM vulnerability for full physrw

Resources