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

Obfuscation at source-code level more effective than obfuscators?

提问by TheFlash

Learning from my last question, most member namesseem to get included in the Project Output.

从我的最后一个问题中学习，大多数成员名称似乎都包含在项目输出中。

Looking at some decompilers like 9rays, Salamander, Jungle, many obfuscating techniques seem to have been already defeated, there's this one particularly scary claim:

看看像9rays、Salamander、Jungle等一些反编译器，很多混淆技术似乎已经被打败了，有一个特别可怕的说法：

Automatically removes string encryptions injected by obfuscators ~ Salamander

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

So is manual, source-code level obfuscating more effectivethan post-compile / mid-compile lathered, 'superficial' obfuscation by well known (easily defeated??) obfuscating programs?

那么，手动的、源代码级别的混淆是否比众所周知的（很容易被击败？？）混淆程序的编译后/中间编译泡沫、“表面”混淆更有效？

采纳答案by Mitch Wheat

Obfuscating source-code is going to be self-defeating in terms of maintenance.

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

If your project is so 'secret', I guess you have two choices:

如果您的项目如此“秘密”，我想您有两种选择：

• Place the 'secret' proprietry code behind a service on a server that you control

• Code it in a language so not easy to decompile such as C/C++

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

• 用一种不容易反编译的语言来编码，比如 C/C++

回答by lc.

The problem there is you will be sacrificing readability to do it. If your project is that sacred to protect, I believe it is safe to assume two things:

问题是你会牺牲可读性来做到这一点。如果您的项目需要保护，那么我相信可以安全地假设两件事：

1. The project is large enough that the hit in readability will come back to bite you in the ass.
2. The people who want to reverse-engineer it will do so anyway. It will just take a slightly larger feat of intelligence to determine what things do (instead of just reading the member names).

1. 该项目足够大，可读性的打击会回来咬你的屁股。
2. 想要对其进行逆向工程的人无论如何都会这样做。只需要稍微大一点的智慧就可以确定事物的作用（而不仅仅是读取成员名称）。

回答by annakata

Maybe, debatably, but you'll destroy maintainability to do so.

也许，值得商榷，但这样做会破坏可维护性。

Is this really worth it?

这真的值得吗？

Actually this just comes down to security through obscurity, i.e. it's not security at all it's just an inconvenience. you should work fromt he assumption that any party interested enough willdecompile your code if they can access it. It's not worth the pain you'll inflict on yourself to make it very slightly more time consuming for the evil haxxors. Deal with the real security problems of access.

实际上，这只是由于默默无闻而归结为安全性，即它根本不是安全性，它只是一种不便。你应该假设任何足够感兴趣的一方如果可以访问它就会反编译你的代码。不值得你给自己造成的痛苦让邪恶的haxxors花费更多的时间。处理访问的真正安全问题。

回答by RS Conley

annakata is correct. Really all you can do is make it more difficult (and costly) for the person to reverse engineer the software.

annakata 是正确的。实际上，您所能做的就是使该人更难（且成本更高）对软件进行逆向工程。

My company identified several areas in which we wanted to make it as difficult as possible for reverse engineering. For example our files are a binary format which each object in our hierarchy responsible for saving itself and reading back the correct version. This means for a person to read our files they would have replicate our entire hierarchy in the code they create to read our files. In addition much of the information in the Job file is useful without the corresponding bit in the shop standards files. So they have to do the work twice in order to understand what the job file is saying.

我的公司确定了几个我们希望使逆向工程尽可能困难的领域。例如，我们的文件是一种二进制格式，我们层次结构中的每个对象负责保存自身并读回正确的版本。这意味着对于读取我们文件的人来说，他们会在他们创建的代码中复制我们的整个层次结构来读取我们的文件。此外，作业文件中的许多信息在车间标准文件中没有相应位的情况下也很有用。所以他们必须做两次工作才能理解作业文件的内容。

Several critical areas (dongle protection, communication with our metal cutting machines) reside in Win32DLL. Which means that they would have to know assembly and how to make DLL that replicate other DLLs signatures in order to reverse engineer our software. Plus our design with our CAM software is that it is highly interactive with the cutting machine (information being exchanged all the time)

几个关键区域（加密狗保护、与我们的金属切割机的通信）驻留在 Win32DLL 中。这意味着他们必须知道程序集以及如何制作复制其他 DLL 签名的 DLL，以便对我们的软件进行逆向工程。加上我们的 CAM 软件设计，它与切割机具有高度交互性（信息一直在交换）

From the few time we heard about competitors trying to deal with our machines alone they wound up replacing the electronics with their own in order to finish the job. Major bucks to do this.

有几次我们听说竞争对手试图单独处理我们的机器，他们最终用自己的机器替换了电子设备以完成工作。大笔钱来做这件事。

Part of the steps we took was based on our own experience with trying to deal with competition's machine and software. We took that experience and learned how to tweak our setup. Of course we have limits in that we are not going sacrifice reliability or maintenance just for the purpose of defeating reverse engineering.

