Reverse Engineering The Games Winter Challenge Copy Protection

Reverse Engineering "The Games: Winter Challenge"

A computer scientist analyzes the 1991 DOS game, uncovering its structure, copy protection (code wheel), and hidden gameplay alterations caused by improper cracks, leading to a functional patch and a detour from the initial ski jumping analysis.

• "The Games: Winter Challenge" is an old Winter Olympics sports game from 1991 for DOS and Sega Genesis.
• The author rediscovered the DOS version, driven by nostalgia and curiosity about its mechanics, especially the ski jumping event.
• The author, a computer scientist, was more interested in the "under the hood" workings and optimizing a perfect ski jump (reaching 100 meters).
• The game has a replay system, useful for analyzing attempts and potentially creating Tool-Assisted Speedruns (TAS).
• Initial plan: disassemble the game to understand ski jumping mechanics. This led down a rabbit hole of early 90s game development details.
• Multiple versions of the game exist, including original floppy, bundle releases, and a GOG release (based on DOSBox emulation).
• The original game used a physical "code wheel" for copy protection, asking for a hidden code at startup.
• The GOG version removed the code wheel check but multiple users report it is "improperly cracked" and doesn't work correctly (e.g., difficulty landing long ski jumps, crashing in speed skating). This resonates with the author's childhood experience.
• A 1996 US release included an official crack (WINTER.COM) to remove the code wheel check.
• Different online versions and cracks also exist.
• The original game install process creates a new executable (WINTER.EXE) each time based on options (graphics modes, "fast loading"). These affect which assets are included and their compression.
• Comparing versions revealed many distinct binaries and stand-alone crack programs.
• Analyzing the original floppy version with disassemblers (Ghidra, IDA) showed it was packed/obfuscated, likely using LZEXE.
• Unpacking the binary revealed it's much smaller and identical across different versions, suggesting a business logic core and separate resources (sprites, sounds, code).
• The game uses a custom overlay management system, loading code pieces (COD and REL files) dynamically from the executable via a custom int 3fh interrupt, likely due to DOS's 640kB memory limit. This wasn't Microsoft C's native overlay system.
• Overlays are not readily visible to standard disassemblers, making manual analysis necessary.
• File IO logging from DOSBox-X revealed the game reads resources from the end of the executable, starting with an "MB" magic number.
• Resource entries in the binary contain size, offset, and an obfuscated name (by adding 0x60).
• De-obfuscating names shows resources include assets (images, meshes, music, SFX) and code overlays (COD, REL files). REL files likely contain relocation data needed for loading code at different memory addresses.
• The variety in installed versions is due to bundling different sets of (packed/unpacked) resources based on installation options. "Fast loading" versions had uncompressed resources but some overlays remained packed for obfuscation.
• Extracted resources can be placed in a "ART" subfolder, and the game will load them instead of embedded resources, confirming accurate extraction.
• The goal was to combine all overlay code into a single binary for easier analysis, bypassing the dynamic loading and int 3fh. This requires re-mapping segment addresses, careful consideration of memory use (stack, heap), and patching int 3fh calls into far calls.
• The solution was to pad the start of the combined binary and place overlays before the main program code, adjusting segment addresses.
• The game's overlay manager has a fallback for detecting function calls instead of interrupts when unloading, which prevents issues after replacing interrupts with calls.
• The game has a two-part anti-debugger check.
  • Part 1: Checks for known debugger filenames (NU-MEGA, SOFTICE1, TDHDEBUG). This check is obfuscated in the code with XOR.
  • Part 2: Relies on the Intel 8253 timer chip and is sensitive to timing. If the game initializes too quickly (common on modern fast computers or fast-loading versions), the check fails. Slowing down the emulator can fix this.
• The debugger check can be bypassed by patching a single conditional jump in the code.
• The code wheel check is more complex than just skipping the input – it's a "honey pot" for crackers.
• The primary code wheel check routine simulates the physical wheel and compares input to an expected XORed value from a table. It also stores the input ticket number in 5 memory locations.
• These 5 stored values are used to derive 6 new values through various operations.
• These 6 derived values are checked against reference values throughout the game in hidden locations.
• These hidden checks are the "improper cracking" issue. If the main code wheel check is skipped, these hidden checks fail.
• Failing hidden checks subtlely alters gameplay in specific events:
  • Ski Jump: Cannot land jumps beyond 86.7m.
  • Speed Skating: Cannot turn in the third lap, forcing a crash.
  • Biathlon: Shots moved randomly top-right on 2nd and 4th targets.
  • Downhill: Physics changes partway through, reducing gravity.
  • Bobsled: Increased drag after initial turns, slowing you down.
  • Luge: Instantly forfeits run near the end if time is below 57.7s.
• Checking different versions/cracks reveals that all except one fail the hidden copy protection checks.
  • GOG version: Skips debugger check and code wheel check, but not hidden checks. Broken.
  • Unknown cracked version: Skips the function leading to the code wheel check. Broken.
  • "The Humble Guys" crack (1991): Injects code into int 21h and int 3fh to skip the code wheel check. Broken.
  • Winter+Summer bundle US release (1996): Uses a loader (WINTER.COM) which injects code similarly to the Humble Guys crack, checking the same unique parameters. Broken.
  • "Razor1911" crack (1991): The only working crack. Patches debugger checks and infects the game's internal code wheel check routine to make it always succeed by overwriting the stored ticket number values with the correct expected result.
• A tool is offered to patch broken game versions (like the GOG one) to remove copy protection checks (debugger, code wheel, and hidden ones).
• The original goal of analyzing ski jumping mechanics was sidetracked by the copy protection investigations, but is now the focus for a potentially future write-up.