The Denuvo DRM Thread

[Grauken]

DRM-decisions are often made at a very high management level by people who force it down as company-policy more on a philosophical base (and their own lack of knowledge of the realities of the market they operate in on a nitty-gritty level) than any real numbers, so this doesn't mean Denuvo is dead

 

[Astral Rag]

Really good analysis

I still can't get over how horrible the new F1 cars look.

 

[InD_ImaginE]

I mean in case of Rage 2 and DMC5 some incompetent hacks somehow let the free of Denuvo .exe lying around so their case don't really say much about Denuvo protection capability.

As mentioned in the article Anno 1800 has yet to be cracked. And really the scene is all about dick measuring contest so it is questionable that a game has yet to be cracked in a month, most likely means that Denuvo do actually protect stuffs from being cracked. After all Denuvo and the scene is playing whack a mole with each new Denuvo versions, with Denuvo patching shit up and the scene trying to find new exploit/find new trigger added in new version of Denuvo.

 

[cvv]

I mean in case of Rage 2 and DMC5 some incompetent hacks somehow let the free of Denuvo .exe lying around so their case don't really say much about Denuvo protection capability.

Link?

 

[InD_ImaginE]

I mean in case of Rage 2 and DMC5 some incompetent hacks somehow let the free of Denuvo .exe lying around so their case don't really say much about Denuvo protection capability.

Link?

To what? The Denuvo free .exe? They are in the scene release for both. I don't really know people who uploaded only the exe.

If you means source, I also monitored these shit from 2nd and 3rd hand account from reddit and a local forum. Probably some people in cs rin ru finding these shits.

 

[Perkel]

I did leave a comment, but I'll reiterate here.
The framerate benchmarks unfortunately don't really show anything of much value, and the minimum framerates are kind of worthless because variables like the shader cache(*) isn't controlled for.
This is why most techtubers will use 1% and 0.1% minimum framerates rather than the absolute minimum, so that they don't have to control for that stuff.
I get the impression he ran the benchmarks with denuvo, then non-denuvo; as he responded to me, he did the denuvo ones, rebooted, then non-denuvo.

Sounds like bunch of excuses. As matter of fact those differences exist.
Secondly you falsely say that just because it is CPU check it will not impact framerate as long as there is enough juice to run game.

Whole nature of Denuvo is to recheck constantly which means it introduces delay into pipeline which needs to be resolved before next frame can be drawn. Ergo it completely explains why non denuvo exe doesn't have those stalls and shitty minimum framerates.

This is similar thing to draw call issues with cpu-gpu on PC. On face value draw calls don't have anything to do with framerate or GPU but because CPU can't handle properly them they stall whole pipeline even if you have enough Mhz and multiple cores free.

It would be one thing to claim this when you didn't have ample evidence but you have now multiple videos confirming it while there are no videos disproving this.

 

[Hirato]

I did leave a comment, but I'll reiterate here.
The framerate benchmarks unfortunately don't really show anything of much value, and the minimum framerates are kind of worthless because variables like the shader cache(*) isn't controlled for.
This is why most techtubers will use 1% and 0.1% minimum framerates rather than the absolute minimum, so that they don't have to control for that stuff.
I get the impression he ran the benchmarks with denuvo, then non-denuvo; as he responded to me, he did the denuvo ones, rebooted, then non-denuvo.

Sounds like bunch of excuses. As matter of fact those differences exist.
Secondly you falsely say that just because it is CPU check it will not impact framerate as long as there is enough juice to run game.

Whole nature of Denuvo is to recheck constantly which means it introduces delay into pipeline which needs to be resolved before next frame can be drawn. Ergo it completely explains why non denuvo exe doesn't have those stalls and shitty minimum framerates.

This is similar thing to draw call issues with cpu-gpu on PC. On face value draw calls don't have anything to do with framerate or GPU but because CPU can't handle properly them they stall whole pipeline even if you have enough Mhz and multiple cores free.

It would be one thing to claim this when you didn't have ample evidence but you have now multiple videos confirming it while there are no videos disproving this.