我们采取的部分步骤是基于我们自己尝试处理竞争对手的机器和软件的经验。我们吸取了这一经验，并学会了如何调整我们的设置。当然，我们有局限性，因为我们不会为了击败逆向工程而牺牲可靠性或维护性。

For your case, you will have to ask yourself what part of your software would be of interest to your competitors and proceed from there. If you are a vertical market developer (machine control, specialized accounting, etc) I suggest using a USB dongle for software control.

对于您的情况，您必须问自己您的竞争对手对您的软件的哪一部分感兴趣，然后从那里开始。如果您是垂直市场开发人员（机器控制、专业会计等），我建议您使用 USB 加密狗进行软件控制。

Otherwise use a serial number system and accept that people are going to pirate your software and build that into your business model. The purpose of a serial number scheme is that is relatively unintrusive, and hinders causal copying plus give you a remote chance of tracking down where the copy came from.

否则使用序列号系统并接受人们会盗版您的软件并将其构建到您的商业模式中。序列号方案的目的是相对不干扰，并阻碍因果复制，并为您提供跟踪副本来源的远程机会。

回答by JoshBerke

As people stated obfuscation is about raising the bar. If you obfuscate your assembly you will stop a casual developer whose just curious but you won't stop a slightly motivated person from reverse engineering.

正如人们所说，混淆是为了提高标准。如果你混淆你的程序集，你会阻止一个随意的开发人员，他只是好奇，但你不会阻止一个稍微有动力的人进行逆向工程。

If you want to raise the bar a little further many obfuscation tools let you use non-printable characters as member names. use reflector on itself to have a look. This will stop a lot more people, I might look at obfuscated code to understand it, but if I can't read it, I'm not going to go through the pain of dumping it to IL, and renaming all the members manually, no motiviation for me to waste that much time.

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

However for some people there is a motiviation so you need to go another step if your business requirements nessecitate it. But no matter what you do if the computer can read it, there will be someone out there who can read it too. The goal is to reduce the number of people who can read it or would be motivated to read it.

但是，对于某些人来说，这是有动机的，因此如果您的业务需求需要动机，则您需要再进一步。但不管你做什么，只要电脑能读，就会有人能读。目标是减少可以阅读它或有动力阅读它的人数。

There are also some tricks which you can use to make reflector break (Obfuscator from PreEmptive breaks reflector in some cases but of course you can still read the IL). I had an interesting conversation once with a developer of an obfusction tool and I won't be able to do it justice but he had a way to make reflector completly break by having the code jump dynamically around. For example one moment in your function a then you'd jump to the middle of function b. Doign this cause PEVerify to raise errors so they never actually implemented it but kind of neat idea.

还有一些技巧可以用来使反射器中断（在某些情况下，来自 PreEmptive 中断反射器的混淆器，但当然你仍然可以阅读 IL）。我曾经与一个混淆工具的开发人员进行了一次有趣的对话，我无法做到公正，但他有办法通过让代码动态跳转来完全破坏反射器。例如，在你的函数 a 中，你会跳到函数 b 的中间。这样做会导致 PEVerify 引发错误，因此他们从未真正实施过它，而是一种巧妙的想法。

回答by Cyril Gupta

I am alarmed that you're even considering code level obfuscation. Won't you be obfuscating the code for yourself too? How do you intend to ever work on it again? For the sake of maintainability this shouldn't be done.

我很震惊，你甚至在考虑代码级别的混淆。您不会也为自己混淆代码吗？你打算如何再次工作？为了可维护性，不应该这样做。

But consider this: -

但考虑一下：-

Suppose there was a script/app that you can run that would open your project and cleverly obfuscate every string/variable name in your project and you compiled it afterward while your original code is securely untouched in a separate location.

假设您可以运行一个脚本/应用程序，它会打开您的项目并巧妙地混淆项目中的每个字符串/变量名称，然后您编译它，而您的原始代码在单独的位置安全地保持不变。

Now that's some idea.

现在这是一些想法。

回答by Paul Alexander

Actually code level obfuscation is less securethan what the obfuscators out there can do. This is primarily because obfuscators can take advantage of strict CLI implementation details that are not permitted by language compilers. For instance, it is entirely legal for private fields to all have the same name - but there isn't a compiler out there that will let you do that.

实际上，代码级别的混淆不如现有的混淆器安全。这主要是因为混淆器可以利用语言编译器不允许的严格的 CLI 实现细节。例如，私有字段都具有相同的名称是完全合法的——但是没有一个编译器可以让你这样做。

回答by gianmarco castagna

you can use a technique like this : http://g.palem.in/SecureAssembly.htmlusing this you write in .net but you embed into a c++ executable your .net executable ,

您可以使用这样的技术：http: //g.palem.in/SecureAssembly.html使用您在 .net 中编写的这个，但您将 .net 可执行文件嵌入到 C++ 可执行文件中，