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
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.
@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.