如何保护我的私有函数免受反射执行？

Question

看到这个之后： 访问修饰符也会影响反射吗？

我尝试使用这个，但它不起作用：

如何防止反射执行我的私有方法？

Answer 1

如果某人当前可以对您的私有方法使用反射，那么他们已经有足够的访问权限来避开您放置在他们的方式中的任何其他内容。以较少的信任运行可能是一种选择，但这只是为了防止插件等拥有过多的访问权限 - 它不会阻止具有（例如）管理员访问权限的用户，他们可以简单地提升访问权限。

如果您不希望代码运行，请不要将其放在恶意用户的物理接触范围内；将其保存在网络服务或类似服务中。用户可用的任何代码都可以直接使用，也可以通过反编译（并在需要时对其进行反混淆）来间接使用。您可以使用一些技巧来阻止他们（通过堆栈跟踪等检查调用者），但这不会阻止某些人的决心。

Answer 2

这是一个迟来的答案，但我认为这是一个更新，因为所有答案都是在 2015 年中期 .NET 4.6 发布之前编写的，该版本引入了一个名为 禁用PrivateReflection。

通过在 AssemblyInfo.cs 中标记该属性，您可以禁用对该程序集的私有成员的反射。

示例：

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

        }
    }
}

在 AssemblyInfo.cs 中添加以下行：

[assembly: DisablePrivateReflection]

然后在引用上述程序集的客户端程序集中，此代码将在运行时失败：

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

抛出的异常类型为 MethodAccessException 并显示消息：

尝试通过方法“Program.Main(System.String[])”访问方法
“DisablingPrivateReflection.Singleton..ctor()”失败。

Answer 3

如何保护我的私有函数免受反射执行？

您可以更改安全策略，以便代码在运行时没有执行“私有反射”的权限。

当然，这只会影响您的机器。如果你想影响别人的机器，发送电子邮件给他们的机器管理员并要求管理员更改用户的安全策略，使其没有权限进行“私人反射”。那是拥有机器及其运行网络的人；显然，您无法更改不属于您的网络上的安全设置。

当然，请注意，比私人反思更强大的权利也必须受到限制。制定一项政策没有任何好处，例如“拒绝私人反映权，但授予更改安全政策的权利”。然后，用户只需更改安全策略即可重新授予自己私有反射。

您还必须限制访问磁盘的能力。可以访问磁盘的人可以简单地从程序集中读取代码，将私有元数据更改为公共，然后正常加载程序集。

因此，您的任务是说服世界上所有的计算机管理员不允许他们的用户访问他们自己的磁盘。我怀疑你不会成功；我建议您找到一种不同的方法来保护您的功能免遭滥用。

Answer 4

访问修饰符不是一种安全机制。

如果如果你可以阻止你的函数通过反射被调用，用户可以反编译你的程序，提取该函数，将其放入一个新的程序集并执行它。

Answer 5

using System;
using System.Reflection;
using System.Diagnostics;
using System.Collections.Generic;
using System.Linq;

class Person
{
    private string SayInternalSecure()
    {
         if (!PrivacyHelper.IsInvocationAllowed<Person>())
            throw new Exception("you can't invoke this private method");
         return "Internal Secure";
    }

    private string SayInternal()
    {
         return "Internal";
    }

    public string SaySomething()
    {
         return "Hi " + this.SayInternal();
    }

    public string SaySomethingSecure()
    {
        return "Hi " + this.SayInternalSecure();
    }

    public void BeingCalledBy()
    {
            Console.WriteLine("I'm being called by: " + new StackTrace().GetFrame(1).GetMethod().Name);
    }
}

public class MethodBaseComparer : IEqualityComparer<MethodBase> 
{
     private string GetMethodIdentifier(MethodBase mb)
     {
      return mb.Name + ":" + String.Join(";", mb.GetParameters().Select(paramInfo=>paramInfo.Name).ToArray());
     }

     public bool Equals(MethodBase m1, MethodBase m2) 
     {
        //we need something more here, comparing just by name is not enough, need to take parameters into account
        return this.GetMethodIdentifier(m1) == this.GetMethodIdentifier(m2);
     }

     public int GetHashCode(MethodBase mb) 
     {
             return this.GetMethodIdentifier(mb).GetHashCode();
     }
}

class PrivacyHelper
{
static Dictionary<Type, MethodBase[]> cache = new Dictionary<Type, MethodBase[]>();
public static bool IsInvocationAllowed<T>()
{
    Type curType = typeof(T);
    if (!cache.ContainsKey(curType))
    {
        cache[curType] = curType.GetMethods(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance).ToArray();
    }
    //StackTrace.GetFrame returns a MethodBase, not a MethodInfo, that's why we're falling back to MethodBody
    MethodBase invoker = new StackTrace().GetFrame(2).GetMethod();
    return cache[curType].Contains(invoker, new MethodBaseComparer());
}
}

