4 ms·

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.