混淆是一种方式,但它不能防止破坏应用程序的盗版保护安全。如何确保应用程序不被篡改,如何确保注册机制不会被逆向工程?
也可以将 C# 应用程序转换为本机代码,而Xenocode成本太高。
C# 提供了很多功能,并且是我的代码的理想语言,因此再次用 C++ 编写整个代码库是不可能的。
可以轻松地从 .NET 中的签名程序集中删除安全证书。
混淆是一种方式,但它不能防止破坏应用程序的盗版保护安全。如何确保应用程序不被篡改,如何确保注册机制不会被逆向工程?
也可以将 C# 应用程序转换为本机代码,而Xenocode成本太高。
C# 提供了很多功能,并且是我的代码的理想语言,因此再次用 C++ 编写整个代码库是不可能的。
可以轻松地从 .NET 中的签名程序集中删除安全证书。
你不能。
您可以采取一些步骤使其变得更加困难,但最终本地计算机上的任何可执行文件都是可破解的。最终,该代码必须转换为本机机器代码,并且每个可运行的应用程序都是易受攻击的。
您要做的只是使其难以破解,使其不值得人们麻烦。
我有一些建议可以帮助保护您的应用程序:
但最终,如果人们希望您的应用程序被破解,他们会的。看看那些拥有大量资源来保护其应用程序的商业软件,但它们甚至在应用程序发布给公众之前就被破解了。
无论您做什么,熟练的逆向工程师都可以启动IDA-Pro并像黄油一样切入您的应用程序。打包的应用程序可以被解包,混淆只会阻止它在公园里散步。您使用复杂的许可证代码所做的所有辛勤工作都可以通过一个字节补丁来撤消。
您只需要接受人们很有可能盗版您的软件。有些人无论如何都不会为您的申请付费,而这些人是您无需担心的。
然而,有许多企业永远不会冒险提起诉讼并乐于购买软件许可证,而许多计算机用户要么不想冒险,要么发现它错了,要么对盗版技术不够了解。这些是您真正的客户,您应该集中精力为他们提供良好的用户体验,而忽略破解您软件的人。
我的应用程序以前被盗版过,我认为这是对我个人的侮辱。在这里,我是一个小开发人员,全心全意地投入到应用程序中,而这些人竟敢从我这里盗版?!他们直接从我的口袋里拿钱!
我立即添加了一堆严苛的 DRM 代码,并试图使用非法或破解副本破坏任何人。我当然应该一直致力于使我的应用程序更好,而不是试图阻止不可避免的事情。不仅如此,我所采取的所有这些额外保护措施都会伤害到我真正的客户。
经过长时间的战斗,我意识到我正在与潮汐作斗争,所有这些浪费的时间都是徒劳的。除了准系统许可功能外,我取出了所有的电话回家代码,再也没有回头。
您无法完全保护任何应用程序(托管或非托管)。如果像 Playstation 和 iPad 这样的系统可以被破解——供应商甚至可以控制硬件——你的应用还有什么希望?谢天谢地,你真的不想。在我看来,您需要保护您的应用程序,以防止有人意外盗版您的产品,仅此而已。
例如,如果您使用每台机器的许可证,那么当您将它安装在新的第二台机器上时,它不应该只工作。你会想要一个好的错误消息来防止额外的支持电话,但不要花费额外的时间让它太难解决,也不要用它来打击用户。
另一个例子是限时试用。甚至不用担心简单的事情,例如用户是否可以回滚系统时钟。这样做的人知道他们正在违反您的许可,并且只要用户知道他们何时违反了您就已经做得足够了。
您需要这样做,因为用户不关心您的许可证。许可证是虚构的东西,除非需要,否则没人关心。没有人阅读它们,他们真的不应该阅读它们。因此,告诉用户边界在哪里的最佳方法是您的应用程序的开箱即用行为是否符合许可。在第一种情况下,这意味着安装失败或第二次以试用版模式安装。对于后者,它可能只是意味着检查配置文件中的纯文本日期。无论哪种方式,请确保以优雅、乐于助人和尊重的方式处理它。
所以这就解释了做那么多是什么意思。但为什么不更进一步呢?为什么不堵住你能找到的每一个小洞呢?答案分为两部分。首先,如果有人越过有意识地违反你的许可条款的道德门槛——即使是以简单的方式——他们也会愿意做一些更困难或更危险的事情,比如从洪流中提取你的应用程序网站 — 运行从不受信任的来源下载的应用程序存在一定的危险。对于这些用户来说,让它变得更难只是一个小烦恼,并有可能导致您的付费客户出现问题。保持简单可能会阻止有人深入研究您的应用程序并发布更全面的破解。其次,你没有多少眼睛可以寻找缺陷;黑客有很多,而且他们有更多的练习来找到它们。你只需要漏掉一个小缺陷,你的应用程序就会在盗版网站上进行相同的分发,就好像你什么都没做一样。你必须每次都是对的;他们只需要幸运一次。因此,所需的努力非常高,任何衡量成功的可能性都非常低。
最终,如果有人想要盗版您的应用程序(而不是仅仅使用它),这是他们的主要目标,他们会的。你无法阻止他们。这是软件的本质;一旦构成您的产品的文件在用户的计算机上,他们就可以随意使用它们。这在 Java 或.NET等托管环境中尤其重要,但它也绝对适用于本机代码。时间站在他们这边,只要有足够的时间,任何数字安全都可以被破解。
由于您无法阻止用户盗版您的产品,因此您最好的做法是让这类用户以一种使他们受益的方式参与其中。通常可以让他们为你工作而不是反对你。考虑到这一点,无论您的应用程序是什么,保留一个几乎完全可用且不会过期的免费版本可能是值得的。即使是 1 美元的价格标签和免费之间的差异也是巨大的,如果没有其他原因,客户不必用他们的信用卡信任您。您的产品的免费版本不仅会有效地扼杀盗版发行(当您可以以相同的价格获得合法版本时,为什么还要冒着盗版的风险?),它有可能极大地扩大您的受众。
结果是你可能需要提高付费版的价格,这样最终你就有了 10 万免费用户,而不是每人 20 美元的 2000 名用户,其中 500 名愿意为“专业”版支付 99 美元. 与花费大量时间锁定产品相比,这可以为您赚更多的钱。不仅如此,您还可以吸引这些免费用户并以多种重要方式利用这种关系。
一是支持。悲观主义者会借此机会抱怨支持 100,000 名免费用户的成本增加,但令人惊奇的事情却发生了:您的产品在很大程度上可以自我支持。在没有钱支付支持成本的大型开源项目中,您总是会看到这种情况。用户将加紧努力并实现它。
免费用户通常一开始就降低了对支持的期望,这是有充分理由的。您需要做的就是将免费版标记为仅符合社区支持的条件,并为此目的建立一个用户主持的在线论坛。您的支持知识库是自动生成的,高级用户将代表您引导那些需要额外帮助的人。更重要的是,这将使您能够更快地识别和纠正错误,最终提高产品质量并降低总支持成本。这在以前是不可能的,因为您的用户群不够大,但是当您将免费用户视为客户时,它可以很好地工作。
另一个是反馈。通过观看您的论坛,您可以了解您可能从未考虑过的重要改进想法。这可以让您最终将更多的免费用户转变为付费用户,并创造出更具吸引力的产品,从而吸引更多的受众。
最后,您需要考虑营销。所有这些免费用户现在都是粉丝而不是对手,他们会采取相应的行动。不仅如此,当发布您的下一个版本时,这些用户都将通过您批准的分发渠道,而不是其他一些未知的机制。这意味着对于您的下一个版本,您将开始与更多、高度感兴趣和支持的观众建立联系。
为专业版保留的最佳功能是旨在简化企业部署和管理的工具。破解者不会将这些视为足够令人信服的理由来破解它以供自己使用,但对于希望购买 300 个许可证并将其在公司范围内推出的企业来说,这是必须具备的。当然,专业版无论如何都会被盗版,但再次强调:不要担心,因为无论您做什么,您都可能无法将产品出售给那些盗版者,因此不会花费您任何收入。
虽然从心理上讲,很难把你的产品送出这么多,但希望你能理解这真的是最好的方式。不仅如此,从长远来看,这是唯一的出路。我知道有人在那里认为他们不想这样做。毕竟,他们多年来一直很好地销售他们锁定的 20 美元产品。但这太糟糕了,因为如果你不这样做,最终会有人这样做。他们的产品会和你的一样好,或者足够接近他们可以逃脱声称。然后突然之间你的定价看起来离谱,销售额急剧下降,你无能为力。如果必须,您可以选择额外的中间层,但这不太可能对您有所帮助。
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 服务,并将您的超级密码保存在您自己的服务器上,只有您可以看到它。
从广义上讲,那里有三类人。
那些不会购买您的软件并求助于破解的人,或者如果他们没有找到任何破解,则根本不使用您的软件。不要指望从这个群体中赚钱。他们要么依靠自己的技能,要么依靠破解者(他们倾向于根据你的有用性和你的受众有多大来优先考虑他们的时间。越有用,破解就越快可用)。
将购买(支付)您的软件的合法用户群体,无论您使用何种保护机制。不要使用精心设计的保护机制让合法用户的生活变得艰难,因为无论如何他们都会为此付出代价。复杂的保护机制很容易破坏用户体验,你不希望这种情况发生在这个群体身上。就个人而言,我会投票反对任何硬件解决方案,这会增加您的软件成本。
少数会诉诸“不道德”破解并且只会为您的软件付费的人,因为它的功能受到许可机制的保护。您可能不想让该组非常容易绕过您的保护。但是,您在保护软件上所付出的所有努力都会得到回报,具体取决于这群人的规模。这完全取决于您正在构建的软件类型。
鉴于您所说,如果您认为有足够多的少数人可以被迫购买您的软件,请继续实施某种形式的保护。考虑一下您可以从这个少数群体中赚多少钱,与您花在保护上的时间,或者您在第三方保护 API/工具上花费的金额。
如果您想实现自己的解决方案,使用公钥加密是防止简单黑客攻击的好方法(与对称算法相反)。例如,您可以对您的许可证(序列号或许可证文件)进行数字签名。解决此问题的唯一方法是反编译、更改和重新编译代码(使用 Simucal 的答案中建议的技术,您可以使代码变得更难)。
您无法阻止人们破解您的软件。
但是,您可以让它们产生裂缝,从而减少对您的销售造成的伤害。可以为您的软件颁发有效注册码的密钥生成器比从您的软件中删除注册激励的简单补丁要糟糕得多。那是因为破解只适用于一个软件版本,并且将不再适用于您发布的下一个软件更新。密钥生成器将继续工作,直到您更改注册密钥算法,这是您不希望经常做的事情,因为它会推迟您的诚实客户。
因此,如果您正在寻找一种方法来对抗您的软件的非法密钥生成器,并且由于生成的注册码较长,您不想使用非对称加密,那么您可以看看 Partial Key Verification。
部分密钥验证确保每个非法密钥生成器仅适用于您的软件的一个特定版本。基本上,您要做的是确保您的软件的每个版本仅与用于检查注册码的某些数字的代码链接。哪些数字是随机的,因此破解者必须对软件的许多不同版本进行逆向工程,并将所有这些组合到一个密钥生成器中,以便发布适用于所有软件版本的密钥生成器。
如果您定期发布新的软件版本,这会导致大量密钥生成器散布在各种不再起作用的软件盗版档案中。潜在的软件盗版者通常会寻找最新版本的破解或注册机,因此他们可能会尝试其中的一些并最终放弃。
我在我的 (C++) 较新的共享软件游戏中使用了部分密钥验证,它非常有效。在我们遇到很多无法解决的密钥生成器问题之前。之后有很多破解和一些仅适用于该特定游戏版本的密钥生成器,但没有适用于所有版本的密钥生成器。我们会定期发布非常小的游戏更新,并让之前存在的所有裂缝失效。
似乎有一个用于 Partial Key Verification 的开源.NET 框架,虽然我没有尝试过。
使用在线更新来阻止那些未经许可的副本。
从应用程序的不同模块验证序列号,不要使用单个函数调用来进行验证(这样破解者就无法轻易绕过验证)。
不仅启动时检查序列号,保存数据时进行验证,每周五晚上进行,用户空闲时进行......
验证应用程序文件校验和,将您的安全校验和存储在不同的地方。
不要在这些技巧上走得太远,确保您的应用程序在验证注册码时永远不会崩溃/出现故障。
为用户构建一个有用的应用程序比为破解者制作一个牢不可破的二进制文件更重要。
你可以..
Microsoft SLP 服务InishTech 的软件潜力提供了在不影响应用程序功能的情况下帮助保护代码的能力。
更新:(披露:我在 Eazfuscator.NET 上工作)使Microsoft SLP 服务软件潜力不同的是能够虚拟化代码,所以你绝对可以。自从最初提出这个问题以来已经过去了几年。今天有更多可用的产品也可以在类似的基础上工作,例如:
.NET Reflector只能打开“托管代码”,这基本上意味着“.NET 代码”。所以你不能用它来反汇编 COM DLL 文件、原生 C++、经典的Visual Basic 6.0代码等。编译的 .NET 代码的结构使其非常方便、可移植、可发现、可验证等。.NET Reflector 利用这让您可以查看已编译的程序集,但反编译器和反汇编器绝不是特定于 .NET 的,只要编译器存在就一直存在。
您可以使用混淆器使代码更难阅读,但您不能完全防止它被反编译,而不会使其对 .NET 不可读。有一些产品(通常很昂贵)声称将您的托管代码应用程序“链接”到本机代码应用程序,但即使这些产品确实有效,一个有决心的人总能找到方法。
然而,当涉及到混淆时,你会得到你所付出的。因此,如果您的代码是如此专有,以至于您必须竭尽全力保护它,您应该愿意在一个好的混淆器上投资。
然而,在我 15 年左右的代码编写经验中,我意识到对源代码进行过度保护是浪费时间并且没有什么好处。仅仅试图在没有支持文档、注释等的情况下阅读原始源代码可能会非常难以理解。再加上反编译器提出的无意义的变量名和现代混淆器创建的意大利面条代码——你可能不必太担心人们窃取你的知识产权。
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 方式进行)。
除了购买保护之外,您(或您的开发人员)还可以学习复制保护。
这些是想法:
首先,尝试编写一个将自身写入控制台的程序。这是一个著名的问题。此任务的主要目的是练习编写自引用代码。
其次,您需要开发一种技术,该技术将以一种依赖于其他方法的CIL的方式重写某些代码。
您可以编写一个虚拟机(但在.NET中)。并在那里放一些代码。最终,虚拟机运行另一个运行代码的虚拟机。这是为了不让性能降低太多而很少调用的函数的一部分。
将一些逻辑重写为 C++/CLI,并将托管代码与非托管代码混合在一起。这将加强拆卸。在这种情况下,不要忘记也提供x64二进制文件。
不幸的是,你不会逃避这一点。最好的办法是用 C 语言编写代码并P/Invoke。
有一个小的 catch-22,有人可以将您的应用程序反编译为CIL并终止任何验证/激活代码(例如,对您的 C 库的调用)。请记住,用 C 编写的应用程序也会被更顽固的黑客进行逆向工程(看看这些天破解游戏的速度有多快)。没有什么可以保护您的应用程序。
最后,它的工作原理很像你的家,保护得足够好,这样它就会付出太多的努力(意大利面条代码在这里会有所帮助),这样攻击者就会移动到你的隔壁邻居身上(竞争:))。看看Windows Vista,一定有10种不同的破解方法。
有一些软件包可以加密您的 EXE 文件并在允许用户使用它时对其进行解密,但再一次,这是使用毫无疑问已被破解的通用解决方案。
激活和注册机制针对的是“普通乔”:那些没有足够的技术知识来绕过它(或者就此而言知道他们可以绕过它)的人。不要为饼干而烦恼,他们手头有太多的时间。
好吧,你不能完全保护你的产品不被破解,但你可以最大化/增强安全级别,让它有点难以被新手和中级破解者破解。
但请记住,没有什么是无法破解的,只有服务器端的软件受到了很好的保护,无法破解。无论如何,为了提高应用程序的安全级别,您可以执行一些简单的步骤来防止某些“并非全部”的破解者破解您的应用程序。这些步骤将使这些饼干发疯,甚至绝望:
这些只是防止新手和中级破解者破解您的应用程序的简单方法。如果您有更多想法来保护您的应用程序,请不要羞于实施它们。它只会让饼干的生活变得艰难,他们会感到沮丧,最终他们会离开你的申请,因为这不值得他们花时间。
最后,您还需要考虑花时间编写优质的应用程序。不要浪费时间编写复杂的安全层。如果一个好的破解者想要破解你的应用程序,无论你做什么,他/她都会做......
现在去为饼干实施一些玩具......
是的。是真的。如果代码没有被混淆,.NET 代码非常容易进行逆向工程。
混淆会给试图对您的软件进行逆向工程的人增加一层烦恼。根据您获得的版本,您将获得不同级别的保护。
Visual Studio 包含一个Dotfuscator版本。由于它是捆绑版本,因此您肯定不会获得最强的混淆。如果您查看他们的功能列表,您会确切地看到您缺少什么(以及应用程序将如何使您的代码更安全)。
还有其他一些免费或开源的 .NET 混淆器(但我无法评论它们使用的质量或各种方法):
最后,没有什么是完美的。如果有人真的想看看你的软件是如何工作的,他们会的。
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.
Salamander是 Remotesoft 的本地 .NET 编译器和链接器,可以在没有 .NET 框架的情况下部署应用程序。我不知道它是否符合其要求。
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.
It's impossible to fully secure an application, sorry.
混淆代码!Obfuscating C# Code中有一个示例。
在客户端上运行的任何东西都可以被反编译和破解。混淆只会让它变得更难。我不知道你的应用程序,但 99% 的时间我认为这不值得付出努力。
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.
我可以推荐使用Obfuscator。
如果它是用 .NET 编写并编译为CIL,则可以反映。如果安全是一个问题并且要避免混淆,那么我建议使用非托管语言编写您的应用程序,从本质上讲,这种语言更难进行逆向工程。
如何保证应用不被篡改,如何保证注册机制不被逆向工程。
两者都有一个非常简单的答案:不要将目标代码分发给不受信任的各方,例如(显然)您的客户。在您的机器上托管应用程序是否可行仅取决于它的作用。
如果它不是Web 应用程序,也许您可以允许通过 X 转发到应用程序服务器(或远程桌面连接,我猜,对于 Windows)进行SSH登录。
如果您将目标代码提供给书呆子类型的人,并且他们认为您的程序可能很有趣,那么它就会被破解。没有办法解决它。
如果您不相信我,请指出一个尚未被破解和盗版的高知名度应用程序。
如果您使用硬件密钥,它将使生产成本更高,并且您的用户会因此而讨厌您。在地板上爬来爬去插拔 27 个不同的 USB 东西真是个婊子,因为软件制造商不信任你(我想)。
有一些软件包可以加密您的 EXE 并在允许用户使用它时对其进行解密
当然,绕过它的方法是破解“我可以使用它”测试,以便它始终返回 true。
一个讨厌的技巧可能是使用操作码的字节值,这些字节值在程序中的其他地方以一种肮脏的方式执行测试,这将使程序很有可能崩溃,除非该值恰到好处。但是,它使您链接到特定的体系结构:-(
只需制作一个好的应用程序并编写一个简单的保护系统。不管你选择什么保护,它都会被逆转……所以不要浪费太多时间/金钱。
坦率地说,有时我们需要对代码进行混淆处理(例如,注册许可类等)。在这种情况下,您的项目不是免费的。IMO,您应该为一个好的混淆器付费。
Dotfuscator会隐藏您的代码,而.NET Reflector在您尝试对其进行反编译时会显示错误。
请记住,99% 以上的用户不会对检查可执行文件以了解其工作方式感兴趣。
鉴于很少有人会费心去尝试,而且大多数混淆器都可以解决,这值得你花时间和精力吗?
你最好把时间花在改进你的产品上,让更多的人想要使用它。
只是添加一个警告:如果您要使用混淆,请检查一切是否仍然有效!混淆可能会改变类名和方法名之类的东西。因此,如果您使用反射来调用某些方法和/或类(例如在插件架构中),您的应用程序可能会在混淆后失败。堆栈跟踪也可能无法追踪错误。
我还对我的设计中的黑客安全性做了一些考虑,并想添加它们,因为其中一些似乎没有被提及:
我的应用程序中有一个脚本接口。为了确保,脚本只能调用打算由(python)脚本调用的方法,我有一个 scriptvisibilityattribute 和 System.Dynamic.DynamicMetaObjectProvider 可以识别这些属性。
许可证使用公钥/私钥。
ViewModel 需要解锁,并为解锁功能提供密码。
CoreRoutines 可以在加密狗上实现。(周围有加密狗支持)
没有计划像包装器这样的大解决方案。
当然,这种脚本/viewModel 方法不会使您无法从代码中解锁和调用脚本不可见的函数,但这样做会变得更加困难——就像所有与反黑客努力相关的事情一样。
最好的答案是第一个来自小开发者的经验,上面讨论的所有反逆向技术对于任何严重的逆向工程师来说都是101个教科书案例。
一些商业 DRM 解决方案相当不错,但它们总是在数小时(或数天)内使用自定义 DRM 解决方案破解每款三重 AAA 游戏。只有引入全新的 DRM 解决方案——有时——不可避免地会延迟几周。
充分利用 DRM 需要花费大量时间和金钱,而且很容易损害性能、可靠性、兼容性/可移植性和一般客户关系。要么坚持一些体面的商业 DRM,而不要试图太聪明并承担你的(更少)损失,或者完全忘记它......
挖自己(商业)坟墓的 DRM 解决方案的一个示例:http ://en.wikipedia.org/wiki/StarForce
是的,.NET二进制文件(EXE 和 DLL)可以很容易地反编译成几乎源代码。检查工具.NET Reflector。只需针对任何 .NET 二进制文件进行尝试。最好的选择是混淆文件,它们仍然可以被 .NET Reflector 反编译,但它们会造成无法阅读的混乱。我认为好的混淆器不会免费或便宜。一个是 Visual Studio 附带的 Dotfuscator Community Edition。
看起来永远是原生的,现在不需要混淆器;看起来像 net core RT 可行的解决方案;很快所有应用程序都将转到 .net 核心;https://www.codeproject.com/Articles/5262251/Generate-Native-Executable-from-NET-Core-3-1-Proje?msg=5753507#xx5753507xx https://docs.microsoft.com/en-us /archive/msdn-magazine/2018/november/net-core-publishing-options-with-net-core
未测试可能与旧的 win .net sdk 可能类似。
根据微软博客中的以下问题:
https://blogs.msdn.microsoft.com/amb/2011/05/27/how-to-prevent-ildasm-from-disassemble-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 中构建应用程序后,当我们尝试在 中打开生成的 EXE 文件时ILDASM
,现在我们收到以下消息:
我从两个主要方面看待这个话题。
A) .NET 是否只能进行逆向工程而不是原生的?
B)我们是什么类型的程序员/业余爱好者?
标题:保护 .NET 代码免受逆向工程
我的观点:
最不喜欢在 .NET 中制作商业应用程序,因为它甚至会在反编译后公开您对构建二进制文件的评论。(我不知道将注释也包含在二进制文件中的逻辑是什么)所以任何人都可以反编译它,重命名/修改/更改外观并在 24 小时内转售应用程序。
在本机应用程序中重命名/修改/更改外观不可能像在 .NET 中那样简单
.NET 中令人担忧的部分是,您可以从单个二进制 exe/dll 获得整个项目的解决方案。
想象一下它在安全方面有多周。因此,即使是外行也可以轻松地对 .NET 应用程序进行逆向工程。
但是现在整个世界都在.NET 后面运行,因为使用高级功能和库很容易制作项目。
使用 Skater .NET 混淆器。该 .NET 保护工具适用于 de4dot,deobfuscator 将原始受保护的程序集成员名称重命名为人类可读的字符串。溜冰者与之抗争!
最近 MindSystemm 小组发布了一个名为 Skater.NetDeobfuscator [url: https://github.com/MindSystemm/Skater.NetDeobfuscator] 的特殊工具,它利用了 Skater .NET 混淆器的漏洞。混淆器的开发者 Rustemsoft LLC 收到了急需保护关键 Skater .NET 混淆器算法和软件基础设施的信号,以便为 Skater 用户提供更强大的源代码保护。那已经解决了。