## https://sploitus.com/exploit?id=CAF30B94-3716-5ED0-9322-60CB8ECCE56D
# DenuOwO SVM/VMX Hypervisor — 6 Vulnerabilities (PoC + Analysis)
**Disclaimer:**
This repository is for **educational and security research purposes only**.
I am not affiliated with Denuvo, Irdeto, or DenuvOwO.
I just read what the computer told me.
**No guarantees.** Use at your own risk.
## TL;DR
- **Target:** Hypervisor used by `DenuvOwO` (KIRIGIRI) to bypass Denuvo DRM.
- **Method:** Static analysis via Ghidra (both AMD SVM and Intel VMX versions).
- **Result:** **6 critical vulnerabilities** discovered:
1. Guest CR3 not validated, process impersonation.
2. Arbitrary write via CPUID(0x336933), Ring 0 write primitive.
3. Exception handler overwrite, control flow hijack from Ring 3.
4. Race condition in VMLOAD/VMRUN / VMX entry.
5. No bounds checking on CPUID / vmcall, crash / info leak.
6. Kernel pointer leak via CPUID(0x41414141), ASLR bypass.
- **PoC:** `poc.c` that triggers all six. No admin rights required.
- **Impact:** Any process — not just the game — can compromise the hypervisor and potentially the whole system.
**Note on Intel disassembly sizes:**
The *full* raw assembly for the Intel version is ~400,000 lines and not uploaded.
The included `.c` files are Ghidra‑reconstructed pseudocode, they contain the exact same logic in a readable form.
Any researcher can reproduce the full disassembly by loading the original binaries into Ghidra/IDA.
## The Vulnerabilities (Detailed Walkthrough)
Below is a description of each bug, referencing actual code from the provided files.
### 1.Guest CR3 Not Validated (Process Impersonation)
**Location:** AMD SVM - `FUN_1400010bc` (lines 1400010c4..1400010f8)
**Intel VMX equivalent:** `hyperhv.dll.c` – look for CR3 comparisons.
The hypervisor compares the guest CR3 with a stored value (`DAT_140005080`), but if they differ, it does **not** check whether the new CR3 belongs to a trusted process.
**Consequence:** Any process can set CR3 to its own value and trick the hypervisor into believing it’s the game.
---
### 2.Arbitrary Write via CPUID(0x336933) (Ring 0 Write Primitive)
**Location:** AMD SVM - `FUN_140001c8c` (case `0x336933`, lines 140001dd1..140001de8)
**Intel VMX equivalent:** Look for a `vmcall` with magic argument `0x336933`.
When the guest executes `CPUID` with `eax = 0x336933`, the hypervisor takes the value from `RAX` (guest) and writes it directly into `DAT_140005088` (a global variable).
**Consequence:** A user‑mode program can write any 64‑bit value to any address (if it can control the target location). Classic **write-what-where**.
---
### 3.Exception Handler Overwrite (Control Flow Hijack)
**Location:** AMD SVM - `FUN_140001c8c` together with `FUN_1400010fc` (jump via `DAT_140005090`)
The hypervisor stores a function pointer at `DAT_140005090`. If the guest causes a `#UD` (via `__ud2`), the hypervisor jumps to that pointer **without validating it**. Using vulnerability #2, an attacker can overwrite `DAT_140005090` with a malicious address.
**Consequence:** Full control flow hijack from Ring 3, execution of arbitrary code in Ring 0.
---
### 4.Race Condition in VM Entry/Exit
**Location:** AMD SVM - `FUN_140001000` (VMLOAD -> VMRUN -> VMSAVE)
**Intel VMX equivalent:** `FUN_180001320` (vmcall) used in DPC callbacks.
There are no locks or barriers between `VMLOAD` and `VMRUN`. If two CPUs simultaneously call into the hypervisor, the guest state can be corrupted.
**Consequence:** Unpredictable behaviour, double fetches, potential privilege escalation.
---
### 5.No Bounds Checking on CPUID Leaves / Hypercalls
**Location:** AMD SVM - `FUN_140001c8c` (the big switch) - only checks a handful of magic numbers.
**Intel VMX equivalent:** The `vmcall` dispatcher in `hyperhv.dll.c` (functions handling parameters 1,2,3,...).
The hypervisor does **not** validate the CPUID leaf or vmcall argument. Any 32‑bit value is accepted, leading to out‑of‑range memory accesses or crashes.
**Consequence:** Crash the hypervisor (and thus the game), or leak information via uninitialised reads.
---
### 6.Kernel Pointer Leak via CPUID(0x41414141)
**Location:** AMD SVM - `FUN_140001910` (lines 14000193a..140001967)
When the guest executes `CPUID` with `eax = 0x41414141`, the hypervisor returns a kernel pointer (the address of `FUN_1400010bc`) in `RAX`.
**Consequence:** Bypasses KASLR (kernel ASLR), aiding further exploitation.
## Proof of Concept (`poc/poc.c`)
The provided `poc.c` demonstrates all six vulnerabilities in one file.
It communicates with the hypervisor using plain `CPUID` instructions and standard exception handling.
**Compilation & usage:**
```bash
# Compile with MSVC or MinGW
cl poc.c /Fe:poc.exe
# or
gcc poc.c -o poc.exe
# Run while a DenuvOwO‑cracked game is active
poc.exe
```
No administrator rights are required - all commands work from a standard user‑mode process.
---
How to Reproduce the Full Analysis (For Researchers)
If you want to verify the findings or continue the research:
Obtain a DenuvOwO‑cracked game (e.g., Resident Evil: Requiem 2026).
Extract the hypervisor driver from memory (or locate hyperhv.sys / hyperhv.dll on disk).
Load the binary into Ghidra (latest version recommended).
Run the initial analysis (default settings).
Navigate to the functions listed above (e.g., FUN_140001c8c).
Observe the same vulnerabilities I documented.
The full Intel disassembly is ~400,000 lines - it is not uploaded here, but the reconstructed C code in analysis/hyperhv.dll.c accurately represents the logic.
---
Why This Matters
DenuvOwO (the cracker group) claims to bypass Denuvo using this hypervisor.
They are running Ring -1 code on millions of users' machines.
That code contains critical security bugs that can be triggered from any process, without admin rights.
This is not about piracy - it's about poorly written security software becoming a danger to its own users.
## Final Notes
This analysis is based **solely** on the binaries extracted from a specific build of **Resident Evil: Requiem (2026)**.
The provided code and PoC have **not been tested** on other games, other versions of the DenuvOwO hypervisor, or other system configurations.
The vulnerabilities described here are **theoretical** - they exist in the code I analyzed, but I do not guarantee they are exploitable in all environments.
This is not a "crack" or a "bypass".
I did not attack Denuvo. I did not attack DenuvOwO.
I simply loaded a driver into Ghidra, read the disassembly, and documented what I found.
---