Hacker News new | ask | show | jobs
by farmdve 377 days ago
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.
1 comments
musjleman 377 days ago
> 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.

link
degosuke 376 days ago
Wasn't there a story on HN about a GTA San Andreas bug that was caused by this? (or something very similar)
link
CodesInChaos 376 days ago
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.

link
musjleman 376 days ago
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.

link