> 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.
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.
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.
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.
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.
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 wonder if that's because they want to avoid these kinds of future incompatiblities with the underlying OS as it evolves.
Theres a list of every game that currently has denuvo here... https://www.reddit.com/r/CrackWatch/comments/p9ak4n/crack_wa...