public class App
{
public static void CheckCaller()
{
    Person p = new Person();

    Console.WriteLine("- calling via delegate");
    Action action = p.BeingCalledBy;
    action();

    Console.WriteLine("- calling via reflection");
    MethodInfo method = typeof(Person).GetMethod("BeingCalledBy", BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);
    Console.WriteLine(method.Invoke(p, null));

    Console.WriteLine("- calling via delegate again");
    action = (Action)(Delegate.CreateDelegate(typeof(Action), p, method));
    action();
}

public static void Main()
{
    Console.WriteLine("Press key to run");
    Console.ReadLine();

    CheckCaller();

    Person p = new Person();
    Console.WriteLine(p.SaySomething());
    Console.WriteLine(p.SaySomethingSecure());

    MethodInfo privateMethod = typeof(Person).GetMethod("SayInternal", BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);
    Console.WriteLine("invoking private method via Reflection:");
    Console.WriteLine(privateMethod.Invoke(p, null));

    Console.WriteLine("----------------------");

    privateMethod = typeof(Person).GetMethod("SayInternalSecure", BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);
    Console.WriteLine("invoking secured private method via Reflection:");
    try
    {
        Console.WriteLine(privateMethod.Invoke(p, null));
    }
    catch(Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
}
}

Answer 6

没有办法做到这一点。为什么要阻止执行私有函数？通常，如果有人使用反射，他就知道自己在做什么。

Answer 7

不可以，修饰符只是为了开发者进行适当的封装。在运行时，一切都处于同一水平可能会令人难过。

反射机制通常由需要调用一些预配置方法（旧的 ORM）或显示它们（IDE）的应用程序使用。如果这个机制做不到这一点，那就真的很难了。

Answer 8

虽然我绝对同意访问修饰符不是安全功能的想法，但为了编程，我一直在思考这个问题，并且我有一个简单的、没有多大用处的机制，用 Reflection 对抗 Reflection ： -）

请注意，这只是一个愚蠢的概念证明，我没有考虑通用方法，它需要对此进行更改...

这个想法是，在您想要保护的每个私有方法的开始处“非法”调用，您只需检查反映您是从该类中的另一个方法调用的，而不是从外部调用的。所以你会使用：
new StackTrace().GetFrame(1).GetMethod();
获取调用者的 MethodBase 并将其与类的 MethodInfos 列表进行比较。

您可以将其添加到辅助类中（无论如何，您需要一个 IEqualityComparer 来比较 MethodBases...

一个问题是您还会阻止一些正确的调用，例如通过委托或通过另一个方法的反射来调用它。 ..所以你在使用它时应该小心，

你可以我的实现此处

Answer 9

我使用 eazfuscator ，它使方法虚拟化似乎可以很好地隐藏方法。

然后在方法中，我喜欢保护，我将在发布模式下更改代码以提供空指针异常，以启动一个将生成空指针的任务并在没有调用堆栈的代码的情况下执行它。

没有很多开发人员可以在不进行调试的情况下使用您的生产代码...

#if !DEBUG
    #pragma warning disable CS8618 
    
    [System.Diagnostics.DebuggerStepThrough, System.Diagnostics.DebuggerNonUserCode]
    [System.ComponentModel.Browsable(false)]
    [System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
#endif

namespace MyApp.Infrastructure.LicenseManager
{
    [Obfuscation(Feature = "apply to member * when method or constructor: virtualization", Exclude = false)]
    internal sealed class LicenseManager(ISomeClass parameter, ILoggerFactory? factory = null)
    {
       //hide the name space for reverse engineering the naming scheme
       _logger = factory?.CreateLogger("MyApp.LicenseManager") 

    #if !DEBUG
        if (System.Diagnostics.Debugger.IsAttached)
        {
            //send computer information for license violation and prosecution then crash
            System.Threading.ThreadPool.UnsafeQueueUserWorkItem(SystemCrasher.SendAbuseAndCrash);
            
            //send a log entry, of don't if you wish to give no warning
           _logger?.LogWarning(Walter.BOM.LogEvents.FireWall_Warning, "Debugging will cause the developer to generate null pointer exceptions in administration context");
           return;
           
           //all class initiolizers will stay null
         }
    #endif

        _myClass= parameter;

}

#if !DEBUG
#pragma warning restore CS8618 // Non-nullable field must contain a non-null value when exiting constructor. Consider declaring as nullable.
#endif

如果您的代码被共享 DLL 中的其他代码（例如 NuGet 包中）使用，那么上述方法将阻止您受到同事的欢迎，您需要一个“调试”友好的方法，使用方法代理结合混淆可能会为您解决问题。

[Obfuscation(Feature = "virtualization", Exclude = false)]
private void MyMethod(int parameter)
{
    MyMethodProxy();
    //do some code
}

private void MyMethodProxy([CallerMemberName] string? calledBy = null)
{
    if (!string.Equals(nameof(MyMethod), calledBy, StringComparison.Ordinal))
    {
        throw new LordOfTheRingsException("You shall not pass!!");
    }
}

通过使用 NameOf 方法，您可以保留混淆器重命名方案中的不可打印字符。

我使用了一些其他选项，但这会限制您自动化和使用面向方面的框架，例如 postsharp

希望它有所帮助在此处输入代码

Answer 10

我知道这已经很旧了，但是基本上在 .NET 中做你所要求的事情是相对不可能的，但是你可以做一些事情来减少表面积，并且它们通常需要更多的工作。最终你想要阻止的是类型的句柄，对吗？考虑以下场景。

public class OuterView
{
   protected internal class HiddenMethods
   {
       public static void DoMoreWork(string msg)
       {
            Console.WriteLine(msg);
       }
   }

   public void DoWork(string msg)
   {
       HiddenMethods.DoMoreWork(msg);
   }
}

假设这是在一个库中，您不想授予对底层方法的直接访问权限 - Assembly.GetTypes() 将不会返回嵌套类，并且您有权访问的类中的 HiddenMethods 中没有引用到（外部视图）。将状态保存在 OuterView 中，并在每次静态调用时将其传递到 HiddenMethods 中。最终，任何拥有足够访问权限来创建 PEReader 的人仍然可以访问您的 HiddenMethods。但上述方法适用于十分之九的情况。

Answer 11

我会尝试解析堆栈跟踪（https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics?redirectedfrom=MSDN&view=netframework-4.7.2）并检查动态调用...