Why copy protection is doomed to failure
Saturday, March 6th, 2010From Slashdot Games Story | Ubisoft’s New DRM Cracked In One Day
Re:Priceless (Score:5, Interesting)
by fuzzyfuzzyfungus (1223518) on Thursday March 04, @11:00PM (#31366974)
Journal
The thing is, “requiring a constant internet connection” isn’t something that you can just tack on in an unhackable way.
You can use the various DRMed binary obfuscation tricks to slow them down; but the hackers will eventually manage to neuter the internet checking stuff, producing a tame version that always returns what the program wants to hear, or a version of the program that doesn’t even care.
The only way to really force the issue is to actually move large chunks of vital game code to the server, and only provide the output of that code to the client. For instance, they could hypothetically ship the game with absolutely no AI code, and have every NPC in the game controlled by AI code on their server, just as if it were a multiplayer game. The trouble with doing that sort of thing is twofold: One is latency. There are only certain parts of a game’s code that can reasonably be moved 100+milliseconds away from the user. AI would be doable, if suboptimal, because of our experience with providing adequate multiplayer FPS results. It’d be worse than doing it locally; but DRM shows a willingness to hurt paying customers, so so what? Second is cost: the more code you move to your server, the more computational capacity you need to maintain for the supported lifespan of the game. The more data you need to transfer back and forth, the higher your bandwidth bills, and the more customers with marginal connections you lose out on.
The problem is, if the internet presence check is purely artificial, hackers will strip it out, just as they stripped out CD presence checks and offline serial key verification checks. If the internet component is vital, the hackers won’t be able to simply strip the checks; because they’ll be left missing whatever pieces are server side; but you run into new issues. If the vital component is static(certain textures or models or something aren’t shipped; but are downloaded when needed) it’ll be extracted and posted on bittorrent inside a week. If the vital component is dynamic(as in the AI example, where the client sends player location data and gets back a series of movement commands for NPCs) it cannot be usefully extracted; but you will take on substantial server load over the lifetime of the game, and whatever that dynamic component is will suffer from latency.
This is where another problem comes in. Since your servers cost money, you want to make the server-side dynamic component as computationally cheap as possible. The simpler it is, though, the easier it will be for hackers to simply write an equivalent version of whatever it is, and make that version, running locally, available in their cracked copies. Unless you can find something that is, simultaneously, computationally cheap to run, very hard to rewrite, and fairly insensitive to latency, you are screwed.
There may, in fact, at least for some games, be an aspect of the game that fulfills these criteria. In that case, anybody who wants to crack the game will, indeed, have to spend weeks or months doing real software engineering to re-implement whatever it was that you left off the disk and on your server(assuming a copy of that doesn’t leak on day two, which would be embarassing) in addition to doing the basic cracking work required to defeat the artificial checks and any SSL style verification of the server the game binary is talking to.