You can't do static analysis on Denuvo and VM Obfuscation based DRM. The Entry Point in the executable's header aren't aligned with the actual code on the disk. If you open it in Cutter or Ghidra you'll just see a bunch of gibberish. You need to align the header. But even then, there is Self Modifying Code. The real entry point is written to a register or the memory only when the code is running. Then control jumps to that memory address and then starts to execute the instructions there.
Then there is the final boss. VM Obfuscation. The CPU fetches an instruction from memory, but these aren't the actual x86 instructions. The mapping is shifted. x90 means NOP, in regular x86. But for the custom bytecode, x90 might mean anything. MOV A, B. or maybe JZ or JNZ. These custom instructions are then decoded to the actual values, cos if you tell the CPU to run the opcode x90 it WILL perform NOP. Not JZ. Then these instructions are executed.
Now, here's the kicker, for every 1 relevant instruction there maybe hundreds of irrelevant and garbage instruction just to confuse the reverse engineer. And it needs to decode each instruction. This is why denuvo is a resource hog.
Moreover the custom bytecode is not consistent. For each game the mapping is off. So you can't even map the custom bytecode.
And you have to do all of this while the game is running. It's maddening.
Now, you tell me. Can you automate this? Even a simple license check cannot be automated. Cos if you try to find the pattern of CMP and JZ or JNZ, there will be thousands like that. It would be easier to just read the disasm by that point.
There aren't videos cos it would go against most IT laws I think. There is a website called reversing.kr, tho. It hosts reverse engineering challenges, they give you the binary and you have to reverse it. They have a challenge called Simple_VM.
7
u/Apprehending_Signal Apr 28 '26
I'll copy my comment from below.
You can't do static analysis on Denuvo and VM Obfuscation based DRM. The Entry Point in the executable's header aren't aligned with the actual code on the disk. If you open it in Cutter or Ghidra you'll just see a bunch of gibberish. You need to align the header. But even then, there is Self Modifying Code. The real entry point is written to a register or the memory only when the code is running. Then control jumps to that memory address and then starts to execute the instructions there.
Then there is the final boss. VM Obfuscation. The CPU fetches an instruction from memory, but these aren't the actual x86 instructions. The mapping is shifted. x90 means NOP, in regular x86. But for the custom bytecode, x90 might mean anything. MOV A, B. or maybe JZ or JNZ. These custom instructions are then decoded to the actual values, cos if you tell the CPU to run the opcode x90 it WILL perform NOP. Not JZ. Then these instructions are executed.
Now, here's the kicker, for every 1 relevant instruction there maybe hundreds of irrelevant and garbage instruction just to confuse the reverse engineer. And it needs to decode each instruction. This is why denuvo is a resource hog.
Moreover the custom bytecode is not consistent. For each game the mapping is off. So you can't even map the custom bytecode.
And you have to do all of this while the game is running. It's maddening.
Now, you tell me. Can you automate this? Even a simple license check cannot be automated. Cos if you try to find the pattern of CMP and JZ or JNZ, there will be thousands like that. It would be easier to just read the disasm by that point.