Everything you were afraid to know about the latest method for bypassing DENUVO: how it works behind the scenes and how safe it is for your computer.
Disclaimer
The author of the article spoke directly with the developers of the DENUVO protection system. It is only because of his location that DENUVO’s management is unable to hold him accountable for disclosing sensitive information.
Analyzing a Denuvo bypass approach based on virtualization.
Hello everyone, since lately there has been a surge of hypervisor-based releases that aim to bypass Denuvoʼs DRM, I decided to make a write-up describing what this approach looks like and how it works from a technical perspective. This write-up is brought to you fully by Rose / Natasha 0x80000003
This article serves more or so to analyze this bypass approach and how to circumvent it on Denuvoʼs side.
Why this method was chosen
Why was this method chosen in the first place? The main reason is that it is a relatively low-effort way to get a protected title running without doing a full reverse engineering effort against the protection itself. It can be shipped quickly, which matters because early release timing can impact sales in the first week. But this comes at the price of bad performance, instability, security concerns and many other issues.
Introduction
In this write-up, we will analyze the main bypass dll from the recent Resident Evil: Requiem release on cs.rin.ru and go into details on how hypervisors such as HyperDBG can be used to spoof hardware values and in effect allow for a Denuvo DRM bypass.
Requirements and constraints
For this approach to work, core Windows kernel protections typically need to be weakened so an unsigned or non-standard kernel driver can be loaded. Commonly mentioned requirements in public releases include:
Disabling Driver Signature Enforcement DSE
Disabling PatchGuard
Disabling Windows Defender
Modification of the Windows Kernel
At this point disable windows just for the game to run XD
You can use EfiGuard (github)to make your whole system as insecure as possible.
Analyzing Resident Evil: Requiem Hypervisor dll
Initial load
In the sample shown here, amd_ags_x64.dll (dllfiles) is replaced with a patched proxy dll included in the release. The proxy dll then loads:
The main bypass dll
The original legitimate AMD GPU Services SDK dll 4, renamed as amd_ags_x64.org .
Since the bypass dll is set as a static PE import, it will be loaded automatically by the Windows loader without needing a separate injector.
Hypervisor back-end selection (Intel / AMD)
Once the main bypass dll is present, it selects the hypervisor back-end based on CPU vendor. The CPUID vendor string is read and a back-end is selected based on the vendor’s ID. In the sample:
"AuthenticAMD"→SimpleSvm.sys"GenuineIntel"→hyperkd.sys
Service creation and driver start
After selecting the driver, a service is created and started for that driver. Because hardware virtualization is typically exclusive, the logic often includes checks to ensure no other hypervisor is already occupying VT-x or AMD-V. If one is present, it may be stopped so the chosen driver can initialize. Some screenshots of this logic :
Resolving syscall numbers from ntdll
Syscall numbers are taken from ntdll.dll and are then used in other functions.
IAT hooking
IAT hooking is used to redirect selected imports in the game’s executable.
Hooked imports are: ntdll.dll, kernel32.dll, kernelbase.dll, user32.dll
With the IAT patched, calls that would normally go directly to these modules are routed through the bypass dll’s handlers.
License file / Token handling
Inside the main bypass dll, there are 2 different pre-generated tokens that are assigned depending on the host’s CPU architecture and the corresponding hypervisor (as shown below). These tokens are written to a .bin file on first launch and are then used by the hypervisor as Denuvo tokens.
Small Notes
Detanup01’s GBE fork was used to load the game and also emulate steam API services
HyperEvade was used to also further hide the hypervisor (I will talk about this more later)
The CPU brand string in the sample I analyzed is set to
DenuvOWO CPU @ 1337 GHz. XD
(I only included this to showcase that some info doesn’t have to be fully real and that environments can be modified to allow for custom values to be used in the hypervisor)
DenuvOWO CPU @ 1337 GHzLet’s dive more into the details!
HyperDBG is a very advanced debugger and thus I won’t analyze every part of it and more or so focus on the main part of hardware spoofing and how it can be done in the context of Denuvo. All the commands here can be used with HyperDBG’s scripting system for testing. A custom implementation can be done later to optimize this process for an actual bypass release.
Hardware Spoofing
SEE at FULL article at official CRACKLAB site:
https://cracklab.team/index.php?threads/1601/
Important Note
Denuvo checks for many other values in KUSER_SHARED_DATA , WinAPI and many other checks pre and post OEP. Want to find them ? Suit yourself and analyze the protection like a normal human being instead of trying to find “vulnerabilities” to bypass it. Though I’d like to say that all of Denuvo DRM checks can be bypassed this way (As of February 2026).
VMX-Hypervisor
There are also many MANY hypervisors that are available publicly on github, check out Marius’ hypervisors as a base:
These were used for some pretty cool shenanigans and are a very good base if you want to study hypervisors and maybe create your own
Finishing up
After we’re done, we can go ahead and generate the Denuvo token matching our CPU (if you have the CPU) or simply generate a new Denuvo token for these specific values in a VM or some kind of Hypervisor (figure it out yourself, there’s a million approaches for this). Though I would recommend that you generate it inside an environment with these values and then use the same values from the environment to avoid any problems with the bypass.
Detecting Hypervisor bypass attempts
Now let’s talk about Denuvo’s favorite part of this article. :3 The various techniques to detect hypervisor bypass attempts and patching such methods. To be honest, there isn’t much to do on user mode level (that I can talk about here / publicly), thus a custom driver would need to be implemented to add most of these checks. In this section I will discuss general techniques to detect hypervisors, I will later on explain why some stuff won’t work in the case of Denuvo.
EPT hook detection
Enforcing DSE on
Timing Checks
SEE at FULL article at official CRACKLAB site:
https://cracklab.team/index.php?threads/1601/
Explaining the current Denuvo situation
There are many checks that can be used to detect hypervisors, but the issue is most of them can be spoofed one way or another. Checks that must be used have to be very reliable and very hard to spoof. An obvious check is already implemented in the bypass dll itself.
Here the dll checks for the Microsoft Hyper-V interface signature using cpuid, and Denuvo could theoretically just start checking every cpuid value and using it for token generation, but that would just end up with another cat and mouse game where Denuvo adds more checks and hypervisor releases keep adding more spoofs which is not reliable at all as a long term solution for hypervisors.
Timing checks are unreliable and thus those also cannot be used.
The solution that Denuvo will use needs to be:
Reliable
Not so easy to bypass
Doesn’t affect performance
Doesn’t rely on a kernel driver
Doesn’t ruin the experience for people that actually bought the game
Overkill Approaches
SEE at FULL article at official CRACKLAB site:
https://cracklab.team/index.php?threads/1601/
Risks
“Bu-but what risks are there ?” Are we serious ?
Does executing kernel level code on your pc from a random guy on the internet sound like a good idea to you ?
If they (the people releasing these “cracks”) really wanted to, they can obfuscate the driver with the excuse of “hiding their techniques from Denuvo” and ship it with whatever they want. They already tell you to disable all security settings so it shouldn’t be hard for them to execute anything they want on your computers anyway. You can go ahead and keep trusting retards but don’t be surprised if greed blinds them one day and they decide to release a “crack” with info stealer code attached.
”But that’s the case with every software on the internet!”
Well, most software on the internet doesn’t require you to run it with higher permissions than your own administrator account, making this a special case scenario. Sadly this isn’t like the old scene where if your crack has the slightest bit of an issue it would get nuked to smithereens. These people couldn’t care less about their reputation because everyone can release these types of cracks, it’s just a time competition on who will release it first.
Overall, it’s really hard trying to convince anyone in the scene that it’s a bad idea to use any of these hypervisor releases, because frankly, they really don’t care. They don’t care if their data and personal information ends up on some random Chinese forum as long as they can enjoy their little game and shitpost about “finally beating Denuvo”.
Summary
When the game is ran, a custom bypass dll is loaded to attach a hypervisor layer that could be used to spoof various values that are checked by Denuvo, this implementation allows the user to run the game under an already generated token configured to the hypervisor environment.
Closing statement
From a purely technical standpoint, this is a pretty cool approach, but I personally don’t think any crack/bypass release of any game should contain code that requires kernel-level access and attaches itself to very low level layers just to operate, especially at the cost of performance and security concerns. Instead of wasting your time with this, study the protection and try to analyze it yourself from a research perspective.
Contact
@unpackme on Discord (official site), no other contact info will be provided unless personally given.
Big thanks to:
Marius - Analysis of Denuvo and helping with this article. (https://github.com/Nitr0G)
Eintim23 - Reviewing the article and suggesting ideas :) (https://eintim.dev/)
********* - Releasing the bypass for Resident Evil : Requiem
Momo5502 - EPT hooks detection analysis (https://github.com/momo5502/ept-hook-detection)
SinaKarvandi - Research on Hypervisors and Development of HyperDBG SinaKarvandi - Overview) (https://github.com/SinaKarvandi/Hypervisor-From-Scratch)
if you need more about Sony DADC AG SecuROM: