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.
Related
I have a windows service written in C# running on a machine and it creates and uses a number of files. Is there a way to prevent a user on the machine, administrators included, from messing with these files(moving, editing, renaming, deleting) from the code?
I know that StreamWriter can achieve this, but I don't want to keep the files open all the time without the need to actually access the data in them, but I can't seem to find any other way.
EDIT: Let me rephrase the question base don the comments below. Is there a way to setup ACL in a way that only my service can access the files? I would also accept if only services could access the files(I have seen mention of All Services security group in Microsoft Docs but I can't seem to actually find it on the system or in .net).
You can do it changing access privileges BUT I strongly suggest to simply keep them open (just be careful to flush the stream after each batch write).
In the first part I try to address directly your question ("How to prevent...") but in the second part I tried to outline a different approach (make your application resilient: keep a backup).
How to prevent...
Assuming that you're running on Windows to avoid other users to mess with them you should:
Set the hidden attribute. By default hidden files are hidden and many users won't even see them. If you can do it at directory level then even better.
Change ACL to deny Full access to Users and Administrators group. Better if you cherry pick and just leave Read permissions. By default Windows pick the most restrictive policy, even when an user belongs to two group, then this will effectively stop everyone to write that file (if you deny also Read permissions then they won't even be able to see its content but see later).
Create a special group (with the required permissions, and only those) with one single user. Be sure that user isn't automatically added to the Users group.
Change your application to impersonate that user when writing those files. If you left the Read permissions in-place then code for reading isn't affected.
Don't forget to check with different versions and editions of Windows (HomeUsers keep bouncing in my mind.) If your application is a Windows Service then things may be slightly easier, see eryksun's comment.
You can experiment with all these things simply using Windows Explorer, just find the right balance but don't forget that each single installation is a different world and only God knows what the environment is (but he doesn't know why).
Few obvious drawbacks:
An administrator can ALWAYS do what he wants then they may find those files and revert permissions. I think (I'm not sure) that System Installer has some special privileges to prevent this but I'm not sure (and I can't imagine how to do it).
Installation is way more complicate (and you will need one if you don't have). You may do it when application is executed first time but then you will need administrative privileges (just once but probably worse.)
Your code is more complex.
More setup means more things that may go wrong, balance this with the effort of your technical support team.
Updates (and tech support job) will be more complicate.
Users with certain privileges won't be affected (see another comment) but this is really a good thing and you shouldn't every try to circumvent it.
Backup is the key!
Don't forget that if they really want to break your application then they will just delete the application directory...
I think, but I don't know your specific use-case, that maybe you're approaching the problem from the wrong angle. If what you want to prevent the user to corrupt your data files (intentionally or not) then what you need is a BACKUP. Save a copy in a different location each time your write them, mark it as hidden and live happy. If they're not too big you may even save content directly inside Windows Registry. For encrypted/hashed/checksummed files your application can easily detect when they're broken or missing: just restore backup and you're done.
I don't want to keep the files open all the time
But keeping them open is a good way that closely follows your intent and requirements.
As long as it's not about hundreds or more, this seems the best option.
The other way is to set the security properties (ACL) but that is messy and requires a higher privilege.
Excluding the Admin is not totally possible and you should not really want that. Avoiding accidental delete or rename is doable, total control is not.
2 Other options are
Set some permissions in the locations here the files are so that no one can access them
If all of the files in question will be created by your application, you could check the options in CreateFile, where you can set the sharing options to 0x00000000 to "Prevent other processes from opening a file or device if they request delete, read, or write access."
If you want to use CreateFile I guess you will have to pinvoke it
I'm looking for Unity function to determine if my game has been de-compiled/ recompiled or modified in any way.
Yes, there is a Unity function for this but it can still be circumvented.
This can be done with Application.genuine which returns false when the application is altered in any way after it was built.
if (Application.genuineCheckAvailable)
{
if (Application.genuine)
{
Debug.Log("Not tempered");
}
}
The problem is that if the person is smart enough to de-compile, modify and compile the game, he/she can also remove the check above so the check above becomes useless. Any type of program genuinity or authenticity check can be removed as long as it is running on the player's machine.
EDIT
You can make it harder to be circumvented by doing the following:
1.Go to File --> Build Settings... then select your platform.
2.Click on Player Settings --> Other Settings and then change the Scripting Backend from Mono to IL2CPP(C++).
This will make it harder to circumvent that but it is still possible to be circumvented.
TL;DR: Thats frankly not possible.
You can never determine whether your program was decompiled, because there exists no measure to determine whether that happened. And every executable can be disassembled into at least assembler even if you scramble and screw up your data. You can make it hard to understand your source code though using obfuscating software. The ultimate obfuscator would be the M/o/Vuscator, which changes all assembler commands into mov instructions, which make it a pain in the butt to understand anything. But it also is slow as heck and probably not what you want (btw. this works because the mov-instruction is touring-complete in the x86 Instruction set. There is a great talk about it here). When you follow this trend further down the rabbit hole you can also use the exact same assembler code (around 10-20ish instructions) to create all programms possible which will make it impossible to get to your source code by simply disassembling your code.
Staying in the realm of the possible though: No, you are not able to prevent people from disassembling or decompiling your code. But you can make it harder (not impossible) to understand.
Detecting a change in the executable is on the possible side, though. Altough probably not feasible for you.
The main problem beeing that any code you build into the app to detect changes can be patched away. So you'll need to prevent that. But there is no practicall way of preventing that...
If you try to detect changes in your app by using a signature of the original and compare that to the actual signature for example, you can just exclude that check in the recompiled version. You can try to verify the signature against a server, but that can still be circumvented by removing the server check. You can force a server check for multiplayer games, but then we'll just use a fake signature. If you then want to calculate the signature on your server to prevent tampering, we'll just give you the original file and run the recompiled one.
There is one way (altough not feasible as mentioned above) to actually absolutely protect parts of your code against decompiling. The mechanism is called "BlurryBox" and was developed at KIT in germany. As I can't seem to find a proper document as a reference, here is what it does to archieve this.
The mechanism uses a stick with an encrypted storage and a microcontroller to do encryption. You put the parts of your code you want to protect (something that is called regularly, is necessary but not that time critical) into the encrypted storage. As it is impossible to retrieve the key [citation needed], you cannot access the code. The microcontroller then takes commands from your programm to call one of the encrypted functions in the storage with given parameters and to return the result. Because it is not possible to read the code you need to analyze its behaviour. Here comes the "Blurry" part of the box. Each function you store needs to have a small and well defined set of allowed parameters. Every other set of parameters leads into a trap that kills your device. As the attacker has no specs as to what the valid parameters are, this method gives you profable security against tampering with the code (as they state). There might be some mistakes on how this exactly works though as I'm writing this down from my memory.
You could try mimicking that behaviour with a server you control (code on the server and IP bans for trying to understand the code)
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..
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.