经典.net混淆器 Confuser EX 2.0 使用介绍及配置 2022

接手了个项目，其内置的1.0混淆器需要更新至2.0版本，顺手将收集到的信息跟大家分享。本站其他几个高赞的混淆器介绍除了介绍怎么用这个界面其实帮助不怎么大....

What -> Why -> How -> Never

一、问题及需求

1. 问题：

• Confuser EX1.0的可靠性是否可靠？请更新至Confuser EX 2.0并比较两代混淆器的差异。

• 现行混淆器参数配置对代码的保护作用是否足够强？

两代混淆器的参数设置对比：左2.0 右1.0

Confuser EX 2.0在加密配置上多了anti dump、watermark、typescramble、harden四个选项，且对前面的设置做了一定程度的修改和加强。

2. 需求

• 改进现有的Confuser EX使用方法

3. 产品预期

• 在不同的模式下采用不同的混淆器配置。

混淆器预设保护强度等级 (决定代码的保护复杂度，同时决定设置的项目多寡）

none->minimum->normal->aggresive->maximum

除none以外的所有preset默认包含anti debug

二、实际执行

• 更新Confuser EX1.0至2.0

更新文件已归档至/Alexsong/Confuser_bin 路径下，可以直接复制后覆盖原文档更新。

• 修改Obfuscation property，确保添加的特性被include

三、问题的解决

Confuser Ex2.0 新特性 及配置介绍

1. AntiTamper: This protection is actually just what is says it is. It's a protection that ensures that the assembly is not altered. The side effect of this protection is that all the method bodies become invisible. How ever when debugging into the protected code with for example dnspy, you'll get the method bodies pretty easily. There are two modes to this protection. The mode "normal" and the mode "JIT". The latter is a broken mess and I strongly suggest to not use it. The protection is (in "normal" mode) sometimes detected as a false positive malicious application. It provides a weak protection from people wanting to look at your code.

1. 防篡改:这种保护实际上就是它所说的那样。这是一种保护，确保组合不被改变。这种保护的副作用是，所有的方法体都变得不可见。无论如何，当使用dnspy调试到受保护的代码时，您将非常容易地获得方法主体。这种保护有两种模式。模式为“normal”和“JIT”。后者是一个破碎的混乱，我强烈建议不要使用它。这种保护(在“正常”模式下)有时被检测为误报恶意应用程序。它提供了一个薄弱的保护，防止人们想要查看您的代码。

1. Constants: This protection hides away constant values. It can protect strings (default), numbers, primitives and initializers (default). It basically encodes the value that is used for the initialization. Be aware that it can't protect const values, as those can't be populated by a function. All others are populated. The protected values can be uncovered by debugging, how ever analyzing the assembly get's much harder, because you can't search for specific strings for example. This protection has the modes "normal" (default), "dynamic" and "x86". I recommend setting it to "x86", because this implements the actual decoder with native code. If you can't use native code, use the "dynamic" mode. The "normal" mode is very easily reversed by some applications that are out there. I'm not aware of any case where this protection was detected by a anti-virus application.

2. 常量:该保护隐藏常量值。它可以保护字符串(默认值)、数字、原语和初始化式(默认值)。它对用于初始化的值进行编码。请注意，它不能保护const值，因为这些值不能用函数填充。其他的都有人口。受保护的值可以通过调试来揭示，但是分析程序集变得更加困难，因为你不能搜索特定的字符串。这个保护有“正常”(默认)，“动态”和“x86”模式。我建议将其设置为“x86”，因为这将使用本地代码实现实际的解码器。如果不能使用本机代码，请使用“动态”模式。“正常”模式很容易被一些应用程序逆转。我不知道任何情况下，该保护被反病毒应用程序检测。

1. Control Flow: The control flow obfuscation basically splits the code in pieces, rearranges it in the function and implements a very large switch block or a lot of jump statements to restore the actual flow of the application. This works best on large functions that can be split many times. The part of the obfuscation that takes care of "selecting the next block" in a obfuscated function, can be implemented in different ways. There is the "normal", the "expression" and the "x86" method. Again I suggest using "x86" if possible. If not either of the others is fine. This protection can be undone if the attacker follows the control flow the application with the debugger or in case the predicate method is decoded and the attacker is able to calculate the next block. I'm not aware of any case where this protection was detected by a anti-virus application. That is unless you got yourself a method that calls a lot of native functions (using Marshalling). Such methods are at times detected. I recommend disabling this protection for functions contains a lot of native calls.

3.控制流:控制流混淆基本上是将代码分割成片段，在函数中重新排列，并实现一个非常大的开关块或许多跳转语句，以恢复应用程序的实际流。这对于可以多次拆分的大型函数最有效。在模糊化函数中，负责“选择下一个块”的模糊化部分可以以不同的方式实现。有“正常”、“表达式”和“x86”方法。我再次建议如果可能的话使用“x86”。如果没有，其他任何一个都可以。如果攻击者使用调试器跟踪应用程序的控制流，或者在谓词方法被解码并且攻击者能够计算下一个块的情况下，这个保护可以撤消。我不知道任何情况下，该保护被反病毒应用程序检测。除非您有一个调用大量本机函数(使用编组)的方法。这种方法有时会被检测到。对于包含大量本机调用的函数，我建议禁用此保护。

1. Reference Proxy: This protection basically hides all calls to functions inside another function. The "normal" mode doesn't help much, but makes it much more strenuous to read the code. This mode is never detected by a anti virus application. The "strong" mode is much more interesting. It hides the method code and some additional memory block and uses a decoder function to read it and create a dynamic method that contains the original code. This is very hard to follow, because you will not see the code in the debugger (at least I don't know how). This mode how ever is sometimes detected as malicious.

