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.

    • loathsome dongeater@lemmygrad.mlEnglish
      6·
      17 days ago

      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.