All copy-protected software can be cracked. The idea is to make it harder for the bad guys to crack your program than to remake it. That seems pretty tough :-p Any good pointers on protecting commercial software? [edit] Please read my reply below. ~BenDilts( void ); [Edited by - BeanDog on November 24, 2005 4:24:43 PM]

Sell access to stuff running on your computers. Like WoW.

http://www.gdconf.com/conference/archives/2004/simon_erik.pdf is a good read for anything else. I haven't seen any serious copy protection scheme yet, so you might as well don't use any.

You could also do something like Valve's Steam, but AFAIK someone can still get around it.

I don't have any numbers to back it up, but my gut feeling is that in many cases piracy isn't hurting sales much. Unless you've got a triple A must have game, I suspect that most people pirating still wouldn't buy the game if they couldn't get around the DRM. Plus the more people playing the game, the more free word of mouth advertising you're getting, leading to increased awareness of the title and likely increased sales.

Having said that, I understand why companies want to copy protect their game (and I don't advocate piracy in any form)- but since a game is going to get cracked regardless, any time you put into copy protection beyond the point where the average user can't crack it himself, would probably be better spent on other parts of the game.

Or as mentioned above you could take the MMORPG route, but if you go that way keep in mind that you aren't really selling a game, you're selling a service.

Let me tell you what I had in mind:

A computer ID is generated from hardware serial numbers. This ID is hashed and then used as a key to a standard encryption algorithm. Integrated into the program (not a game, sorry guys) is a registration form that hits up a web server's publicly-available PHP page, passing in the computer's ID and getting back a registration code. If that computer ID has been registered with the server as a paying user, they get a permanent registration code. Otherwise they get a 30-day trial code. The trial code is logged in a database on the web server, so even if the user formats his computer and reinstalls, his trial won't start over.

At program startup (and at various places scattered through the program code), the program gets the computer's ID, hashes it, encrypts it, and checks it against the last registry code the computer got from the web server. If it matches, the program starts up fine. Otherwise, the user is prompted to register for a trial or purchase the software.

A paying user would be able to go to a fully-automated web site and retrieve a new registration code if his computer's hardware changed significantly. After a reasonable number of codes (say, 5 within a month), the user has to email technical support for permission to get another registration code.

A normal e-commerce web site would sell password-protected access to the registration code-producing page.

Anything wrong with this picture?



~BenDilts( void );

To make it short: that scheme sucks. Just think about what you're trying to do. You're not binding the software to a user, but to a computer. You don't want that in most cases. You want to verify that the person using the software has the right to do so, and you don't want to make that person suffer from the fact that his old computer hast broken down and he's got no internet access. With your scheme, there's just two possible solutions: (1) the user is just... uhm... you know what I mean, or (2) the scheme grants access until net access is restored. You definitely don't want nr. 1 lest thine userbase runneth away, and nr. 2 means free (as in beer) use on machines not connected to the net. And no, requiring net access every so often is not an option since that would still make it impossible to use your software on machines that just aren't allowed to access the internet for security reasons.

I don't think there's any copy control scheme that doesn't cause considerable inconvenience to the user, and as soon as it does that, it's effectively better for the user to get a pirated, cracked version. In the last six months, I haven't bought about 5 games that I really would have loved to play just because they use a CC scheme (*cough*starforce*cough*) that installs mysterious drivers, and which I consider borderline criminal. See Sony for the logical continuation of that theme.

Quote:Original post by BeanDog
At program startup (and at various places scattered through the program code), the program gets the computer's ID, hashes it, encrypts it, and checks it against the last registry code the computer got from the web server.

Anything wrong with this picture?

99% of all copy protections are similar your sketch. They get cracked every day.

Quote:Original post by Trap
99% of all copy protections are similar your sketch. They get cracked every day.

Thanks for the useful tip. Now I know how to fix my problem.



~BenDilts( void );

What else should I tell you? If your software is popular enough, somebody will try to crack it and if he is skilled enough he will succeed.

You can spend your development time on developing a copy protection that will be cracked or spend it on developing useful features that make your software worth buying. I don't know which of this two options is earning you more money, that's something you have to decide.
All I know is: you have to invest a big amount of time in developing the copy protection to stop even novice crackers (though any protection will stop average users). Once there is a crack your whole protection development time is wasted.

Quote:Original post by BeanDog
Let me tell you what I had in mind:

A computer ID is generated from hardware serial numbers. This ID is hashed and then used as a key to a standard encryption algorithm. Integrated into the program (not a game, sorry guys) is a registration form that hits up a web server's publicly-available PHP page, passing in the computer's ID and getting back a registration code. If that computer ID has been registered with the server as a paying user, they get a permanent registration code. Otherwise they get a 30-day trial code. The trial code is logged in a database on the web server, so even if the user formats his computer and reinstalls, his trial won't start over.

At program startup (and at various places scattered through the program code), the program gets the computer's ID, hashes it, encrypts it, and checks it against the last registry code the computer got from the web server. If it matches, the program starts up fine. <snipped>

I believe under this strategy someone could simply send a random ID to the PHP page and recieve a new 30-day trial registration

Quote:Original post by BeanDog
Let me tell you what I had in mind:

A computer ID is generated from hardware serial numbers. This ID is hashed and then used as a key to a standard encryption algorithm. Integrated into the program (not a game, sorry guys) is a registration form that hits up a web server's publicly-available PHP page, passing in the computer's ID and getting back a registration code. If that computer ID has been registered with the server as a paying user, they get a permanent registration code. Otherwise they get a 30-day trial code.

What if I have my proxy redirect your program's requests to a fake server I've set up?

Quote:
The trial code is logged in a database on the web server, so even if the user formats his computer and reinstalls, his trial won't start over.

So if he sells his computer to somebody else, they don't get a trial unless they also buy some new hardware?

Quote:
At program startup (and at various places scattered through the program code), the program gets the computer's ID, hashes it, encrypts it, and checks it against the last registry code the computer got from the web server. If it matches, the program starts up fine. Otherwise, the user is prompted to register for a trial or purchase the software.

I'm curious about this "various places scattered through the program code". Are you going to make a trial user restart his trial if he attaches a USB device? What if he inserts a hot-pluggable PCI card?

What if they're not online? Do they just not get to use your program?

What if they're behind a very stern firewall? You expect them to losen their security because your application happens to want to phone home before and during its execution?

Quote:
A paying user would be able to go to a fully-automated web site and retrieve a new registration code if his computer's hardware changed significantly. After a reasonable number of codes (say, 5 within a month), the user has to email technical support for permission to get another registration code.

That's reasonable? Perhaps it is for you. What about sites which might habitually change their hardware configurations more than 5 times a month?

Quote:
Anything wrong with this picture?

It won't prevent piracy, and will inconvience legitimate users. It doesn't matter how clever your server is: they only need to crack the client.