views:

189

answers:

5

In my .net application I want to restrict reflection to certain assemblies. I mean I want that my a particular assembly can be reflected by only some predefined assemblies not by any other than that. How can i do that?

Edit:

This tool completely shuts down .NET disassembly and decompilation of an assembly. I want to allow some predefined assemblies to reflect this assembly but restrict others doing this. I want something that should be declared assembly wise e.g. AssemblyOne has gives permission to AssemblyTwo that you can reflect me, so only AssemblyTwo should be able to reflect it with full trust, no one else.

+4  A: 

If the person has full trust of the assembly, you can't prevent them from accessing any part of it.

http://www.pcreview.co.uk/forums/thread-2196297.php

Kevin
+1  A: 

Reflection is irresistible! :-)

I don't think you can prevent reflection other than writing native code. And still, that can be disassembled. If you need to keep some code off unauthorized hands, keep it on a server that you control and allow remote access to it.

guardi
+2  A: 

The tool you linked to basically compiles the entire application into native code. That doesn't really "shut down" Reflection or anything else, it just turns the application into something entirely different, it's no longer bytecode and not technically a .NET assembly anymore.

Callers with full trust can always use reflection on a .NET assembly and everything inside it. Aside from (a) obfuscation, which anybody with enough patience and determination could de-obfuscate, or (b) compiling into native code, which would prevent any kind of reflection (and many other useful features), you can't prevent this from happening, and you certainly can't restrict it to specific assemblies.

The ReflectionPermissionAttribute, contrary to what one of the other answers says, does not prevent callers from reflecting on your code; rather, it controls access from that code to the Reflection APIs. It's not going to be of any help here.

Why is it so important to hide your code or class structure anyway? Unless you're working for the NSA, most code just isn't that valuable/secret, and most applications are trivially easy to reverse-engineer given sufficient time and resources. Realistically, an attacker or plagiarist stands to gain very little from copying code out of Reflector and/or using Reflection to discover your API.

I suppose I can only speak for myself, but given 1 free day to either implement a cool feature or invest in trying to protect the internal code, I would always work on new features that actually add value.

Aaronaught
I have some requirements of this sort from client, they want to block some of the assemblies being reflected. So I needed to move code that I am reflecting within application, from those assemblies to separate one, but if there is a way to permit some particular assemblies to reflect, It can save a lot of work of mine
viky
@viky: Then your client needs to be educated on how reflection works. There is no opt-in/opt-out system. Moving the code to a separate assembly will not protect the code either.
Aaronaught
+1  A: 

I'm wondering what your scenario is for wanting to restrict reflection. Are you concerned about exposing some super-secret data baked into your codebase? some chunk of code that is so incredibly smart that you have some advantage with it?

The reason I ask is I just don't believe that anything that we do in software dev is so unique in itself at code library level that it requires people not looking at it--so I wonder if maybe you are going down the wrong path. Since you don't mention why you want to block reflection I don't know if maybe your scenario makes sense (at least from my POV) to restrict access.

I can't think of a real-world scenario where restricting access would really get ya anywhere--it's not the brilliance of any particular chunk of code that makes a system nowadays, it's the full package (UX, customer service, rapid evolution keeping pace with usage, etc). If your code is any good, it will change over time so that anyone 'cracking' it will be two steps behind your current iteration (at least). Your value is your brain, not the assembly.

And if you are doing it for security reasons, then you really shouldn't be attempting to 'secure' it by blocking reflection.

Again, you might have a valid reason to block reflection that I haven't thought of, but I rather doubt it's worth the effort and I would tend to believe that your energy would be better spent elsewhere... as in making that code you want to block even better.

Kevin Won
A thief can definitely break the locks but still you lock your doors. Isn't it?
viky
Anyways, There are some specific reasons for which I have to do it but seems there is no way around
viky
Kevin Won
A: 

Kevin: Some developers want to protect their hard work so other people cannot just pick it up, change the company name on it and resell it with minimal effort. That is enough reason. You don't have to work for NSA for your code to be considered valuable. Just because it is difficult to protect the code does not mean it's not worth protecting.

viky: I'd suggest making your application into a Web application for better security if possible. If you must distribute, you can look into code obfuscator's or Mircrosoft SLP Services but I don't think anything is foolproof.

John