Restricting using strong named dlls functionality

Question

Hi, I'm trying to think of a way that prevent others using your published dlls, for example let's say you create a cool light weight winui photo processing tool that's separated into several assemblies. one of them is your precious filters.dll assembly that basically does all of the core filtering work. Once you publish your application, how can you prevent from others taking this filters.dll and using it in other projects.

I've already tried to look at the StrongNameIdentityPermissionAttribute which has a good example here but it doesn't seem to work for me, the code just works without throwing any security exceptions..

Any ideas ?

Answer 1

One method that may work for you is to declare the the methods and classes in the filter assembly to be internal and explicitly specify the assemblies that can access it as "friends".

You do this with an assembly declaration (ususally in assemblyinfo) like:

[assembly:InternalsVisibleTo("cs_friend_assemblies_2")]

see Friend Assemblies for more info.

Also make sure you obfuscate the assembly or people can dig into the code with reflector.

Answer 2

Strong names have nothing to do with preventing or inhibiting reverse engineering. They only serve to stop people substituting assemblies with hacked versions - and only if people havent turned off strong name verification. There's nothing to stop people taking your code, ILDASMing or Reflectoring and re-ILASMing as they see fit.

InternalsVisibleTo and friends are on an honour system at the compiler level too, so not much use for what you're looking for (although for some obfuscators, internals get more agressively obfuscated than publics by default - though this can generally be overcome). My main concern here is to point out that jsut because something is 'internal' doesnt bestow on it any magic code protection pixie dust that stops reverse engineering.

Most of this stuff re why these sort of approaches arent a solution for code protection is summarised very well in this article

There are also code protection products on the market that go beyond obfuscation which sound like the tool for the job you describe.

Answer 3

Don't bother worrying too much about protecting your .NET code. If you deploy it to someone elses computer, and that person wants to use or read your code, they will.

If your code is valuable enough you need to keep it on a computer you control (such as a web server) and guard against unauthorised access.

Obfuscation will only slow determined people down. Strong naming and signing is not used to protect your code, but instead to ensure that the user can confirm the code originates from who they expect it to come from (ie ensure it hasn't been tampered with).