>免责声明：我非常清楚客户端程序永远不会受到专门的逆向工程师的影响。
主要是出于个人的好奇心，我一直在学习 C# 应用程序的"混淆"技术。似乎一种流行的技术是"字符串加密"，它似乎可以加密软件中的字符串常量并解密它们以供以后使用。这使得它们无法在像 Reflector 这样的反编译器中正确显示（如果这是错误的，请纠正我）。
如果这是真的，并且您只在 Reflector 中看到字符串的加密版本，那么需要做什么（即有多难）来解决此问题并获取解密的字符串？显然，这必须是可能的，否则应用程序将无法做到这一点，但它会有多大的威慑力？
我对C#混淆器没有任何经验，但是我看过的Java混淆器（Stringer，Allatori，Zelix Klassmaster，JFuscator）非常糟糕。通常，我可以在一两天后对加密算法进行逆向工程，然后我可以对受相同混淆器版本保护的所有应用程序进行去混淆，而其他版本通常只需要稍作调整。
请注意，这是用于纯粹的静态分析，以找出算法并编写一个脚本来解密它而不执行任何代码。如果您的目标是快速解密内容，那么简单地执行解密功能要容易得多。好的混淆器有一个调用上下文检查，所以你不能直接做，但找到和编辑检查是一件简单的事情。这可能在几分钟内完成。
显然，有一些方法可以使逆向工程变得更加困难，但在实践中并没有完成。
如果您的应用程序中有加密的字符串，那么您的应用程序中还嵌入了解密密钥。
因此，中等确定的人员可以使用调试器单步执行解密代码以检索密钥，然后轻弹手腕即可解密应用程序中的所有其他字符串。
理解需要多少时间取决于一般的混淆级别，
即。如果有一个方法解密可以像那样调用......
通过编译，所有可能<1分钟
另一种简单的方法：使用调试信息重新编译，设置断点，
执行程序，只需读取VS
中的字符串（"简单"取决于进入此代码部分所需的内容）
我最近才知道 secureString 类。我相信这不是一个完整的解决方案，但与其他技术相结合，它可能会有所帮助。
http://msdn.microsoft.com/en-us/library/system.security.securestring%28v=vs.80%29.aspx
初始化实例或修改值时，将自动加密 SecureString 实例的值。 请注意，安全字符串没有检查、比较或转换安全字符串值的成员。缺少此类成员有助于保护实例的价值免受意外或恶意泄露。