NOTE:

a. Normal font is the data collected from MKDEV Team Post and their last NFO.

b. Bold font is the simplified version.

Denuvo works by replacing the original instructions in game functions, morphing them in VM so the same instructions are executed in the end but in a "different form". And it makes a single value on "one" of the instructions in each function "calculation" dependent, basically encrypting a single value on one of the original instructions in the function. Calculation will only provide the correct value in each VM if the runtime hardware/OS environment checks "match" the values written to dwords in .exe before OEP. These dwords combine bytes both from the license and from hardware/environment checks run before OEP.

All 3 variables (License bytes, hw/env check results before OEP, Runtime hw/env checks that is executed on runtime in each VM with a "protected" function.) must be correct for the calculations to give the correct result in each VM. However, obviously there is still only one single correct calculation result as the original game instruction has to be executed before exiting the VM.These values for the original Denuvo game can be cracked by hard coding such values in the VM, thus executing the original instructions no matter the results of the hardware/env checks. Our method does exactly this instead of patching HW/Env checks.

**1. Denuvo’s Core Mechanism: Denuvo works by modifying the original instructions within a video game’s functions. These instructions are altered in a way that they are still executed but in a “different form.” This process is performed within a Virtual Machine (VM).

2. Encryption of a Single Value: Denuvo makes one specific value within one of the instructions in each function dependent on certain calculations. This effectively encrypts a portion of the original instruction.

3. Runtime Hardware and OS Checks: To ensure the game runs correctly, Denuvo checks whether the values within the VM match certain criteria set by the hardware and operating system environment. These checks are conducted before the game reaches its Original Entry Point (OEP).

4. Combining Values: Denuvo combines values from three sources: license bytes, hardware/environment checks performed before the OEP, and runtime hardware/environment checks executed within each VM while running a “protected” function.

5. Necessity of Correct Values: For Denuvo to function correctly, all three variables mentioned above (license bytes, pre-OEP hardware/environment checks, and runtime checks) must be accurate. The calculations will only yield the correct result within the VM if these values match the expected criteria.

6. Cracking Denuvo: The paragraph suggests that Denuvo can be bypassed by hard-coding values within the VM. This means that the original game instructions will be executed regardless of the results of hardware and environment checks. This method circumvents the need to patch the hardware and environment checks directly.**

In summary, Denuvo aims to protect games from piracy by encrypting and obfuscating key parts of the game’s code and verifying the integrity of the hardware and environment in which it is running. However, as the paragraph suggests, determined hackers have found ways to crack Denuvo by altering values within the VM to force the execution of the original game instructions.

Denuvo constants, so in VM this is now mov edx, [calculation result] literally everything else in this function untouched in VM even with a garbage license. If Denuvo tool picks an instruction in function that won't be executed due to previous conditional jumps, then the whole VM becomes useless and you can skip it, even with a garbage license you can run it fine. Loading up to OEP with invalid license and running through the VM's, makes the corrupt calculation results in VM obvious.

**1. Denuvo and Constants: Denuvo seems to rely on constants within the game code. In the context of the paragraph, these constants play a role in the calculations performed by Denuvo to validate the game’s authenticity.

2. Modification of Instructions in VM: Within the virtual machine (VM) used by Denuvo, certain instructions are modified. In this case, the instruction “mov edx, [calculation result]” is mentioned. This means that Denuvo alters the code in a way that it moves the value of “calculation result” into the EDX register.

3. Selective Modification: Importantly, not all instructions in the function are touched or altered within the VM. It appears that Denuvo selectively modifies specific instructions to achieve its anti-piracy goals while keeping the majority of the function’s code unchanged.

4. Conditional Jumps: Conditional jumps in code are used to control the flow of execution based on certain conditions. The paragraph suggests that if Denuvo picks an instruction within a function that won’t be executed due to previous conditional jumps, it renders the entire VM useless. In other words, if a particular instruction isn’t essential for the game’s execution, it may be skipped even with a corrupted or invalid license.

5. Detecting Corrupt Calculation Results: The paragraph implies that running the game with an invalid license and passing through the VMs can make corrupt calculation results within the VM apparent. This is likely one way that hackers and crackers can identify and exploit weaknesses in Denuvo’s protection.**

In summary, this paragraph provides insights into the intricacies of Denuvo’s protection mechanism, emphasizing the importance of constants, the selective modification of instructions within VMs, and the role of conditional jumps in the system’s security. It also hints at potential vulnerabilities in Denuvo’s protection if certain instructions can be skipped without affecting the game’s execution.

Thread safe patch that indicates a specific VM entry, required for patching inside the VM. As you can see our patch supplies the correct 11BC value. R12 has the calculation result and is corrupted with invalid license. "mov edx,11BC", this is the obfuscated version of it in VM, and R12 depends on calculation. 11BC (R12) is now in VM stack (rbx+D0) and will eventually become EDX, performing the original instruction.

**1. Thread-Safe Patch: The paragraph mentions a “thread-safe patch,” which is a modification made to a program or system that ensures it can be safely accessed and altered by multiple threads (parallel execution units) without causing conflicts or errors.

