Detecting Pirated Copies
Author
How do you go about detecting if a player is using a pirated version of you're game and send them a message back saying pirated copies are not allowed?
This is a pretty large and complex topic. Depending on what type of software you are developing and the architecture it uses will greatly influence the direction you will want to go with for DRM. Without knowing the specifics of your software, here are some general things to think about.
First, what constitutes a "pirated copy". If you mean simply being in possession of your software without buying it, then that means you need hardware node locked licenses so it only runs on the machine a user purchased it from. If users wanted to run it on other machines, then they'd have to buy more licenses. Depending on the type of software you have, this may not be acceptable. That is more on the extreme side of the spectrum, but some types of software require it.
If anyone can be in possession of your software but needs a registration name/key to validate it, then you are looking at some sort of key validation system. If it is "offline", embedded into the program, then people will be able to make "keygens" for it. Trying to detect pirated copies would simply involve checking the registration information against your customer database. You can maintain an activation count based on system information and IP address to know if registrations were shared since the count would be abnormally high compared to the others.
This type of stuff would easily be accomplished through 3rd party software, such as WinLicense or any of the products listed here. The hardest part of doing it yourself is that you have to be well versed in Reverse Engineering and breaking such protections in order to know what to code for and how people are going to try to circumvent your protections. It certainly is possible to make software that is very hard to pirate and would require too much time and effort for people to try and break it, but it would require a lot of time and money to implement such a solution.
Getting into the more technical stuff, the process of sending information between a program and a server is pretty simple. You don't even have to implement anything special nowadays (raw socket programming) since you can just use a HTTP library like cURL and SSL to handle the process. In that case, you setup a traditional web server that is the authentication and then the program connects and sends data back and forth over HTTP. You can create your own custom higher level protocol though if you want, but most of what you will want to do can be accomplished just fine over HTTP.
The biggest challenges will be:
- Making sure people cannot trivially reverse your client/server logic. (You have to continually invest into an EXE protector such as Themida, Safengine, Armadillo, etc... to stay one step ahead of the tools that unpack such things)
- Ensuring you don't code a logic system that can easily be broken. I.e., you code a system vulnerable to replay attacks or one that can be easily exploited.
- And most importantly don't punish your legitimate customers by putting them through DRM hell when pirates could avoid it all. There are tons of references you can look up for this so I won't even list any of the past blunders people have made.
So, like I said before, this is a huge topic and these are just a few starting points. Depending on what type of environment your software runs on and depending on all the specifics of your software, the direction you will want to go will vary. If you can, post some more specific information if you'd like to get some more ideas.
First, what constitutes a "pirated copy". If you mean simply being in possession of your software without buying it, then that means you need hardware node locked licenses so it only runs on the machine a user purchased it from. If users wanted to run it on other machines, then they'd have to buy more licenses. Depending on the type of software you have, this may not be acceptable. That is more on the extreme side of the spectrum, but some types of software require it.
If anyone can be in possession of your software but needs a registration name/key to validate it, then you are looking at some sort of key validation system. If it is "offline", embedded into the program, then people will be able to make "keygens" for it. Trying to detect pirated copies would simply involve checking the registration information against your customer database. You can maintain an activation count based on system information and IP address to know if registrations were shared since the count would be abnormally high compared to the others.
This type of stuff would easily be accomplished through 3rd party software, such as WinLicense or any of the products listed here. The hardest part of doing it yourself is that you have to be well versed in Reverse Engineering and breaking such protections in order to know what to code for and how people are going to try to circumvent your protections. It certainly is possible to make software that is very hard to pirate and would require too much time and effort for people to try and break it, but it would require a lot of time and money to implement such a solution.
Getting into the more technical stuff, the process of sending information between a program and a server is pretty simple. You don't even have to implement anything special nowadays (raw socket programming) since you can just use a HTTP library like cURL and SSL to handle the process. In that case, you setup a traditional web server that is the authentication and then the program connects and sends data back and forth over HTTP. You can create your own custom higher level protocol though if you want, but most of what you will want to do can be accomplished just fine over HTTP.
The biggest challenges will be:
- Making sure people cannot trivially reverse your client/server logic. (You have to continually invest into an EXE protector such as Themida, Safengine, Armadillo, etc... to stay one step ahead of the tools that unpack such things)
- Ensuring you don't code a logic system that can easily be broken. I.e., you code a system vulnerable to replay attacks or one that can be easily exploited.
- And most importantly don't punish your legitimate customers by putting them through DRM hell when pirates could avoid it all. There are tons of references you can look up for this so I won't even list any of the past blunders people have made.
So, like I said before, this is a huge topic and these are just a few starting points. Depending on what type of environment your software runs on and depending on all the specifics of your software, the direction you will want to go will vary. If you can, post some more specific information if you'd like to get some more ideas.
In what context?
If your game is online, you can cut out the posibility of pirate copies connecting to your servers by attaching purchases to an account and requiring a login.
You can also attach a licence key to the game which the game sends to the server on connect; if you then make the server check these incoming ID;s you can be certain that no more than 1 person can then connect per purchased copy.
If the game is single player this is harder. You will face various ethical issues; besides that, the first crack to come out will have removed the "feature". You may as well not bother in this situation.
If a user requires technical support, it would be prudent to check if they are a customer; this can be again done through licence keys.
The most important thing to remember when considering the use of any kind of DRM is that if you affect your genuine customers you will lose far more money than you gained from the (impossible to calculate) number of potential customers who went with a pirate copy. Its impossible to know how many people will buy it if a pirate copy is not available.
Classic example:
I bought a game which came with Securom. It didn't work in my machine, refusing to recognise the DVD. So I was forced to install a crack to run what I had just paid for; but if the crack was available anyway, then Securom was pointless in the first place.
If your game is online, you can cut out the posibility of pirate copies connecting to your servers by attaching purchases to an account and requiring a login.
You can also attach a licence key to the game which the game sends to the server on connect; if you then make the server check these incoming ID;s you can be certain that no more than 1 person can then connect per purchased copy.
If the game is single player this is harder. You will face various ethical issues; besides that, the first crack to come out will have removed the "feature". You may as well not bother in this situation.
If a user requires technical support, it would be prudent to check if they are a customer; this can be again done through licence keys.
The most important thing to remember when considering the use of any kind of DRM is that if you affect your genuine customers you will lose far more money than you gained from the (impossible to calculate) number of potential customers who went with a pirate copy. Its impossible to know how many people will buy it if a pirate copy is not available.
Classic example:
I bought a game which came with Securom. It didn't work in my machine, refusing to recognise the DVD. So I was forced to install a crack to run what I had just paid for; but if the crack was available anyway, then Securom was pointless in the first place.
How do you go about detecting if a player is using a pirated version of you're game and send them a message back saying pirated copies are not allowed?
You make the game software freely available, so that copying it is a GOOD thing. Then you gate the actual content that users want behind a network log-in, which is tied to the money you want to extract -- say, a credit card number. Make sure that not more than one game can be logged in at the same time, and you're good!
Btw: If your game is inherently about consuming content (single player) rather than interacting (multiplayer), then this is harder, because a "crack" could be written that pretends to be a server that says it's OK to show the content. The solution to this is to gate the actual content server-side, and not cache it on the client. (Think "Netflix")
You make the game software freely available, so that copying it is a GOOD thing. Then you gate the actual content that users want behind a network log-in, which is tied to the money you want to extract -- say, a credit card number. Make sure that not more than one game can be logged in at the same time, and you're good!
Btw: If your game is inherently about consuming content (single player) rather than interacting (multiplayer), then this is harder, because a "crack" could be written that pretends to be a server that says it's OK to show the content. The solution to this is to gate the actual content server-side, and not cache it on the client. (Think "Netflix")
This pricing model is somewhat controversial though. You may lose customers this way. Market research is key here.
This pricing model is somewhat controversial though. You may lose customers this way. Market research is key here.
What's controversial about the WoW/Netflix pricing model (subscription), or the Wizard101/DnDOnline/Zynga pricing model (microtransactions)?
Both of them make money, and don't worry about piracy. Neither of them seems to lose a lot of customers because of their method of making money.
What's controversial about the WoW/Netflix pricing model (subscription), or the Wizard101/DnDOnline/Zynga pricing model (microtransactions)?
Both of them make money, and don't worry about piracy. Neither of them seems to lose a lot of customers because of their method of making money.
Perhaps you're right; some people don't want to have to pay money for anything, and those people will always kick up a stink.
Author
Great answers guys , il probably use a cdkey method so there is no way they can connect,could you use a cdkey to unlock offline mode to , so they would need to be online just to send there key to my server and unlock offline mode, would that work?
What's controversial about the WoW/Netflix pricing model (subscription), or the Wizard101/DnDOnline/Zynga pricing model (microtransactions)?
Both of them make money, and don't worry about piracy. Neither of them seems to lose a lot of customers because of their method of making money.
The controversial part is forcing server connect for single player games. Especially if you are going to netflix the content (no local storage 100% stream) so that load times explode. Heck even steam has off line mode and people still complain about that quite often.
Great answers guys , il probably use a cdkey method so there is no way they can connect,could you use a cdkey to unlock offline mode to , so they would need to be online just to send there key to my server and unlock offline mode, would that work?
Yes, you can clearly implement the following mechanism:
1) Program starts up
2) If program finds the right value in the registry, keep going.
3) If the right value is not in the registry, prompt the user for a CD key.
4) Once the CD key is entered, register it with an online server. If you can't get to the server, or the server says the key is already registered, then exit program.
5) Update the registry with the "right value" so that the next start-up works.
Two problems:
a) If something goes wrong between 4) and 5), the user may have "used" the CD key, but not have the right value in the registry. You can ease this by allowing up to N re-registrations within M days, and maybe Q total registrations over time (for backup, re-imaging, new-computer cases).
Someone can figure out either what the value is in the registry, or where the check lives in the code, and patch the code or provide a registry editor that bypasses the check in 2.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
