How can I protect my private funcs against reflection executing?

Question

After seeing this: Do access modifiers affect reflection also?

I tried using this, but it doesn't work:

How can I prevent reflection from executing my private methods?

Answer 1

If someone can currently use reflection on your private methods, then they already have enough access to sidestep anything else you place in their way. Running with less trust may be an option, but that is only to prevent things like plugins from having too much access - it won't stop a user with (say) admin access to the box, who can simply elevate the access.

If you don't want code running, don't put it in physical reach of the malicious user; keep it at a web-service or similar. Any code available to a user can be used directly, or indirectly by decompiling it (and deobfuscating it if needed). You can use some tricks to get in their way (checking the caller via the stacktrace etc), but that will not stop someone determined.

Answer 2

This is a late answer, but I consider it an update since all the answers were written before the release of .NET 4.6 in mid of 2015 which introduces a new assembly attribute called DisablePrivateReflection.

With that attribute tagged in your AssemblyInfo.cs, you can disable reflection over private members of that assembly.

Example:

namespace DisablingPrivateReflection
{
    public class Singleton
    {
        private Singleton()
        {

        }
    }
}

And in your AssemblyInfo.cs add this line:

[assembly: DisablePrivateReflection]

Then in your client assembly that is referencing the above assembly, this code would fail at run-time:

var singleton = Activator.CreateInstance(typeof(Singleton), true);

The exception thrown is of type MethodAccessException with message:

Attempt by method 'Program.Main(System.String[])' to access method 'DisablingPrivateReflection.Singleton..ctor()' failed.

Answer 3

How can I protect my private funcs against reflection executing?

You can change your security policy so that the code does not have permission to do "private reflection" when you run it.

Of course, that will only affect your machine. If you want to affect someone else's machine, send an email to their machine administrator and ask the administrator to change the user's security policy so that it does not have permission to do "private reflection". That's the person who owns the machine and the network it runs on; obviously you do not have the ability to change the security settings on a network you don't own.

Note of course that rights more powerful than private reflection also have to be restricted. It does no good to set a policy that says, for example "private reflection rights are denied, but the right to change security policy is granted". The user could then just change security policy to re-grant private reflection to themselves.

You'll also have to restrict ability to access the disk. Someone who can access the disk can simply read the code out of the assembly, change the private metadata to public, and load the assembly normally.

So, your mission is to convince all of the machine administrators of the world to not allow their users to access their own disks. I suspect you will be unsuccessful; I suggest that you find a different way to protect your functions from abuse.