The Denuvo DRM Thread

[fantadomat]

It means using a crack objectively gives you a better product, therefore the DRM is anti-consumer.

Problem is that in most cases Denuvo isn't removed from the executable when a game is "cracked", it's merely bypassed. The shitware will still be consuming resources behind the scenes.

True,but it doesn't necessarily consume as much as uncracked. Also i games that removed their denuvo shit run better than their version with it.

 

[Cael]

It means using a crack objectively gives you a better product, therefore the DRM is anti-consumer.

Problem is that in most cases Denuvo isn't removed from the executable when a game is "cracked", it's merely bypassed. The shitware will still be consuming resources behind the scenes.

True,but it doesn't necessarily consume as much as uncracked. Also i games that removed their denuvo shit run better than their version with it.

How do the bypass work? If it leaves the function there, but stops it from being called, then it will use up some memory but it won't affect CPU usage as much. If it is still being called but just not displayed, then it will chew up even more memory and CPU usage.

I would say that it is blocked from being called, and so the function is never used. While that might still increase the memory used compared to the function not being there, it would still be much less than if it were actively being called.

The thing is, you guys are arguing two different things here. One is comparing the crack to if the DRM is not there at all, and the other is comparing to if the DRM is being actively used. A crack should be somewhere in the middle.

 

[deama]

It means using a crack objectively gives you a better product, therefore the DRM is anti-consumer.

Problem is that in most cases Denuvo isn't removed from the executable when a game is "cracked", it's merely bypassed. The shitware will still be consuming resources behind the scenes.

True,but it doesn't necessarily consume as much as uncracked. Also i games that removed their denuvo shit run better than their version with it.

How do the bypass work? If it leaves the function there, but stops it from being called, then it will use up some memory but it won't affect CPU usage as much. If it is still being called but just not displayed, then it will chew up even more memory and CPU usage.

I would say that it is blocked from being called, and so the function is never used. While that might still increase the memory used compared to the function not being there, it would still be much less than if it were actively being called.

The thing is, you guys are arguing two different things here. One is comparing the crack to if the DRM is not there at all, and the other is comparing to if the DRM is being actively used. A crack should be somewhere in the middle.

The bypass works by the cracking group creating a type of "emulator" that communicates with denuvo offline.

 

[Cael]

How do the bypass work? If it leaves the function there, but stops it from being called, then it will use up some memory but it won't affect CPU usage as much. If it is still being called but just not displayed, then it will chew up even more memory and CPU usage.

I would say that it is blocked from being called, and so the function is never used. While that might still increase the memory used compared to the function not being there, it would still be much less than if it were actively being called.

The thing is, you guys are arguing two different things here. One is comparing the crack to if the DRM is not there at all, and the other is comparing to if the DRM is being actively used. A crack should be somewhere in the middle.

The bypass works by the cracking group creating a type of "emulator" that communicates with denuvo offline.

That sounds like it responds to the function call. There might be a lesser RAM and CPU usage, but it would still be present and would still be significant. However, it is also possible for it to use even more CPU and RAM due to both the crack and the function call being processed, which is the worst of both worlds. Speed increase could be because the call isn't waiting for a response from an online server, but is localised to the computer running the game.

Either way, a game without the DRM should have better performance simply because you are not putting another thing in memory.

 

[fantadomat]

it is also possible for it to use even more CPU and RAM due to both the crack and the function call being processed

Nah,it is like running winamp in the background while without the crack denuvo is interfering with the game,which is high power needed program. It is still haemorrhage memory,but it is less with the crack than without it.

 

[PrettyDeadman]

Also this

I don't see a problem with the custom of adding a little free malware to AAA popamole titles.

>CPU 80C
Jesus Christ, not even fucking Frostbite running 100% CPU all the time does that on my 3570 with stock cooler (max was like 73), what CPU is that?

These screens do not contain information about temperature of CPU....

 

[Jarpie]

 

[CthuluIsSpy]

Its almost as if having another process working in the background puts more load on the computer.
Well, that explains why Total Warhammer runs like shit.

 

[GrainWetski]

Denuvo's good for you. Fucking retards defending that shit.

 

[fantadomat]

Really good analysis

 

[Perkel]

Can't wait to read on internet Denovo defense force every-time he does video.

 

[Gerrard]

I'd just like to use this occasion to remind everyone that Durante shilled this shit in a PCgamer article
https://www.pcgamer.com/denuvo-drm-performance-final-fantasy-15/

 