4. 引用代理:这种保护基本上隐藏了对另一个函数内部的函数的所有调用。“正常”模式没有多大帮助，但会使读取代码变得更加吃力。此模式不会被防病毒应用程序检测到。“强”模式更有趣。它隐藏方法代码和一些额外的内存块，并使用一个解码器函数来读取它，并创建一个包含原始代码的动态方法。这是非常困难的，因为您将看不到调试器中的代码(至少我不知道如何)。这种模式有时会被检测出是恶意的。

1. Resources: This protection encodes the embedded resource files (mostly the ones created by *.resx files. This only works fine in case the resource is accessed using the generated code that accompanies the *.resx file. In case you got a assembly where you directly work with the resource file or in case you need to use the resource file across assemblies, I suggest disabling this protection.

5. 资源:这个保护对嵌入的资源文件进行编码(大部分是由*创建的。resx文件。这只适用于使用伴随*生成的代码访问资源的情况。resx文件。如果您有一个程序集，您可以直接使用资源文件，或者如果您需要跨程序集使用资源文件，我建议禁用此保护。

1. AntiIDasm: Can be enabled without and worry. It simply sets a flag that says "please don't deobfuscated me". I think ILSpy honored this flag (once).

6. AntiIDasm:可以启用，不用担心。它只是设置了一个标志，说“请不要清除我的混淆”。我想ILSpy(曾经)尊重过这面旗帜。

1. AntiDebug: Depending on the mode this protection adds some codes to the assembly that makes it impossible to attach the debugger. This should only be added to the main executables. The code does nothing in normal operation, but it turns any attached debugger either inoperable or very glitchy. It works well together with other protections that can be reversed with the debugger, to make things harder. But it's fairly easy using a msil editor to get rid of the code that break the Debuggers.

7. AntiDebug:根据模式，此保护会向程序集添加一些代码，使其无法附加调试器。这应该只添加到主可执行文件中。该代码在正常操作中什么也不做，但它会导致任何附加的调试器不可操作或非常故障。它与其他可以用调试器逆转的保护一起工作得很好，使事情变得更困难。但是，使用msil编辑器清除破坏调试器的代码是相当容易的。

1. AntiDump: Works similar to AntiDebug, it tries to block memory dumping of the application memory. I usually don't use this, because it prevents minidumps to be created on the customer system.

8. AntiDump:类似于AntiDebug，试图阻止应用内存的内存转储。我通常不使用它，因为它可以防止在客户系统上创建最小转储。

1. Invalid Metadata: Adds some buggy metadata to the classes and methods that cause some decompilers to break. This also causes massive issues in case you are trying to compile an application referencing an assembly protected with this.

9. 无效元数据:在类和方法中添加了一些有bug的元数据，导致一些反编译器崩溃。这也会导致大量的问题，如果您试图编译一个应用程序引用一个受此保护的程序集。

1. TypeScambler: Some versions of ConfuserEx contain this. Don't use it. It's broken.

10. 某些版本的ConfuserEx包含这个。不要使用它。它坏了。

1. Rename: The renamer is the big bad among the protections. This protection is the only truly irreversible one and also the one that requires the most fine tuning. ConfuserEx tries to set it up right for you, but in some cases it needs to be disabled for parts of an application. Mostly in case the application accesses specific classes a lot with reflections by name.

11. 重命名:在保护措施中，重命名是最大的缺点。这种保护是唯一真正不可逆的保护，也是最需要微调的保护。ConfuserEx尝试为您正确设置它，但在某些情况下，它需要为应用程序的某些部分禁用。大多数情况下，应用程序通过名称反射访问特定的类。

1. Compress packer: The compress packer is the part that combines multiple assemblies into one. This is detected as malicious code very often.

12. 压缩封隔器:压缩封隔器是将多个组件组合成一个组件的部件。这通常被检测为恶意代码。

四、混淆器预设preset内包含保护项详情

Protection / Preset	Minimum	Normal	Aggressive	Maximum
Anti Debug	✅	✅	✅	✅
Anti Dump				✅
Anti IL Dasm	✅	✅	✅	✅
Anti Tamper				✅
Constants		✅	✅	✅
Control Flow		✅	✅	✅
Invalid Metadata				✅
Name	✅	✅	✅	✅
Hardening	✅	✅	✅	✅
Reference Proxy		✅	✅	✅
Resources		✅	✅	✅
Type Scramble
Watermark	✅	✅	✅	✅

以上内容均选自github社区内作者回复

附上大佬的github链接https://github.com/mkaring/ConfuserEx