Related
I'm currently involved in developing a product (developed in C#) that'll be available for downloading and installing for free but in a very limited version. To get access to all the features the user has to pay a license fee and receive a key. That key will then be entered into the application to "unlock" the full version.
As using a license key like that is kind of usual I'm wondering :
How's that usually solved?
How can I generate the key and how can it be validated by the application?
How can I also avoid having a key getting published on the Internet and used by others that haven't paid the license (a key that basically isn't "theirs").
I guess I should also tie the key to the version of application somehow so it'll be possible to charge for new keys in feature versions.
Anything else I should think about in this scenario?
Caveat: you can't prevent users from pirating, but only make it easier for honest users to do the right thing.
Assuming you don't want to do a special build for each user, then:
Generate yourself a secret key for the product
Take the user's name
Concatentate the users name and the secret key and hash with (for example) SHA1
Unpack the SHA1 hash as an alphanumeric string. This is the individual user's "Product Key"
Within the program, do the same hash, and compare with the product key. If equal, OK.
But, I repeat: this won't prevent piracy
I have recently read that this approach is not cryptographically very sound. But this solution is already weak (as the software itself has to include the secret key somewhere), so I don't think this discovery invalidates the solution as far as it goes.
Just thought I really ought to mention this, though; if you're planning to derive something else from this, beware.
There are many ways to generate license keys, but very few of those ways are truly secure. And it's a pity, because for companies, license keys have almost the same value as real cash.
Ideally, you would want your license keys to have the following properties:
Only your company should be able to generate license keys for your products, even if someone completely reverse engineers your products (which WILL happen, I speak from experience). Obfuscating the algorithm or hiding an encryption key within your software is really out of the question if you are serious about controlling licensing. If your product is successful, someone will make a key generator in a matter of days from release.
A license key should be useable on only one computer (or at least you should be able to control this very tightly)
A license key should be short and easy to type or dictate over the phone. You don't want every customer calling the technical support because they don't understand if the key contains a "l" or a "1". Your support department would thank you for this, and you will have lower costs in this area.
So how do you solve these challenges ?
The answer is simple but technically challenging: digital signatures using public key cryptography. Your license keys should be in fact signed "documents", containing some useful data, signed with your company's private key. The signatures should be part of the license key. The product should validate the license keys with the corresponding public key. This way, even if someone has full access to your product's logic, they cannot generate license keys because they don't have the private key. A license key would look like this: BASE32(CONCAT(DATA, PRIVATE_KEY_ENCRYPTED(HASH(DATA))))
The biggest challenge here is that the classical public key algorithms have large signature sizes. RSA512 has an 1024-bit signature. You don't want your license keys to have hundreds of characters.
One of the most powerful approaches is to use elliptic curve cryptography (with careful implementations to avoid the existing patents). ECC keys are like 6 times shorter than RSA keys, for the same strength. You can further reduce the signature sizes using algorithms like the Schnorr digital signature algorithm (patent expired in 2008 - good :) )
This is achievable by product activation (Windows is a good example). Basically, for a customer with a valid license key, you need to generate some "activation data" which is a signed message embedding the computer's hardware id as the signed data. This is usually done over the internet, but only ONCE: the product sends the license key and the computer hardware id to an activation server, and the activation server sends back the signed message (which can also be made short and easy to dictate over the phone). From that moment on, the product does not check the license key at startup, but the activation data, which needs the computer to be the same in order to validate (otherwise, the DATA would be different and the digital signature would not validate). Note that the activation data checking do not require verification over the Internet: it is sufficient to verify the digital signature of the activation data with the public key already embedded in the product.
Well, just eliminate redundant characters like "1", "l", "0", "o" from your keys. Split the license key string into groups of characters.
Simple answer - No matter what scheme you use it can be cracked.
Don't punish honest customers with a system meant to prevent hackers, as hackers will crack it regardless.
A simple hashed code tied to their email or similar is probably good enough. Hardware based IDs always become an issue when people need to reinstall or update hardware.
Good thread on the issue:
http://discuss.joelonsoftware.com/default.asp?biz.5.82298.34
When generating the key, don't forget to concatenate the version and build number to the string you calculate the hash on. That way there won't be a single key that unlocks all everything you ever released.
After you find some keys or patches floating in astalavista.box.sk you'll know that you succeeded in making something popular enough that somebody bothered to crack. Rejoice!
I'm one of the developers behind the Cryptolens software licensing platform and have been working on licensing systems since the age of 14. In this answer, I have included some tips based on experience acquired over the years.
The best way of solving this is by setting up a license key server that each instance of the application will call in order to verify a license key.
Benefits of a license key server
The advantages with a license key server is that:
you can always update or block a license key with immediate effect.
each license key can be locked to certain number of machines (this helps to prevent users from publishing the license key online for others to use).
Considerations
Although verifying licenses online gives you more control over each instance of the application, internet connection is not always present (especially if you target larger enterprises), so we need another way of performing the license key verification.
The solution is to always sign the license key response from the server using a public-key cryptosystem such as RSA or ECC (possibly better if you plan to run on embedded systems). Your application should only have the public key to verify the license key response.
So in case there's no internet connection, you can use the previous license key response instead. Make sure to store both the date and the machine identifier in the response and check that it's not too old (eg. you allow users to be offline at most 30 days, etc) and that the license key response belongs to the correct device.
Note you should always check the certificate of license key response, even if you are connected to the internet), in order to ensure that it has not been changed since it left the server (this still has to be done even if your API to the license key server uses https)
Protecting secret algorithms
Most .NET applications can be reverse engineered quite easily (there is both a diassembler provided by Microsoft to get the IL code and some commercial products can even retrieve the source code in eg. C#). Of course, you can always obfuscate the code, but it's never 100% secure.
I most cases, the purpose of any software licensing solution is to help honest people being honest (i.e. that honest users who are willing to pay don't forget to pay after a trial expires, etc).
However, you may still have some code that you by no means want to leak out to the public (eg. an algorithm to predict stock prices, etc). In this case, the only way to go is to create an API endpoint that your application will call each time the method should be executed. It requires internet connection but it ensures that your secret code is never executed by the client machine.
Implementation
If you don't want to implement everything yourself, I would recommend to take a look at this tutorial (part of Cryptolens)
Besides what has already been stated....
Any use of .NET applications are inherently breakable because of the intermediate language issues. A simple disassembly of the .NET code will open your product to anyone. They can easily bypass your licensing code at that point.
You can't even use hardware values to create a key anymore. Virtual machines now allow someone to create an image of a 'licensed' machine and run it on any platform they choose.
If it's expensive software there are other solutions. If it's not, just make it difficult enough for the casual hacker. And accept the fact that there will be unlicensed copies out there eventually.
If your product is complicated, the inherent support issues will be create some protection for you.
The C# / .NET engine we use for licence key generation is now maintained as open source:
https://github.com/appsoftware/.NET-Licence-Key-Generator.
It's based on a "Partial Key Verification" system which means only a subset of the key that you use to generate the key has to be compiled into your distributable. You create the keys your self, so the licence implementation is unique to your software.
As stated above, if your code can be decompiled, it's relatively easy to circumvent most licencing systems.
I've used Crypkey in the past. It's one of many available.
You can only protect software up to a point with any licensing scheme.
I don't know how elaborate you want to get
but i believe that .net can access the hard drive serial number.
you could have the program send you that and something eles ( like user name and mac address of the nic)
you compute a code based off that and email them back the key.
they will keep them from switching machines after they have the key.
I strongly believe, that only public key cryptography based licensing system is the right approach here, because you don't have to include essential information required for license generation into your sourcecode.
In the past, I've used Treek's Licensing Library many times, because it fullfills this requirements and offers really good price. It uses the same license protection for end users and itself and noone cracked that until now. You can also find good tips on the website to avoid piracy and cracking.
The only way to do everything you asked for is to require an internet access and verification with a server. The application needs to sign in to the server with the key, and then you need to store the session details, like the IP address. This will prevent the key from being used on several different machines. This is usually not very popular with the users of the application, and unless this is a very expensive and complicated application it's not worth it.
You could just have a license key for the application, and then check client side if the key is good, but it is easy to distribute this key to other users, and with a decompiler new keys can be generated.
I've implemented internet-based one-time activation on my company's software (C# .net) that requires a license key that refers to a license stored in the server's database. The software hits the server with the key and is given license information that is then encrypted locally using an RSA key generated from some variables (a combination of CPUID and other stuff that won't change often) on the client computer and then stores it in the registry.
It requires some server-side coding, but it has worked really well for us and I was able to use the same system when we expanded to browser-based software. It also gives your sales people great info about who, where and when the software is being used. Any licensing system that is only handled locally is fully vulnerable to exploitation, especially with reflection in .NET. But, like everyone else has said, no system is wholly secure.
In my opinion, if you aren't using web-based licensing, there's no real point to protecting the software at all. With the headache that DRM can cause, it's not fair to the users who have actually paid for it to suffer.
You can use a free third party solution to handle this for you such as Quantum-Key.Net It's free and handles payments via paypal through a web sales page it creates for you, key issuing via email and locks key use to a specific computer to prevent piracy.
Your should also take care to obfuscate/encrypt your code or it can easily be reverse engineered using software such as De4dot and .NetReflector. A good free code obfuscator is ConfuserEx wich is fast and simple to use and more effective than expensive alternatives.
You should run your finished software through De4Dot and .NetReflector to reverse-engineer it and see what a cracker would see if they did the same thing and to make sure you have not left any important code exposed or undisguised.
Your software will still be crackable but for the casual cracker it may well be enough to put them off and these simple steps will also prevent your code being extracted and re-used.
https://quantum-key.net
How to use ConfuserEx?
https://github.com/0xd4d/de4dot
https://www.red-gate.com/dynamic/products/dotnet-development/reflector/download
I know this is an old question, but I referenced this when I was re-writing my licensing process for one of my applications.
After reading a lot of opinions out there and relying on past experience with license codes I came up with this process.
public static class LicenseGenerator
{
private static string validChars = "ACEFHJKMNPRSTUVWXYZ234579";
private static Random rnd = new Random(Guid.NewGuid().GetHashCode());
/// <summary>
/// Generate a license code
/// </summary>
/// <param name="length">length of each phrase</param>
/// <param name="number">number of phrases separated by a '-'</param>
/// <returns></returns>
public static string GetNewCode(int length, int number)
{
string license = string.Empty;
for (int numberOfPhrases = 0; numberOfPhrases < number; numberOfPhrases++)
{
license += getPhrase(length);
if (numberOfPhrases < number)
license += "-";
}
return license.TrimEnd('-');
}
/// <summary>
/// generate a phrase
/// </summary>
/// <param name="length">length of phrase</param>
/// <returns></returns>
private static string getPhrase(int length)
{
string phrase = string.Empty;
for (int loop = 0; loop < length; loop++)
{
phrase += validChars[rnd.Next(validChars.Length)];
}
return phrase;
}
}
You really don't want to provide a code that has similar letters; it makes for a mess when the end user goes to enter it in. Letters like 6 and G, B and 8, L, I, and 1. Of course if you do want them, you can always add them back in... The above code will generate a license like xxxx-xxxx-xxxx-xxxx using the characters in "validChars". Calling GetNewCode(4, 4) will return a code like above.
I'm using Azure functions to register then validate the code. When my app registers the code, it generates an encrypted hash with things that are unique to the install, device and/or user. That is provided to the registration function and is stored with the key in the DB in Azure.
The validate regenerates the key and provides it with the license code, IP address (which in my case will not change and if it does then it will need to be updated anyway), and the regenerated hash then the Azure function returns if the application is licensed. I do store a "temporary" key on their server that allows the app to run for a period of time without talking back up.
Of course, my app must be on the net for it to work regardless.
So, the end result is a simple key for the end user to type in and an easy process to manage the license on the backend. I can also invalidate a license if need be.
I solved it by interfacing my program with a discord server, where it checks in a specific chat if the product key entered by the user exists and is still valid. In this way to receive a product key the user would be forced to hack discord and it is very difficult.
Im building a small winforms app using: ayende rhino licensing. The licensing is working fine, I can create licences and distribute them as I choose.
The problem is, How do I make each license work on just one machine? I know there is a class in ayende's project called LicensingService which I believe does something like what I'm trying to do, but I just cant figure it out. I've done quite a bit of searching and couldnt really find any tutorials except this one.
Maybe someone has implemented this, or has some tips on how I could accomplish this? I do have access to a webserver, if that helps.
Any help is much appreciated, as always.
Depends how annoying you want to make it for your users to be honest. You could implement a HWID (see How to fast get Hardware-ID in C#? on how to generate them) which will be unique from system to system, then have your program check if the HWID matches the ID found to the place you store them on-line (usually by using a database).
Needless to say, this will make your application require internet connection in order to run which might be a bit frustrating for your users.
Or you can merge the HWID with the serial and have your application do the same to verify if they match, but that would be easily cracked by the average cracker.
In the end of the day, .net isn't the best as far as security goes since you can easily get the source code and modify the assemblies as needed to patch certain protections. Keep that in mind when deciding what route you want to take to protect your software.
I do not know what exactly is a rhino licensing. To tackle your need generally there are two approaches.
Either give some randomly generated password to the client machine, and maintain a pool of passwords in your server. Each time a password is entered to register the application in a local machine, check if it was already registered elsewhere by connecting to your server via internet.
Or, what we do is, generate a code unique to that machine (perhaps a hash of some unique machine id, say mac id) and get the client sent it to you. You would then rehash the code and send it back using some logic. Now when the client enters this code to his machine do the same thing: fetch the very machine id, do the same rehashing using the same some logicand check if it matches.
I cant think of anything else
I need some ideas how to create a activation algorithm. For example i have demo certificate. Providing that the application runs in demo mode. When full version certificate is provided then application runs in full mode.
Is it even possible and how would be a good way creating this system?
One simple was i was thinking would be just have a 2 encrypted strings, now when the decryption is succsessful with the demo public key certificate then the application will run in demo mode and etc..
You could do something like:
Generate public/private key pair
As owner of private key, you can sign those "activation certificates" (called AC from now on)
In your app, with public key, you can check if the sign is correct
As Overbose mentioned -- you can't prevent reverse engineering. In general someone could take functionality and put it in his/hers own app and thus eliminate any possible activation algorithm. So you can only assume (or make) this is hard enough not to be worth the effort (this is the same as for cryptography -- when you make the cost of breaking the message greater then the profit of gaining it you can say it is well secured).
So you could:
Make executable self-verifying (signed by you, self-checking based on hard-coded public key (one thing: you must skip this value when self-checking)).
Do some tricks with pointers (point to the activation function, go to 7th bit and change value of it for something based on value of another pointer; in some weird places change hard-coded values to those based on occurrence of some bits in other places of the code; generally -- make it more difficult to break than by simply changing bits in executable with hex editor)
Try to make some protocol that your server would use to ask questions about the app ("gimme the value of 293 byte of yourself") and check answers.
Use imagination and think of some weird self-checking method nobody used before :)
As mentioned -- none of this is secure from cutting the authentication part off. But nothing is and this could make it harder for crackers.
Background: I've deployed an activation based system built on top of a third-party license system, i.e. server, database, e-commerce integrations. I've also separately written a C# activation system using RSA keys, but never deployed it.
Product Activation commonly means that the software must be activated on a given machine. I assume that's what you mean. If all you want to do is have two strings that mean "demo" and "purchased", then they will be decrypted and distributed within hours (assuming your product is valuable). There is just no point.
So. assuming you want "activation", then when the user purchases your software, the following process needs to happen:
Order-fulfillment software tells Server to generate "Purchase Key" and send to user
User enters "Purchase Key" into software
Software sends Purchase Key and unique Machine ID to server.
Server combines Purchase Key and Machine ID into a string and signs it with its certificate and returns it to user.
Software checks that signature is valid using Servers public key.
Software could check in lots of places: loading the sig in lots of places, checking it in others.
When generating Purchase Keys, the server can store not only what produce was purchased, but what level of product. You can also have "free" products that are time limited, so the user can try the full version of the software for 30 days.
You are using C#, so make sure you obfuscate the binaries, using dotfuscator or equivalent. However, even with that there is nothing you can do against a determined hacker. Your goal, I assume, is to force non-paying users to either be hackers themselves, or to have to risk using a cracked version: kids wont care, corporations might. YMMV.
The code that does the checking needs to be in every assembly that needs protecting, otherwise an attacker can trivially remove protection by replacing the assembly that does the checking. Cut and paste the code if you have to.
Or just buy something.
Another option is to have the server pre-generate "Purchase Keys" and give them to the Order fulfillment service, but then you dont get to link the key to the customers details (at least not until they register). Better to have the ecommerce server hit your server when a purchase has been made, and have your server send it out.
The hard part isn't so much the generation of activation keys as it is the creation of the server, database, and the integration with e-commerce software, and most of all, human issues: do you allow unlimited installs per Purchase Key? Only 1? If only 1 then you have to have customer-support and a way to allow a user to install it on a new machine. That's just one issue. All sorts of fun.
This guy wrote a blog post about a similar idea, explaining what he did with their own commercial software. Also wrote a list of recommendations about the most obvious cracking techniques. Hope it helps.
One simple was i was thinking would be just have a 2 encrypted
strings, now when the decryption is succsessful with the demo public
key certificate then the application will run in demo mode and etc..
Could be a simple solution. But this way you won't prevent someone to reverse engineer your binaries and make the execution jump to the correct line. Everyone has your program, has a complete version of it, so it's only a matter of find how to break this simple mechanism.
Maybe a better solution is encrypt a part of the binaries needed to use the full application version, instead of a simple string. This way to execute the application complete version someone need to decrypt those binaries in order to execute them.
Please take in consideration that even that solution isn't enough. There are other problems with that:
Does all the version of your tool will share the same encryption key? Breaking one of them for breaking all..
Even if you use a different key for each binary application released, does the encrypted binary are identical? Once cracked one, you can reuse the unencrypted binaries for all distributed applications.
How to solve these problems? There's no simple solution. Most of the more important commercial software with even sophisticated protection systems are broken just few hours or days after they have been released.
Product activation is not a problem that asymmetric cryptography can solve. Asymmetric cryptography is about keeping secrets from your adversary. The problem is that you can't keep a secret that is stored on you're adversaries machine, that would be security though obscurity.
The correct way to do product activation. Is to generate a Cryptographic Nonce that is stored in a database on your server. You give this Nonce to the customer when they buy the product, and then they activate it online. This activation process could download new material, which would make it more difficult for the attacker to modify the copy they have to "unlock" new features.
But even with DRM systems that require you to be online while using the product. Like the ones found in new games like "From Dust" are still broken within hours of their release.
One of the benefits of public key encryption is that you can verify the origin of a given piece of data. So if you store the public key in your assembly, then sign a given piece of data (say an authorization code or serial number) your assembly can verifiably determine that you were the one that created that data - and not a hacker. The actual data itself isn't all that important - it can be a simple pass/fail value.
This is actually pretty easy to do with .NET. You can use an x509 certificates or like we use in DeployLX Licensing the RSACryptoServiceProvider.
I would highly recommend buying a commercial product (doesn't really matter which one, though DeployLX is excellent) and not doing this yourself for 2 reasons
Even if you're a great developer, you'll probably get it wrong the first time. And any savings you might have enjoyed by rolling your own will be lost to recovering from that mistake.
You'll spend far more time working on your own system - time that you should spend making your product great.
The second phase in protecting the software is to make sure that it runs the way you created it - and hasn't been modified by a hacker. It really doesn't matter what encryption you use if hackers can check if( licensed ) to if( true ).
You can use AsProtect to solve this problem. This is good staring point.
It might be duplicate with other questions, but I swear that I googled a lot and search at StackOverflow.com a lot, and I cannot find the answer to my question:
In a C#.Net application, where to store the protection trial info, such as Expiration Date, Number of Used Times?
I understand that, all kinds of Software Protection strategies can be cracked by a sophiscated hacker (because they can almost always get around the expiration checking step). But what I'm now going to do is just to protect it in a reasonable manner that a "common"/"advanced" user cannot screw it up.
OK, in order to proof that I have googled and searched a lot at StackOverflow.com, I'm listing all the possible strategies I got:
1. Registry Entry
First, some users might not have the access to even read the Registry table.
Second, if we put the Protection Trial Info in a Registry Entry, the user can always find it out where it is by comparing the differences before and after the software installation. They can just simply change it.
OK, you might say that we should encrypt the Protection Trial Info, yes we can do that. But what if the user just change their system date before installing?
OK, you might say that we should also put a last-used date, if something is wrong, the last-used date could work as a protection guide. But what if the user just uninstall the software and delete all Registry Entries related to this software, and then reinstall the software?
I have no idea on how to deal with this. Please help.
A Plain File
First, there are some places to put the plain file:
2.a) a simple XML file under software installation path
2.b) configuration file
Again, the user can just uninstall the software and remove these plain file(s), and reinstall the software.
- The Software Itself
If we put the protection trial info (Expiration Date, we cannot put Number of Used Times) in the software itself, it is still susceptible to the cases I mentioned above. Furthermore, it's not even cool to do so.
- A Trial Product-Key
It works like a licensing process, that is, we put the Trial info into an RSA-signed string. However, it requires too many steps for a user to have a try of using the software (they might lose patience):
4.a) The user downloads the software;
4.b) The user sends an email to request a Trial Product-Key by providing user name (or email) or hardware info;
4.c) The server receives the request, RSA-signs it and send back to the user;
4.d) The user can now use it under the condition of (Expiration Date & Number of Used Times).
Now, the server has a record of the user's username or hardware info, so the user will be rejected to request a second trial. Is it legal to collection hardware info?
In a word, the user has to do one more extra step (request a Trial Product Key) just for having a try of using the software, which is not cool (thinking myself as a user).
NOTE: This question is not about the Licensing, instead, it's about where to store the TRIAL info. After the trial expires, the user should ask for a license (CD-Key/Product-Key). I'm going to use RSA signature (bound to User Hardware)
P.S.: My software will be targetting the China market, whose software market is different from US. Most people in China, they only buy hardware, they usually don't buy software like Micosoft Windows/Office (they just use pirated copies). However, some professional software aiming to a specific field, research people are still willing to buy it IF there is no crack version or the crack version is very difficult to install.
Either option 1 (plain registry key) or 2 (plain file) is just fine. Here's my reasoning:
Standard-privileged users do have read permissions for the registry. If they can't read your key, something else is wrong. Standard-privileged users do not have write permissions for the registry, but this doesn't matter because they also don't have permissions to install software in the first place. In other words, either the user will have permission to create your registry key at install time, or they'll need help installing anyway. Therefore the basic technical issues you raised for the registry key aren't really a factor.
Just don't worry about those users who do things like set back their system clock or manually hack the registry to break your key. Let me say that again: Just don't worry about users who make a conscious decision to alter their system in a significant way to get past your trial limitations — and make no mistake, setting back the system clock or editing the registry are significant modifications. The reason you shouldn't worry about these users is that they represent exactly $0 in potential income. A user willing to make to take this kind of conscious choice about pirating your software isn't going to just give up and decide to pay for your product if it doesn't work. If they can't get your software for free, they'll either go with a competitor or do without. You're in this to make money - you don't want to spend time and resources trying to grab sales you can't win or sending users to a competitor. Therefore, the basic security issues you raised for either option aren't a factor.
You won't find a single perfect solution. The efforts you put into this should be proportional to the price of the product you make. If it's worth a lot, then buy a professional solution. If not, then use any combination of methods that you find. Use the registry, request an online trial key, check if the user manipulates the system time, and so on.
I would suggest taking a slightly different tact.
Give a "lite" version of your software away. No trial, just really limited functionality.
If they want to trial a "professional" version then ask them to get a trial key. This should be encrypted in some format, store it where ever you want. When the app starts, test for the existence of this trial key. If it's there then decrypt it. Inside the key should be the expiration date of the software.
Test the date and act accordingly. If it doesn't exist then just run as the lite version.
To get a trial key, you can have them enter an email address and some other info you want into a box in your app. It's not unreasonable to ask that the machine be connected to the internet for this limited part. Even MS Office requires you to connect to the internet briefly to validate the keys. Have the app contact your server with the key request. Email them back the key.
For bonus points tie the trial key to some metric of the machine itself. Even if it's just the name of the box. Those change rarely and it's a trial anyway.
If you truly can't force them to be connected to the internet to acquire a key, then you can go a slightly different route. Have the app generate a request (which includes the machine name or something along those lines). Have the user either call you with that generated request id or have them plug it into a website. Then email them the key for that machine.
All of this prevents sharing keys. Has a fall back in case the key location is jacked with and prevents the key from being moved to other machines. It also gives you a way of doing this in a completely disconnected manner. Even if they rip the public encryption key out of your app to decrypt the software license key, they won't have your private encryption key in order to build a new license key file.
Now, key management is only one aspect of the evil you are fighting.
The next step is that you need to obfuscate your app in such a way that they can't simply decompile it and bypass your key checks. This is much more common than passing around key files.
You might even have multiple methods in the app that test for the key in different ways.. But this is a different question.
As a final bonus for those vindictive enough to do this: Seed the various pirate boards with key gen software that does interesting things to the machines of the people who are trying to rip you off. You can get really creative here.
Or, like Joel said, you could just simply not worry about them. After all, if they are going out of their way to find a cracked version of your software they weren't going to pay for it anyway and you really haven't lost anything.
Can you require that users using the trial be connected to the internet? If so just have the trial version contact a server during startup and you can check all sorts of things. you don't have to worry about storing stuff on the users computer or them tampering with the data or the system time.
I know this is an old thread, but I just stumbled upon it and other might find this useful.
A valid option these days could be that your application queries a rest service at install time to generate a trial or payed license. Every time the user opens the application the application queries the rest service for the license info that is linked to that one specific copy of software.
Does anybody know the solution for this? I create an exe file of my software. After first installation I have to disable the exe, so it cannot be run again because when someone purchases the software from me they can install it only once.
To do this you'll need to store something somewhere, that something could be:
A file
A registry entry
A call to a web service you own that stores a unique identifier for the machine, and is checked on subsequent installation attempts (Note: If you choose this method you must be clear and up-front with your users that it's what you're doing).
Bear in mind that a determined user will be able to circumvent file and registry methods and also quite possibly the web service method. The former two by using something such as Process Monitor to identify the files/registry entries you're writing to and clear them. For the latter, by using something like Fiddler to identify the web service calls you're making and replacing the responses with ones that allow them to bypass your protection.
Remember, ultimately the user can disassemble your code and remove the protection mechanisms you've put in place, so don't rely on them being 100% un-breakable
Forget it, mate. It's software - you absolutely cannot enforce something like that because the user has complete control over the environment where the binary runs, including reverse engineering, virtualization, backups etc. etc. And the ones who you want to foil are precisely the ones who will go to any length to thwart any protection measure you could invent.
No, the only thing that works is to force an online connection and register, on your system, the fact that a particular binary was installed once, then forbid it the next time. That requires you to make each installer different and have a cryptographically strong key generator, and it's still susceptible to replay attacks - but it's the only thing that is not useless by definition.
(Well, either that, or make your software so insanely great that people will fall in love you and want to give you the money. That solution is probably even harder.)
You could store the installation path in the registry or some secret location and have your .exe check that if it has started from a location different than the one stored, to simply exit, as you probably don't want to tell the user what you are doing.