Sign in to follow this  
BeanDog

Copy protection?

Recommended Posts

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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 );

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 );

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by RunningInt
I believe under this strategy someone could simply send a random ID to the PHP page and recieve a new 30-day trial registration

The client itself will recheck the registration code to ensure it's actually associated with the ID.

Of course, that could be circumvented by cracking the client so that it thinks you have whatever ID you want it to think you have. You can change it twice a month and still be within the 5/ID changes-per-month limitation.

So it's not impossible, but it's a little more tricky than just sending a random ID via your browser.

Share this post


Link to post
Share on other sites
If you really need copy protection, then you should probably license something like FlexLM. People who have to deal with software on a daily basis know how it works, and it helps keep honest people honest. Meanwhile, crackers will always have cracked copies of all software.

If you're thinking more of a shareware registration scheme, then add a nag screen after a 15 day trial, that's short enough that nobody really needs to crack it, and remove the nag screen with a hash of name, e-mail address and a secret key. When they pay, they supply their name and e-mail address, and you send them the appropriate hash to enter into the software. The splash screen and about boxes will then show the name and e-mail addresses -- some small defense against people trying to post authentication codes on the web. (Most people who pay for shareware actually believe you're worth the money, so they're less likely to do that -- but it could still happen)

Share this post


Link to post
Share on other sites
Beware: transmitting uniqueness information, particularly "identifying" uniqueness information without someones knowledge and authorisation is a legal minefield that others have had problems with; tread carefully.


Suggestion: for personal education, get a trial of someone elses software using a similar scheme and try to crack it; unless you can think like a cracker and know how they will attack your security, you'll miss some very obvious ways to knobble your system.
Hint: the moment you display that "your trial has expired" dialog, you can wave goodbye to your protection - it doesn't take long with WinDBG and decent asm knowledge to work back to the key check from there - once the key method is understood, it doesn't take much to do a static code pattern search to find similar code constructs (or worse, the non-inlined functions which do the test(s)).


Suggestion: Writing Secure Code is a good book to read/own/borrow - it won't tell you how to write a protection system or how to crack, but it will get you thinking the right way.


Concern: "the last registry code the computer got from the web server" that has to be stored somewhere for times when the machine is offline (registry, file, self modifying code etc).
The better hidden that storage is, the more you'll annoy some people (cf. recent Sony DRM rootkit debacle), and the more you'll trip heuristics of various virus and spyware scanners.
The fact that your user validity information is stored somewhere on the machine and retrieved somehow by the program is your biggest weakness. I can use RegMon to watch you read the specially renamed key in the registry; I can use FileMon to watch you hide that NotMyProtection.dat file in Windows\System; I can use DiskMon to watch you do that raw sector read; I can use RootKitRevealer to spot your kernel filter driver that's trying to hide the above.


Suggestion: don't go too low level when hiding stuff on the machine; unless you have access to a major compatibility lab that is - a number of *commercial* copy protection schemes caused products to have 1000s of returns due to checking protected CD-ROMs by raw-reading parts of the CD and only working if the magic location failed the CRC check; what they didn't count on was CD-ROM drive manufacturers being helpful and doing hardware CRC recalculation on the bad data (idea being that some of the data on a scratched disc may still be ok, so auto-correct - designed for audio where a millisecond of noise is better than a whole block being skipped).


Thought: you can store more than just a key on the valid machine; consider vital data and/or program code - encrypted with the same uniqueness information. But have a solid plan for still working with changes in uniqueness (e.g someone changes network card and their MAC address differs).


Corollary: the better and more up-front your protection is, the more incentive there is to crack it (anyone remember the hardware dongle protected Robocop game on the Amiga?[wink]). The simpler protection schemes that don't do what everyone else does and don't advertise much can be surprisingly good (personal experience: it took 3 cracks to remove a simple "CD must be in the drive for the game to work" check I had to put in for a product I worked on many many moons ago[wink])


Suggestion: build value into owning a full/original version of your software - updates, tech support, a printed manual, etc. Also don't make the trial as complete as the full version - otherwise the crackers will attack your timeout code directly and just make it never count down.


Fact: if a product is going to be usable enough to not p*ss your customers off or have crazy physical security requirements (smart cards, fingerprint scanners etc [grin]), it'll get cracked. If it's popular that is. If it isn't popular, it won't be on anyone's radar.

Share this post


Link to post
Share on other sites
IMHO all software protection schema is crackable. Its only a question of time, so for instance, if your software/game has a lifetime of one year, you don't need a complex protection schema, jsut beacause in one year probably nobody will use your software/game and you will supply the source code =). So its a question of software quality/desire/life time to the cracker to do or not to do a crack.

I belive that cryptography, digital signatures and remote authentication CAN prevent, for a quite BIT of time (ages lol), software copying. Also, automatic update from a trusted server can dificult the cracker task. Offline software protection its more passive of cracking.

Sorry bad english lol

Share this post


Link to post
Share on other sites
Internet access is only needed at the time of purchase (to get the code from the server) and then again when hardware changes. "Hardware" includes CPU, motherboard, primary hard drive, and NIC. These are unlikely to change every week. USB devices won't mess it up.

