混淆是一种方法，但它不能防止破坏应用程序的盗版保护安全。如何确保应用程序不被篡改，如何确保注册机制无法被逆向工程？
此外，还可以将 C# 应用程序转换为本机代码，Xenocode 也可以昂贵。
C# 提供了很多功能，并且是我的代码的理想语言，因此用 C++ 再次编写整个代码库是不可能的。
可以轻松地从 .NET 中的签名程序集中删除安全证书。
Obfuscation is one way, but it can't protect from breaking the piracy protection security of the application. How do I make sure that the application is not tampered with, and how do I make sure that the registration mechanism can't be reverse engineered?
Also it is possible to convert a C# application to native code, and Xenocode is too costly.
C# provides lot of features, and is the ideal language for my code, so writing the whole codebase again in C++ is out of the question.
Secure certificates can be easily removed from the signed assemblies in .NET.
发布评论
评论（30）
你不能。
您可以采取一些步骤来使其变得更加困难，但最终本地计算机上的任何可执行文件都是可破解的。最终，该代码必须转换为本机机器代码，并且每个可运行的应用程序都容易受到攻击。
你想做的只是让它变得足够难以破解，以至于不值得人们去麻烦。
我为您提供一些有助于保护您的应用程序的建议：
但最终，如果人们希望你的应用程序被破解，他们就会这么做。看看所有拥有大量资源来保护其应用程序的商业软件，但它们在应用程序向公众发布之前就被破解了。
熟练的逆向工程师可以启动 IDA-Pro 并像黄油一样剖析您的应用程序，无论发生什么你做。打包的应用程序可以被解包，混淆只会阻止它变得轻松自如。您使用复杂的许可证代码所做的所有努力都可以通过一个字节补丁来撤销。
您只需要接受这样一个事实：人们很有可能会盗版您的软件。有些人无论如何都不会为您的申请付费，您无需担心这些人。
然而，有许多企业永远不会冒诉讼的风险并乐意购买软件许可证，而许多计算机用户要么不想冒这个风险，要么发现它是错误的，要么不精通技术而无法进行盗版。这些是您真正的客户，您应该集中精力为他们提供良好的用户体验，而忽略破解您软件的人。
我的应用程序以前曾被盗版过，我认为这是对我个人的侮辱。我，一个小开发者，全心全意地投入到一个应用程序中，而这些人竟然厚颜无耻地盗用我的作品？！他们直接从我口袋里拿钱！
我立即添加了一堆严厉的 DRM 代码，并试图使用非法或破解的副本来破坏任何人。我当然应该努力让我的申请变得更好，而不是试图阻止不可避免的事情发生。不仅如此，我所采取的所有这些额外保护措施还伤害了我的真正客户。
经过长时间的战斗，我意识到我正在与潮流抗争，而浪费的所有时间都是徒劳的。我拿出了除了准系统许可证功能之外的所有回拨代码，并且再也没有回头。
You can't.
There are steps you can take to make it a little more difficult, but ultimately any executable on the local machine is crackable. Eventually, that code has to be converted into native machine code and every application that is runnable is vulnerable.
What you want to do is just make it difficult enough to crack to make it not worth peoples' trouble.
Some suggestions I have for you to help protect your application:
Ultimately though, if people want your application cracked they will. Look at all the commercial software out there that has a vast amount of resources to protect their applications and yet they are cracked before the applications are even released to the public.
A skilled reverse engineer can fire up IDA-Pro and slice through your application like butter no matter what you do. A packed application can be unpacked and obfuscation only prevents it from making it a walk in the park. All your hard work with your complex license code can be undone with a single byte patch.
You just need to accept that there is a very real chance people are going to pirate your software. There are some people who are never going to pay for your application no matter what and these are the people you don't need to worry about.
There are however, many businesses out there who would never risk a lawsuit and happily buy software licenses and many computer users who either don't want to risk it, find it wrong or are not tech savvy enough to pirate. These are your true customers, and you should focus your efforts on providing them with a good user experience and ignore the people cracking your software.
I've had my application pirated before, and I took it as a personal affront. Here I was, a small-time developer, pouring my heart and soul into an application and these people had the gall to pirate from me?! They were taking money directly from my pocket!
I immediately added in a bunch of draconian DRM code and attempted to sabotage any person using an illegitimate or cracked copy. I should of course have been working on making my application better instead of trying to stop the inevitable. Not only that, but I was hurting my true customers will all these extra protections I was putting in.
After a long battle I realized I was fighting the tides and all this time wasted was for naught. I took out all the phone-home code except for the barebones license functions and never looked back.
您无法完全保护任何应用程序（托管或非托管）。如果像 Playstation 和 iPad 这样的系统可以被破解——供应商甚至可以控制硬件——你的应用程序还有什么希望呢？值得庆幸的是，你并不是真的想这么做。在我看来，您需要确保您的应用程序足够安全，以免有人意外盗版您的产品，仅此而已。
例如，如果您使用每台计算机许可证，它不应该只在您将其安装在新的第二台计算机上时才起作用。您需要一条良好的错误消息来防止额外的支持电话，但不要花费额外的时间使其变得难以解决，也不要用它来打击用户。
另一个例子是限时审判。甚至不用担心简单的事情，比如用户是否可以回滚系统时钟。这样做的人知道他们正在违反您的许可证，只要用户知道他们何时违反了您的规定，您就已经做得足够了。
您需要做这么多，因为用户不关心您的许可证。许可证是虚构的东西，除非需要，否则没有人关心。没有人读它们，他们也确实不应该读。因此，告诉用户边界在哪里的最佳方法是应用程序的开箱即用行为是否符合许可证。在第一种情况下，这意味着安装失败或第二次以试用版模式安装。对于后者，这可能只是意味着检查配置文件中的纯文本日期。无论哪种方式，请确保以优雅、乐于助人和尊重的方式处理此事。
这就解释了“做那么多”意味着什么。但为什么不更进一步呢？ 为什么不堵住你能找到的每一个小洞？答案分为两部分。首先，如果有人跨越有意识违反您的许可条款的道德门槛——即使是以一种简单的方式——他们也会愿意做一些更困难或危险的事情，比如从torrent 站点 — 并且运行从不受信任的来源下载的应用程序存在一定的危险。对于这些用户来说，让它变得更加困难只是一个小烦恼，并且有可能给您的付费客户带来问题。保持简单可能会防止有人深入研究您的应用程序并发布更全面的破解。其次，你没有足够的眼睛来寻找缺陷；黑客有很多，而且他们有更多的练习来找到它们。你只需要错过一个小缺陷，你的应用程序就会在盗版网站上有相同的分布，就好像你什么也没做一样。你必须每次都正确；他们只需要幸运一次。因此，所需的努力非常高，而任何成功的可能性都非常低。
最终，如果有人想要盗版您的应用程序（而不是仅仅使用它），而这是他们的主要目标，他们就会这么做。 你无法阻止它们。这是软件的本质；这是软件的本质。一旦构成您产品的文件位于用户的计算机上，他们就可以按照自己的意愿使用这些文件。这在 Java 或 .NET 等托管环境中尤其重要，但它绝对适用于本机代码以及。时间站在他们一边，只要有足够的时间，任何数字安全都可以被攻破。
由于您无法阻止用户盗版您的产品，因此您最好的做法是以一种对您有利的方式吸引此类用户。通常可以让他们为你工作而不是反对你。考虑到这一点，无论您的应用程序是什么，保留几乎功能齐全且不会过期的免费版本可能都是值得的。即使是 1 美元的价格标签和免费之间的差异也是巨大的，如果没有其他原因，只是客户不必信任你的信用卡。产品的免费版本不仅可以有效地消除盗版发行（当您可以以相同的价格买到正版产品时，为什么还要冒险购买盗版版本呢？），它还有可能极大地扩大您的受众。
结果是，您可能需要提高付费版本的价格，这样最终您将拥有 100,000 个免费用户，而不是 2,000 个每个 20 美元的用户，其中 500 个愿意为“专业”版本支付 99 美元。与花费大量时间锁定产品相比，这可以为您赚更多的钱。不仅如此，您还可以通过多种重要方式吸引这些免费用户并利用这种关系。
一是支持。悲观主义者会借此机会抱怨支持 100,000 个免费用户的成本增加，但令人惊奇的事情却发生了：你的产品在很大程度上变得自给自足。在没有资金支持成本的大型开源项目中，您经常会看到这种情况。用户将挺身而出并实现这一目标。
免费用户通常一开始就降低了支持期望，这是有充分理由的。您所需要做的就是将免费版本标记为仅符合社区支持的资格，并为此目的建立一个用户管理的在线论坛。您的支持知识库是自动生成的，高级用户将代表您指导那些需要额外帮助的人。更重要的是，这将使您能够更快地识别和纠正错误，最终提高产品质量并降低总支持成本。这在以前是不可能的，因为您的用户群不够大，但是当您将免费用户视为客户时，它可以很好地工作。
另一个是反馈。通过观看您的论坛，您可以了解到您可能从未考虑过的重要改进想法。这可以让您最终将更多免费用户转变为付费用户，并创建更具吸引力的产品，吸引更多受众。
最后，您需要考虑营销。所有这些免费用户现在都是粉丝而不是对手，他们会采取相应的行动。不仅如此，当发布您的下一个版本时，这些用户将全部通过您批准的分发渠道，而不是其他一些未知的机制。这意味着对于您的下一个版本，您将开始与更多、高度感兴趣和支持的受众建立联系。
为专业版保留的最佳功能是旨在简化企业部署和管理的工具。破解者不会认为这些是一个足够令人信服的理由来破解它供自己使用，但对于想要购买 300 个许可证并将其推广到全公司范围的企业来说，这是必须具备的。当然，专业版无论如何都会被盗版，但再次强调：不要担心，因为无论你做什么，你都可能无法将产品出售给那些盗版者，所以它不会花费你任何< /em> 收入。
虽然从心理上来说，放弃这么多的产品可能很困难，但希望您能理解这确实是最好的方式。不仅如此，从长远来看，这是唯一的出路。我知道有人认为他们不想这样做。毕竟，他们多年来一直通过销售 20 美元的锁定产品来维持现状。但这太糟糕了，因为如果您不这样做，最终会有其他人这样做。他们的产品将和你的产品一样好，或者足够接近，他们可以侥幸声称这一点。然后突然之间，你的定价看起来非常离谱，销量急剧下降，而你却无能为力。如果需要，您可以选择额外的中间层，但这不太可能对您有帮助。
You can't fully secure any application (managed or not). If systems like the Playstation and iPad can get cracked — where the vendor even controls the hardware — what hope does your app have? Thankfully, you don't really want to. In my opinion, you need to secure your application just enough that someone can't accidentally pirate your product, and no more.
For example, if you use a per-machine license, it shouldn't just work when you install it on a new second machine. You'll want a good error message to prevent extra support calls, but don't spend extra time making it too hard to work around and don't hit users over the head with it.
Another example is a time-limited trial. Don't even worry about simple things like if users can just roll back the system clock. Someone who does that knows they are breaking your license, and as long as a user knows when they are in violation you've done enough.
You need to do this much because users don't care about your license. Licenses are made-up things that nobody cares about until they need to. No one reads them, and they really shouldn't have to. Therefore the best way to tell the user where the boundaries are is if the out-of-the-box behavior for your application complies with the license. In this first case that means either failing to install or installing in trial-version mode the second time. For the latter, it might just mean checking a plain-text date in a configuration file. Either way, make sure you handle it in an elegant, helpful, and respectful manner.
So that explains what it means do just that much. But why not go any further? Why not plug every little hole you can find? The answer is in two parts. First, if someone will cross the ethical threshold of consciously breaking your license terms — even in a simple way — they'll also be willing to do something more difficult or dangerous like pull your application from a torrent site — and there is a certain amount of danger involved in running applications downloaded from untrusted sources. Making it any harder is only a minor annoyance for these users and risks causing problems with your paying customers. Keeping it simple may prevent someone from digging into your application and releasing a more comprehensive crack. Second, you have few eyes available to look for flaws; the hackers have many, and they have more practice finding them. You only need to miss one little flaw, and your app will have the same distribution on pirate sites as if you did nothing. You have to be right every time; they only have to be lucky once. So the effort required is very high, and the likelihood of any measure of success is very low.
Ultimately, if someone wants to pirate your application (as opposed to just using it), and that is their main goal, they will. There's nothing you can do to stop them. This is the nature of software; once the files that make up your product are on a user's computer they will be able to do with them as they wish. This is especially relevant in managed environments like Java or .NET, but it definitely applies to native code as well. Time is on their side, and given enough time any digital security can be broken.
Since you can't stop users from pirating your product, your best course of action is to engage this class of user in a way the uses them to your benefit. It is often possible to get them working for you rather than against you. With that in mind, no matter what your application is, it's probably worth it to keep a free version that is almost completely functional and doesn't expire. The difference between even a US$1 price tag and free is huge, if for no other reason than that the customer doesn't have to trust you with their credit card. A free edition of your product will not only effectively kill pirated distribution (why risk a pirated version when you can be legitimate for the same price?), it has the potential to dramatically expand your audience.
The result is that you may need to increase the price of the for-pay edition, so that in the end instead of 2,000 users at $20 each you have 100,000 free users, of which 500 are willing to pay $99 for the "professional" edition. This earns you more money than if you spent a bunch of time locking up your product. More than that, you can engage these free users and leverage the relationship in several important ways.
One is support. A pessimist would take this opportunity to complain about the increased cost of supporting 100,000 free users, but something amazing happens instead: your product becomes largely self supporting. You see this all the time with large open source projects that have no money for support costs. Users will step up and make it happen.
Free users generally have reduced support expectations to begin with, and for good reason. All you need to do is mark the free edition as only qualifying for community support and put up a user-moderated online forum for that purpose. Your support knowledge base is self-generating, and advanced users will shepherd those who need extra hand-holding on your behalf. Even more importantly, this will allow you to identify and correct bugs faster, ultimately improving the quality of your product and lowering total support costs. This wasn't possible before because your user base wasn't large enough, but when you treat the free users as customers it can work very well.
Another is feedback. By watching your forum, you learn important improvement ideas that you may never have considered otherwise. This can allow you to ultimately turn more of your free users into paid users and create a more compelling product that will attract an even larger audience.
Finally, you need to consider marketing. All these free users are now fans rather than adversaries, and they will act accordingly. Not only that, but when it comes time to release your next version these users will have all gone through your approved distribution channel, rather than some other unknown mechanism. That means for your next version you start out connected with a larger, highly interested and supportive audience.
The best features to reserve for the professional edition are tools aimed at making it easy to do corporate deployment and management. A cracker won't see these as a compelling enough reason to hack it for his own use, but for a business looking to buy 300 licenses and push it out company-wide this is a must-have. Of course, the professional edition will be pirated anyway, but again: don't sweat it because you probably wouldn't be able to sell the product to those pirates no matter what you did, so it's not costing you any revenue.
While psychologically it can be hard to give away your product this much, hopefully you can understand how it really is the best way to go. Not only that, it's the only way to go in the long term. I know someone is out there thinking that they don't want to do it this way. After all, they've got by just fine selling their locked-down $20 product for years. But that's just too bad, because if you don't do it this way, eventually someone else will. And their product will be just as good as yours, or close enough they can get away with claiming that. Then all of a sudden your pricing looks outrageous, sales drop dramatically, and there's nothing else you can do. You can opt for an additional middle tier if you must, but it's unlikely to help you.
根据我的经验，让你的应用程序或库更难破解会伤害你诚实的客户，同时只会稍微延迟不诚实的客户。专注于制造出色、低摩擦的产品，而不是花费大量精力来推迟不可避免的事情。
In my experience, making your application or library more difficult to crack hurts your honest customers whilst only slightly delaying the dishonest ones. Concentrate on making a great, low friction product instead of putting a lot of effort into delaying the inevitable.
与很多人分享的秘密就不是秘密。如果你的代码中有秘密内容，对其进行混淆并不能起到保护作用；只需要对其进行反混淆一次。如果您有不想与客户分享的秘密，那么就不要与客户分享。。将您的代码编写为 Web 服务，并将您的超级秘密代码保存在您自己的服务器上，只有您可以看到它。
A secret that you share with lots of people is not a secret. If you have secret stuff in your code, obfuscating it is no protection; it only has to be deobfuscated once. If you have a secret that you don't want to share with your customers, then don't share it with your customers. Write your code as a web service and keep your super secret code on your own server, where only you can see it.
从广义上讲，存在三类人。
那些不会购买您的软件并诉诸破解的人，或者如果他们没有找到任何破解，则根本不会使用您的软件。不要指望从这个团体中赚到任何钱。他们要么依靠自己的技能，要么依靠破解者（他们倾向于根据你的有用性和受众有多大来优先考虑他们的时间。越有用，破解就越早可用）。
无论您使用什么保护机制，都会购买（付费）您的软件的合法用户群体。不要使用复杂的保护机制让合法用户的生活变得困难，因为无论如何他们都会为此付出代价。复杂的保护机制很容易破坏用户体验，您不希望这种情况发生在这个群体上。就我个人而言，我会投票反对任何硬件解决方案，因为这会增加软件的成本。
少数人会诉诸“不道德”破解，并且只会为您的软件付费，因为其功能受到许可机制的保护。您可能不想让该组织非常容易地规避您的保护。然而，您为保护软件所付出的所有努力都会得到回报，具体取决于这群人的规模。这完全取决于您正在构建的软件类型。
鉴于您所说的，如果您认为有足够多的少数人可以被迫购买您的软件，请继续实施某种形式的保护。考虑一下您可以从这少数人身上赚多少钱，以及您在保护上花费的时间，或者您在第三方保护 API/工具上花费的金额。
如果您想实现自己的解决方案，那么使用公钥加密是防止轻易黑客攻击的好方法（与对称算法相反）。例如，您可以对您的许可证进行数字签名（序列号或许可证文件）。解决这个问题的唯一方法是反编译、更改和重新编译代码（您可以使用 Simucal 的答案中建议的技术使代码变得更难）。
Broadly speaking, there are three groups of people out there.
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.
Given what you've said, if you think there is a large enough minority who can be pushed into buying your software, go ahead and implement some form of protection. Think about how much money you can make from this minority versus the time you spend working on the protection, or the amount you spend on a third party protection API/tool.
If you like to implement a solution of your own, using public-key cryptography is a good way (as opposed to symmetric algorithms) to prevent easy hacks. You could for instance digitally sign your license (serial no, or license file). The only way to get around this would then be to decompile, alter and recompile the code (which you could make harder using techniques such as those suggested in Simucal's answer).
您无法阻止人们破解您的软件。
但是，您可以让它们产生裂缝，从而减少对您销售的影响。可以为您的软件发出有效注册码的密钥生成器比从您的软件中消除注册激励的简单补丁要糟糕得多。这是因为破解仅适用于一个软件版本，并且将不再适用于您发布的下一个软件更新。密钥生成器将继续工作，直到您更改注册密钥算法为止，这是您不想经常做的事情，因为它会推迟您诚实的客户。
因此，如果您正在寻找一种方法来对抗软件的非法密钥生成器，并且您不想使用非对称加密，因为它会生成很长的注册代码，那么您可以看看部分密钥验证。
部分密钥验证可确保每个非法密钥生成器仅适用于软件的一个特定版本。基本上，您要做的就是确保软件的每个版本仅与用于检查注册代码的某些数字的代码链接。哪些数字到底是随机的，因此破解者必须对软件的许多不同版本进行逆向工程，并将所有这些组合到一个密钥生成器中，以便发布适用于所有版本的软件的密钥生成器。
如果您定期发布新的软件版本，这会导致大量密钥生成器散布在各种软件盗版档案中，而这些密钥生成器不再起作用。潜在的软件盗版者通常会寻找最新版本的破解版或注册机，因此他们可能会尝试其中一些并最终放弃。
我在我的 (C++) 较新的共享软件游戏中使用了部分密钥验证，它非常有效。在此之前，我们的密钥生成器遇到了很多我们无法解决的问题。后来出现了很多破解和一些仅适用于该特定版本游戏的密钥生成器，但没有适用于所有版本的密钥生成器。我们定期发布游戏的非常小的更新，并使所有先前存在的裂缝变得毫无用处。
似乎有一个开源用于部分密钥验证的.NET框架，尽管我还没有尝试过。
You can't prevent people from cracking your software.
However, you can make them create cracks that will hurt your sales less. Keygenerators that can issue a valid registration code for your software are much worse than simple patches that remove registration incentives from your software. That's because a crack will work for one software version only, and will cease to work with the next software update you release. The keygenerator will continue to work until you change your registration key algorithm and that's something you don't want to do often because it will put off your honest clients.
So, if you are looking for a method to fight illegal keygenerators for your software and you do not want to use assymetric encryption because of the long registration codes this generates, you might have a look at Partial Key Verification.
Partial Key Verification makes sure that each illegal keygenerator works only for one particular release of your software. Basically what you do is to make sure that each release of your software only links with the code for checking SOME digits of the registration code. Which digits exactly is random, so crackers would have to reverse engineer many different versions of your software and combine all this into one keygenerator in order to release a keygenerator that works for all versions of your software.
If you release new software versions on a regular basis, this leads to numerous keygenerators spread on all kinds of software piracy archives which are not working anymore. Potential software pirates usually look for a crack or keygen for the latest version, so they will likely try a few of those and give up eventually.
I've used the Partial Key Verification in my (C++) newer shareware games and it has been very effective. Before we had plenty of problems with keygenerators which we could not fight. Afterewards there were lots of cracks and some few keygenerators that worked only for that particular version of the game, but no key generator that would work with all versions. We regularly released very minor updates of the game and to render all previously existing cracks useless.
There seems to be an open source .NET framework for Partial Key Verification, although I have not tried it.
使用在线更新来阻止那些未经许可的副本。
验证应用程序不同模块的序列号，不要使用单个模块
调用函数进行验证（这样破解者就无法轻易绕过验证）。
不仅检查序列号
启动时，进行验证
保存数据，每周五执行一次
晚上，当用户空闲时执行
...
验证应用程序文件检查
sum，将您的安全检查总和存储在
不同的地方。
不要在这些方面走得太远
技巧，确保你的应用程序
永远不会崩溃/出现故障
验证注册码时。
构建一个对用户有用的应用程序是
比做一个重要得多
对于破解者来说是牢不可破的二进制文件。
Use online update to block those unlicensed copies.
Verify serial number from different modules of your application and do not use a single
function call to do the verification (so that crackers cannot bypass the verification easily).
Not only check serial number at
startup, do the verification while
saving data, do it every Friday
evening, do it when user is idle
...
Verify application file check
sum, store your security check sum in
different places.
Don't go too far on these kind of
tricks, make sure your application
never crash/get into malfunction
while verifying registration code.
Build a useful app for users is
much more important than make a
unbreakable binary for crackers.
您可以..
Microsoft SLP 服务InishTech 的软件潜力提供帮助保护代码的能力而不影响您的应用程序的功能。更新：（披露：我在 Eazfuscator.NET 上工作）
Microsoft SLP Services软件潜力的不同之处在于虚拟化代码的能力，因此你绝对可以。可以。自从这个问题最初提出以来已经过去了好几年了。如今，有更多产品也可以在类似的基础上工作，例如：You can..
Microsoft SLP ServicesInishTech's Software Potential offers the ability to help protect code without affecting the functionality of your applications.UPDATE: (Disclosure: I work on Eazfuscator.NET) What makes
Microsoft SLP ServicesSoftware Potential different is the ability to virtualize the code, so you definitely can. Several years passed since the question was originally asked; today there are more products available that also work on a similar basis such as:.NET Reflector 只能打开“托管代码”，基本上意味着“.NET 代码”。因此您不能使用它来反汇编 COM DLL 文件、本机 C++、经典 Visual Basic 6.0
您可以使用混淆器使代码更难以阅读，但您无法完全阻止其被反编译，同时又使其无法被 .NET 读取。有一些产品（通常很昂贵）声称可以“链接”您的托管代码将应用程序转换为本机代码应用程序，但即使这些实际上有效，有决心的人总会找到方法。
然而，当涉及到混淆时，你会得到你付出的代价。因此，如果您的代码是如此专有，以至于您必须竭尽全力保护它，那么您应该愿意投资一个好的混淆器。
然而，在我大约 15 年的代码编写经验中，我意识到过度保护源代码是浪费时间，而且没有什么好处。仅仅尝试阅读原始源代码而不支持文档、注释等可能会非常难以理解。再加上反编译器产生的毫无意义的变量名和现代混淆器创建的意大利面条代码 - 您可能不必太担心人们窃取您的知识产权。
.NET Reflector can only open "managed code" which basically means ".NET code". So you can't use it to disassemble COM DLL files, native C++, classic Visual Basic 6.0 code, etc. The structure of compiled .NET code makes it very convenient, portable, discoverable, verifiable, etc. .NET Reflector takes advantage of this to let you peer into compiled assemblies but decompilers and disassemblers are by no means specific to .NET and have been around as long as compilers have been around.
You can use obfuscators to make the code more difficult to read, but you can't exactly prevent it from being decompiled without also making it unreadable to .NET. There are a handful of products out there (usually expensive) that claim to "link" your managed code application into a native code application, but even if these actually work, a determined person will always find a way.
When it comes to obfuscation however, you get what you pay for. So if your code is so proprietary that you must go to such great lengths to protect it, you should be willing to invest money in a good obfuscator.
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.
如果您希望人们能够运行您的代码（如果您不这样做，那么您为什么要首先编写它？），那么他们的 CPU 需要能够执行您的代码。为了能够执行代码，CPU需要能够理解它。
由于 CPU 是愚蠢的，而人类不是，这意味着人类也可以理解代码。
只有一种方法可以确保您的用户不会收到您的代码：不要向他们提供您的代码。
这可以通过两种方式实现：软件即服务 (SaaS)，即您运行您的软件位于您的服务器上，并且只允许您的用户远程访问它。例如，这就是 StackOverflow 使用的模型。我很确定 StackOverflow 不会混淆他们的代码，但你无法反编译它。
另一种方式是设备模型：您不向用户提供代码，而是向他们提供包含该代码的计算机。这是游戏机、大多数手机和 TiVo 使用的模型。请注意，这仅在您“拥有”整个执行路径时才有效：您需要构建自己的 CPU、自己的计算机、编写自己的操作系统和自己的 CLI 实现。然后，只有这样您才能保护您的代码。 （但请注意，即使是最小的错误也会使您的所有保护措施毫无用处。微软、苹果、索尼、音乐行业和电影行业都可以证明这一点。）
或者，您可以什么也不做，这意味着您的代码将自动受到版权法的保护。
If you want people to able to run your code (and if you don't, then why did you write it in the first place?), then their CPU needs to be able to execute your code. In order to be able to execute the code, the CPU needs to be able to understand it.
Since CPUs are dumb, and humans aren't, this means that humans can understand the code as well.
There's only one way to make sure that your users don't get your code: don't give them your code.
This can be achieved two ways: Software as a service (SaaS), that is, you run your software on your server and only let your users access it remotely. This is the model that Stack Overflow uses, for example. I'm pretty sure that Stack Overflow doesn't obfuscate their code, yet you can't decompile it.
The other way is the appliance model: instead of giving your users your code, you give them a computer containing the code. This is the model that gaming consoles, most mobile phones and TiVo use. Note that this only works if you "own" the entire execution path: you need to build your own CPU, your own computer, write your own operating system and your own CLI implementation. Then, and only then can you protect your code. (But note that even the tiniest mistake will render all of your protections useless. Microsoft, Apple, Sony, the music industry and the movie industry can attest to that.)
Or, you could just do nothing, which means that your code will be automatically protected by copyright law.
真的值得吗？只要有足够的决心，每一种保护机制都可以被打破。考虑你的市场、产品价格、客户数量等。
如果你想要更可靠的东西，那么就走硬件密钥的道路，但这对用户来说相当麻烦而且更昂贵。软件解决方案可能会浪费时间和资源，而且它们唯一能给您的就是“安全”的错误感觉。
还有一些想法（没有一个是完美的，因为没有完美的）。
并且不要在上面浪费太多时间，因为破解者对典型技术有很多经验，并且比你领先几步。除非您想使用大量资源，否则可能会更改编程语言（以 Skype 方式进行）。
Is it really worth it? Every protection mechanism can be broken with sufficient determination. Consider your market, price of the product, amount of customers, etc.
If you want something more reliable then go down the path of hardware keys, but that's rather troublesome (for the user) and more expensive. Software solutions would be probably a waste of time and resources, and the only thing they would give you is the false sense of 'security'.
Few more ideas (none is perfect, as there is no perfect one).
And don't waste too much time on it, because the crackers have a lot of experience with the typical techniques and are few steps ahead of you. Unless you want to use a lot of resources, probably change the programming language (do it the Skype way).
除了购买保护之外，您（或您的开发人员）还可以学习复制保护。
这些是想法：
首先，尝试编写一个将自身写入控制台的程序。这是一个著名的问题。此任务的主要目的是练习编写自引用代码。
其次，您需要开发一种技术，以某种方式重写一些代码
依赖于其他方法的CIL。
您可以编写虚拟机（但在 .NET 中）。并在里面放一些代码。
最终，虚拟机运行另一个运行代码的虚拟机。
这是为了不让性能降低太多而很少调用的函数的一部分。
将一些逻辑重写为 C++/CLI，并将托管代码与非托管代码混合。这将使拆卸变得更加困难。在这种情况下，也不要忘记提供 x64 二进制文件。
Apart from purchasing protection, you (or your developers) can learn to copy-protect.
These are ideas:
At first, try to write a program that writes itself to console. That's a famous problem. Primary purpose of this task is to practice writing self-referencing code.
Second, you need to develop a technology that will rewrite some code in a way
dependable on other methods' CIL.
You may write a virtual machine (yet in .NET). And put some code in there.
Ultimately, the virtual machine runs another virtual machine which runs the code.
That's for a part of rarely-called functions for not to slow the performance too much.
Rewrite some logic into C++/CLI, and mix managed code with unmanaged. This will harden the disassembling. In this case, do not forget to provide x64 binaries too.
有几个 .NET 混淆工具的详细比较表：
屏幕截图取自 obfuscators.io
There is a detailed comparison sheet for several .NET obfuscation tools:
Screenshoot taken from obfuscators.io
不幸的是，你不会逃避这个。最好的选择是用 C 语言编写代码，然后P/Invoke它。
有一个小陷阱 22，有人可以将您的应用程序反编译为 CIL 并终止任何验证/激活代码（例如，对 C 库的调用）。请记住，用 C 语言编写的应用程序也会被更顽固的黑客进行逆向工程（只需看看现在破解游戏的速度有多快）。没有什么可以保护您的应用程序。
最后，它的工作原理很像你的家，保护得足够好，这样就需要付出太多的努力（意大利面条代码在这里会有所帮助），这样攻击者就会移动到你的隔壁邻居（竞争:)）。看看Windows Vista，肯定有10种不同的破解方法。
有一些软件包可以加密您的 EXE 文件，并在允许用户使用它时解密它，但同样，这是使用毫无疑问已被破解的通用解决方案。
激活和注册机制针对的是“普通人”：那些没有足够技术头脑来绕过它的人（或者就此而言，他们知道他们可以绕过它）。别为饼干而烦恼，他们有太多的时间了。
Unfortunately, you are not going to run away from this. Your best bet is to write your code in C and P/Invoke it.
There is a small catch-22, someone could just decompile your application to CIL and kill any verification/activation code (for example, the call to your C library). Remember that applications that are written in C are also reverse-engineered by the more persistent hackers (just look at how fast games are cracked these days). Nothing will protect your application.
In the end it works a lot like your home, protect it well enough so that it is too much effort (spaghetti code would help here) and so that the assailant just moves onto your next door neighbor (competition :) ). Look at Windows Vista, there must be 10 different ways to crack it.
There are packages out there that will encrypt your EXE file and decrypt it when the user is allowed to use it, but once again, that is using a generic solution that has no doubt been cracked.
Activation and registration mechanisms are aimed at the 'average Joe:' people who don't have enough tech savvy to bypass it (or for that matter know that they can bypass it). Don't bother with crackers, they have far too much time on their hands.
是的。是真的。如果代码没有被混淆，.NET 代码非常容易被逆向工程。
混淆会给试图对你的软件进行逆向工程的人增加一层烦恼。根据您获得的版本，您将获得不同级别的保护。
Visual Studio 包含 Dotfuscator 版本。由于它是捆绑版本，因此您绝对不会获得最强的混淆。如果您查看他们的功能列表，您将准确地看到您所缺少的内容（以及应用程序将如何使您的代码更安全）。
还有其他一些免费或开源的 .NET 混淆器（但我无法评论它们使用的质量或各种方法）：
最后什么都没有很完美。如果有人真的想看看你的软件是如何工作的，他们就会的。
Yes. It is true. .NET code is extremely easy to reverse engineer if the code is not obfuscated.
Obfuscation will add a layer of annoyance to people trying to reverse engineer your software. Depending on which version you get, you'll get different levels of protection.
Visual Studio includes a version of Dotfuscator. Since it's a bundled version, you're definitely not getting the strongest obfuscation possible. If you look at their feature lists, you'll see exactly what you're missing (and exactly what the application will do to make your code more secure).
There are a couple of other free or open source .NET obfuscators out there (but I can't comment on the quality or the various methods they use):
In the end, nothing is perfect. If somebody really wants to see how your software works, they will.
好吧，您无法完全保护您的产品不被破解，但您可以最大化/增强安全级别，并使其变得有点难以被新手和中级破解者破解。
但请记住，没有什么是破解不了的，只有服务器端的软件受到很好的保护，无法破解。无论如何，为了增强应用程序的安全级别，您可以执行一些简单的步骤来防止某些“并非全部”破解者破解您的应用程序。这些步骤会让这些破解者发疯，甚至绝望：
这些只是防止新手和中级破解者破解您的应用程序的简单方法。如果您有更多保护应用程序的想法，请不要羞于实施它们。这只会让破解者的生活变得艰难，他们会感到沮丧，最终他们会离开你的申请，因为这不值得他们花时间。
最后，您还需要考虑花时间编写良好且高质量的应用程序。不要浪费时间编写复杂的安全层。如果一个好的破解者想要破解你的应用程序，无论你做什么他/她都会做......
现在去为破解者实现一些玩具......
Well, you cannot FULLY protect your product from being cracked, but you can maximize/enhance the security levels and make it a little bit too difficult to be cracked by newbies and intermediate crackers.
But bear in mind nothing is uncrackable, only the software on server side is well protected and cannot be cracked. Anyway, to enhance the security levels in your application, you can do some simple steps to prevent some crackers "not all" from cracking your applications. These steps will make these crackers go nuts and maybe desperate:
Those are just simple methods to prevent newbies and intermediate crackers from cracking your application. If you have more ideas to protect your application just don't be shy to implement them. It will just make crackers lives hard, and they will get frustrated, and eventually they will leave your application, because it's just doesn't worth their time.
Lastly, you also need to consider spending your time on coding a good and quality applications. Don't waste your time on coding complicated security layers. If a good cracker wants to crack your application he/she will do no matter what you do...
Now go and implement some toys for the crackers...
Salamander，它是 Remotesoft 的本机 .NET 编译器和链接器，可以在没有 .NET 的情况下部署应用程序框架。我不知道它的表现如何。
There's Salamander, which is a native .NET compiler and linker from Remotesoft that can deploy applications without the .NET framework. I don't know how well it lives up to its claims.
如果微软能够拿出一个解决方案，我们就不会有盗版Windows版本，所以没有什么是非常安全的。以下是 StackOverflow 中的一些类似问题，您可以实施自己的保护方式。如果您要发布不同的版本，那么您可以针对不同的版本采用不同的技术，这样当第一个版本被破解时，第二个版本就可以接管。
基于许可证管理 C++ 应用程序的功能
使用许可证文件保护 DLL 文件
许可/保护软件？< /em>
If Microsoft could come up with a solution, we will not have pirated Windows versions, so nothing is very secure. Here are some similar questions from Stack Overflow and you can implement your own way of protecting them. If you are releasing different versions then you can adopt different techniques for different version so by the time first one is cracked the second one can take over.
Managing features on a license basis for a C++ application
Secure a DLL file with a license file
Licensing / protection software?
.NET Reactor
更新
Jared 指出 de4dot 声称能够反编译它。
.NET Reactor
Update
Jared pointed out that de4dot claims to be able to decompile it.
这里有一个想法：您可以拥有一台由您的公司托管的服务器，您的软件的所有实例都需要连接到该服务器。仅仅让他们连接并验证注册密钥是不够的——他们只会删除检查。除了密钥检查之外，您还需要让服务器执行一些客户端无法自行执行的重要任务，因此无法删除。当然，这可能意味着您的服务器需要进行大量繁重的处理，但这会使您的软件难以窃取，并且假设您有一个好的密钥方案（检查所有权等），那么密钥也将很难被窃取偷。这可能比您想要的更具侵入性，因为它需要您的用户连接到互联网才能使用您的软件。
Here's one idea: you could have a server hosted by your company that all instances of your software need to connect to. Simply having them connect and verify a registration key is not sufficient -- they'll just remove the check. In addition to the key check, you need to also have the server perform some vital task that the client can't perform itself, so it's impossible to remove. This of course would probably mean a lot of heavy processing on the part of your server, but it would make your software difficult to steal, and assuming you have a good key scheme (check ownership, etc), the keys will also be difficult to steal. This is probably more invasive than you want, since it will require your users to be connected to the internet to use your software.
任何在客户端运行的东西都可以被反编译和破解。混淆只会让事情变得更加困难。我不知道你的申请，但 99% 的时候我认为这不值得付出努力。
Anything running on the client can be decompiled and cracked. Obfusification just makes it harder. I don't know your application, but 99% of the time I just don't think it's worth the effort.
抱歉，不可能完全保护应用程序。
It's impossible to fully secure an application, sorry.
混淆代码！ 混淆 C# 代码中有一个示例。
Obfuscate the code! There is an example in Obfuscating C# Code.
请记住，99% 以上的用户不会有兴趣检查可执行文件以了解其工作原理。
鉴于很少有人愿意费心去尝试，而且大多数混淆器都可以解决，这值得你花时间和精力吗？
您最好投入时间来改进您的产品，以便更多的人想要使用它。
Bear in mind that 99%+ of your users aren't going to be interested in examining your executable to see how it works.
Given that so few people are even going to bother trying and that most obfuscators can be worked around, is it worth your time and effort?
You'd be better off investing the time into improving your product so that more people want to use it.
只是添加一个警告：如果您要使用混淆，请检查一切是否仍然有效！混淆可能会改变类名和方法名等内容。因此，如果您使用反射来调用某些方法和/或类（例如在插件架构中），您的应用程序可能会在混淆后失败。此外，堆栈跟踪对于追踪错误可能毫无用处。
Just to add a warning: if you are going to use obfuscation, check that everything still works! Obfuscation might change things like class- and method-names. So if you use reflection to call certain methods and/or classes (like in a plugin-architecture) your application could fail after obfuscating. Also stacktraces might be useless to track down errors.
如果它是用.NET编写并编译为CIL，则可以反映。如果安全性是一个问题并且要避免混淆，那么我建议使用非托管语言编写应用程序，这本质上更难进行逆向工程。
If it's written in .NET and compiled to CIL, it can be reflected. If security is a concern and obfuscation is to be avoided, then I recommend writing your application using a non-managed language, which is, by nature, harder to reverse engineer.
两者都有相同的非常简单的答案：不要将目标代码分发给不受信任的各方，例如（显然）您的客户。在您的计算机上托管应用程序是否可行仅取决于它的用途。
如果它不是网络应用程序，也许您可以允许SSH 登录，使用 X 转发到应用程序服务器（或 远程桌面连接，我猜，适用于 Windows）。
如果您将目标代码提供给书呆子类型的人，并且他们认为您的程序可能很有趣，那么它就会被破解。没有办法解决它。
如果您不相信我，请指出一个尚未被破解和盗版的高调应用程序。
如果您使用硬件密钥，则会提高生产成本，并且您的用户会因此而讨厌您。在地板上爬来爬去插拔 27 个不同的 USB 东西真是太糟糕了，因为软件制造商不信任你（我想）。
当然，解决方法是破解“can-I-use-it”测试，使其始终返回 true。
一个令人讨厌的技巧可能是以一种肮脏的方式使用在程序中其他地方执行测试的操作码的字节值，除非该值恰到好处，否则很可能会使程序崩溃。不过，它使您链接到特定的架构:-(
Both have the same very simple answer: don't hand out object code to untrusted parties, such as (apparently) your customers. Whether it's feasible to host the application on your machines only depends on what it does.
If it isn't a web application, maybe you can allow for SSH login with X forwarding to an application server (or Remote Desktop Connection, I guess, for Windows).
If you give object code to nerdy type persons, and they think your program might be fun to crack, it will get cracked. No way around it.
If you don't believe me, point out a high-profile application that hasn't been cracked and pirated.
If you go with the hardware keys, it'll make production more expensive and your users are going to hate you for it. It's a real bitch to crawl around on the floor plugging and unplugging your 27 different USB thingies because software makers don't trust you (I imagine).
Of course, the way around it is to crack the "can-I-use-it" test so that it always returns true.
A nasty trick might be to use the byte values of the opcodes that perform the test somewhere else in the program in a dirty way that'll make the program crash with high probability unless the value is just right. It makes you linked to a particular architecture, though :-(
只需制作一个好的应用程序并编写一个简单的保护系统即可。无论您选择什么保护，它都会被逆转...所以不要浪费太多时间/金钱。
Just make a good application and code a simple protection system. It doesn't matter what protection you choose, it will be reversed... So don't waste too much time/money.
对于 .NET，如果您要发布 Windows 窗体 应用程序（或任何应用程序）如果客户端有可移植可执行文件），它就可以被破解。
如果您想坚持使用 .NET 并希望最大程度地减少源代码被盗的可能性，那么您可能需要考虑将其部署为 ASP.NET 应用程序跨网络服务器，而不是使其成为 Windows 窗体应用程序。
When it comes to .NET, if you're releasing a Windows Forms application (or any application where the client has the Portable Executable file), it's able to be cracked.
If you want to stick with .NET and want to minimize the chance of having your source code taken, then you may want to consider deploying it as an ASP.NET application across a webserver, instead of making it a Windows Forms application.
坦白说，有时我们需要对代码进行混淆（例如，注册许可证类别等）。在这种情况下，您的项目不是免费的。 IMO，你应该花钱买一个好的混淆器。
Dotfuscator 隐藏您的代码并且.NET Reflector 在您尝试反编译它时显示错误。
Frankly, sometimes we need to obfuscate the code (for example, register license classes and so on). In this case, your project is not free. IMO, you should pay for a good obfucator.
Dotfuscator hides your code and .NET Reflector shows an error when you attempt to decompile it.