tags:

views:

951

answers:

8

Hello, How do I protect the dlls of my project in such a way that they cannot be referenced and used by other people?

Thanks

+3  A: 

You could embed it into your executable, and extract and loadlibrary at runtime and call into it. Or you could use some kind of shared key to encrypt/decrypt the accompanying file and do the same above.

I'm assuming you've already considered solutions like compiling it in if you really don't want it shared. If someone really wants to get to it though, there are many ways to do it.

gokult
In .NET exe files are assemblies as well and can be referenced.
Brian Rasmussen
What is the solution for this?
Josh
Unfortunately, thats a very easy solution to circumvent. It's quite easy to dump the assembly from memory once you've loaded it thus allowing anyone to use the "encrypted" assembly.
Paul Alexander
+8  A: 

You can't.

Dave
Yay! This is the correct answer :)
Robert Gould
+3  A: 

Take a look at the StrongNameIdentityPermissionAttribute. It will allow you to declare access to your assembly. Combined with a good code protection tool (like CodeVeil (disclaimer I sell CodeVeil)) you'll be quite happy.

Paul Alexander
+12  A: 

The short answer is that beyond the obvious things, there is not much you can do.

The obvious things that you might want to consider (roughly in order of increasing difficulty and decreasing plausibility) include:

  • Static link so there is no DLL to attack.
  • Strip all symbols.
  • Use a .DEF file and an import library to have only anonymous exports known only by their export ids.
  • Keep the DLL in a resource and expose it in the file system (under a suitably obscure name, perhaps even generated at run time) only when running.
  • Hide all real functions behind a factory method that exchanges a secret (better, proof of knowledge of a secret) for a table of function pointers to the real methods.
  • Use anti-debugging techniques borrowed from the malware world to prevent reverse engineering. (Note that this will likely get you false positives from AV tools.)

Regardless, a sufficiently determined user can still figure out ways to use it. A decent disassembler will quickly provide all the information needed.

Note that if your DLL is really a COM object, or worse yet a CLR Assembly, then there is a huge amount of runtime type information that you can't strip off without breaking its intended use.

EDIT: Since you've retagged to imply that C# and .NET are the environment rather than a pure Win32 DLL written in C, then I really should revise the above to "You Can't, But..."

There has been a market for obfuscation tools for a long time to deal with environments where delivery of compilable source is mandatory, but you don't want to deliver useful source. There are C# products that play in that market, and it looks like at least one has chimed in.

Because loading an Assembly requires so much effort from the framework, it is likely that there are permission bits that exert some control for honest providers and consumers of Assemblies. I have not seen any discussion of the real security provided by these methods and simply don't know how effective they are against a determined attack.

A lot is going to depend on your use case. If you merely want to prevent casual use, you can probably find a solution that works for you. If you want to protect valuable trade secrets from reverse engineering and reuse, you may not be so happy.

RBerteig
+5  A: 

You're facing the same issue as proponents of DRM.

If your program (which you wish to be able to run the DLL) is runnable by some user account, then there is nothing that can stop a sufficiently determined programmer who can log on as that user from isolating the code that performs the decryption and using that to decrypt your DLL and run it.

You can of course make it inconvenient to perform this reverse engineering, and that may well be enough.

j_random_hacker
+1 because +100 isn't allowed.
RBerteig
A: 

You may be interested in the following information about Friend assemblies: http://msdn.microsoft.com/en-us/library/0tke9fxk(VS.80).aspx

Sean Newton
A: 

Well you could mark all of your "public" classes as "internal" or "protected internal" then mark you assemblies with [assembly:InternalsVisibleTo("")] Attribute and no one but the marked assemblies can see the contents.

Saint Gerbil
Reflection allows to use even private types/members.
Michael Damatov
Do you mean, even if you apply the InternalsVisibleTo attribute Reflector.Net can still expose the code?
Jon
A: 

Have you tried .Net reactor? I recently came across it. Some people say its great but I am still testing it out.