Had also a look at Denuvo a while ago. Used LLVM to remove the x86 obfuscation and broke it down to VM-Opcodes. Atleast back then, Denuvo seemd to translate gamecode into a stackmachine.
This is how a VM push looks like:
temp[0]=add(mem[e268], fffffffffffffff8)
mem[temp[0]]]=mem[e560]
mem[e268]=temp[0]
(vmreg_e268 is stackpointer, its decremented and stored in tempreg, then the value of vmreg_e560 is copied to stackpointeraddr, then new stackpointervalue is written back)But i quickly lost interest when it became MBA galore:
temp[7]=sub(add(add(and(mem[ebe8], b2f7), 3fd8), xor(lshr(mem[ebe8], 1), 2684)), lshr(add(mem[ebe8], b2f8), 1))
temp[d]=or(sub(sub(4ad, temp[7]), xor(and(shl(temp[7], 1), 95c), 95c)), 8000)
temp[e]=lshr(temp[d], 1)
temp[11]=lshr(add(temp[d], 8001), 1)
mem[ebe8]=sub(xor(xor(temp[e], 3fff), temp[11]), shl(and(and(temp[e], 3fff), temp[11]), 1))
(looks like its doing some operation with a constant to vmreg_ebe8, but obfuscated by MBAs and most likely the result won't ever being used, so its just noise to drown out the real operations)BTW: anyone aware of LLVM optimizer passimplementations that can deal with MBAs ?
It is clearly effective. Go to a PC game piracy site and most games will be available, but anything covered by Denuvo is unavailable even years later. Either nobody is willing to crack it (unlikely) or Denuvo have done an exceptional job.
years ago, a friend of mine built something functionally equivalent to Denuvo in his spare time over the span of a few years. I think his original idea was "DRM for the little guy", recognizing that indie games probably lose massive revenue from initial release piracy.
He had no idea how to sell it. After it sitting around for awhile, I tried pitching the technology to few friends in VC, who had absolutely no idea what I was talking about.
It bothered me for a long time to see such a culmination of talent and effort get 0 reward for it. I've wondered if such technology would be interesting to some large publisher to just buy outright, bringing their anti-piracy in-house rather than relying on Denuvo. Any ideas/help appreciated :)
Vote with your wallet and don't buy games with this junk.
Lets see Empress's analysis
Also unrelated, but seeing "A 2nd Year Computer Science Student" in the blog name was both breathtaking in a positive way, but also hurts a little. Kudos to the author, seriously.
Very interesting analysis and as someone who practiced reversing/cracking in my youth, it helps me to understand why Denuvo is so effective. I have, for awhile, had a policy that I will not buy any game with Denuvo, and I continue to stand by that policy. I only play games w/ Steam on Linux (Steam Deck or Framework 13 laptop) and Denuvo makes this impossible, so it's a hard no from me. But I respect the engineering they invested into this DRM.
I haven't pirated games since I was in highshool, but this nonsense has resulted in the worst UX for games I have paid for - with no recourse on my part. I guess it's like Cloudflare: some people have to suffer because other people don't behave nicely
I'm confused by calling the identifying information "stolen constants" or "stolen instructions". I don't understand why it's considered stolen. Do we mean "intercepted"?
What happened to the empress?
Is she (he?) still schizoposting via homophobic and transphobic .nfo files, combining super natural female moon goddess intuition with deep rooted cracking knowledge and has a growing telegram community full of G*mer simps?
For those not in the know, empress is/was THE famous denuvo cracker with a rather... eccentric online presentation of themself.
Buy from GoG and indies
Don't play AAA slop
ph34r!
op is top
Nothing a well-trained model won't be able to instantly solve. It's literally just grunt work, not rocket science.
F DRMs though. Good news is those AAA games are rarely worth anyone's time anyways. Better spin up indies or classic games - a good SNES game is worth a hundred of those garbo AAA license rehashes.
Game developers have Denuvo as an anti-piracy option. This is your choice for single player PC games.
There’s also multiplayer as anti piracy. It is impracticable to spoof unseen, complex server code forever.
Environment Integrity is the most flexible. That means you can’t pirate because you can’t sideload code that doesn’t belong to you, and that a remote license check cannot be spoofed. The environment also has to provide enough incremental value in updates that most people will keep auto-update on. Although, of course, Apple could force updates.
To me, the problem is how to avoid this conversation altogether. The kind of person who has the personality defect that makes him post rants about DRM doesn’t listen long enough to figure out “validity” in games.
Like imagine when people invoke that word, “valid.” This is what DRM is about to audiences, not technology. Video games are aesthetic experiences, you don’t have to play them to survive, to me it is valid to consider anything related to the game, like its DRM or the development team or whatever, as fair game for “valid.” But.
If you don’t think Denuvo is valid, you don’t think “AAA single player games on PC” is valid. And maybe that’s okay, maybe you can only go to iOS or the Switch or PS5 (Environment Integrity DRM) for AAA single player. There are no indie developers on consoles, so suddenly, you are also saying, “the only place for single player that costs money to make for self published is iOS.”
This is why I personally find the crusade against Denuvo so ironic: the people who could take the biggest creative risks and reap the most reward, including the right to keep making whatever it is they want, benefit the most from Denuvo.
What isn't mentioned in the article is why UD2 is chosen. It is a relic from the SecuROM days, in fact, one of the developers on SecuROM is the one who also works or worked at Denuvo.
I would imagine many things from the SecuROM era live on in Denuvo.
But if you read the article you will realize that certain games will not work in the future due to Denuvo.
"This destroyed any exception-based hooking since majority of the time an exception is triggered, Windows will write an EXCEPTION_RECORD high up in unused stack space. You can probably see where this is going. Now, whenever the CPUID is hooked via an exception, that important value will become overwritten with an EXCEPTION_RECORD, causing undefined behaviour later on. I believe this can be bypassed if you attach a debugger to the process and set certain flags when it comes to exception handling, but the method of patching every hardware check is still cumbersome due to randomness anyway."
As Windows matures, behaviour can change, breaking certain stuff.