How should I best spend my valuable time, money and man-power so as to keep those dastardly crackers at bay, and the money rolling in? There are so many commercial protection schemes out there; some cheap and some certainly not, but they all seem to be compromised… Is it really worth all that money? Or should I maybe set one of my most talented programmers on the task for a couple of weeks? At least that way, my security will be truly unique. All I know is that the more pirated copies of my game are made, the more of my revenue goes down the drain!

Stop! If this sounds familiar then I beg you to hear me out, even though you probably won’t like it. I’ve spent plenty of time reverse-engineering games in the company of the black-hats and I’ve seen the situation from both sides of the fence. Here’s your chance to learn from the mistakes of thousands before you and save some money in the process. At least, that goes for everybody to whom this next paragraph doesn’t apply.

If you’re writing a multiplayer client-server game and your interest is in keeping the hackers from ruining everyone else’s fun, then the solution is simple (although it needs to be understood from the beginning of development): Any code that can be taken advantage of must go on the server side. No matter how much time and intelligence you have, the hacker collective has more, and so sensitive code in the client application is a disaster waiting to happen. For example, if the client program is responsible for his own collision detection, then you are responsible when your paying customers complain about their enemies walking through walls. Once you’ve made sure that your design ensures the client can’t cheat, no matter what data it sends the server’s way, your job is done.

But for the rest of you, who are concerned about illicit copying, things are even simpler. Let’s suppose I am a software pirate, for a moment. Then here are some facts:

• If I can run your program, then I can disassemble it. If I can disassemble it, then I can reverse-engineer it.
• If your game isn’t worth hacking, I won’t try, and your efforts will go to waste.
• If your game is worth hacking, then I will try to hack it, and given sufficient time and motivation I will succeed. At this point, your protection scheme is worth nothing. It only takes one successful hack, and the cat is out of the bag.
• There are many hackers working on any popular commercial protection scheme at any moment, and once we’ve cracked one sample, the method extends with relative ease.
• The more effective a protection is, the more popular it will become and the more attention it will get from us bad guys. Together with the last point, this places a limit on the value of any commercial protector.
• It is very, very easy to slip up when writing such a system. All but the best-thought-out, most thoroughly-tested schemes (generally written by those with years of experience) boil down to a single conditional jump somewhere along the line. Once I find this Achilles’ heel, I win.

And here are some commonly upheld non-facts:

• If somebody is prepared to steal your game, then they are prepared to buy it in the absence of a crack.
• Protection schemes reliably keep a game safe from crackers long enough to ride out the majority of its public consumption.
• Protection schemes reliably keep a game safe from crackers for at least a few days.

So both buying and home-brewing a protection are bad ideas? Not at all, they’re just not as good as they sound. A shop-bought PE-protector is an excellent investment if you deem its level of protection worth the value on the price-tag. But you’ll be investing in a false economy by fooling yourself into believing that this level of protection is anything more than ‘a week’s head-start from release’ or simply ‘keeping honest people honest’. And home-brewed protections are a very good idea, just keep them simple. If it’s going to be cracked anyway, then keep it as simple as possible. Why not restrict yourself to the five man-minutes it takes to check for the presence of your game’s CD?

1. Enumerate the disc-drives on the system.
2. Find the one that contains your game’s CD, by checking for a specifically-named file
3. Check the file’s attributes, to make sure that it is read-only.

If something goes wrong at any point in this sequence, then you simply demand the user puts the CD in the drive, and loop. Now, even a half-witted hacker will circumvent this in minutes, but it’s enough to keep the layman in check, and that’s all you want.

Update: I hate CD-swapping as much as the next man, and so if you can bear it I’d recommend you avoid this too. The ideal solution is a server-based disposable serial database system, but most developers don’t have a server lying around to dedicate to this cause. If you do decide to use a CD-check, then at least be reasonable and disable it after a few days of successful use.

So now that you’ve saved yourself the hundreds or thousands of dollars you were about to give to Silicon Realms or Macrovision, you can afford to spend more on getting your game perfect, and that is what the consumer is happy to pay for. All that’s left is to price your game appropriately, and this means doing a little market research. Once we remove from the equation the user who pirates everything (the type you can do nothing about and should disregard), the situation is extremely simple:

If the user wants and can afford your game, then he’ll consider buying it.
If he has pirated it then he didn’t consider it worth paying for.

Posted: Monday, December 3rd, 2007, 9:00 am
Filed under: Game Programming.