A firewall would have to block the HTTP port to all but a specific list of servers for it to keep me from retrieving a key from my server, since I'm just sending an HTTP request to my server for a PHP page and taking the result as my code. Even in those cases, a registered user can log in anywhere, type in the computer ID (visible on the About screen), and get back a valid registration code. Maybe a little bit of a hassle, but again, only when they get a new motherboard or something.

My approach is keenly vulnerable to someone making a keygen utility. That is, all a computer needs is a matching key to its computer ID. With a keygen, anyone could manage it. I'm just confident nobody will care enough to make a keygen utility :-)

The idea, of course, is that you just can't give other people your code and have all your friends instantly have fully-registered copies of the software. I experienced one of the major headaches of this approach recently when I installed a new motherboard and my OEM Windows XP simply would NOT let me in. So I understand the hassle it can be to users. But I'm not keeping them from booting up; I'm just having them run a PHP script on my server when they make major hardware changes.

I realize I can't stop all hackers; that's impossible. I figure that if I, as your average Joe Blow programmer, can't figure a way around it, most of my users (Joe Blow programmers) won't care enough to figure out how.

Without some kind of access to a remote source of registration keys, though, it's impossible to keep users from simply reusing the same registration key again and again. Isn't it?

Thanks for the input.



~BenDilts( void );

Share this post


Link to post
Share on other sites
Quote:
Original post by BeanDog
Internet access is only needed at the time of purchase (to get the code from the server) and then again when hardware changes. "Hardware" includes CPU, motherboard, primary hard drive, and NIC. These are unlikely to change every week. USB devices won't mess it up.

Then there's little point checking the ID "at various places scattered through the program code". Unless you think it terribly likely that the user will replace their CPU, motherboard, hard disk or NIC whilst using the program.
Quote:

A firewall would have to block the HTTP port to all but a specific list of servers for it to keep me from retrieving a key from my server, since I'm just sending an HTTP request to my server for a PHP page and taking the result as my code.

It's not uncommon for a firewall to be configured to disallow all connections by default, and then make exceptions. I doubt that's common for firewalls used on personal computers, so if your program isn't intended for corporate use, that might not be a problem.
Quote:

My approach is keenly vulnerable to someone making a keygen utility. That is, all a computer needs is a matching key to its computer ID. With a keygen, anyone could manage it.

This really depends upon the complexity of the key. If your site generates an encrypted license file, it could be impossible to generate a fake one without knowing your site's private key. Although, a cracker could just replace the public key, which would need to stored inside the client. So ignore that.
Quote:

I'm just confident nobody will care enough to make a keygen utility :-)
...
The idea, of course, is that you just can't give other people your code and have all your friends instantly have fully-registered copies of the software.

If all my friends want copies of the software, then it's all the more likely that somebody will care enough to make a keygen utility. If nobody wants to make a keygen, it's because the program sucks or is not of interest to a wide group. If that's the case, people aren't going to be sharing it with their friends anyway, so what does this draconian copy protection system buy you?
Quote:

I realize I can't stop all hackers; that's impossible. I figure that if I, as your average Joe Blow programmer, can't figure a way around it, most of my users (Joe Blow programmers) won't care enough to figure out how.

But you've already figured out several ways around it.
Quote:

Without some kind of access to a remote source of registration keys, though, it's impossible to keep users from simply reusing the same registration key again and again. Isn't it?

The key could contain the date it was obtained, so it would be good for 30 days from when you register it, regardless of when you install. The key could also contain the hardware ID. This would be easy if you didn't have a particular need for the key to be short enough to write down in a few seconds. Of course, it would be no less crackable than a short key, but it might be better for the user: you wouldn't need to connect to the site because we'd automagically know if the current hardware ID matched up with the one it was registered with.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nathan Baum
Quote:
Original post by BeanDog
Internet access is only needed at the time of purchase (to get the code from the server) and then again when hardware changes. "Hardware" includes CPU, motherboard, primary hard drive, and NIC. These are unlikely to change every week. USB devices won't mess it up.

Then there's little point checking the ID "at various places scattered through the program code". Unless you think it terribly likely that the user will replace their CPU, motherboard, hard disk or NIC whilst using the program.


The idea was to aggravate people using disassemblers to change the code, not to continue making sure the program is registered as the program continues.



~BenDilts( void );

Share this post


Link to post
Share on other sites
Just make sure that when you connect to that PHP script, you use (or give the option of using) IE's proxy settings, rather than only attempting a direct connection. People in university and any medium-to-large company will likely be behind some kind of proxy, and if your registration doesn't work because it uses plain sockets and attempts a direct connection (instead of going through the inet API, or similar), then they're gonna be pissed off.

Second, I have a question on this topic: What methods are there to detect the types of tools that crackers use to crack software? Is there a reliable way to detect debuggers trying to attach to your program, or breakpoints being set, etc?

John B

Share this post


