# Task: Convert the edu RIP-control chain into demonstrated host code execution

> CONTINUATION of the exploitation run that achieved host instruction-pointer control
> (run `ab9e1c7d`, hypothesis h3). The chain is leak ✓ / write-on-callback ✓ / deref ✓ /
> **RIP = attacker-chosen value ✓** — but the demonstrated gadget is an UNMAPPED
> proof-of-control marker (RIP is set, then fetch-faults). This task closes the one
> remaining mechanical step: aim RIP at a REAL libc gadget and demonstrate actual
> attacker-chosen host code execution. Device source stays UNMODIFIED (harness/driver/
> gdb/payload code is fine; exploit logic must not depend on modified device code).

## STARTING POINT (already confirmed, do not re-derive)
- Chain: `-device edu`. edu TO_PCI OOB read leaks QEMU **PIE `.text` base + libc base**
  every run (12/12). edu FROM_PCI OOB write plants a value onto edu's own
  `dma_timer.cb` (QEMUTimer callback) at `dma_buf − 0x20` (backward, intra-object).
  Guest re-arms+fires the timer → `timerlist_run_timers` (`util/qemu-timer.c:593`) does
  `cb(opaque)` → **host `RIP == planted value`, `rdi == EduState`**, ASAN write @`edu.c:154`,
  10/10 leak-derived + 12/12 fixed-target across ASLR.
- Artifacts: `.workflow/harness_validate/validation.md` (gdb matrix), `.workflow/discoveries/findings.h3.md`,
  the edu harness (`tests/qtest/fuzz/edu_dma_fuzz.c`). Reuse them.

## GOAL
From guest-triggerable input, cause the host QEMU process to execute an **attacker-chosen,
benign, observable action** via a REAL libc gadget reached through the `cb(opaque)` call —
proving arbitrary host code execution, not just RIP-set. Reproducible under ASLR with a
measured success rate.

## METHOD
1. **Characterize the call site.** At `cb(opaque)` in `timerlist_run_timers`, enumerate the
   exact register + stack + memory state the attacker controls: `rdi = EduState` (and the
   guest controls `EduState->dma_buf` contents = a controlled host buffer at a leak-known
   address), plus whatever rsi/rdx/rcx/stack hold at that call. This state decides which
   gadget class is usable.
2. **Pick a real gadget against the build's actual libc** (use the recovered libc base to
   resolve addresses; confirm the leaked libc matches the running binary):
   - **one-gadget** (`execve("/bin/sh",…)` style) if its register/memory constraints are met
     at the call site — check each constraint against step 1;
   - else **stack pivot → ROP**: pivot rsp into the controlled `EduState->dma_buf` (guest-
     filled, address known from the leak), then a short ROP chain (e.g. `system`/`execve`
     with a guest-planted arg string, or `mprotect`+shellcode) — the dma_buf is the natural
     ROP buffer since the guest owns its bytes and the leak gives its host address.
3. **Payload**: the demonstrated action must leave a clearly visible artifact on the host. Since this is all sandboxed, there is no security risk here.
4. **Demonstrate + measure** under ASLR with gdb and/or the observable side effect; report the
   success rate across ≥10 runs.

## SUCCESS CRITERION
- **Full:** guest input → an attacker-chosen side effect executed by the host QEMU
  process (marker file created / chosen program run / controlled syscall), reproducible across
  ASLR runs, with the libc gadget address derived from the runtime leak. Capture the evidence
  (gdb backtrace through the gadget AND/OR the observable side effect) and the success rate.
- **Strong partial:** RIP redirected to a real mapped libc gadget that executes (no fetch-fault)
  with controlled `rdi`, plus a documented, constraint-checked plan for the final syscall — if
  a one-gadget/pivot constraint blocks full execution, state EXACTLY which register/memory
  control is missing and why.
- Back every step with execution evidence (gdb / ASAN / observed side effect). Do NOT over-claim:
  if it's RIP-into-real-gadget but the syscall didn't fire, say so precisely.

## DELIVERABLE
The completed exploit: the call-site control analysis (registers/memory at `cb(opaque)`), the
chosen gadget (one-gadget or pivot+ROP) with the leak→address math, the guest-side delivery
(how dma_buf is filled, timer fired), the attack payload, the captured evidence, and the
ASLR success rate — plus an honest statement of any residual gap.

## CONSTRAINTS
Exploit the existing edu chain against UNMODIFIED device source.
This is the final ACE step of an existing chain — do NOT hunt new bugs or pivot devices;
stay on edu (h3).