Copy protection for electronically distributed

Started by
11 comments, last by schattenmaennlein 12 years, 8 months ago
Hi all,

I have an (almost)finished PC-game(300MB) I want to sell and distribute online. Seperately I will launch a freeware version with a lot less content.
It is an offline game written in C using SDL and OpenGL. At the time only for Windows, I will worry about porting it later.

Currently I am working on the copy protection.

I want to
a) prevent casual users from simply copying the registered game
b) be able to change the protection on upgrades if need arises(I will update the game monthly)

As I understand it the most common way of getting basic protection is to put some type of more or less hidden key on the system.
Which happens as simple as a registry entry or as intrusive as direct disk access or even messing around with the OS itself.

I am not going to do anything intrusive and making a registry entry seems a little bit too simple(people would merely have to copy the key).
Although this is probably something I also should do.

Then protections requiring online log-in have been mentioned. I don't like these either because I think being connected to the internet should
be optional. I think people should be able to install the game on their offline laptop and register it wherever. Also I'd like to avoid dealing with peoples firewalls.

So my method of choice is to generate an user id based on whatever unique/semi-unique information I can find and create a request code based on that.
It does not need to be 100% unique, just enough to make copying a little bit harder than watching registry changes.
I think if cracking the game needs at least the use of a disassembler or hexeditor it will limit the people capable and willing to make the effort drastically.
I imagine this will end in a cracker either faking a different user id/request code or working out how the responsecode has to be, or what variables
have to be altered to pass the test. At which point I can do stuff like hidden checks and let the program pretend to be cracked but crash
after X hours. Just to generate some revenue.

Or so I think, but I am an amateur. So my questions are:

Is this reasonable?
What kind of information should I use to make the request code a different one on different machines and how do I access it?

Thank You
Advertisement
Honestly, I wouldn't put too much time into it. I guarantee that no matter what you do, someone with too much time on their hands will dedicate themselves to breaking your system.

I'd go more along the route of a "pay what you want" system. You'd be surprised at how many people will pay and the people that don't wouldn't have paid anyway. Given your self-confessed status as an amateur, I'd be more concerned with getting as many people as possible to play your game without worrying about getting money for it.
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight
A "good" system is an algorithmic one. Basically your program asks a control server a question and knows based on the content of the response if it's genuine or not. This often takes the form of some computed hash that your program can reverse back to its original state and therefore "see" it's good. This is good until your algorithm is cracked but it's about the best you can reliably do. Anything else is simply too easily bypassed. However, unless you're a mathematician you're not too likely to come up with a complex enough algorithm to be worth implementing though there are a ton of math resources out there you could look into.
What information should I use to identify the user and how is it accessed? Does this have to be OS-specific?
I would probably modify a necessary and always ran file to hard code some sort of ID token upon a successful registration along with the computer name. Then upon each run, send the ID token but respond with the computer name. The app then compares the computer name your auth server responded with and the computer name of the local computer. Match? Great! No match? Show em the registration screen.
the OP wants something that works also offline.

I agree with the suggestion of not loosing your sleep over this one.

look into WMI to access hardware information needed to generate a machine almost unique request code. Write an algorhithm to transform that request code into an unlock code and implement it in the game and on a server side script or webservice.
The user provides the request code together with some credential (email, buying code) that get validated by the server with a "user DB", if the user is found, the server sends back a valid unlock code.

Be VERY careful with WMI.. if you choose the wrong things to generate ur request codes you can quickly get in trouble.. for example, in my first game I used the CPU speed as one of the elements to generate the request code.. bad mistake, some CPU had different readings and some user had to constantly reactivate the software.
After 3 spent answering support requests my game was cracked and I realized how stupid it was to waste such a long time on an aggressive protection scheme.. after 1 week a patch was out that simply used the player "character name" to generate the request code.. and that's good enough to make sure that the ones willing to pay will.

We're trying to make games here.. pirates are just a bunch of retarded monkeys with too much time to waste.. dont waste your time trying to get around them, they have much more time you'll ever had.

Stefano Casillo
TWITTER: [twitter]KunosStefano[/twitter]
AssettoCorsa - netKar PRO - Kunos Simulazioni

I didn't see the offline requirement. /shrug

Just saw your rant about pirates and figured I'd plug this in here: http://yro.slashdot....-Good-Customers

Enjoy :cool:
hm i think the slashdot link is talking about "pirates" that download stuff.. my rant was directed to "pirates" that hack stuff.. .should we call them hackers?

Stefano Casillo
TWITTER: [twitter]KunosStefano[/twitter]
AssettoCorsa - netKar PRO - Kunos Simulazioni

If you wish to make that distinction go ahead.

I would probably modify a necessary and always ran file to hard code some sort of ID token upon a successful registration along with the computer name. Then upon each run, send the ID token but respond with the computer name. The app then compares the computer name your auth server responded with and the computer name of the local computer. Match? Great! No match? Show em the registration screen.

They should be able to register multiple computers. It would be very unfriendly to force them to register again and purchase a second copy just to run the game on their laptop instead of their desktop.

This topic is closed to new replies.

Advertisement