Change Language 
╭∩╮ (◜◡◝)╭∩╮ The idea behind the hypervisor solution is that it solves checks that are very hard to patch via other methods, whether due to code path randomization by Denuvo, self-modifying code or integrity checks. Patched checks are listed below. It is assumed that when these are taken out of the equation, P2P will be able to deal with rest of the environmental checks listed at the end of the .txt since they are much harder to protect. Refer to the hypervisor source code (A modified version of SimpleSvm) and the Resources section at the bottom of this .txt for more details. The code was made for a PoC and is messy. We hope people will take this up, improve the method, and bring back day 0 releases. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ [SGDT] SGDT instruction has a dedicated intercept available for virtualized guests. CR4.UMIP is disabled for easier interception. CR4 reads and writes are intercepted to mask this change from Windows PatchGuard. The guest GdtrBase and GdtrLimit are changed to a fixed value when this instruction intercept hits in the target game process, interrupts are disabled, trap flag is set and the GDTR values are corrected before the next instruction is executed. #PF, #AC and #SS exceptions which are possible to encounter during a SGDT instruction are intercepted when GDTR is loaded with spoofed values since it can lead to a triple fault otherwise. Please note that this is only done to avoid decoding the instruction, and a different method where the instruction is decoded is available in NoirVisor. SIDT, SLDT and STR instructions also have dedicated intercepts if needed. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ [CPUID] CPUID instruction has a dedicated intercept available for virtualized guests. For leaf 0x1, 0x80000002, 0x80000003 and 0x80000004, the hypervisor uses the values from the PC that generated the license for the results of this instruction when executed in the target game process. (CR3 check) Spoofing is further limited to Denuvo section in the file by checking the RIP, however this is not necessary and can lead to missed checks since Denuvo could execute CPUID outside of its region. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ [SYSCALL] LSTAR for the virtualized guest is redirected to our hook which checks if the CR3 is matching the target process, RIP that executed the instruction, the value in EAX for the syscall and the SYSTEM_INFORMATION_CLASS. If the SYSCALL results don't need to be spoofed depending on those checks, the hook jumps to the original OS LSTAR. If spoofing is required, we move the NRIP from RCX to RAX, and move RCX to the address of our syscall handler in the patched game process, and then do a 64-bit SYSRET. Note that RCX needs to be corrected to hold NRIP before jumping back the NRIP or the hook might be revealed. RIP check for limiting the spoofing to the Denuvo section is not required. Necessary code to avoid PatchGuard detection on AMD processors is included in the source, tested on Win11 24H2 build 26100.3037 with a Zen 3 CPU. Please note that the introduction of FRED for x86 may require adjustments to the code, and Windows PatchGuard may have more detection methods in the future to prevent hooks, however none of these developments would be fundamental barriers since in the end the OS provides the results of this instruction which can always be patched, and not the CPU directly. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ [KUSER_SHARED_DATA] PFN for the target game process KUSER page is replaced with one for a sharable PE section which holds the KUSER from the PC that generated the license. Dynamic fields in that section are then continually updated either by the hypervisor driver (HyperHide has such implementation) or the patched game process. Search for KUSER_SPOOF in the source for more details. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ [XGETBV] Not all x86 processors support the XGETBV instruction and this is indicated in CPUID.01H:ECX.XSAVE[bit 26] Denuvo does not execute this instruction if the XSAVE bit is 0 since it could result in a #UD exception for a very old CPU. Hypervisor provides the CPUID results so that the bit is 0, hence the check is patched. In case the CPUID bit is ignored by Denuvo, the instruction has limited potential values, since the result depends on the XCR register, which is based on the feature set of the CPU. Licenses can be requsted for all few potential results, which is another way of patching the check. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ [Floating point inaccuracies between AMD/Intel or different CPU generations and instructions with undefined flag states] If Denuvo make use of such differences, new licenses can be generated on different CPUs to solve these checks. Note that this is not a case where every CPU will provide a different result, rather it depends on the architecture, hence once again quite limited number of possibilities. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ [Checks that are not patched by the Hypervisor] NTDLL checks such as Image Data Directory, Import RVAs GetVolumeInformationW GetWindowsDirectoryW GetComputerNameW GetUsernameW CryptGetProvParam - to get CryptoAPI CSP UniqueKeyContainer which change based on OS version and MachineGuid PEB +118, 11C, 12C, 130, B8 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Resources: AMD64 Architecture Programmer's Manual, Volumes 1-5: https://docs.amd.com/v/u/en-US/40332-PUB_4.08 Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4: https://cdrdv2-public.intel.com/868137/325462-089-sdm-vol-1-2abcd-3abcd-4.pdf NoirVisor: https://github.com/Zero-Tang/NoirVisor HyperHide: https://github.com/Air14/HyperHide SimpleSvm: https://github.com/tandasat/SimpleSvm Denuvo Analysis: https://connorjaydunn.github.io/blog/posts/denuvo-analysis
User User 
Batman 
Dafür ist ja xREL da. Wenn es nicht passt, wird es schon gelöscht 
Hast du das verstanden? Ja! | Nein!
#