[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.


The cancer known as Denuvo has no impact on framerates, provided that ample CPU power is available.
It performs no work on the GPU, so if we're looking at GPU bound benchmarks, we will see no difference.

Denuvo, at least for the moment, is a strictly CPU based affair, so benchmark wise, he'd be far better off locking the framerate at moderate settings and comparing the CPU usage of the before and after.
Its known impacts include

1. Massively bloating executable file sizes
   This is bad for cache coherency; meaning it causes thrashing of L1/L2/L3 caches, which can severely impact performance.
   Windows also needs to map the entire executable into RAM, which add a few seconds of overhead and an unnecessary 200MB or so to RAM usage.
   
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.
   
3. General overhead from validation checks
   From what I understand, denuvo games need to do regular validation checks, these are often done in loading screens, or in the input handler.
   The more well behaved games do about 5 a second or so maximum.

Ergo, his benchmarks were completely focused on the wrong thing.
The loading times are still useful statistics, as that's almost pure CPU, and shows improvements between 10-30%.
But the frametimes are useless without the corresponding CPU Usage to put it into perspective, as Denuvo has no impact on GPU load.
It's all well and good to know that framerate went up 10%, but what's the CPU usage?
Does it achieve that 10% at the same CPU Usage? Meaning it's just a straight out 10% improvement.
Does it perhaps achieve the 10% while using 20% fewer CPU cycles? Suddenly that 10% becomes a far more impressive 37%.



(*) Assuming the only difference between the executables is the presence of Denuvo, then he could've given the non-denuvo run an unfair advantage.
As they're still the same game, they'll most likely use identical shaders; for each shader during compile time, the driver follows this simplified procedure.

1. Calculate checksum of shader
2. Check cache for match, go to step 5 if there's a hit
3. Compile Shader
4. Store in cache
5. Return compiled shader

This cache is persistent, and is only invalidated when the driver is upgraded to a different version.
This means that the denuvo runs possibly paid the full the shader compilation costs, whereas the non-denuvo run might've gotten away without having to compile a single shader.
And by having to pay the full compilation, the denuvo run had terrible minimum framerates - I believe the 59 vs 60 runs to be more indicative of what it would be in reality if this was controlled for.

This is also why games tend to stutter a bit when you play them for the first time, or right after a driver upgrade.
And why proper benchmarks consist of multiple runs (minus outliers) - and techtubers utilise .1% and 1% minimums, rather than absolute minimums.

 

[Gerrard]

"Denuvo has no impact on performance except when it does."
I already said this in the Denuvo thread years ago: how the fuck can it have no impact on performance when it's running checks constantly (some games even per frame)? What is doing those checks if not the CPU?

 

[unfairlight]

I don't think you fully read the post. Don't get flustered so fast.

 

[passerby]

>CPU 80C
Jesus Christ, not even fucking Frostbite running 100% CPU all the time does that on my 3570 with stock cooler (max was like 73), what CPU is that?

Either incorrectly installed cooler, or deliberate quiet PC setup.
I have delided 4670k 4,5GHz OC with huge 140mm cooler, configured to not spin up above minimum 650 rpm, until it hits 75C and max out rpm at 85C.
In summer with 26C in the room, it hits 82C with OCCT stress test and 72C in real applications and games. If it was comparable 120mm cooler configured the same way it would hit around 80C in game.
Occassionally hitting 80+ is perfectly safe.

 

[Hirato]

I don't think you fully read the post. Don't get flustered so fast.

I even bolded the other half of that exact sentence because I knew people were going to do that...

 

[Jarpie]

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.


The cancer known as Denuvo has no impact on framerates, provided that ample CPU power is available.
It performs no work on the GPU, so if we're looking at GPU bound benchmarks, we will see no difference.

Denuvo, at least for the moment, is a strictly CPU based affair, so benchmark wise, he'd be far better off locking the framerate at moderate settings and comparing the CPU usage of the before and after.
Its known impacts include

1. Massively bloating executable file sizes
   This is bad for cache coherency; meaning it causes thrashing of L1/L2/L3 caches, which can severely impact performance.
   Windows also needs to map the entire executable into RAM, which add a few seconds of overhead and an unnecessary 200MB or so to RAM usage.
   
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.
   
3. General overhead from validation checks
   From what I understand, denuvo games need to do regular validation checks, these are often done in loading screens, or in the input handler.
   The more well behaved games do about 5 a second or so maximum.

Ergo, his benchmarks were completely focused on the wrong thing.
The loading times are still useful statistics, as that's almost pure CPU, and shows improvements between 10-30%.
But the frametimes are useless without the corresponding CPU Usage to put it into perspective, as Denuvo has no impact on GPU load.
It's all well and good to know that framerate went up 10%, but what's the CPU usage?
Does it achieve that 10% at the same CPU Usage? Meaning it's just a straight out 10% improvement.
Does it perhaps achieve the 10% while using 20% fewer CPU cycles? Suddenly that 10% becomes a far more impressive 37%.



(*) Assuming the only difference between the executables is the presence of Denuvo, then he could've given the non-denuvo run an unfair advantage.
As they're still the same game, they'll most likely use identical shaders; for each shader during compile time, the driver follows this simplified procedure.

1. Calculate checksum of shader
2. Check cache for match, go to step 5 if there's a hit
3. Compile Shader
4. Store in cache
5. Return compiled shader

This cache is persistent, and is only invalidated when the driver is upgraded to a different version.
This means that the denuvo runs possibly paid the full the shader compilation costs, whereas the non-denuvo run might've gotten away without having to compile a single shader.
And by having to pay the full compilation, the denuvo run had terrible minimum framerates - I believe the 59 vs 60 runs to be more indicative of what it would be in reality if this was controlled for.

This is also why games tend to stutter a bit when you play them for the first time, or right after a driver upgrade.
And why proper benchmarks consist of multiple runs (minus outliers) - and techtubers utilise .1% and 1% minimums, rather than absolute minimums.

As Denuvo uses CPU, doesn't that then mean that if you get, let's say 60 fps on 90% of the CPU usage, and Denuvo uses 20% of the CPU, it affects the framerate? Also, even if (or when) denuvo uses the CPU, and not GPU, it still uses up resources from the computer, compared to without denuvo, so it should always be better without it.

 

[Cael]

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.


The cancer known as Denuvo has no impact on framerates, provided that ample CPU power is available.
It performs no work on the GPU, so if we're looking at GPU bound benchmarks, we will see no difference.

Denuvo, at least for the moment, is a strictly CPU based affair, so benchmark wise, he'd be far better off locking the framerate at moderate settings and comparing the CPU usage of the before and after.
Its known impacts include

1. Massively bloating executable file sizes
   This is bad for cache coherency; meaning it causes thrashing of L1/L2/L3 caches, which can severely impact performance.
   Windows also needs to map the entire executable into RAM, which add a few seconds of overhead and an unnecessary 200MB or so to RAM usage.
   
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.
   
3. General overhead from validation checks
   From what I understand, denuvo games need to do regular validation checks, these are often done in loading screens, or in the input handler.
   The more well behaved games do about 5 a second or so maximum.

Ergo, his benchmarks were completely focused on the wrong thing.
The loading times are still useful statistics, as that's almost pure CPU, and shows improvements between 10-30%.
But the frametimes are useless without the corresponding CPU Usage to put it into perspective, as Denuvo has no impact on GPU load.
It's all well and good to know that framerate went up 10%, but what's the CPU usage?
Does it achieve that 10% at the same CPU Usage? Meaning it's just a straight out 10% improvement.
Does it perhaps achieve the 10% while using 20% fewer CPU cycles? Suddenly that 10% becomes a far more impressive 37%.



(*) Assuming the only difference between the executables is the presence of Denuvo, then he could've given the non-denuvo run an unfair advantage.
As they're still the same game, they'll most likely use identical shaders; for each shader during compile time, the driver follows this simplified procedure.

1. Calculate checksum of shader
2. Check cache for match, go to step 5 if there's a hit
3. Compile Shader
4. Store in cache
5. Return compiled shader

This cache is persistent, and is only invalidated when the driver is upgraded to a different version.
This means that the denuvo runs possibly paid the full the shader compilation costs, whereas the non-denuvo run might've gotten away without having to compile a single shader.
And by having to pay the full compilation, the denuvo run had terrible minimum framerates - I believe the 59 vs 60 runs to be more indicative of what it would be in reality if this was controlled for.

This is also why games tend to stutter a bit when you play them for the first time, or right after a driver upgrade.
And why proper benchmarks consist of multiple runs (minus outliers) - and techtubers utilise .1% and 1% minimums, rather than absolute minimums.

As Denuvo uses CPU, doesn't that then mean that if you get, let's say 60 fps on 90% of the CPU usage, and Denuvo uses 20% of the CPU, it affects the framerate? Also, even if (or when) denuvo uses the CPU, and not GPU, it still uses up resources from the computer, compared to without denuvo, so it should always be better without it.

No. He is saying that if you are using 50% of the CPU to run your 60fps, and Denovu requires 50%, you're sweet.

Stupid troll logic, of course, because running a CPU harder has obvious consequences.

 

[unfairlight]

Eh, I don't think that's too much the case either. When it comes to ultra high frame rates, your CPU will start bottlenecking earlier than your GPU. If for example games that people try to run at the highest frames such as CS:GO had Denuvo, Denuvo would in almost all situations cause a very bad performance drop. On the other hand with a reasonable FPS cap and a powerful CPU you should have no loss in performance.
It's fair to note that this is all awful no matter how small the performance loss is, as it's still a loss and it still objectively leads to a worse experience at no benefit to the paying consumer.

 

[Hirato]

As Denuvo uses CPU, doesn't that then mean that if you get, let's say 60 fps on 90% of the CPU usage, and Denuvo uses 20% of the CPU, it affects the framerate?

It means that without denuvo, you'll get 60 FPS at 70% CPU Usage instead (or would that be 72%?).

Also, even if (or when) denuvo uses the CPU, and not GPU, it still uses up resources from the computer, compared to without denuvo, so it should always be better without it.

That obviously goes without saying.

There's other obvious advantages as well
1. People with weaker CPUs can enjoy more games, where denuvo's overhead would have previously made it unplayable,
2. Your CPU will run cooler - might be a fun idea to bludgeon game companies with this in a "don't you care about the environment!?" sense and see if they'll react.



EDIT: The key point I wanted to make in the last post is that denuvo adds 0 overhead to the rendering pipeline.
Tthe overhead it adds is everywhere else from physics, event handling, game logic, network logic, asset loading, etc.

 

[Average Manatee]

All I know is that Total War Warhammer has the most godawful load times ever (2-3 minutes for returning from battles on min settings and an SSD), and it has Denuvo. No other Total War game that I've played has anywhere near these problems.

Actually now that I think about it, Prey had pretty bad load times too and it apparently has Denuvo. Haven't played any othe Denuvo games, but its 0/2.

 

[CyberModuled]

Least Prey is probably going to drop Denuvo this year the same way Dishonored 2 did last year since even Bethesda ironically have enough brain cells to realize how useless it is. SEGA on the other hand... who the fuck knows what they're doing (they dropped it for Yakuza 0, Two Point Hospital, Kiwami 1 before launch, and Sonic Mania yet a few of their other games still have/will have it on games like Warhammer 2, Three Kingdoms and Sonic Team Racing... but Kiwami 2 doesn't have it yet).

 