2. Specific VM Entry: The patch seems to target a particular entry point within a virtual machine (VM). This entry point is essential for making changes inside the VM, likely related to altering the program’s behavior or bypassing security measures.

3. Correct 11BC Value: The patch is designed to provide the correct value of 11BC. This value is essential for the operation of the program or VM.

4. R12 and Calculation Result: The paragraph mentions that R12 contains the calculation result but is corrupted due to an invalid license. This suggests that the patch aims to restore or provide the correct value for R12 within the VM.

5. “mov edx,11BC”: This line appears to represent an obfuscated version of an instruction. It indicates that the value 11BC is being moved into the EDX register. This is likely a critical instruction for the program’s operation.

6. VM Stack and Calculation: The paragraph states that 11BC (which is now in R12) is in the VM stack (rbx+D0) and will eventually become EDX. This implies that the patch ensures that the value in R12 (11BC) is correctly processed and used as EDX to execute the original instruction.**

In summary, this paragraph discusses a patching technique that involves restoring or providing a specific value (11BC) within a virtual machine (VM) to ensure the correct execution of a critical instruction (“mov edx,11BC”). This is done in a thread-safe manner and is likely related to bypassing security measures or modifying program behavior.

This is literally everything that Denuvo does, the rest is a clown show inside VM. Just be careful when the value that is encrypted is for "cmp" instructions or "imul", "shl" etc.

**1. Core Functionality: The paragraph asserts that the primary essence of Denuvo’s anti-piracy technology is encapsulated in the sentence, “This is literally everything that Denuvo does.” This suggests that the fundamental purpose or effectiveness of Denuvo revolves around a specific operation.

2. Clown Show Inside VM: The phrase “rest is a clown show inside VM” is a colloquial and somewhat dismissive way of describing other aspects of Denuvo’s operation within the virtual machine (VM). It implies that these additional elements or measures may not be as crucial or effective as the core functionality mentioned earlier.

3. Caution with Encrypted Values: The paragraph ends with a warning to exercise caution when the values being encrypted are related to certain instructions, such as “cmp” (compare), “imul” (integer multiplication), “shl” (shift left), and so on. This suggests that encryption involving these specific instructions may require special attention or considerations.**

In summary, this paragraph provides a concise perspective on Denuvo’s functionality, highlighting the significance of a particular aspect while implying that other elements within the VM may be less critical. It also advises caution when dealing with encrypted values related to certain types of instructions.

Sometimes the "9E0" in example original instruction "cmp eax, dword ptr ds:[rcx+0x9E0]" can be encrypted, or the "1" in cmp eax, 1 etc. The "18" in mov rax, [rcx+18], etc.

**1. Example Original Instruction: The paragraph provides an example of an original instruction: “cmp eax, dword ptr ds:[rcx+0x9E0].” This instruction likely involves comparing the value in the EAX register to a value stored at a specific memory address.

2. Encryption of Constants: The paragraph mentions that sometimes, constants within these instructions can be encrypted. In the example, “9E0” is highlighted as a value that could be encrypted. This implies that the value to be compared (in this case, “9E0”) may be obscured or hidden to make it more difficult for someone to understand or modify the instruction.

3. Encryption of Other Values: The paragraph also suggests that values like “1” in “cmp eax, 1” or “18” in “mov rax, [rcx+18]” can also be encrypted. This implies that not only memory addresses but also immediate values used in instructions can be subjected to encryption or obfuscation. ** In summary, this paragraph discusses how specific values within program instructions, including constants and immediate values, can be encrypted or hidden to enhance security or make it more challenging for reverse engineers or hackers to understand and modify the code.

TLDR: The first paragraph explains the technical workings of Denuvo, an anti-piracy technology used in video games. It mentions how Denuvo modifies game instructions within a virtual machine (VM) to ensure the correct execution of code. Denuvo encrypts specific values in game functions, and these values are dependent on various checks related to hardware, the operating system environment, and licensing. The paragraph also suggests that hackers can bypass Denuvo’s protection by manipulating values within the VM.

The second paragraph discusses a thread-safe patch designed to target a specific entry point within the VM. It aims to provide the correct value (11BC) for an instruction that is essential for the program’s operation. The paragraph mentions that R12 contains the calculation result and is corrupted due to an invalid license. The patch ensures that the value in R12 is correctly processed within the VM.

The third paragraph provides a brief summary of Denuvo’s core functionality, suggesting that its effectiveness revolves around a specific operation. It also dismisses other elements within the VM as a “clown show.” The paragraph ends with a caution regarding the encryption of values related to specific instructions, such as “cmp,” “imul,” and “shl.”

The fourth paragraph discusses how certain constants and values within program instructions can be encrypted or modified. It gives examples of instructions like “cmp eax, dword ptr ds:[rcx+0x9E0]” and mentions that values like “9E0,” “1,” and “18” can be encrypted or obfuscated.

In essence, these paragraphs collectively provide insights into Denuvo’s anti-piracy mechanism, thread-safe patching techniques, the core functionality of Denuvo, and the encryption of values within program instructions to enhance security or hinder reverse engineering.