I can tell reading comprehension isn't your strong suit.
I clearly laid out my case, of what he did wrong (tracking GPU utilisation when he should've tracked CPU utilisation), what Denuvo is known to do (bloat exes, kill performance CPU side), and what he should've done (tracked CPU usage).


Do you understand what the shader cache does?
Have you ever tried one of those fancy new emulators that generate thousands of shaders?
Ever notice how they take about 10 minutes to build the bloody things during the first run after updating your driver?
And launch almost instantly in subsequent runs?

That's the shader cache at work.
He ran the denuvo version before the non-denuvo one - doesn't matter if he rebooted - as such the non-denuvo one gets to reuse the shaders from the denuvo version (because they're the same), granting it far higher absolute minimums.
That's because retrieving it from the cache is super cheap (e.g. 0.01s each) versus stalling the pipeline and compiling it (e.g. 1s each).
This is why I made the point about 0.1% and 1% minimum framerates being the standard among tech-youtubers.



We all here agree that Denuvo is fucking aids.
I just take umbridge with the fact that he did a piss poor job demonstrating the primary impact, because frankly, his video made denuvo look "not that bad."
Probably doesn't help that he was encoding/saving the video on the computer he was doing the benchmarks on too, as that adds significant CPU and GPU overhead.

 

[zwanzig_zwoelf]

[...] so this doesn't mean Denuvo is dead

Fine by me, Denuvo is doing wonders for my desire to join ISIS.

FTFY

 

[deama]

I did leave a comment, but I'll reiterate here.
The framerate benchmarks unfortunately don't really show anything of much value, and the minimum framerates are kind of worthless because variables like the shader cache(*) isn't controlled for.
This is why most techtubers will use 1% and 0.1% minimum framerates rather than the absolute minimum, so that they don't have to control for that stuff.
I get the impression he ran the benchmarks with denuvo, then non-denuvo; as he responded to me, he did the denuvo ones, rebooted, then non-denuvo.

Sounds like bunch of excuses. As matter of fact those differences exist.
Secondly you falsely say that just because it is CPU check it will not impact framerate as long as there is enough juice to run game.

Whole nature of Denuvo is to recheck constantly which means it introduces delay into pipeline which needs to be resolved before next frame can be drawn. Ergo it completely explains why non denuvo exe doesn't have those stalls and shitty minimum framerates.

This is similar thing to draw call issues with cpu-gpu on PC. On face value draw calls don't have anything to do with framerate or GPU but because CPU can't handle properly them they stall whole pipeline even if you have enough Mhz and multiple cores free.

It would be one thing to claim this when you didn't have ample evidence but you have now multiple videos confirming it while there are no videos disproving this.

I can tell reading comprehension isn't your strong suit.
I clearly laid out my case, of what he did wrong (tracking GPU utilisation when he should've tracked CPU utilisation), what Denuvo is known to do (bloat exes, kill performance CPU side), and what he should've done (tracked CPU usage).


Do you understand what the shader cache does?
Have you ever tried one of those fancy new emulators that generate thousands of shaders?
Ever notice how they take about 10 minutes to build the bloody things during the first run after updating your driver?
And launch almost instantly in subsequent runs?

That's the shader cache at work.
He ran the denuvo version before the non-denuvo one - doesn't matter if he rebooted - as such the non-denuvo one gets to reuse the shaders from the denuvo version (because they're the same), granting it far higher absolute minimums.
That's because retrieving it from the cache is super cheap (e.g. 0.01s each) versus stalling the pipeline and compiling it (e.g. 1s each).
This is why I made the point about 0.1% and 1% minimum framerates being the standard among tech-youtubers.



We all here agree that Denuvo is fucking aids.
I just take umbridge with the fact that he did a piss poor job demonstrating the primary impact, because frankly, his video made denuvo look "not that bad."
Probably doesn't help that he was encoding/saving the video on the computer he was doing the benchmarks on too, as that adds significant CPU and GPU overhead.