Link to post
Share on other sites
Quote:
Original post by BeanDog
I realize I can't stop all hackers; that's impossible. I figure that if I, as your average Joe Blow programmer, can't figure a way around it, most of my users (Joe Blow programmers) won't care enough to figure out how.


But, all it takes is ONE, single genius John Smith programmer to get around it and post a crack or workaround somewhere. Then even the dumbest pirate (yarr!) can use it.

Thats why only the simplest copy protection schemes are worth the time invested. And make damn sure it doesnt hurt your legit users.

Share this post


Link to post
Share on other sites
Quote:
Original post by BeanDog
Quote:
Original post by Nathan Baum
Quote:
Original post by BeanDog
Internet access is only needed at the time of purchase (to get the code from the server) and then again when hardware changes. "Hardware" includes CPU, motherboard, primary hard drive, and NIC. These are unlikely to change every week. USB devices won't mess it up.

Then there's little point checking the ID "at various places scattered through the program code". Unless you think it terribly likely that the user will replace their CPU, motherboard, hard disk or NIC whilst using the program.

The idea was to aggravate people using disassemblers to change the code, not to continue making sure the program is registered as the program continues.

Well, that wouldn't work. If I wanted to make a program believe that I had a particular hardware setup, I wouldn't even look at the object code: I'd hook the system calls which it uses to see what hardware is attached.

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBSmall
[...]Second, I have a question on this topic: What methods are there to detect the types of tools that crackers use to crack software? Is there a reliable way to detect debuggers trying to attach to your program, or breakpoints being set, etc?

John B
There are some methods to detect specific tools, but essentially the hacker can just run windows in an emulator and have full access to every piece of data in the hardware, including any memory addresses, etc.

I've looked through the book Crackproof Your Software: Protect Your Software Against Crackers(ISBN: 1886411794) in a bookstore, and it seemed to have decent information, but it also mentions repeatedly how it is impossible to make entirely crackproof software. If you want to make seriously secure (from cracking, as opposed to cryptographic security) software, you'll have to read many, many books and become very familiar with many things before you can do so with any hope of success. There is a reason that even commercial protection is regularly cracked, and it isn't because they're making it easy on purpose. The problem is simply that current machine architectures were never meant to protect software from mailicous users, and in fact actually go quite far in the opposite direction with the goal of making development (and related tasks such as debugging) easier.

Share this post


Link to post
Share on other sites
Quote:
Original post by Trap
http://www.gdconf.com/conference/archives/2004/simon_erik.pdf is a good read for anything else.

Interesting read indeed.

Short summary of the central hypothesis:
-100% secure copy protection is impossible.
-Secure-enough copy protection (that buys you some weeks until it's cracked) is possible.
-If every game had this kind of copy protection, crackers wouldn't be able to keep up with the work.

I think it's an interesting view to keep in mind, quite different to the common "don't bother" attitude. Obviously, this only applies to games and their "must sell lots of units in the first month" market.

The only part I don't really buy is this one:
Quote:

despite the world-wide network of cracking groups there are not awfully many cracker . The number of highly talented crackers who can attack new protection code lies around 12 Persons world-wide. Additionally, there are "retired" Crackers who might react to a call for help and programmers with a Cracker's skillset who are not Scene members. There are roughly 30 of these.

These numbers seem extremely low. 30 programmers with a Cracker's skillset worldwide? What kind of skills do you need beyond strong assembly "debugging" and "puzzle solving" skills?


Quote:
Original post by BeanDog
The idea was to aggravate people using disassemblers to change the code,

I think here lies the big weakness of your scheme. It only stops people from sharing serial numbers, but not from cracking it. Sprinkling the code with multiple tests is a nice start, but not nearly enough. The web server lookup actually weakens your position in this context.

Share this post


Link to post
Share on other sites
Quote:
Original post by samv
Quote:
Original post by Trap
http://www.gdconf.com/conference/archives/2004/simon_erik.pdf is a good read for anything else.

Interesting read indeed.

Short summary of the central hypothesis:
-100% secure copy protection is impossible.
-Secure-enough copy protection (that buys you some weeks until it's cracked) is possible.
-If every game had this kind of copy protection, crackers wouldn't be able to keep up with the work.

Neither would the programmers. "Secure-enough" copy protection is "secure-enough" because nobody has seen it before. Programmers would have to develop an entirely new copy protection scheme for each game. One obvious consequence of this is that it would soon become nontrivial to make "secure-enough" copy protection: imagine if each time you wanted to sort a list, you had to use a different sort algorithm. By the tenth sort operation, you'd probably be out of ideas.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nathan Baum
One obvious consequence of this is that it would soon become nontrivial to make "secure-enough" copy protection:

Nobody said it would be trivial. But considering the budget of AAA games and the alleged losses caused by piracy, even a nontrivial effort wouldn't be inappropriate.
Quote:

imagine if each time you wanted to sort a list, you had to use a different sort algorithm. By the tenth sort operation, you'd probably be out of ideas.

Imagine if each time you wanted to design a game(/compose a song/design a level/...), you had to use a different game mechanic(/melody/layout/...). [WINK]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this