Reflector作为一个如此强大的反编译工具，其本身的保护也一定很完善。曾经有高手的文章[1][2]介绍Reflector的保护方法，但是时过境迁，新版本的Reflector又采用了更为隐晦的保护措施，给想了解Reflector内部细节的人提高了门槛。
下面，就本着学习的态度，把我在分析Reflector时所看到的保护方法简单介绍一下，以当前的最新版本4.2.45.0为例。
1，混淆
混淆应该是Assembly保护的最基本措施了，混淆工具也是比比皆是。用Reflector打开Reflector自己，便可以看到除了若干接口、枚举的定义，就是8，9个名字都为“□”的类；类里面的所有成员以及Nested Class的名字也都叫“□”。这里和以前的版本是相同的，只不过是把各种标识符的名字用系统无法显示的unicode字符代替而已吧。
名字混淆时，很重要的一点就是把实现接口的方法名、Main方法名等等也要加以混淆——不要以为这些名字是不能混淆的。
此外，Reflector还对IL代码进行了简单的混淆，使得很多重要的方法用Reflector反编译成其他语言时，会显示“This item appears to be obfuscated and can not be translated.”。这种情况下为了分析代码，只能读IL；或者是用其他反编译工具分析。
2，防篡改·反Debug
为了防止篡改Assembly，Reflector中为Assembly增添StrongName，以及在程序中检测StrongName是否正常。
为了防止被动态跟踪，在Reflector当中很多地方都会用System.Diagnostics.Debugger.IsAttached检测Debugger是否存在。
3，字符串加密
通常的混淆当中，虽然可以将类和成员的名字变成“乱码”，但是源代码中的字符串（例如要显示一个消息）往往会轻易暴露一段代码的意图。假如某段代码中含有“Error: Can not open file”字样的字符串，我们很容易猜测到这里是不是在打开一个文件。Reflector当中为了防止别人轻易地看到字符串，使用了一个简单的加密函数。这样，别人在阅读源代码时，所有字符串的部分都是毫无意义的一些乱码。Reflector在使用这些字符串时，首先将他们解密，然后再使用。
4，动态加载Assembly
当我们打开Reflector.exe查看Reflector的源代码时，发现代码量很少；也就是说，真正的应用部分被隐藏起来了——隐藏到哪里了呢？前版本的Reflector据说是隐藏在Menifest Resource里面了；新版本的Reflector为了增强隐蔽性，直接把它隐藏在PE文件的.rsrc段的末尾了。为了读取这段“真身”，Reflector.exe当中专门有一个读取PE文件的类，基本逻辑就是找到.rsrc Section，加上.rsrc Section的长度（也即定位到其末尾），再读取一个Int32（“真身”的长度），然后将这段内容读取到内存当中。
这段内容是经过3DES加密的，很有趣的是，密钥是一段劝说你不要破解Reflector的文字的MD5 Hash值。
就算解密之后，这段内容仍然不是一个有效的Assembly——它到底是什么呢？仔细看看Reflector之后的举动，我们就发现，这段内容其实是一个Zip文件。Reflector把这段内容在内存中解压缩，再使用Assembly.Load(byte[])将其载入（并且载入过程全部是用反射方法，程序中根本不会直接出现Assembly.Load字样）。
因此整个过程就是，Reflector是将其主要逻辑所在的Assembly（Reflector.Application.dll）先压缩成一个Zip文件，然后用3DES算法加密，塞到.rsrc段的末尾；在执行时，进行反向操作，动态加载Assembly。
以上简单介绍了Reflector的保护方法。和传统的EXE文件的加密和保护相比，.Net Assembly的保护还显得很稚嫩，Reflector的IL虽然也经过了简单混淆，但是也没有汇编代码那样的错综复杂的、大段无用的代码，看起来仍然是比较易懂的。
下面，就本着学习的态度，把我在分析Reflector时所看到的保护方法简单介绍一下，以当前的最新版本4.2.45.0为例。
1，混淆
混淆应该是Assembly保护的最基本措施了，混淆工具也是比比皆是。用Reflector打开Reflector自己，便可以看到除了若干接口、枚举的定义，就是8，9个名字都为“□”的类；类里面的所有成员以及Nested Class的名字也都叫“□”。这里和以前的版本是相同的，只不过是把各种标识符的名字用系统无法显示的unicode字符代替而已吧。
名字混淆时，很重要的一点就是把实现接口的方法名、Main方法名等等也要加以混淆——不要以为这些名字是不能混淆的。
此外，Reflector还对IL代码进行了简单的混淆，使得很多重要的方法用Reflector反编译成其他语言时，会显示“This item appears to be obfuscated and can not be translated.”。这种情况下为了分析代码，只能读IL；或者是用其他反编译工具分析。
2，防篡改·反Debug
为了防止篡改Assembly，Reflector中为Assembly增添StrongName，以及在程序中检测StrongName是否正常。
为了防止被动态跟踪，在Reflector当中很多地方都会用System.Diagnostics.Debugger.IsAttached检测Debugger是否存在。
3，字符串加密
通常的混淆当中，虽然可以将类和成员的名字变成“乱码”，但是源代码中的字符串（例如要显示一个消息）往往会轻易暴露一段代码的意图。假如某段代码中含有“Error: Can not open file”字样的字符串，我们很容易猜测到这里是不是在打开一个文件。Reflector当中为了防止别人轻易地看到字符串，使用了一个简单的加密函数。这样，别人在阅读源代码时，所有字符串的部分都是毫无意义的一些乱码。Reflector在使用这些字符串时，首先将他们解密，然后再使用。
4，动态加载Assembly
当我们打开Reflector.exe查看Reflector的源代码时，发现代码量很少；也就是说，真正的应用部分被隐藏起来了——隐藏到哪里了呢？前版本的Reflector据说是隐藏在Menifest Resource里面了；新版本的Reflector为了增强隐蔽性，直接把它隐藏在PE文件的.rsrc段的末尾了。为了读取这段“真身”，Reflector.exe当中专门有一个读取PE文件的类，基本逻辑就是找到.rsrc Section，加上.rsrc Section的长度（也即定位到其末尾），再读取一个Int32（“真身”的长度），然后将这段内容读取到内存当中。
这段内容是经过3DES加密的，很有趣的是，密钥是一段劝说你不要破解Reflector的文字的MD5 Hash值。
就算解密之后，这段内容仍然不是一个有效的Assembly——它到底是什么呢？仔细看看Reflector之后的举动，我们就发现，这段内容其实是一个Zip文件。Reflector把这段内容在内存中解压缩，再使用Assembly.Load(byte[])将其载入（并且载入过程全部是用反射方法，程序中根本不会直接出现Assembly.Load字样）。
因此整个过程就是，Reflector是将其主要逻辑所在的Assembly（Reflector.Application.dll）先压缩成一个Zip文件，然后用3DES算法加密，塞到.rsrc段的末尾；在执行时，进行反向操作，动态加载Assembly。
以上简单介绍了Reflector的保护方法。和传统的EXE文件的加密和保护相比，.Net Assembly的保护还显得很稚嫩，Reflector的IL虽然也经过了简单混淆，但是也没有汇编代码那样的错综复杂的、大段无用的代码，看起来仍然是比较易懂的。