[GrainWetski]

They probably leave it up to the devs. CA is a bunch of cunts.

 

[Infinitron]

Goodnight sweet prince: https://www.pcgamer.com/denuvo-cracks-2019/

Denuvo DRM cracks seem to be happening faster and faster
Rage 2 is the second Denuvo game to get a zero day crack this year, and others have been cracked within days.

Denuvo is an unpopular DRM solution that's nevertheless still used by a large number of PC game publishers, including Ubisoft, Sega, Square Enix, and others. Last year, Denuvo argued that cracking and pirating games is inevitable, and its main goal "is to protect initial sales" before cracks are released. But with Bethesda's Rage 2 defanged of its DRM in less than 24 hours, that promise isn't holding up well in 2019.

In this case, a weakness in Denuvo's security wasn't actually to blame. According to posts on the CrackWatch subreddit, while the Steam version of Rage 2 shipped with Denuvo, the .exe on the Bethesda Launcher did not contain the DRM. That strange oversight (or choice) on Bethesda's part gave crackers a way in. Access to a clean executable seemingly made it trivial to release a crack that bypassed Rage 2's online check-in at launch.

Crackers didn't even have to wade into Denuvo's code to pirate Rage 2, and it's sadly common for games that don't have strong copy protection to be cracked on release day, according to CrackWatch. But looking at other Denuvo games released this year, the DRM doesn't seem to be holding up as well as it did in the past, even without slip-ups like Bethesda's.