It doesn't work this way because the 2 versions are viewed seperately in the eyes of the OS. If you're talking about the CPU layered caches, maybe, but those are like what, 100MBs? They usually get cleared after shutting the game down. Besides, the different .exe versions contain extra instructions that will have to be added to the cache if they weren't there already, and this is ignoring the potentialy different compilations on the different .exes because e.g one could use the xmm instruciton set instead of the FPU etc...

 

[Perkel]

I can tell reading comprehension isn't your strong suit.
I clearly laid out my case, of what he did wrong (tracking GPU utilisation when he should've tracked CPU utilisation), what Denuvo is known to do (bloat exes, kill performance CPU side), and what he should've done (tracked CPU usage).


Do you understand what the shader cache does?
Have you ever tried one of those fancy new emulators that generate thousands of shaders?
Ever notice how they take about 10 minutes to build the bloody things during the first run after updating your driver?
And launch almost instantly in subsequent runs?

That's the shader cache at work.
He ran the denuvo version before the non-denuvo one - doesn't matter if he rebooted - as such the non-denuvo one gets to reuse the shaders from the denuvo version (because they're the same), granting it far higher absolute minimums.
That's because retrieving it from the cache is super cheap (e.g. 0.01s each) versus stalling the pipeline and compiling it (e.g. 1s each).
This is why I made the point about 0.1% and 1% minimum framerates being the standard among tech-youtubers.

We all here agree that Denuvo is fucking aids.
I just take umbridge with the fact that he did a piss poor job demonstrating the primary impact, because frankly, his video made denuvo look "not that bad."
Probably doesn't help that he was encoding/saving the video on the computer he was doing the benchmarks on too, as that adds significant CPU and GPU overhead.

You might have right to argue that if you didn't have actual proof before your eyes. It doesn't matter what kind of arguments you put forward when you have absolute data before your eyes when you can compare direct results.

Secondly your argument for cache only works when you have game running once. If you watch video he often run games MULTIPLE times each including denovo ones. Which renders your whole point about shader cache pointless, secondly even if we would agree on that point you still have averages which are also different which can't be explained with shader cashe. Loading times also are noticeably longer which is not illogical considering natures of this DRM and that data stalls are exactly reason for shitty minimums as DRM protection wants to validate data moving through pipeline which also incurs penalty on average frame-rate itself much like draw calls do when GPU sends a lot of them to CPU regardless of CPU juice i mentioned before.

So he did not do "piss poor job".

 

[DalekFlay]

I mean in case of Rage 2 and DMC5 some incompetent hacks somehow let the free of Denuvo .exe lying around so their case don't really say much about Denuvo protection capability.

Link?

The Bethesda store version of Rage 2 does not have Denuvo, that's confirmed by people who bought it there. People suspect it's because review copies were through Steam, so it was all about preventing pre-release leaks.

 

[Goi~Yaas~Dinn]

I mean in case of Rage 2 and DMC5 some incompetent hacks somehow let the free of Denuvo .exe lying around so their case don't really say much about Denuvo protection capability.

As mentioned in the article Anno 1800 has yet to be cracked. And really the scene is all about dick measuring contest so it is questionable that a game has yet to be cracked in a month, most likely means that Denuvo do actually protect stuffs from being cracked. After all Denuvo and the scene is playing whack a mole with each new Denuvo versions, with Denuvo patching shit up and the scene trying to find new exploit/find new trigger added in new version of Denuvo.

