提到 .Net 的保护，首推就是混淆保护了，而名称混淆基本上是所有混淆保护工具都具有的功能。
可以说不支持名称混淆的工具称不上混淆保护工具。
对于混淆保护，大家有一个认识，就是 混淆是一个不可逆的过程。而加密保护是一个可逆的过程。
名称混淆真的完全不可逆吗？答案是否定的。
名称混淆有一部分是可以精确还原的。
.Net的名称混淆在 剖析DotNet的名称混淆保护技术 中有详细介绍。今回注意介绍名称混淆中可逆的部分，以及还原的方法。
一. 属性名称 以及 getter 和 setter 函数。
少部分工具有这个问题。
按照正常规则 属性名称为Name，则 getter函数为 get_Name, setter 函数为 set_Name。
有些工具在混淆是处理不完整。只处理了属性名，没有处理 getter，setter函数名。
比较常见的是 只混淆的 getter和setter函数名，而没有混淆属性名。
这三个只要知其中一个就能推出另外两个。
对于属性还能在一定层度上实现对私有成员变量名的反混淆。
一般属性是公共的，大部分混淆器对公共成员是不混淆的。
如果这个属性有一个私有成员变量和它对应，实际上根据编程习惯，大部分属性都是这样的。
我们能将这个私有成员变量修改得 readable。
二、事件名称 以及 add , remove, fire 函数。
这个和 属性名称以及其setter，getter函数一样。
三、虚函数，接口实现函数
大部分工具对于基类虚函数和接口函数都没有混淆
而只混淆了继承类、实现类中的函数名称。
如：某个类 overide了 ToString 这个函数，然后这个函数名称被混淆了，
通过override 属性我们就能知道它原始的函数名称。
这里也包含了接口中继承的属性，即可以根据接口中的属性名称还原实现类中的属性名称。
四、Form，UserControl等类，窗体设计器的约定规则
根据规则我们知道 有一个必要的设计器变量 private System.ComponentModel.IContainer components 。
两个函数 protected override void Dispose(bool disposing)
和 private void InitializeComponent()。
一般我们很容易就能找到 那个变量和 Dispose函数。
InitializeComponent 我们一般可以从 构造函数中去找，它一般被构造函数调用。
这三个名称还原之后，我们就从 InitializeComponent 的函数体去分析。
根据规则，我们知道 Control.Name 就是 其变量的名称。
Control.Name 是在代码运行时赋值的。根据这个规则，我们能完全还原 Control 的
变量名称。
然后对于控件的事件处理函数，也是在 代码运行时赋值的。
如 button1 的 click 事件处理函数，可以还原为 button1_Click 。
设计器默认的名称就是这种规则。当然，不能保证和原始程序的名称一样。
虽不能100%还原事件处理函数的名称，但已经readable了。
另外附一个工具：
元数据名称编辑器