I think I understand the theory. If I was a cracker though, I would think that patching out the system clock calls (in order to prevent DRM checks) would have a lot of game-breaking unintended side-effects (animations, other time-based mechanics, etc). And if that was the case, it would be a perfect place to trigger the DRM calls, since a cracker couldn't patch the system time calls without breaking the game.

tehbeard (another comment in this thread) makes a point that maybe not attaching the DRM calls to the clock makes it easier to hide them, since a cracker would probably be looking for a time-based trigger.

A game’s animation and other in-game timing functions are very unlikely to be based on wall-time, instead typically relying on monotonic counters that are higher resolution, less overhead, and not potentially adjusted backwards or forwards while the game is running. Thus, disabling wall-time accesses for a crack should have little influence on game timing and animations.

That makes sense to use monotonic counters for game mechanics. I think the point still stands in that case though: if the DRM calls were tied to the same time source as the animation system, you couldn't patch one without breaking the other.

That's assuming you couldn't selectively patch the calls, but yes, sounds as though it would be harder.

> Generally in a software system you can't count on a time source to move forward, to move in consistent intervals, or to move at all.

By way of illustrating this point: C++ has std::chrono::system_clock, std::chrono::steady_clock, and std::clock, all of which give different guarantees on how the clock behaves.