混淆的优点/缺点？

问题描述

我正在玩一个名为Reflector的免费反编译器。我在.NET程序集中运行了它b / b
，并且非常惊讶于它将IL转换回C＃的能力。它让我想到了混淆。


我对混淆的有限理解是方法和变量

被随机重命名。名为''Stagmire''的属性可能被重命名为''xdFd''或

a方法名为''ComputeCorrelation（）''可能被重命名为''Fooodbone（）''。

虽然这种技术当然不能阻止逆向工程，但是它至少会使代码被盗和随后的人工解释变得更加困难，

这真的是我所有的一切我想要完成。


混淆有什么缺点？换句话说，为什么没有&b
VS2005默认情况下会混淆？肯定有一些缺点。


调试测试版应用程序时，我喜欢做的一件事是抓住未处理的异常，然后显示堆栈跟踪在弹出窗口中。然后

beta测试人员将堆栈跟踪复制/粘贴到我的电子邮件中，这样我就可以跟踪问题的根源。在我看来，如果代码被混淆了，那么堆栈跟踪将无法解释，因为

方法名称会被破坏，对吗？这对我来说是一个问题。


VS2005附带的混淆器是否适合大多数程序员

或者你建议使用第三方解决方案吗？


谢谢，


Johnny Drama

解决方案

I was playing around with a free decompiler called "Reflector." I ran it
against a .NET assembly and was pretty amazed with how well it converted IL
back to C#. It got me thinking about obfuscation.

My limited understanding of obfuscation is that methods and variables
are renamed randomly. A property named ''Stagmire'' might be renamed ''xdFd'' or
a method named ''ComputeCorrelation()'' might be renamed ''Fooodbone()''.
Although this technique certainly can''t prevent reverse engineering, it at
least makes code theft and subsequent human interpretation a lot harder,
which is really all I''m trying to accomplish.

What are the drawbacks of obfuscation? In other words, why doesn''t
VS2005 just obfuscate by default? There must be some drawbacks.

One thing I''m fond of doing when debugging beta apps is to catch
unhandled exceptions and then display the stack trace in a popup window. The
beta tester then copy/pastes the stack trace into an email to me so I can
track down the source of the problem. It seems to me that if the code were
obfuscated, the stack trace would be impossible to interpret because the
method names would be mangled, correct? That would be a problem for me.

Is the obfuscator that comes with VS2005 sufficient for most programmers
or do you recommend going with a 3rd party solution?

Thanks,

Johnny Drama

解决方案

这篇关于混淆的优点/缺点？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！