c# 混淆工具ConfuserEx

github:https://github.com/mkaring/ConfuserEx

使用方式：

加密规则详解

As for the protections:关于保护：

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.
防篡改：这种保护实际上就是它所说的那样。这是一种保护，确保组件不会被更改。这种保护的副作用是所有的方法体都变得不可见。然而，当调试到受保护的代码（例如dnspy）时，你会很容易地得到方法体。这种保护有两种模式。模式“正常”和模式“JIT”。后者是一个破碎的混乱，我强烈建议不要使用它。
该保护（在“正常”模式下）有时被检测为误报恶意应用。它提供了一个薄弱的保护，防止人们想要查看您的代码。
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.
常量：此保护隐藏常量值。它可以保护字符串（默认），数字，原语和初始化器（默认）。它基本上对用于初始化的值进行编码。请注意，它不能保护const值，因为这些值不能由函数填充。所有其他人都被填充。受保护的值可以通过调试发现，但是分析程序集要困难得多，因为您无法搜索特定的字符串。
此保护具有“正常”（默认）、“动态”和“x86”模式。我建议将其设置为“x86”，因为这将用本机代码实现实际的解码器。如果你不能使用本机代码，请使用“动态”模式。“正常”模式很容易被一些应用程序逆转。我不知道任何情况下，这种保护是由反病毒应用程序检测。
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.
控制流：控制流混淆基本上是将代码分割成几段，在函数中重新排列，并实现一个非常大的switch块或大量的跳转语句来恢复应用程序的实际流。这对于可以拆分多次的大型函数效果最好。在混淆函数中负责“选择下一个块”的混淆部分可以以不同的方式实现。有“普通”、“表达式”和“x86”方法。如果可能的话，我再次建议使用“x86”。如果不是，其他人都很好。
如果攻击者使用调试器跟踪应用程序的控制流，或者如果谓词方法被解码并且攻击者能够计算下一个块，则可以撤消此保护。我不知道任何情况下，这种保护是由反病毒应用程序检测。
除非你有一个调用大量本机函数的方法（使用Marshalling）。这种方法有时会被发现。我建议对包含大量本机调用的函数禁用此保护。
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.
参考代理：这种保护基本上隐藏了对另一个函数内部函数的所有调用。“正常”模式没有太大帮助，但会使阅读代码更加费力。此模式永远不会被防病毒应用程序检测到。“强”模式要有趣得多。它隐藏了方法代码和一些额外的内存块，并使用解码器函数来读取它并创建包含原始代码的动态方法。这很难理解，因为你不会在调试器中看到代码（至少我不知道如何做到）。然而，这种模式有时被检测为恶意的。
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.
资源：此保护对嵌入的资源文件（主要是由.resx文件创建的资源文件）进行编码。只有在使用随.resx文件生成的代码访问资源的情况下，这才能正常工作。如果你有一个程序集，你直接使用资源文件，或者如果你需要跨程序集使用资源文件，我建议禁用这种保护。
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).
AntiIDasm：可以启用而不用担心。它只是设置一个标志，说“请不要对我进行模糊处理”。我认为ILSpy尊重了这面旗帜（一次）。
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.
AntiDebug：根据模式的不同，此保护会向程序集添加一些代码，使其无法附加调试器。这应该只添加到主可执行文件中。该代码在正常操作中不做任何事情，但它会使任何附加的调试器无法操作或非常不稳定。它与其他保护一起工作得很好，这些保护可以通过调试器逆转，使事情变得更困难。但是使用msil编辑器来删除破坏调试器的代码是相当容易的。
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.
AntiDump：与AntiDebug类似，它试图阻止应用程序内存的内存转储。我通常不使用这种方法，因为它会阻止在客户系统上创建小型转储。
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.
无效元数据：向类和方法中添加一些有错误的元数据，这些元数据会导致一些反编译器中断。如果您试图编译引用受此保护的程序集的应用程序，这也会导致大量问题。
TypeScambler: Some versions of ConfuserEx contain this. Don’t use it. It’s broken.
类型Scambler：某些版本的ConfuserEx包含此功能。别用它坏了
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.
重命名：重命名者是保护中最大的缺点。这种保护是唯一真正不可逆的保护，也是最需要微调的保护。ConfuserEx尝试为您正确设置它，但在某些情况下，需要为应用程序的某些部分禁用它。大多数情况下，应用程序访问特定的类很多反射的名称。
Compress packer: The compress packer is the part that combines multiple assemblies into one. This is detected as malicious code very often.
压缩打包机：压缩封隔器是将多个组件组合成一个组件的部件。这经常被检测为恶意代码。
To create the same result every time you can set the seed to a fixed value, but this will not help you with the anti virus application. These applications will always scan your application. You should upload your application to virus total to check if it’s detected as virus.
要创建相同的结果，每次你可以设置种子为一个固定的值，但这不会帮助你的反病毒应用程序。这些应用程序将始终扫描您的应用程序。你应该把你的应用程序上传到病毒总检查它是否被检测为病毒。

In general I recommend to use:一般来说，我建议用途：

AntiTamper防篡改
Constants常数
Control Flow控制流
Reference Proxy参考代理
Resources资源
AntiIDasm抗IDasm
Rename重命名
You have to setup the pattern and options so especially the WPF bindings (in case they are written using WPF) are not broken. So you may have to disable it for some classes. Just enabling these protections for everything usually does not result in a working output. So try to disable protections for part of your application where they cause error. That can be done in the .crproj file or in the code using the ObfuscationAttribute
您必须设置模式和选项，以便特别是WPF绑定（如果它们是使用WPF编写的）不会被破坏。所以你可能不得不为某些类禁用它。仅仅为所有内容启用这些保护通常不会产生工作输出。因此，请尝试禁用应用程序中会导致错误的部分的保护。这可以在.crproj文件中完成，也可以在代码中使用ObfuscationAttribute

So the answer “what is the strongest protection” is very difficult to answer, because it very much depends on your application.
因此，“什么是最强的保护”这个问题很难回答，因为这在很大程度上取决于您的应用程序。