3 ms·

My guess is they want intermittent checks, but don't trust the system clock to advance, but a zombie kill is evidence that time has advanced for the player. See

My guess is they want intermittent checks, but don't trust the system clock to advance, but a zombie kill is evidence that time has advanced for the player. Seems like it shouldn't block the main game thread and there should be a longer time to live for that check, and maybe those are the bugs.

daenz 5y ago
Do some cracks rely on preventing the system clock from advancing?
- ip26 5y ago
  I’m not a cracker but messing with the system clock is a classic exploit for all kinds of things.
- tehbeard 5y ago
  More that the function calls for the system clock are fairly easy to trace back to find these DRM hooks.
- arcticbull 5y ago
  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.
  - daenz 5y ago
    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.
    - deleted 5y ago
      [deleted]
    - dognotdog 5y ago
      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.
      - daenz 5y ago
        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.
        robertlagrant 5y ago
        That's assuming you couldn't selectively patch the calls, but yes, sounds as though it would be harder.
  - pdpi 5y ago
    > 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.
- neom 5y ago
  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.
  - Scoundreller 5y ago
    If there was a free trial, yes.

daenz 5y ago

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

ip26 5y ago
I’m not a cracker but messing with the system clock is a classic exploit for all kinds of things.
tehbeard 5y ago
More that the function calls for the system clock are fairly easy to trace back to find these DRM hooks.
arcticbull 5y ago
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.
- daenz 5y ago
  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.
  - deleted 5y ago
    [deleted]
  - dognotdog 5y ago
    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.
    - daenz 5y ago
      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.
      - robertlagrant 5y ago
        That's assuming you couldn't selectively patch the calls, but yes, sounds as though it would be harder.
- pdpi 5y ago
  > 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.
neom 5y ago
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.
- Scoundreller 5y ago
  If there was a free trial, yes.