I have created a desktop application(winfoms) using C#.net 3.5, the application is an SEO application, so it has to be connected to the internet, i implemented a simple licensing routine where every time the application is started it will query the web service on my server with the key and machine hash to validate.

But recently i have noticed that some "crackers" have disabled the license verification (simply removed the lines of code that does that) of the application which i have obfuscated, and the sad thing is that they are selling it at a cost that is only 10% of what i am selling for, they didn't even bother to remove my website address and company details from the about box. The application is having an auto-update feature, which they so-called crackers have intentionally left it on in the cracked version

I was just trying to figure out a way out of this, i can release an update and disable all the versions that are brought from the crackers, but without a proper licensing it will broken again and the next time, i don't have the guarantee that they will keep the auto update feature on.

  • I have already checked this stackoverflow.com/questions/2923166/… question it is not related
    – Vamsi Krishna
    Nov 3, 2011 at 11:26
  • that's what you get if you depend on the client to do license verification... Should have kept core functionality on the server, and require a valid account in order to access that functionality.
    – jwenting
    Nov 3, 2011 at 12:06
  • @jwenting I agree with you, but the problem is that there will be too much data to be handled by the server, as the application has already reached more than 500 users and the data each user processes is more than 5 MB per request and there are like 15 request by user on an average day, which adds up-to around 10-20 GB per day(based on the number of users active.
    – Vamsi Krishna
    Nov 3, 2011 at 12:13
  • 1
    @VamsiKrishna - At this point there is nothing you can do about those cracked copies that currently exist. You can contact the owners of the website in question, request they stop selling your application, and if they do not comply with your request sue them. Going forward change the authentication model, require the user to supply their own username and password plus a authentication key on startup. Only allow one machine per account at a time. Intialize your program based on outputs from the server. Just make it to much of a hassel to pirate.
    – Ramhound
    Nov 3, 2011 at 13:26
  • I outlined it below, but since you said you have auto-update and can disable the cracked copies. That leaves you an opportunity to try and convert the people who bought illegal copies to your side, and in your next version make it tougher for the crackers. Since you have auto-update, you can pretty much solve many of your problems.
    – CaffGeek
    Nov 3, 2011 at 14:39

4 Answers 4


In your next update, if it's pushed down to the cracked versions automatically, add an update to the app that alerts the users that they bought a cracked version.

Inform them their copy is illegal, and will be disabled in X days. Don't leave them out in the cold. Offer a discounted rate to get a valid copy. Something like 50%. Entice them to become your customers.

By offering a discount, and not just shutting them down the users will hopefully take it as a sign of good faith, and switch. Some won't.

However, their software is updating through you, so you have more control than the crackers, and they aren't going to keep buying it from them, nor get support. They will realize if it's a worthy product, they are better getting it from you.

As for preventing future purchases from crackers. Try and sneak in some 'unique' code into each version downloaded. That way you can determine which person is buying your software and reselling it. IANAL, so consult one, but it would aid the authorities if you chose legal action.

Also, improve your authentication verification in the next version. Leave parts of the app out, and require that they be downloaded at login. Have some files encrypted, and require they go to your server to be decrypted. The more you make the crackers have to do, to crack, the better.


There is no sure way of preventing this. What you really want to aim for is to make it take longer or be more hassle to "hack" your software than it is to just buy it from you.

Or, seeing as your application always has to be connected to the web you could implement a user login system, whereby everyone who purchases your software gets a username and a password that verifies itself to your server every time the application loads.

You can make it so that a particular username and password combination can only be logged in in one place at any particular time.

If you have ever used Steam, this is basically what it does.

It won't prevent someone distributing their username and password but if they are continually kicked off whenever someone else is using the same one it'll get annoying.

That being said, I am no lawyer and I am not sure if there are legal issues around calling home with a username and password every time the application launches. I assume you'd have to clearly tell your user that they must agree to this else the software doesn't work, but it's best looking into that. (You're probably fine given that you already query a web service every time the application loads).

As for forcing an update, I am not sure. You may just have to cut your losses and release all future versions with a new system.

  • 1
    But the primary "crack" is still present, the cracker can still remove the login code and simply skip ahead
    – Vamsi Krishna
    Nov 3, 2011 at 12:26
  • Ah yes. Good point. I'll think more on this.
    – AndrewC
    Nov 3, 2011 at 16:11

Unfortunately, as long as it is a client application, you will probably have to spend considerable time trying to stay ahead of the 'crackers'.

To get around this, one method would be to move some of the 'business logic' of the application on to your own servers. So for some functionality, it has to call your server (with licensing details) to calculate the result. This would help stop them from being able to circumvent licensing.

Obviously that means it is more expensive running costs for you per user.

If they is completely out of the option, try the following approach:

Have core parameters used in your application stored server side. The each time the application is opened, as part of the licensing check, return these core parameters used by the system.

I'm sure you get the idea here. You have to have something on your servers that the application needs to run to stop crackers from simply disabling authorization.

  • 1
    Unless those "core parameters" are always changing, the crackers could just add them to the code base.
    – CaffGeek
    Nov 3, 2011 at 13:31
  • @Chad, hence the first line. At least this way they would have to actually register the product once to be able to get these core parameters. If you are smart enough, you could arrange for a particular parameter to be unique per user. It might help you track down who is actually doing it. Nov 3, 2011 at 14:38

the problem is that there will be too much data to be handled by the server, as the application has already reached more than 500 users and the data each user processes is more than 5 MB per request and there are like 15 request by user on an average day

Considering the size of your requests, adding a few dozen more characters to each request for a license key will have nearly zero cost. Indeed, if you're not already including some identifier that links each request to the user, you probably should be. You don't tell us what your app does, but perhaps adding such an identifier would let you store more data on your server, which might significantly reduce the amount of data that you need to transfer with each request.

  • The application does not send any data to the server now, i was just saying that the amount of data to be handled by the server would be very high if the data is sent to the server by all the client applications
    – Vamsi
    Nov 4, 2011 at 5:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.