.NET模糊处理工具/策略 [英] .NET obfuscation tools/strategy

问题描述

我的产品具有多个组件：ASP.NET，Windows Forms App和Windows Service。大约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.

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

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-syntax和 var 这样的编译器魔术师，以及像 yield 这样的C＃2函数（其中导致名称不可读的新类）。反编译的代码与可编译的代码之间的距离很长。

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.

有很多时间的专业团队仍然可以再次对其进行反向工程，但是对于任何混淆的代码来说，情况都是如此。他们从中获得的代码是难以维护的，并且很可能是非常bug。

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屋！