This question already has answers here:
How to pass the smart screen on Win8 when install a signed application?
(9 answers)
Closed 4 years ago.
We Use SNK key files to sign our assemblies, then we use wix to create msi install file, when we download the msi file, we get that smart screen, windows protected your PC, I read about all the certification stuff and I told the team we should get a certificate and so on, but they said no we just use snk files and add in .crproj file, is that correct or I have to do it
Update: not duplicate and yes you can sign code just with SNK, I did that
You will need to look into Code Signing for your app.
but they said no we just use snk files
I think your team is confusing Strong Naming with Code Signing. Though both use certificates, the certificates used with strong naming is not sufficient for Code Signing, which is what you need here.
Strong Naming is somewhat of a poor man's way to identify something (filename, culture, public key). It's identification method is not objective (as there is no third party) and it does not show whether something has been tampered with. It is purely a .NET beast.
Code Signing (or authenticode) identifies something by way of a trusted third party and can show if something has been tampered with or not. CS can be used with .NET and native apps.
Both are complex to discuss in full here particularly the latter.
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.
I'm looking for the right approach to verify a currently running executable from within that executable.
I've already found a way to compute a (SHA256) hash for the file that is currently running.
The problem is: Where do I safely store this hash? If I store it in a config file, a malicious user can just calculate his own hash and replace it. If I store it in the executable itself, it can be overridden with a hex editor probably.
A suggestion I read was to do an asymmetrical en- (or was it de-) cryption, but how would I go about this?
A requirement is that the executable code hashes and en/decrypts exactly the same on different computers, otherwise I can't verify correctly. The computers will all be running the same OS which is Windows XP (Embedded).
I'm already signing all of my assemblies, but I need some added security to successfully pass our Security Target.
For those who know, it concerns FPT_TST.1.3: The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code.
All the comments, especially the one from Marc, are valid.
I think your best bet is to look at authenticode signatures - that's kind of what they're meant for. The point being that the exe or dll is signed with a certificate (stamping your organisation's information into it, much like an SSL request) and a modified version cannot (in theory plus with all the normal security caveats) be re-signed with the same certificate.
Depending upon the requirement (I say this because this 'security target' is a bit woolly - the ability to verify the integrity of the code can just as easily be a walkthrough on how to check a file in windows explorer), this is either enough in itself (Windows has built-in capability to display the publisher information from the certificate) or you can write a routine to verify the authenticode certificate.
See this SO Verify whether an executable is signed or not (signtool used to sign that exe), the top answer links to an (admittedly old) article about how to programmatically check the authenticode certificate.
Update
To follow on from what Marc suggested - even this won't be enough if a self-programmatic check is required. The executable can be modified, removing the check and then deployed without the certificate. Thus killing it.
To be honest - the host application/environment really should have it's own checks in place (for example, requiring a valid authenticode certificate) - if it's so important that code isn't modified then it should have its own steps for doing so. I think you might actually be on a wild goose chase.
Just put whatever check will take least amount of effort on your behalf without worrying too much about the actual security it apparently provides - because I think you're starting from an impossible point. If there is actually any genuine reason why someone would want to hack the code you've written, then it won't just be a schoolboy who tries to hack it. Therefore any solution available to you (those mentioned in comments etc) will be subverted easily.
Rent-a-quote final sentence explaining my 'wild goose chase' comment
Following the weakest link principle - the integrity of an executable file is only as valid as the security requirements of the host that runs that executable.
Thus, on a modern Windows machine that has UAC switched on and all security features switched on; it's quite difficult to install or run code that isn't signed, for example. The user must really want to run it. If you turn all that stuff down to zero, then it's relatively simple. On a rooted Android phone it's easy to run stuff that can kill your phone. There are many other examples of this.
So if the XP Embedded environment your code will be deployed into has no runtime security checks on what it actually runs in the first place (e.g. a policy requiring authenticode certs for all applications) then you're starting from a point where you've inherited a lower level of security than you actually supposed to be providing. No amount of security primitives and routines can restore that.
Since .NET 3.5 SP1, the runtime is not checking the strong name signature.
When your assemblies are strong named, so I suggest to check the signature by code.
Use the native mscoree.dll with p/Invoke.
private static class NativeMethods
{
[DllImport("mscoree.dll")]
public static extern bool StrongNameSignatureVerificationEx([MarshalAs(UnmanagedType.LPWStr)] string wszFilePath, byte dwInFlags, ref byte pdwOutFlags);
}
Than you can use the assemlby load event and check every assembly that is loaded into your (current) app domain:
AppDomain.CurrentDomain.AssemblyLoad += CurrentDomain_AssemblyLoad;
private static void CurrentDomain_AssemblyLoad(object sender, AssemblyLoadEventArgs args)
{
Assembly loadedAssembly = args.LoadedAssembly;
if (!VerifytrongNameSignature(loadedAssembly))
// Do whatever you want when the signature is broken.
}
private static bool VerifytrongNameSignature(Assembly assembly)
{
byte wasVerified = 0;
return NativeMethods.StrongNameSignatureVerificationEx(assembly.Location, 1, ref wasVerified);
}
Of course, someone with enough experience can patch out the "check code" from you assemlby, or simply strip the strong name from your assembly..
It is a good practice to always sign executable files (exe, dll, ocx, etc.). On the other hand, with an open source project it may considered disregarding the contributions to the project from all other developers.
This is quite an ethical dilemma for me and I would like to hear more opinions on this from either people who have been in a similar situation or people who contributed to an open source project.
I would like to note that this question is for an open-source project that was written in C# using .NET 4 so when user clicks the executable, he or she will be prompted a warning stating that the file is from an untrusted publisher if it is not digitally signed.
By the way, the assemblies all have strong-naming (signature) already, but they are not digitally signed yet (i.e. using a Verisign Code signing certificate).
.Net is a diffrent beast as many features require (especially libraries) require the file to be signed with a strong name key, but those can be self signed with no complaint from the final product (it uses the programs cert not the libraries to pop up that message box you refer to in your original question).
However in the general case I see nothing wrong with a group signing the official distro with a private key. If you do something to the source and recompile technically "the file is from an untrusted publisher" as I may trust Canonical but I do not trust you. As long as the executable being not being signed from a specific publisher does not stop it from being used in the manner it was intended (the tivoization clause in the GPL) I see no reason NOT to sign your executables.
Saying that this is "quite an ethical dilemma" is probably blowing it out of proportion. You definitely want to code sign your executables, and I don't really see the problem with you signing it. For example, TortoiseSVN is signed by "Stefan Kueng, Open Source Developer".
That said, it is probably a good idea to form some kind of legal entity for your project, and then get the code-signing certificate in the name of your project's entity. That way, rather than you personally signing the executable (and thus "taking all the credit"), your project's name shows up as the publisher.
If you were in the US, I would suggest either forming a LLC or possibly a 501(c)(3) organization, which is exempt from income tax and allows individuals to make tax-deductable donations to the project. (Many open source projects organize as 501(c)(3) entities, including WordPress and jQuery.) I see you're in Turkey, so you'll have to research your local requirements for forming some kind of legal entity; once formed, you'll be able to get a certificate from a CA in the name of your project's entity rather than your own.
i've got a question, is it possible to identify the creator of a .NET assembly, just with traces from VisualStudio within the assembly ?
Or can you even get a kind of unique ID of the creator out of it?
I don't mean the application information like company or description, they can be edited too easily.
The answer based on the fact that the code is not strong named or signed is no. Ultiamtely the only way would be to use some kind of public authority isseued certificate based code signing approach. And that is say unequivocally (theft aside) that a particular certificate owner signed the code, not that someone wrote the code.
Into the realms of more conjecture perhaps, if the code was written via a unique compiler, then one could possibly work this out. However I cannot see even this being unequivocal as who ran the compiler etc....
This question already has answers here:
How can I protect my .NET assemblies from decompilation?
(13 answers)
Closed 6 years ago.
I am writing a .NET application (a Windows class library) for implementing the licensing our product.
The problem is that the DLL can be easily disassembled by the MSIL disassembler or any other third-party tools and one can easily break the code.
I have even tried signing the assembly, but still it can be disassembled.
So how do I prevent this?
Is there any tool to available for this?
Check out the answers for this question.
You cannot achieve complete protection, but you can hinder disassembly in ways that make it more difficult for people to succeed at it. There are more ways to do this, some of them detailed in the answers to the question in my link above:
Obfuscate your code.
Use public/private key or asymmetric encryption to generate product license keys.
Use a packer to pack your .NET executable into an encrypted w32 wrapper application.
What I would add would be incremental updating, both for your core functionality and the protection code, so your users will constantly benefit from the new features while making crackers lag behind you in breaking your software. If you can release faster than they can break and distribute your software, you are in gain. Legitimate users will always have technical support and a word to say regarding new features. They are your best market, as the ones who crack your software wouldn't have payed for it anyway.
You can't, but you can use an obfuscator so that it's impossible to make sense out of your code.
For example, have a look at Dotfuscator.
The community edition of this program is included with Visual Studio.
.NET has an attribute called SuppressIldasmAttribute which prevents disassembling the code. For example, consider the following code:
using System;
using System.Text;
using System.Runtime.CompilerServices;
[assembly: SuppressIldasmAttribute()]
namespace HelloWorld
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello world...");
}
}
}
As you can see, there are just two differences:
We have added System.Runtime.CompilerServices namespace decleration.
We have added [assembly: SuppressIldasmAttribute()] attribute.
After building the application in Visual Studio, when we try to open the resulting EXE file in ILDASM, now we get the error message.
Anything written for the .NET framework is subject to disassembly. You cannot prevent it.
There are obfuscation tools available that will change variable names and insert other 'noise' into your IL, for instance Dotfuscator.
You might want to consider taking another approach with your licensing library, that is, using something else other than .NET, if licensing your product is absolutely necessary.
As mentioned above in the selected answer, there is no true full proof way to secure you code.
Even in something like c++, if your applications code is in your customers hands : Eg - they have physical access to the binary, that application could potentially be disassembled.
The solution would be to keep the functionality that you are licensing, out of reach of people who may want to disassemble it, let them use it, but don't let them hold it.
Consider using :
Web Services
Keep your marketable content server side and beyond the reach of your clients. They can use it, but not examine the code.
Encrypted Binaries and Online Binaries
Maybe even streaming assemblies in an encrypted format to a wrapper application. Keep your decryption keys server side to prevent offline disassembly. This might be circumvented however if someone found a way of exporting the assembly from the app domain of the application, once it has loaded it. (You cannot load an encrypted binary, so an end user might wait until your application has done the work of decryption, then exploit that to export the finished binary) (I was investigating a way to accomplish this (the exporting) - I didn't quite get it working, doesn't mean someone else wont)
The only thing to remember is that ANY code, no matter how well coded it may be, is vulnerable if it is on a users system. You have to assume the worst when you put binaries on their system. A really talented Engineer can disassemble any dll, be it c++ or c#.