When you basically brag to the entire world about how "badass" your shiny new DRM is (at one point I seem to recall they even used the magic words for throwing down the gauntlet, calling it "unbreakable") it's pretty much inevitable how things are going to play out. They are not going to win this. Moving the goalposts can only be done so many times before even the clueless MBA types catch on to what you're doing (because they're all too familiar with the tactic themselves).

These assholes are guilty of hubris (as used in the ancient Greek sense).

 

[DalekFlay]

It's all going to be moot eventually anyway because publishers will be making almost 100% online games and indies release on GOG already anyway.

 

[Anthedon]

It's all going to be moot eventually anyway because publishers will be making almost 100% online games and indies release on GOG already anyway.

Except for Grimoire.

 

[abija]

The Bethesda store version of Rage 2 does not have Denuvo, that's confirmed by people who bought it there. People suspect it's because review copies were through Steam, so it was all about preventing pre-release leaks.

Why suspect that if there wasn't a quick steam patch to remove it after release?

 

[cvv]

I mean buying the Denuvo protection (not exactly a cheap deal for a major triple A game I heard) for just one version of your game and not for others is about the dumbest business decision I've heard about in a while.

 

[Goi~Yaas~Dinn]

I mean buying the Denuvo protection (not exactly a cheap deal for a major triple A game I heard) for just one version of your game and not for others is about the dumbest business decision I've heard about in a while.

We've already established we're not dealing with smart people. Just greedy.

 

[Hirato]

It doesn't work this way because the 2 versions are viewed seperately in the eyes of the OS. If you're talking about the CPU layered caches, maybe, but those are like what, 100MBs? They usually get cleared after shutting the game down. Besides, the different .exe versions contain extra instructions that will have to be added to the cache if they weren't there already, and this is ignoring the potentialy different compilations on the different .exes because e.g one could use the xmm instruciton set instead of the FPU etc...

I'm talking about the driver level shader cache.
It's an on-disc cache that has the shader itself, the compiled shader, and some metadata about the shader (e.g. what uniforms were defined, the pipeline used - that kind of thing).
For example, nvidia on windows stores its cache at C:\ProgramData\NVIDIA Corporation\NV_Cache.
As I already explained twice, this cache is generally only cleared or invalidated when the driver version changes.

I'm not an expert on the implementation, but generally it will build a checksum based on the shader itself (i.e. the hlsl program) and some metadata (i.e. is it for DX9? 11? is it using SM 3? 4? etc).
And when a program, any program, requests the driver compile a specific shader, it will check this cache for an existing object, compare the shader and metadata, and on a match, it will just reuse the object it compiled previously instead of doing the lexing and assorted expensive optimisation passes again.
There is no discrimination done on the origin of the compilation request.

Windows' own caching stuff is completely separate, the executables are a non-issue here; The denuvo one is filled with crap that bloats the executable by about 300-400MB, so they have nothing in common and its wasting memory already, and as a consequence thrashes L1/2/3 caches on the CPU
Also by pure virtue of being different files, windows won't share any memory between the two EXEs anyway, even if they were somehow identical or shared identical sections.

You might have right to argue that if you didn't have actual proof before your eyes. It doesn't matter what kind of arguments you put forward when you have absolute data before your eyes when you can compare direct results.

Secondly your argument for cache only works when you have game running once. If you watch video he often run games MULTIPLE times each including denovo ones. Which renders your whole point about shader cache pointless

According to his own response to me:

"then tested in order of denuvo -> non-denuvo -> denuvo ->non-denuvo," This is not how I did it. The system was restarted between the two versions.

Does that sound like he did multiple runs for the framerate benchmarks? Because to me it bloody doesn't; it sounds like he did denuvo -> reboot -> non-denuvo.

even if we would agree on that point you still have averages which are also different which can't be explained with shader cashe. Loading times also are noticeably longer which is not illogical considering natures of this DRM

Oh gee, I wonder what I said about those.

2. Blocking synchronous checks
This can cause stalls, in particular causes a ~20s or so stall during first run before the game will even initialise.
As you can see later on his screen, his CPU didn't even clock up from 800MHz until denuvo validated and the game finally commenced loading.

The loading times are still useful statistics, as that's almost pure CPU, and shows improvements between 10-30%.

Gosh, it almost sounds like we're arguing over nothing.

data stalls are exactly reason for shitty minimums as DRM protection wants to validate data moving through pipeline which also incurs penalty on average frame-rate itself much like draw calls do when GPU sends a lot of them to CPU regardless of CPU juice i mentioned before.

Do you have a source that explains what kind of validation Denuvo actually does? I'd be quite curious to see it.

Also, if he didn't do multiple runs for the levels (which is strongly implied by his response), the cases where there's massive differences (e.g. ~5 vs 60), it can easily be explained away as stuttering from shader compilation, which is why absolute minimums are stupid if you don't control for this - as I've mentioned twice now, others use an average of the 1% or 0.1% slowest frames precisely because of this.

When both of them had their resources loaded, the result looked like this:

Compare the load time impact of 10-30%, would you not expect a similar discrepancy here? At least between the maximums?
This is practically margin of error! plus we also have no context on CPU usage before and after to compare!
This was the utter majority of his video, and it is why I'm saying his benchmarks showing framerates and frametimes exclusively are for all practical intents and purposes: utterly useless.

So he did not do "piss poor job".

No mate, he absolutely did a piss poor job demonstrating the primary impact of Denuvo.
He did a fine job demonstrating secondary impacts such the significantly longer loading times.
But that's it.
Full stop.

 

[Perkel]

I'm talking about the driver level shader cache.
It's an on-disc cache that has the shader itself, the compiled shader, and some metadata about the shader (e.g. what uniforms were defined, the pipeline used - that kind of thing).
For example, nvidia on windows stores its cache at C:\ProgramData\NVIDIA Corporation\NV_Cache.
As I already explained twice, this cache is generally only cleared or invalidated when the driver version changes.

You do understand that he runs every game multiple times ? You do understand that this completely erases your whole point ?

Does that sound like he did multiple runs for the framerate benchmarks? Because to me it bloody doesn't; it sounds like he did denuvo -> reboot -> non-denuvo.

"Sounds" aka you assume he did poor job because you have nail in your ass for some reason.
Why you insist that when you can see from his video that 1) he talks about running games multiple times, 2) you can see that clearly when he test games for loading times where you have scores for 1st 2nd and sometimes 3rd run much like you test Hybrid drives.

