How can I restrict reflection for certain assembli

问题:

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.

回答1:

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.

回答2:

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

回答3:

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.

回答4:

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.