Game copy protection was an art form, as well as #cracking these protections. This cat and mouse game evolved over time, with protections including more and more complicated and well-hidden checks trying to identify poor or quickly made cracks. The best protections hindered the release of a crack long enough for the game to hit enough initial sales. After the initial sales the eventual release of a crack would no longer hurt (much).

Rewind to 2025 and legal purchase of early 90s PC games from palaces such as COG: Apparently, there are plenty of releases that have the poor crack built-in, and where the anti-crack checks kick in, making the game unplayable. The irony is that the only way to play is to get a proper “real crack”.

Cool write-up of the protection in “The Games: Winter Challenge” and the associated problems of “legal releases”:
https://mrwint.github.io/winter/writeup/writeup.html

#retrogaming #hacking

  • Hugo Mills@mstdn.social
    link
    fedilink
    arrow-up
    1
    ·
    26 days ago

    @[email protected] The one thing I ever cracked (30+ years ago) involved self-modifying/decrypting code – you’d set a breakpoint, and it would crash because it modified that instruction before it reached the breakpoint. Work it through by hand from there, and you’d get the right instruction, which got you to the next section of self-modifying code.

    Six times.

    I eventually got through it, and had a version that I could run from the hard disk. That was all I wanted.

    Fun times. :)

    • riplin@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      26 days ago

      I remember one way a program would detect the presence of a debugger was to rely on the fact that cache memory was write-through, not write-back. This would modify the code in memory, but not in cache. When a debugger comes along and you step the code, the cache would get flushed every time so it would load the modified version and execute differently. This technique would fail with the advent of write-back cache support. So later 486’s and pentium onward could not run those games.

      • Hugo Mills@mstdn.social
        link
        fedilink
        arrow-up
        1
        ·
        26 days ago

        @riplin This one was on ARM3, and the RiscOS debugger wrote a trap instruction to the breakpoint, so when the self-modifying code modified it, it mangled the breakpoint, and the debugger failed.

        Fortunately, the self-modifying sequence was short enough to run by hand, and you could grab enough state out of memory to work out what the instruction should have been.

        The cache thing is another level of awkward, though.

  • @[email protected] SSI had the best copy protection in the 80’s. Those games were so text heavy, rather than shipping more floppies, they shipped huge manuals and the game was like “just read pages 89-91 for dialogue”.
    Disassembling a code wheel and taking it to the copy machine was one thing. But a 100 page manual?