Do you have a source that explains what kind of validation Denuvo actually does? I'd be quite curious to see it.

Voksi (who was one of key people cracking denuvo games) multiple times talked about what denuvo precisely does.
It depends from game to game and denuvo version but most of the time it flies thousands of calls to check various files in pipeline.
In case of few games it flies 100s of thousands calls which tanked completely performance (RIME case)

You don't need to even coder to understand that if you check files on the fly pipeline will have to wait for that check to complete which produces stall regardless if you have CPU performance or not. Because every check is additional wait time on top of original work which MUST produce lower framerates.

Which is why i used draw calls comparison. In theory CPUs should be able to run milions of drawcalls easy in practice most of modern games dispatch few thousands and those best CPUs even with plenty of juice left can't manage them which caused huge shift years ago where those drawcalls started to get packed into batches.

The whole DX12 and Vulcan API stuff was specifically to address that problem and the biggest advantage they give was removal of this barrier that didn't exist in consoles and developers craved on PC.

No mate, he absolutely did a piss poor job demonstrating the primary impact of Denuvo.
He did a fine job demonstrating secondary impacts such the significantly longer loading times.
But that's it.
Full stop.

Primary impact of denuvo are framerates and he clearly have shown difference there. Both minimums, maximums and averages are most of the time different. It is like watching someone red car and you argue that this is actually green car.

 

[DalekFlay]

Why suspect that if there wasn't a quick steam patch to remove it after release?

I don't think that says much either way as there would surely be a contract for length of time used. Dishonored 2 had it patched out eventually, but I'm guessing there was a time limit on how soon they could do it. We're all just guessing though, yes. However I find the "Bethesda forgot to put Denuvo on their own version!!!" theory much more silly.

 

[DalekFlay]

Rage 2 just got Denuvo removed on Steam, so yeah it was just for review copies.

 

[karoliner]

Total War Chinkdoms is cracked now.

 

[DemonKing]

Total War Chinkdoms is cracked now.

https://www.dsogaming.com/news/the-...anti-tamper-tech-denuvo-6-0-has-been-cracked/

 

[Cyberarmy]

What about Octopath?

 

[Black Plague]

What about Octopath?

Now is the time.