Gamasutra: The Art & Business of Making Gamesspacer
Keeping the Pirates at Bay
View All     RSS
September 19, 2014
arrowPress Releases
September 19, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Keeping the Pirates at Bay

October 17, 2001 Article Start Previous Page 2 of 3 Next


Now that the meat of YOTD's crack protection had been implemented, it was time to move on to the second stage — slowing down the crackers as much as possible. We had already tried to make the protection as difficult as possible to understand, mixing in the checksum code with regular game code, and using different implementations so that it would be hard to understand. We thought that if the crackers couldn't understand what we had done, it would be a lot harder for them to crack the game. We wanted to make it hard enough to reduce the pool of people capable of cracking it. If there are only a couple of pirates with enough skill to crack a game's protection, it might take them a week or two to get around to it. Unfortunately, with YOTD being such a high-profile game, this was probably wishful thinking.

Thus we wanted to make the job of cracking YOTD time-consuming and tedious. If we could just keep the crackers busy at finding the protection, that's time taken away from them working out how to remove it. Again, we were trying to reduce the pool of people available who could crack the game. Not every cracker would have enough time available to make the crack; it probably isn't anyone's day job. On this note, it's worth pointing out that for most crackers this is a hobby. If they get bored, they may well give up. We tried to make the crackers have to wade through plenty of chaff before finding the protection. There were a couple of techniques we tried to achieve this.

First of all, if the crackers know what they are looking for, they often don't even have to boot up the game to find the protection. They can simply search the disk and sometimes even edit the protection right there and then. Simply doing an XOR of as much of YOTD's code as possible before burning it to the CD means that this technique will not work. It also makes it difficult to match up data in memory with its source on the disk. We worked under the assumption that code can't be modified if it can't be found.

Second, we made it as difficult as possible to debug. If you've ever had to debug code that behaves differently when you trace through it, you know how much of a pain debugging can be. We used trace traps to make the code behave differently if breakpoints had been placed. The checksum helped with this, as any software breakpoints used would alter the checksum. Rebooting the debugger and the game takes time, and the more often we could force the cracker to do this, the more of their time we were wasting.

Perversely, though, the harder a crack is to make, the more fun it is for the cracker to make it. It's a challenge, and therefore fun. Paradox, the cracking group who produced the working patch for YOTD, even thanked the "Sony coders" who added such interesting protection to the game. The more difficult the crack, the more effort they will put into making it.

It's the same with the length of time it takes to produce. The longer that the game has been out without a crack, the more prestige there is in being the first to produce one. Again, this means more effort will be put into producing it.

Taking Action

Of course, all of this effort is worth nothing if the game doesn't do anything once a crack is detected, but this needs to be handled carefully. If the game just halts as soon as any modification is detected, the cracker would soon find and remove all the protection. However, if we wait too long to react, too much of the game would be playable even if an incomplete crack was used. To balance this, we used as many layers of protection as possible, which occurred at different points during the game. In YOTD we had four layers, including the copy protection.

The copy protection stopped the game very early. When this was removed, the game appeared to work for some time. We assumed that the crackers generally don't play the games they crack very much, they just play until the point where the protection they know about kicks in. Then they release a crack, believing it to be complete.

To play on this, we designed the game to break in ways that weren't immediately obvious. Most of the protection is "off-camera," affecting levels other than the one currently being played. In YOTD the object of the game is to collect eggs and gems, which are then used to open later parts of the game. The protection removed eggs and gems, so that the player could not make progress. We tried to make the game unplayable for any length of time, while at the same time making it difficult to determine exactly where things had gone wrong. If errors accumulated slowly until the game broke, the cracker would not notice such behavior so easily.

Other, more obvious protection was done less frequently. Callbacks were corrupted, which made the game crash in odd ways. The European version changed languages randomly. Some of these actions break the game and others are just an annoyance to the player, but if the game is difficult or frustrating to play because of the failed crack, this can be more effective than breaking completely.

By making the game behave in as many odd ways as possible, we hoped to cause a lot of confusion. The pirates wouldn't know if the crack didn't work, whether they had just failed to apply the crack correctly, or if the disk had failed to burn correctly. The people who didn't play a lot of the game wouldn't notice that anything was wrong and claim that the crack worked. This happens more than you would think. A lot of people pirate more out of habit than anything else, booting up the game to have a look before moving on quickly. All of this would help to delay a complete crack from being made, because no one would be sure that it was required.

The Costs

Implementing all of this protection takes time and resources away from actually developing the game. For YOTD those costs were as follows:

Programmer time. One programmer was required for three to four weeks. The programmer spent this time adding the copy protection, integrating the anticrack protection into the game, and writing tools to mask the data and generate checksums. For about six months prior to actually writing any code, some time was spent thinking of methods for protecting the game and what to do when a crack was detected. This was slightly less than two percent of the total programmer time budgeted for the game.

Game data preparation. The game data needed additional preparation before a disk could be burned. The game's WAD file had to be run through tools to generate checksums and mask data. This added about an hour to the burn cycle, making it about three hours long. The extra steps involved also made this process more prone to error, though this diminished over time as we became used to it and automated what we could.

Debugging. Any version of the game with protection included was very difficult to debug, as any software breakpoints would trigger the protection. Beyond a certain point, hardware breakpoints were turned off by the copy protection. This effectively meant that any debugging had to be done by the programmer who implemented the protection (me) on production versions of the game.

Testing. The protection was designed to produce effects almost indistinguishable from bugs, so testing was also affected. If any false positives occurred in the protection, they could be reported incorrectly. For this reason a very thorough debugging plan was produced just for the protection. Every location that could trigger protection was listed, along with how long it would take to trigger, what the exact effect would be, and where you had to look to see the effect. Testers had to visit the locations, wait the required amount of time, and then look to see if the protection had been triggered. Having any of the protection give a false positive was obviously our biggest worry. Therefore all the protection was set up on a compile-time switch so that it could be turned off at any time if we weren't absolutely sure that the protection was reliable (and believe me, there were a few moments when it didn't seem to be).

Article Start Previous Page 2 of 3 Next

Related Jobs

Vicarious Visions / Activision
Vicarious Visions / Activision — Albany, New York, United States

Software Engineer-Vicarious Visions
Mixamo — San Francisco, California, United States

Animation Outsource Manager
Phosphor Games Studio
Phosphor Games Studio — Chicago, Illinois, United States

Game Producer
Trion Worlds
Trion Worlds — Redwood City, California, United States

Senior Gameplay Engineer


Francois Grenier
profile image
Thanks for this, it was great. Quite the modern cat and mouse game.

Neil Harding
profile image
Back when I was programming on the Atari ST / Amiga, we used Rob Northern's copy protection code, but because it was supplied as a block piece of data rather than source we couldn't modify it, and it also meant it was easier to remove (search for 512 bytes of data and patch that) and I believe there were automated tools for doing that. So for Vindicators I added the code to the program, but I huffman coded the main file and added a preloader so that a simple search wouldn't work. The code returned a value that you were supposed to check, but I didn't use the value directly, I instead xored some game data with the value so it would only work if the correct was returned.