TLDR: Hypervisor Bypass method is a way to play latest PC games for free by bypassing the Denuvo DRM. It is so good that games are getting pirated before they even release.
The downside in Windows was that it required disabling security features to work. But with Linux, it doesn’t require that works with security on.
You must log in or register to comment.
That’s pretty cool but the setup is too much for me. I’m on Bazzite so I can’t use a dkms module, otherwise I’d be willing to try it. Hopefully HV bypass games get’s cracked soon, specially Black Flag Resynced, I really want to play that, I loved the original back when it launched.
Bazzite is kinda ass if you actually want to own your system. Honestly I would move to some other distro if it’s not some gaming exclusive PC.
I disagree, it can do almost anything other distros can apart from a few stuff like this. Usually you have to do it in a different way, but still doable. The benefits of an Atomic distro far outweighs the cons for me, I don’t have to worry about manually updating, I can easily rollback if any issue arrives (right now I have to use an older version for example because kernel 6.19+ is crashing RDNA 1 all the time when gaming), among other stuff. My experience with other distros, including Arch-based ones has been far worse in one way or another.
Besides, you can spin up your own image if you want, some users do this, so while it is much more involved to do something like that, you can still have it fine tuned to your needs if you want it to.
I’m with you on this, there have only been two times in years that I have had any issues with not being able to run anything.
Right now with this, and a brand new Ragnarok Online server that insisted on trying to make an Appimage for Linux, only tested on Cachy, and didn’t bundle all the dependencies. I just used Proton instead.
It’s usually jank stuff 99% of people won’t be doing or should be done a different way anyway.
I really wouldn’t do this stuff on a PC that isn’t exclusive for Gaming
immutable seems fine for like 90% of use cases idk. i don’t use it myself but totally get the appeal
deleted by creator
It’s not that easy because Bazzite is based an actual Fedora Atomic image, rather than a locked down Debian/Arch install. You can still easily install programs by layering them, but dkms modules and stuff need you to use their tools to copy the Bazzite image, add/remove whatever you want, then bake it all in again. They have guides to do this and it’s easy enough, but not necessary for most people and is definitely more effort than most people will go through for this kind of thing.
yessssssssssss
how do we use it?
Here is the actual thread on cs.rin.ru with instructions. Takes quite a bit of setup.
Implying there are any games that use Denuvo I would want to play
Jk
its good for folks who need it
I have the same problem. There aren’t sny denuvo games that I really want to play. There was that Digimon game but they dropped denuvo for it like two days ago.
Can someone explain to me why its possible to have HV run on Linux without disabling all those security features?
They explain it on cs.rin. i have copy pasted the explanation below:
Windows uses the hypervisor to do the following things:
- Intercept CPUID instructions to spoof CPU information and accept information from the crack
- Overwrite KUSER_SHARED_DATA (Read-only memory mapped into each process about the hardware and Windows install)
- Hook into every syscall by overwriting the LSTAR MSR pointing to its syscall hook (essentially overwriting the Windows syscall handling routine with a hook in the hypervisor)
- Intercept SGDT instructions to return a GDT Limit of 0x7F
CPUID, KUSER_SHARED_DATA and GDT Limit are all used by Denuvo to generate the token. Additionally, it runs the NtQuerySystemInformation syscall to get further information that will be used for token generation. The syscallhook reroutes syscalls to the crack (the DenuvOwO.dll, Reflex.dll, version.dll, winmm.dll and others) to take over and return spoofed data.
On Linux, the same problems are tackled in different ways: CPUID is intercepted via a CPU feature called cpuid_fault. If both the CPU and kernel support this feature, it can be enabled for that process and its children via a syscall. Consecutive CPUID instructions will then cause a segmentation fault. These can then be handled in the SIGSEGV handler the same way the hypervisor handles it on windows, except in userspace. As for CPUs that don’t natively support cpuid_fault, the hypervisor reimplements the same interface cpuid_fault has and throws a fault on cpuid instructions the same way native hardware would, so the same syscall to enable it is used. There is really nothing DenuvOwO-bypass specific about it, it literally just reimplements cpuid_fault.
KUSER_SHARED_DATA is neither mapped into processes by the kernel, nor is it read only. We can just write to it. So could a .exe or .dll for that matter. So we just write the same data the Windows hypervisor does into this memory region.
As for syscalls, Windows syscalls don’t mean a thing to the Linux kernel, so handling these syscalls in userspace is already a solved issue. Syscall User Dispatch is a Linux feature that allows processes to have syscalls cause SIGSYS signals. This was implemented so wine itself could support Windows syscalls. As a result, the way we hook into these is to simply write the same syscall hook from the Windows hypervisor into the SIGSYS handler of Wine.
Unfortunately, there is no way on Linux to intercept and emulate SGDT instructions from userspace. This is actually exactly what UMIP is for, UMIP stops on SGDT instructions being executed in userspace and causes a general protection fault (essentially a segmentation fault). So while this sounds like cpuid_fault, the difference is that the Linux kernel doesn’t allow us to handle this in the form of a signal in userspace, the kernel just emulates it with its own made up values (a GDT Limit of 0, instead of 0x7F) :( Essentially, the way to fix this would be to modify the fake values in the kernel and recompile the kernel, or infiltrate the Linux Kernel Mailing List to make the GDT Limit in the UMIP path configurable. But as it turns out, when you disable UMIP and let the CPU run the real SGDT instruction, the real GDT Limit is always 0x7F! We got really lucky here. By the way, if you want to go the custom kernel route without disabling UMIP, the relevant variable is in the Linux source file arch/x86/kernel/umip.c#L232. Set the dummy_limit variable to 0x7F and you’re good to go.
Apart from not needing a hypervisor in most cases there is also another benefit with this; every part of this, apart from disabling UMIP, is limited to the Wine/game process by design. cpuid_fault can only be enabled by a process for itself, there is no risk that CPUID will be spoofed for a different process. Same with Syscall User Dispatch, it is only enabled for the game process, no other syscalls get intercepted. KUSER_SHARED_DATA is inherently a Windows data structure, no other process uses it or even has access to it.
Another benefit of being self contained like this is that it shouldn’t be an issue to have multiple different bypass games running at the same time on Linux. On Windows, the hypervisor can only store one TargetSysHandler (memory address in the crack where syscalls are handled). These will likely differ between two games, so you wont be able to run more than one game at a time on windows.
They have a write up about that on the post.
https://cs.rin.ru/forum/viewtopic.php?f=10&t=159989
It depends on how the CPU handles instructions and turning one setting off in BIOS sends the value required to initiate the bypass. In windows you have to hijack CPU requests and modify them.
