本文以Dotfuscator 4.x为例，并制造一个简单的ConsoleApplication用来做小白鼠，以此窥探字符串混淆的一斑。一下是简单ConsoleApplication的代码：
1
using System;
2
3namespace ConsoleApplication1
4![]()
}
编译，然后使用Dotfuscator混淆——我使用的Dotfuscator是4.x Pro，你需要在Option Tab里面设置Disable String Encryption为No，再Input Tab 设置输入为上面工程的编译结果，在String Encryption Tab里勾选所有的项或者添加type为*和method为*的两条规则，然后编译，完成后就可以在输出目录里找到已经混淆过了的ConsoleApplication1.exe了，使用Reflector打开，可以看到代码如下：2
3
4
1private static void a(string[] A_0)
2![]()
}
一串乱码，同时还可以看到这里增加了一个叫a的方法，那么这个a到底是什么呢？Reflector报告如下：2
从IL代码来看，混淆逻辑使用了一个永远为true的条件（等效为if(0<1)），做了一次跳转，这才到真正的循环上，显然这里对string的每一个char进行遍历并处理，然后依次对char的高低位分别和参考量做异或运算，在交换高低位后做对高低位求或，其结果就是真实的字符串了。
总结整理了一下，算法如下：
1static string GetString(string source, int salt)
2{
3 int index = 0;
4 char[] data = source.ToCharArray();
5 salt += 0xe74d6d7; // This const data generated by dotfuscator
6 while (index < data.Length)
7 {
8 char key = data[index];
9 byte low = (byte)((key & '\x00ff') ^ salt++);
10 byte high = (byte)((key >> 8) ^ salt++);
11 data[index] = (char)((low << 8 | high));
12 index++;
13 }
14 return string.Intern(new string(data));
15}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
由此可见，字符串混淆的代价是相当大的，对于商业应用来说，应该尽量避免，也就是说避免使用hard code字符串保存敏感信息。此外，显然以上字符串混淆只能阻碍静态逆向分析，因为在.NET所有的字符串对CLR Runtime Host都是透明的，如果hacker使用debugger或者类似ProcessExplorer之类的工具是很容易分析出字符串里的秘密的。