Of this year's Denuvo releases tracked on Crackwatch, there are a rare few that remain uncracked, like Anno 1800 (a month old). Some other uncracked games like Mortal Kombat 11 and The Division 2 will probably never be cracked, not because they can't be, but because their online connectivity renders a crack especially difficult or pointless.

Outside games like those, Crackwatch doesn't paint a great picture for Denuvo in 2019.

• Rage 2 cracked: Day 0 (non-Denuvo .exe uploaded)
• Metro Exodus cracked: Day 4
• Devil May Cry 5 cracked: Day 0 (non-Denuvo .exe uploaded)
• Resident Evil 2 cracked: Day 6
• Far Cry New Dawn cracked: Day 6
• Ace Combat 7 cracked: Day 13

Scrolling down into 2018, and the crack times are generally much longer. Hitman 2 and Just Cause 2 were both cracked within a day, but Assassin's Creed: Odyssey took 36 days, FIFA 19 took 63, and Shadow of the Tomb Raider took 64. In 2018, it was common for Denuvo cracks to take weeks or months, with some big exceptions like a day zero crack for Final Fantasy 15.

In 2019, multiple Denuvo games have been available to pirate the same week they launched. Launch day may be the most important for sales, but six days is still a very narrow window for DRM to be effective.

Only about a dozen games have launched with Denuvo this year, at least according to Crackwatch, but those that have been cracked have been cracked fast. If Denuvo's main value really is in fending off piracy at launch, it might be time for publishers to reconsider whether less than a week of protection is worth it, considering how unpopular Denuvo is with PC gamers.