> As Windows matures, behaviour can change, breaking certain stuff.
How do you expect the aforementioned tech to break the games it's on? If anything it "breaking" will just make the anti-tamper feature ineffective.
The anti-tamper codes, if any tampering is detected will crash on undefined/unallocated regions. Meaning that if Windows ever were to overwrite that region for whatever reason, will trigger the crash.
Such was the case for SecuROM in early days. It featured the CRC checks mentioned, if any single byte was changed, including an INT (breakpoint) instruction, it would crash. Here it's unlikely that it wont crash. Rendering the game inoperable.
> The anti-tamper codes, if any tampering is detected will crash on undefined/unallocated regions.
That's basically the whole point of any anti-tamper product. I just think you picked a terrible example of a feature that could break due to OS changes specifically.
> Meaning that if Windows ever were to overwrite that region for whatever reason, will trigger the crash.
We're talking about random stack memory inside of a virtual machine that likely doesn't call any external code whatsoever. There should be no real way for Microsoft to accidentally corrupt this memory.
Wasn't there a story on HN about a GTA San Andreas bug that was caused by this? (or something very similar)
In that case the "unused" stack was overwritten by a function called on that thread. But I'd assume that Denuvo is careful to not call any third party code while it expects the "unused" stack data to remain unmodified, so this shouldn't happen here.
So this code can only break if the data is overwritten from code outside the control of that thread. On Unix, certain signals could cause that. Or the OS could decide to zero out the unused thread while the thread isn't running. Zeroing the thread could the helpful to wipe secrets spilled there (forward secrecy related), or if whole pages can be zeroed (via something like MADV_ZERO), it could reduce the memory consumption by allowing threads to shrink.
While I would like that thread zeroing feature, I think it's unlikely that MS will implement something like it. So the code should be unlikely to break in practice.
Yes and no.
The GTA SA bug was reading of an uninitialized variable. The value it contained was correct simply by chance as it was placed there by the previous invocation of the function and never overwritten by something else intermittently. Any changes to functions that happened to be called in between these 2 could have changed the value of the stack memory.
The aforementioned check on the other hand is placing random value below the stack pointer. This means that by design it cannot call any external/os/game functions and is basically isolated/"pure" from any interactions with third party code.
I imagine that if some Denuvo servers enter legacy status at some point they'll be removed entirely.
Yeah it's not uncommon to see Denuvo patched out of a game title once the initial sales window has passed..
I wonder if that's because they want to avoid these kinds of future incompatiblities with the underlying OS as it evolves.
IIRC Denuvo costs a fortune to keep in a game, since it’s a subscription model. Once sales sufficiently taper off there’s not much sense in paying for it anymore.
Some games have had it for an extremely long time. and some publishers never remove it (Eg. Sega). In some cases I guess they got a lifetime deal with an older version of Denuvo, but other cases are sus. I wonder is it for money laundering purposes.
Theres a list of every game that currently has denuvo here... https://www.reddit.com/r/CrackWatch/comments/p9ak4n/crack_wa...
I think the dev pays for the service window and after the Denuvo contact is up they update the game without it.
Not a horrible system. Protects the initial sales spike from piracy, but doesn't obstruct long term archival or playability after the servers go down.