Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Where do programs save their secret license or install related information? I notice that often times when you uninstall a program, clear out appdata references, check registries to make sure there is no residue of any relevant information.
If you reinstall the trial program again, it seems to know it was installed before. I'm not looking to find a way to crack trial programs but actually need to implement something similar and can't find any good information on how to do this.
Registry
online
file in folder Windows with system like name
I even seen apps that hacked unused OS variables to store custom data in registry.
But the simplest method is to register a handler for a custom unused file type like .sof (if that is there, it was installed before) Edit 1 You have to register the handle to open a known executable on the system, not to your app. Because cleaners will detect if points to a no longer existing app location. As for storing additional params like date of trial expiry you can include them in the path as a param, like: cmd.exe -o 2010-02-09
I have handled this in two ways. First, in windows apps, I put in an encrypted Registry entry which is not in a standard location so that it is not easily found. This is a good solution if you don't mind people who either a) reformat often which removes all registry entries or b) use your software on a virtual machine which can be quickly reverted to a pre-trial state (and thus your trail can be used again quickly).
The better alternative is to have an online registry component which catches the MAC address of the machine which the trial is loaded on. Whenever the trial is reloaded, the software checks against a web service to see if the MAC address has been seen before. The only way around this is again using a Virtual Machine with the ability to change the MAC address. However, if you have a user that goes to this extreme, they'll use your trial regardless.
Probably the most foolproof way of licensing (when done right) is through something the user physically has - some kind of hardware dongle.
very hard to copy/duplicate
not dependent on network access
tamper-resistant (compared to software)
user-friendly (when working correctly)
licence count enforcement (can't easily plug 1 dongle into 10 machines at once)
Of course, it has also numerous disadvantages:
expensive to produce
hard to repair/replace
actually requires you to communicate with the dongle in a cryptographically secure way - any kind of if(dongle_ok()) { do_stuff() } is an invitation for crackers to patch that over to if (1) { do_stuff() }...
...which will require special drivers...
...maybe even a special interface (I still have a LPT dongle, but no LPT ports; USB<->LPT sucks)
don't even think of hooking it up to a virtual machine (although peripheral support is better in VMs nowadays)
support hell (is it connected? is it not broken? is the driver not broken? are the signatures/keys right and unexpired?)
fragile, esp. if it sticks out of the computer and/or has destructive anti-tamper mechanisms
may break communication with other peripherals (esp. those "pass-through" things were notorious for this)
For most programs, the disadvantages far outweigh the advantages; however, if you're making expensive, complex software (think "production plant control"), your clients are rather cavalier about licensing (in other words, "would buy a single copy (crack it if necessary) and run it on 50 machines if they could get away with it"), and lawsuits are impractical (take too long, you don't have much evidence, uncertain outcome), this may be useful. (I didn't say simple, did I?)
They save it wherever they can, secret files, secret registry keys. There are commercial products that offer this kind of protection, like asprotect, armadillo, etc.
Some products will utilize ADS (Alternate Data Streams) and hide the data in various places.
Others will leave behind "rootkits" cough SONY.
Also some will create special registry entries that cannot be delete easily, such as entries with NULLs in the name.
It sometimes depends on how scrupulous the developer is.
Could also try making the file or folder hidden - most users don't know to reveal hidden files and folders. Then you can put it anywhere really. C:/WINDOWS is sometimes a good choice because of that silly window that shows up when you click it for the first time that says "DANGER! DO NOT EDIT ANYTHING IN THIS FOLDER OR YOUR OS WILL MESS UP!" This will hide most anything from the lay man, but let's face the facts, you're not hiding anything from anyone that is active on stack overflow. :)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am developing a Windows Application. That requires users to register to use it...
Now, I am storing my license info as a file in APpData. But deleting that file resets the trial version date. So, I am now planning to save it in registry.
But, Most of the Users will not have administrative privileges (Limited Users) in Windows to Access the registry.
What can I do ? Where can I save my serial number and date ?
In my opinion the point is you have to change how you manage your license.
Where
If they delete license data file then trial restarts? Do not start application if file doesn't exist and create it with an install action first time it's installed.
Now you face a second problem: what if they uninstall and reinstall application? Second step is to move this file to application data folder (for example Environment.SpecialFolder.CommonApplicationData). This is just little bit more safe (because application data won't be deleted when uninstall) but it's still possible for them to manually find and delete it. If application will be installed by low privileges users there isn't much you can do (you can't try to hide license somewhere in Registry).
Now it's a game between you and crackers. They'll win, always. You'll only make life of legitimate users more hard so read cum grano salis. Where you may store license data:
Registry. Pro: easy to do. Cons: easy to crack and for low privileges user it's valid only for one user per time. A registry key (in a per-user base) can be somehow hidden if it has \0 in its name. Take a look to this nice post.
File. Pro: easy to do and IMO little bit more safe than Registry. Cons: easy to crack (but you can hide it more, see later).
Application itself (appending data to your executable, few words about that on this post). Pro: harder to detect. Cons: an antivirus may see this as...a virus and an application update may delete license too (of course if you don't handle this situation properly) so it'll make your code and deployment more complicated.
How to hide license in a file?
If you're going with a file (it doesn't matter where it's located) you may consider to make crackers life (little bit) harder. Two solutions come to my mind now:
Alternate Data Streams. File is attached to another file and they won't see it with just a search in Windows Explorer. Of course there are utilities to manage them but at least they have to explictly search for it.
Hide it inside application data (a bitmap, for example, using steganography). They just don't know it's license data, what's more safe? Problem is they can easy decompile your C# program to see what you do (see paragraph about Code Obfuscation).
Probably many others (fantasy here is our master) but don't forget...crackers will find it (if they really want) so you have to balance your effort.
How
Keeping your license schema you're now on a dead path. Decision you have to take is if the risk they use trial longer than allowed is higher than risk they stop to use your application because of boring protection.
Validation
If you can assume they have a network connection then you may validate license on-line (only first time they run your application) using some unique ID (even if it's about Windows 8 you may take a look to this post here on SO). Server side validation can be pretty tricky (if you want to do it in the right way), in this post is explained an example of program flow to manage that in a proper way.
Data Obfuscation/Encryption
Your license file/data is now in a safe place. Hardly crackers will find it. Now you need another step: obfuscation. If your license data is in plain text once they found your file it's too easy to change it. You have some options (ordered by increased security and complexity):
Obfuscate your files. If they can't understand what's inside a file with a simple text editor (or even a hex editor) then they'll need more time and effort to crack it. For example you may compress them: see this post about XML file obfuscation with compression. Note that also a simple base64 encoding will obfuscate your text files.
Encrypt them wit a symmetric algorithm. Even a very simple one will work well, here you're just trying to hide data. See this post for an example. I don't see a reason to prefer this method to a simpler obfuscation.
Encrypt them with an asymmetric algorithm. This kind of encryption is a big step in complexity and security and it'll be (very) useful only if license token is provided by a server/external entity. In this case it'll obfuscate license signed with its private key. Client application will validate signature with its public key and even if cracker will find this file (and decompile your code to read public key) they still won't be able to change it because they don't have private key.
Please note that data obfuscation/encryption can be used in conjunction with above mentioned steganography (for example to hide encrypted license file inside an image).
Code Obfuscation
If you're not using license signing with asymmetric encryption then last step is to obfuscate your code. Whatever you will do they'll be able to see your code, check your algorithm and workaround it. So sad, you're deploying instructions manual! Obfuscate with an Obfuscator if you want but what I strongly suggest is to move your license check in a less obvious place.
Put all your license related code in a separate DLL. Sign it (be aware that signed assemblies may be decompiled and recompiled to remove signing, there are even tools to do it almost automatically).
Pack it inside your executable resources (with a not so obvious name) and do not deploy DLL.
Handle event AppDomain.AssemblyResolve, when your DLL will be needed at run-time you'll unpack in memory and return its stream of bytes. See more about this technique in this Jeffrey Richter's post.
I like this method because they'll see there is a license check but...they won't find license code. Of course any good cracker will solve this issue in 10 minutes but you'll be (little bit more) safe from random ones.
Conclusions
To summarize a little bit this is a list of what you may do to provide a stronger license check (you can skip one or more steps, of course, but this will reduce safety):
Split your license check code in two assemblies (one to perform the check and manage license and the other to provide a public interface to that engine).
Strong sign all your assemblies.
Embed your License Engine assembly inside your License Interface assembly (see Code Obfuscation section).
Create a License server that will manage your licenses. Be careful to make it secure, to have secure connection and secure authentication (see Validation section).
Save license file locally in a safe location (see Where section) and encrypted with an asymmetric encryption algorithm (see Data Obfuscation section).
Sometimes validate license with your License Server (see Validation section).
Addendum: Software Protection Dongles
A small addendum about hardware keys (Software protection dongles). They're an invaluable tool to protect your software but you have to design your protection even more carefully. You can assume hardware itself is highly secure but weak points are its connection with computer and communication with your software.
Imagine to simply store your license into the key, a cracker may use an external USB (assuming your SPD is USB) to share same key with multiple computers. You should also store some hardware unique ID within the key but in this case weak point is connection (hardware can be emulated by a software driver). It's a pretty easy crack and this false sense of security ("I'm using Software Protection Dongle, my software is then safe") will make your application even more vulnerable (because you risk to forget other basic protections to simplify license management).
Cost vs benefits for a poor designed protection using SPD should make you consider to use a normal USB pen drive. It costs 1 $ instead of 15/20$ (or much more) for a SPD and you have same level of protection against casual crackers. Of course it won't stop a serious cracker but also a poor designed SPD won't stop it.
A true protection (assuming you're not running on a DRM enabled device) is a dongle which can also execute your code. If you can move some basic algorithms (at least to decrypt vital - and dynamic - support files) into the key then to crack your software they will need to crack hardware. For a half-decent dongle this is a very very very hard task. More carefully you design this and more code you move into the key and more you'll be safe.
In any case you should doubt about marketing campaigns: software protection with a dongle isn't easier. It can be (much) more safe but it isn't as easy as vendors say. In my opinion plug-n-play protection cost is too high compared to its benefits (benefits = how much it'll make crackers' life harder).
Unfortunately wherever you store licence information on a client's machine it's open to abuse (because it's their machine!).
The only secure way to do this is to have your program check in with a remote service, obviously this requires a lot of overhead.
My own approach is that if customers mess with their licence key then they should expect issues and you are under no obligation to assist. I would make sure your key contains information about the machine it's running on (to prevent simply copying the key) but otherwise keep it very simple.
When researching licencing myself I found a philosophy I tend to stick by - you drive away more potential customers with convoluted and difficult licencing setups than you lose through piracy.
My suggestion would be that you reverse your logic - instead of having allowing the removal of a licence key to restart the free trial why not force them to have a licence key to unlock the full application?
If you are going to write to HKEY_CURRENT_USER you won't need Administrative rights.
on the other hand, writing to HKEY_LOCAL_MACHINE requires Administrative rights.
be sure when you open the key for writing to call it like this
RegistryKey key = Registry.CurrentUser.OpenSubKey(#"Software\YourAppPath", true);
if that doesn't work for you, there is a trick to write to the end of the executable file itself, but that's another thing.
Apps downloaded from the Windows Store are installed in this location:
C:\Program Files\WindowsApps
If you look inside this folder you can access each application's .exe and use reflector to decompile them.
Currently, my Windows RT application sends a password over SSL to a WCF service to ensure that only people using my app can access my database (via the service).
If my code can be read by anybody, how can I ensure that only people using my Windows 8 app are accessing the service?
Thanks!
In the very general sense, it is impossible. If ever you create anything that is placed on the customer's computer, eventually you will stumble upon someone that will manage to decipher your code and understand how to call your service. You may obfuscate it into insane levels, but still it has to be executable by the processor, so the processor has to understand it. And if it does, then potentially anyone knowing assembly can understand it too. You may smartly obfuscate it so that it will be very time-consuming to cleanup the code from unimportant trash, but still, at some point of time someone will read it.
One of common defenses is in trying to detect who* is actually trying to use your service. This is why all the "portals" require you to "register". This way, the application identity is marginalized and it is the user who provides login, password, PGP keys, etc is checked and verified whether he/she is allowed to actually run your service.
Also, on the OS/framework layer, there are several ways to selectively provide "licenses" to your customers and then in your application you may use keys/hashes from the licenses to authenticate in your service. This may partially remove from the user the burden of remebering the passwords etc, or it may provide an additional authentication factor, or it may simply be a yes-no flag that allows to run the app or not. Still, it will not guard your code against being read. Licenses just help in verifying if the software copy is legit and if belongs to that specific user/computer.
You may act selectively only against 'reflectoring' (or dotpeeking, or ildasming, or ...). Those tools really make the decompilation easy (although the original reflector is now paid software). So, the simpliest form would be to use obfuscator that will make the decompilation impossible or harder - that cuts some percentage of the potential code-readers and you can assume scriptkiddies are gone. You may ignore obfuscators and you may write the service connector in native code (C++, not C++/cli). That will make the code completely un-reflectorable and un-ildasmable, and that will cut off another large percentage of people, but with some will still be left (me and thousands of others, but that's much less than millions).
While this does not give you definitive answer, I wanted to show you that you can only get some "level of hardness", but you cannot make it totally safe from being read. This is why you should focus on making the service access in that way, that showing your code to a stranger on the street does not compromise your security.
Now gettint to your problem: the core thing seems to lie not in the fact that your app uses some secret algorithms, but rather - that you have hardcoded the password in. You see, there's with this approach, they do not need to read your code at all. They just need to listen what data your app sends over the sockets..
Another issue is that everyone uses the same keyphrase.
A hardcoded magic string may be some sort of validation, but never authentication. If you want the app to be register-free, make the registration silent and automatic at first run? Of course, you will just bounce the problem: anyone could read the code and learn how to autoregister, and then they will make a clone.. But, again, like I've said: you never know who's on the other side. Is it your app, or is it an ideal-clone of it? Or maybe is it a clone that uses your own hacked-a-bit libraries to connect to you? If it looks like a duck, and quacks like a duck, it is a duck..
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.
There are loads of profilers and static code analyzers out there for C# assemblies.
Just wonder if there are any methods to prevent being analyzed, because it does make me feel a bit nervous when being stripped.
I have searched all over the Internet and stackoverflow. There seems none for my wonder.
What I've got are only some even more scary titles like these (sorry, new user can't post hyper links, please google them):
"Assembly Manipulation and C#/VB.NET Code Injection"
"How To Inject a Managed .NET Assembly (DLL) Into Another Process"
Is it just me being too worried or what?
BTW, with C#, we are building a new winform client for a bank's customers to do online transactions. Should we not do this in the winform way or should we use some other language like Delphi, C++? Currently we have a winform client built with C++ Builder.
If by analyzed you mean someone decompiling the code and looking at it, then the Dotfucstor that ships with VS Pro and above is a simple (free) tool to help here. There is a fuller functionality (but paid for) version that can do more.
To prevent someone tampering with your deployed assmebliles, use Strong Names.
Where there's a will, there's a way, whether it's managed code or native assembly. The key is to keep the important information on the SERVER end and maintain control of that.
Just about any application can be "analysed and injected". Some more than others. That's why you NEVER TRUST USER INPUT. You fully validate your user's requests on the server end, making sure you're not vulnerable to buffer overruns, sql injection and other attack vectors.
Obfuscators can make .NET assemblies harder to analyze. Using a secure key to strong-name your assemblies can make it much harder to alter your code. But, like everything else in the digital world, somebody can exploit a vulnerability and get around whatever safeguards you put in place.
The first thing you need to decide against what you are trying to protect?
Obfuscators are useful only to protect "secret sauce" algorithms, but the attacker can simply extract the code and use it as black-box. In 99% of cases obfuscators are waste of money.
If the attacker has physical access there is not much you can do.
If the end user is running with administrative privileges then they will be able to attach a debugger, and modify your code, including target account details. My local friendly bank has given me a chip & pin reader that I have to enter the last n digits of the target account, which it hashes/encrypts with my bank card's Chip; I then enter the code from the device into the bank's web application which can checked at the bank's end as well. This mitigates "man in the middle" type attacks...
Security is only possible on systems you physically control access to, and even then not guaranteed, merely achievable. You must assume any code not executing on a system you control can and will be compromised. As Rowland Shaw stated, the best bet for a financial institution is some sort of physical token which effectively adds a offline unique component to all transactions that cannot be (easily) known ahead of time by an attacker operating from a compromised system. Even then you should be aware of the fact that if the users computer has been compromised and he logs in with his secure token from that point forward until the session ends the attacker is free to perform whatever actions the user has permission to, but at least in that case the user is more likely to notice the fraudulent activity.