源代码级别的混淆比混淆器更有效？

从我的上一个问题中学习,大多数成员名称似乎都包含在项目输出中.

看看像9-7,Salamander,Jungle这样的反编译器,许多混淆技术似乎已经被打败了,这是一个特别可怕的声明:

自动删除由混淆器~ Salamander注入的字符串加密

因此,手动,源代码级别的混淆比后编译/中间编译更有效,通过众所周知的(容易被击败的)混淆程序进行"表面"混淆？

混淆源代码在维护方面会弄巧成拙.

如果你的项目是如此"秘密",我想你有两个选择:

将"秘密"专有代码放在您控制的服务器上的服务后面

用一种语言对它进行编码,这样就不容易反编译,比如C/C++

也许,令人遗憾的是,但你会破坏可维护性.

这真的值得吗？

实际上,这只是通过默默无闻来降低安全性,即它根本不是安全性,这只会给您带来不便.你应该工作,因为他认为任何有兴趣的人都会反编译你的代码,如果他们可以访问它.你为自己造成的痛苦不值得为邪恶的黑客们带来更多的时间.处理访问的真正安全问题.

正如人们所说,混淆是提高标准.如果你对你的装配进行模糊处理,你就会阻止一个只是好奇的临时开发人员,但你不会阻止一个有动力的人进行逆向工程.

如果您想进一步提高条形,许多混淆工具允许您使用不可打印的字符作为成员名称.使用反射器本身来看看.这将阻止更多的人,我可能会看到混淆代码来理解它,但如果我无法阅读它,我不会经历将其转储到IL的痛苦,并手动重命名所有成员,没有动力让我浪费那么多时间.

然而,对于某些人来说,有一种动机,所以如果您的业务需求无法保证,您需要再迈出一步.但无论你做什么,如果电脑都可以阅读它,那里会有人也可以阅读它.目标是减少可以阅读它或有动力阅读它的人数.

还有一些技巧可以用来使反射器断裂(PreEmptive的Obfuscator在某些情况下会破坏反射器,但当然你仍然可以读取IL).我与一个obfusction工具的开发者进行了一次有趣的对话,我无法做到这一点,但他有办法通过让代码动态地跳转来使反射器完全中断.例如,在你的函数中的一个时刻,你就会跳到函数b的中间.这样做会导致PEVerify引发错误,因此他们从未真正实现过它,而是一种干净利落的想法.