看起来永远是本地的，现在不需要在混淆器; 看起来像网芯RT可行的解决方案;很快所有的应用程序都将使用。net core;https://www.codeproject.com/Articles/5262251/Generate-Native-Executable-from-NET-Core-3-1-Proje?msg=5753507 xx5753507xx https://learn.microsoft.com/en-us/archive/msdn-magazine/2018/november/net-core-publishing-options-with-net-core

没有测试过，也许用旧的win .net SDK可能做类似的事情。

如果微软能想出一个解决方案，我们就不会有盗版的Windows版本，所以没有什么是非常安全的。下面是来自Stack Overflow的一些类似问题，您可以实现自己的保护方式。如果你正在发布不同的版本，那么你可以针对不同的版本采用不同的技术，这样当第一个版本被破解时，第二个版本就可以接管。

基于许可证管理c++应用程序的特性 使用license文件保护DLL文件 授权/保护软件?

广义上讲，有三种人。

Those who will not buy your software and resort to cracks, or if they don't find any, not use your software at all. Don't expect to make any money from this group. They rely either on their own skills or on crackers (who tend to prioritize their time depending on your useful and how big your audience is. The more useful, the sooner a crack will be available). The group of legitimate users who will buy (pay for) your software, irrespective of what protection mechanism you use. Don't make life hard for your legitimate users by using an elaborate protection mechanism since they are going to pay for it in any case. A complex protection mechanism can easily spoil the user experience and you don't want this happening to this group. Personally, I'd vote against any hardware solution, which adds to the cost of your software. A minority who will resort to "unethical" cracking and will only pay for your software because its features are protected by a licensing mechanism. You probably don't want to make it exceedingly easy for this group to circumvent your protection. However, all that effort you spend on protecting your software will pay back, depending on how big this group of people is. This entirely depends on the type of software you're building.

根据您所说的，如果您认为有足够多的少数人可以被推动购买您的软件，那么请继续执行某种形式的保护。考虑一下你能从这些少数人身上赚到多少钱，与你花在保护上的时间相比，或者你花在第三方保护API/工具上的钱。

如果您想实现自己的解决方案，那么使用公钥加密是防止容易被黑客攻击的好方法(与对称算法相反)。例如，您可以对您的许可证(序列号或许可证文件)进行数字签名。解决这个问题的唯一方法就是反编译、修改和重新编译代码(你可以使用Simucal回答中建议的技术来增加难度)。

我也做了一些关于黑客安全的考虑，在我的设计中，我想添加他们，因为他们中的一些人似乎没有被提及:

我在我的应用程序中有一个脚本接口。为了确保，脚本只能调用(python)打算调用的方法-脚本i有一个scriptvisibilityattribute和System.Dynamic.DynamicMetaObjectProvider，它可以识别这些属性。

license使用公钥/私钥。

ViewModels需要被解锁，给解锁函数一个密码。

CoreRoutines可以在加密狗上实现。(周围有加密狗支持)

像包装这样的大解决方案并不是计划好的。

当然，这种脚本/viewModel方法并没有使我们不可能从代码中解锁和调用脚本不可见的函数，但它使这样做变得更加困难——就像所有与反黑客相关的工作一样。

我认为这个话题主要有两个方面。

A) .NET只是反向工程而不是原生的吗?

B)我们是什么类型的程序员?

标题: 保护.NET代码不受逆向工程的影响

我的观点:

Least preference to make commercial application in .NET, because it will expose even your comments on the built binary after decompile. (I don't know what is the logic to include the comments also with binary) So any one can just decompile it, rename/modify/change the look and resell the application in 24 hours. In native application rename/modify/change of look is not possible as easy as one could do in .NET Worried part in .NET is that you could get the whole project with solution from a single binary exe/dll.

想象一下现在的安全状况有多糟糕。 因此，即使是外行也可以轻松地对. net应用程序进行逆向工程。

如果它是本地应用程序，如c++ /VB6/Delphi，只有知道ASM的专家破解者才能修补exe，而不是像。net那样100%逆向工程。

但是现在整个世界都在使用。net，因为用它的高级特性和库很容易做项目。

好消息是，微软似乎在2020年支持。net的本地输出，这将使像我这样的程序员考虑将。net c#作为主要语言。

https://www.codeproject.com/Articles/5262251/Generate-Native-Executable-from-NET-Core-3-1-Proje?msg=5755590#xx5755590xx

根据微软博客中的以下问题:

https://blogs.msdn.microsoft.com/amb/2011/05/27/how-to-prevent-ildasm-from-disassembling-my-net-code/

如何防止ILDASM分解程序集?

. net有一个名为SuppressIldasmAttribute的属性，它可以防止分解代码。例如，考虑以下代码:

using System;
using System.Text;
using System.Runtime.CompilerServices;
[assembly: SuppressIldasmAttribute()]

namespace HelloWorld
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello world...");
        }
    }
}

如你所见，只有两个不同之处:

我们添加了System.Runtime.CompilerServices命名空间减速。 我们添加了[assembly: SuppressIldasmAttribute()]属性。

在Visual Studio中构建应用程序后，当我们尝试在ILDASM中打开生成的EXE文件时，现在我们得到以下消息: