---
name: reap-19-kernel-and-driver-exploitation-research
description: REA prompt pack:  Kernel & driver exploitation research (7 ready-to-paste prompts). Use when doing reverse-engineering investigation of kernel & driver exploitation research with REA (rea.tools) via an AI coding agent.
---

# REAP — 19. Kernel & driver exploitation research

Part of REAP (REA Investigation Prompts). Replace everything in <angle brackets>; keep each request focused on one feature. Demand file/function/address evidence and separate facts from hypotheses.

> Authorized contexts only: your own vulnerable driver, a CVE you are validating
> for a bug bounty, a CTF kernel challenge, or defensive hardening review.
> "Exploitation research" here means proving reachability of a flaw and
> documenting the primitive — not building public weaponized exploits.

### Vulnerable-driver primitive analysis (BYOVD-style, own driver)

```text
Use REA on <driver .sys> that I own/am authorized to assess (e.g. a known
vulnerable driver used in my lab).

Document the read/write primitive: which IOCTL gives arbitrary physical or
virtual memory R/W, exactly how the handler validates (or fails to validate)
the input buffer, the struct layout the driver expects, and the shortest
reproducible sequence that demonstrates the primitive against my own test
buffer. Give handler addresses and the missing check that makes it possible.
```

### CVE reachability validation on a patched build

```text
Use REA on <kernel binary / module version X> to check whether the fix for
<CVE-ID> is complete for this build.

Locate the patched function, verify the added check exists and covers every
caller path that reaches it, then search the rest of the binary for the same
unchecked pattern (similar copy, same struct, different entry point). Report:
fix present/absent, any bypass path found, and any sibling location still
missing the check — each labeled hypothesis vs confirmed, with addresses.
```

### Race condition / TOCTOU hunt in a driver

```text
Use REA on <driver>. Find handlers that touch shared state (global buffers,
device extension fields, linked lists) from multiple IRQLs or concurrent IOCTLs.

Identify where a check and the subsequent use are separated without a lock or
atomic reference (TOCTOU), or where a use-after-free window opens between
close/unload and a pending operation. For each candidate: the two racing code
paths with addresses, the shared object, and the smallest controlled test that
would confirm or refute the race.
```

### Kernel attack-surface ranking

```text
Use REA on <kernel module / driver>. Enumerate every user-reachable entry point
(IOCTLs, syscalls, netlink/socket handlers, minifilter callbacks), and for each
record: input validation depth (probe method, size checks, pointer
dereference), state it touches, and privilege context.

Rank the entry points by exploitable-risk with evidence for the ranking, and
name the top 3 worth a deeper source-level or crash-driven look.
```

### Windows/Linux kernel structure recovery

```text
Use REA on <kernel image / driver>. Reconstruct the key data structures used by
<subsystem>: field-by-field layout inferred from access offsets in the code,
with the address of every access that proves each field's offset and width.
Annotate the decompiler output with recovered struct names and types.
```

### Reference-count / lifetime bug hunt (UAF candidates)

```text
Use REA on <driver / kernel module>. For every object type that is allocated
and later freed (look for the alloc/free or ref-count increment/decrement
pairs), trace whether any code path can use the object after its last
release: missing reference taken before storing a pointer, decrement-then-use
ordering, callbacks registered without a hold. For each candidate: the
alloc/free/use address triple, the path that reaches the stale use, and the
smallest controlled test that would confirm it. Label every finding as
hypothesis until validated.
```

### Windows syscall / SSDT surface walk

```text
Use REA on <ntoskrnl / win32k image or a documented syscall number> to
explain how <NtUserXxx/NtXxx> handles attacker-controlled arguments: the
entry stub, parameter validation (probe, capture, alignment), the user-mode
structures it reads, and the kernel objects it touches. Show the dispatch
path with addresses and flag any argument that reaches a sensitive operation
without a visible check. Static analysis only.
```

---