Do some cracks rely on preventing the system clock from advancing?

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. In a system that is designed to be resistant to attack, it actually makes a lot of sense to instead rely on a desirable event critical to progression. Especially one that occurs relatively infrequently and is likely associated with a lot of other complex calculations.

I think this is pretty smart.

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.

More that the function calls for the system clock are fairly easy to trace back to find these DRM hooks.

I’m not a cracker but messing with the system clock is a classic exploit for all kinds of things.

In the late 90s early 2000s for some stuff you didn't need cracks, you could often literally just set the system clock back to 1990.

If there was a free trial, yes.