请记住，99%以上的用户不会有兴趣检查你的可执行文件，看看它是如何工作的。

考虑到很少有人会去尝试，而且大多数混淆器都是可以解决的，它值得你花时间和精力吗?

你最好把时间投入到改进你的产品上，让更多人愿意使用它。

只需编写一个好的应用程序和一个简单的保护系统。不管你选择什么保护，它都会被逆转……所以不要浪费太多时间/金钱。

请记住，99%以上的用户不会有兴趣检查你的可执行文件，看看它是如何工作的。

考虑到很少有人会去尝试，而且大多数混淆器都是可以解决的，它值得你花时间和精力吗?

你最好把时间投入到改进你的产品上，让更多人愿意使用它。

除了购买保护之外，您(或您的开发人员)还可以学习复制保护。

这些想法是:

首先，尝试编写一个将自己写入控制台的程序。这是一个著名的问题。这个任务的主要目的是练习编写自引用代码。

其次，您需要开发一种技术，以某种方式重写一些代码 可依赖于其他方法的CIL。

你可以编写一个虚拟机(但是使用。net)。在这里放一些代码。 最终，虚拟机运行另一个运行代码的虚拟机。 这是针对很少调用的函数的一部分，目的是为了不太降低性能。

将一些逻辑重写为c++ /CLI，并混合托管代码和非托管代码。这将使拆卸变得坚硬。在这种情况下，不要忘记提供x64二进制文件。

广义上讲，有三种人。

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回答中建议的技术来增加难度)。

. net Reflector只能打开“托管代码”，这基本上意味着“。NET代码”。所以你不能用它来分解COM DLL文件、原生c++、经典的Visual Basic 6.0代码等。编译后的。net代码的结构非常方便、可移植、可发现、可验证等。net Reflector利用了这一点，让你窥探已编译的程序集，但反编译器和反汇编器绝不是。net特有的，它们和编译器一样早就存在了。

您可以使用混淆器使代码更难阅读，但是您不能在不使. net无法读取的情况下完全阻止它被反编译。市面上有一些产品(通常价格昂贵)声称可以将托管代码应用程序“链接”到本地代码应用程序，但即使这些产品真的可以工作，有决心的人总能找到方法。

然而，当涉及到混淆时，一分钱一分货。因此，如果您的代码是如此专有，以至于您必须竭尽全力来保护它，那么您应该愿意在一个好的混淆器上投资。

However, in my 15 or so years of experience writing code I've realized that being over-protective of your source code is a waste of time and has little benefit. Just trying to read original source code without supporting documentation, comments, etc. can be very difficult to understand. Add to that the senseless variable names that decompilers come up with and the spaghetti code that modern obfuscators create - you probably don't have to worry too much about people stealing your intellectual property.