Protect C# DLL from third party

Question

Duplicate of: How to protect dlls?

I'd like to protect my C# DLL from being used by third party applications. I'd like only MY applycation to use this DLL. How can I achieved that ?

Thank you.

Answer 1

Make everything internal in the DLL and then in the Properties\AssemblyInfo.cs, set the InternalsVisibleTo attribute to only point to the strong name of your application.

Answer 2

Hi,

There is no single effective barrier however you can setup a number of hurdles to put people off binding to your DLL.

1. Use the Publisher and/or Identity code access security permissions, such that you can check the calling code came from you (via x509cert test, and strongname). Don't forget to use the -t when signing your assembly otherwise when your x509cert expires it will fail.

(Strong Name identifies the assembly, Publisher identifies who published the assembly.)

You would also want to check for the disabling of the CAS security in .NET which again can be performed programmatically in the asset you are protecting.

1. Obfuscate your DLL post build (but before signing).

2. Consider adding some sort of licensing check final programmatic check.

HTH

Phil'

Answer 3

Hi,

Obfusc your code is complementary solution

Answer 4

Do keep in mind that this protection needs to be two-fold. If you protect just the DLL, any hacker would just start to analyze your application to learn how it's calling the DLL. Furthermore, if the third-party has full access to your DLL then they will succeed in discovering it's internal workings, no matter how strong your protection is. Although some protection schemes will take more time to crack than others. Basically, the protection of your DLL should depend on the value of this DLL. If a hacker can save or earn millions by hacking your DLL, they will surely do it. If your DLL just provides them a minimum financial gain, it's more likely that they won't even bother to crack it.

If you want to keep your DLL code secure, set up a web service somewhere and set up your application to call this service instead of a local DLL. Then hackers will have much more trouble to access your library. Unfortunately, it also requires your users to have a continuous Internet connection.

(Basically, this is why cloud computing is becoming more popular. Users can use cloud applications, but don't have access to the binaries.)

Answer 5

This is simply not possible.

The whole code access security system is based upon the notion that security decisions come from the user running the code, not from the author of the code. You, the code author, do not get to tell your users what their security decisions are; you are the user's servant, not the user's master.

Now, you can make it difficult for third-party code to use your code. You can use various security attributes to document that your intention is for third-party code to not use your code. Those are good steps, but they do not actually solve your problem in any world where your users are hostile to you. In the CAS model, users always win.

For example: you can have methods in your code do security demands that trigger stack walks to check to see whether everyone on the call stack has certain evidence associated with them. For example, the evidence "this DLL was signed with Guillaume's strong name private key, which is locked in a drawer in Guillaume's office" would be good evidence to check for. That would almost guarantee that everyone calling your code is also your code.

But that is not the purpose of strong name signing; the purpose of strong name signing is to help the user know that the code they think they are running actually came from you. Using a security tool for a purpose other than what it was intended for is dangerous, as we'll see. It gives you a completely false sense of security.

Suppose your user wants to make an application that isn't yours that uses your DLL. Users can write fully trusted code, and fully trusted code has the right to forge evidence. That's what "fully trusted" means. So the user makes an application that was not signed by you, but because the user can fully trust that application, the fully-trusted application is allowed to forge the evidence to say that the code comes from you.

For that matter, there is nothing stopping the user from simply taking your code, removing your signature, and replacing it with their signature. You can say that your EULA forbids that, and you can sue them if you find out, but you cannot do anything to stop them.

And heck, the user can disable the ENTIRE security system if they want, in which case anything can run.

You should consider whether you want to ship your DLL to customers at all. If it contains secrets that you do not want to get out, then don't share those secrets with thousands of customers, some of whom might be hostile to you. If you keep your DLL on your own servers and provide your service via the web then you don't ever ship your DLL to customers and therefore they cannot use it on their own machines for purposes other than what you intend.