.NET 混淆工具/策略 [英] .NET obfuscation tools/strategy

问题描述

我的产品有几个组件:ASP.NET、Windows 窗体应用程序和 Windows 服务.95%左右的代码是用VB.NET编写的.

My product has several components: ASP.NET, Windows Forms App and Windows Service. 95% or so of the code is written in VB.NET.

出于知识产权的原因，我需要对代码进行混淆，直到现在我一直在使用 dotfuscator 的一个版本，这个版本现在已经超过 5 年了.我认为是时候转向新一代工具了.我正在寻找的是在搜索新的混淆器时应该考虑的要求列表.

For Intellectual Property reasons, I need to obfuscate the code, and until now I have been using a version of dotfuscator which is now over 5 years old. I'm thinking it is time to move to a new generation tool. What I'm looking for is a list of requirements which I should consider when searching for a new obfuscator.

我知道我应该寻找的东西:

What I know I should look for so far:

• 序列化/反序列化.在我当前的解决方案中，我只是告诉工具不要混淆任何类数据成员，因为无法加载以前序列化的数据的痛苦实在是太大了.
• 与构建过程集成
• 使用 ASP.NET.过去，由于更改 .dll 名称(通常每页有一个)，我发现此问题存在问题 - 并非所有工具都能很好地处理.

• Serialization/De-serialization. In my current solution, I simply tell the tool not to obfuscate any class data members because the pain of not being able to load data which was previously serialized is simply too big.
• Integration with Build Process
• Working with ASP.NET. In the past, I have found this problematic due to changing .dll names (you often have one per page) - which not all tools handle well.

推荐答案

回到 .Net 1.1 混淆是必不可少的:反编译代码很容易，你可以从汇编到 IL，再到 C# 代码，然后用很少努力.

Back with .Net 1.1 obfuscation was essential: decompiling code was easy, and you could go from assembly, to IL, to C# code and have it compiled again with very little effort.

现在使用 .Net 3.5 我完全不确定.尝试反编译 3.5 程序集；你得到的距离编译还有很长的路要走.

Now with .Net 3.5 I'm not at all sure. Try decompiling a 3.5 assembly; what you get is a long long way from compiling.

添加 3.5 中的优化(远好于 1.1)以及匿名类型、委托等由反射处理的方式(它们是重新编译的噩梦).添加 lambda 表达式、编译器魔术"(如 Linq 语法和 var)和 C#2 函数(如 yield(这会导致新类的名称不可读).你的反编译代码离可编译还有很长的路要走.

Add the optimisations from 3.5 (far better than 1.1) and the way anonymous types, delegates and so on are handled by reflection (they are a nightmare to recompile). Add lambda expressions, compiler 'magic' like Linq-syntax and var, and C#2 functions like yield (which results in new classes with unreadable names). Your decompiled code ends up a long long way from compilable.

一个有很多时间的专业团队仍然可以再次对其进行逆向工程，但任何混淆的代码也是如此.他们从中得到的代码将是不可维护的，并且极有可能有很多错误.

A professional team with lots of time could still reverse engineer it back again, but then the same is true of any obfuscated code. What code they got out of that would be unmaintainable and highly likely to be very buggy.

我建议对您的程序集进行密钥签名(这意味着如果黑客可以重新编译一个，他们必须重新编译所有程序集)但我认为混淆不值得.

I would recommend key-signing your assemblies (meaning if hackers can recompile one they have to recompile all) but I don't think obfuscation's worth it.

这篇关于.NET 混淆工具/策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！