源代码级别的混淆比混淆器更有效？
从我的最后一个问题中学习，大多数成员名称似乎包含在项目输出中。
查看一些反编译器，例如 9rays、火蜥蜴，丛林，许多混淆技术似乎已经被击败，有一个特别可怕的说法：
自动删除混淆器注入的字符串加密 ~ Salamander
手动、源代码级别混淆也是如此比众所周知的（很容易被击败？？）混淆程序进行的编译后/编译中的“表面”混淆更有效？
Learning from my last question, most member names seem 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:
Automatically removes string encryptions injected by obfuscators ~ Salamander
So is manual, source-code level obfuscating more effective than post-compile / mid-compile lathered, 'superficial' obfuscation by well known (easily defeated??) obfuscating programs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
正如人们所说，混淆是为了提高标准。 如果你混淆你的程序集，你会阻止一个只是好奇的临时开发人员，但你不会阻止一个稍微有动力的人进行逆向工程。
如果您想进一步提高标准，许多混淆工具允许您使用不可打印的字符作为成员名称。 用反光板本身看看。 这会阻止更多的人，我可能会查看混淆的代码来理解它，但如果我无法阅读它，我不会经历将其转储到 IL 并手动重命名所有成员的痛苦，我没有动力浪费那么多时间。
然而，对于某些人来说，存在动机，因此如果您的业务需求需要，您需要采取另一步骤。 但无论你做什么，如果计算机可以读取它，就会有人也可以读取它。 目标是减少能够阅读或有动力阅读的人数。
还有一些技巧可以用来破坏反射器（PreEmptive 的 Obfuscator 在某些情况下会破坏反射器，但当然您仍然可以阅读 IL）。 我曾经与一个混淆工具的开发人员进行过一次有趣的对话，我无法公正地进行对话，但他有一种方法可以通过让代码动态跳转来使反射器完全破坏。 例如，在函数 a 中的某个时刻，您会跳到函数 b 的中间。 这样做会导致 PEVerify 引发错误，因此他们从未真正实现过它，但这是一个不错的主意。
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.
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.
安纳卡塔是正确的。 实际上，您所能做的就是让人们对软件进行逆向工程变得更加困难（并且成本更高）。
我的公司确定了我们希望尽可能加大逆向工程难度的几个领域。 例如，我们的文件是二进制格式，层次结构中的每个对象负责保存自身并读回正确的版本。 这意味着对于读取我们的文件的人来说，他们将在他们创建的代码中复制我们的整个层次结构来读取我们的文件。 此外，作业文件中的许多信息在车间标准文件中没有相应位的情况下也是有用的。 因此，他们必须做两次工作才能理解工作文件的内容。
几个关键区域（加密狗保护、与我们的金属切削机的通信）驻留在 Win32DLL 中。 这意味着他们必须了解汇编以及如何制作复制其他 DLL 签名的 DLL，以便对我们的软件进行逆向工程。 另外，我们对 CAM 软件的设计是，它与切割机具有高度交互性（始终交换信息）
从我们几次听说竞争对手试图单独处理我们的机器以来，他们最终用自己的设备替换了电子设备。命令完成工作。 做这件事要花很多钱。
我们采取的部分步骤是基于我们自己尝试处理竞争对手的机器和软件的经验。 我们吸取了这次经验并学习了如何调整我们的设置。 当然，我们有局限性，因为我们不会仅仅为了击败逆向工程而牺牲可靠性或维护。
对于您的情况，您必须问自己您的竞争对手会对您的软件的哪些部分感兴趣，然后从那里开始。 如果您是垂直市场开发人员（机器控制、专业会计等），我建议使用 USB 加密狗进行软件控制。
否则，请使用序列号系统，并接受人们将盗版您的软件并将其构建到您的商业模式中的事实。 序列号方案的目的是相对不具有侵入性，并且阻碍随意复制，并且使您有机会追踪副本的来源。
annakata is correct. Really all you can do is make it more difficult (and costly) for the person to reverse engineer the software.
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)
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.
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.
问题是你将牺牲可读性来做到这一点。 如果你的项目如此神圣，值得保护，我相信可以安全地假设两件事：
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:
我很惊讶您甚至正在考虑代码级混淆。 你不会自己也混淆代码吗？ 你打算如何再次开展这方面的工作？ 为了可维护性，不应该这样做。
但请考虑这一点： -
假设有一个脚本/应用程序可以运行，它会打开您的项目并巧妙地混淆项目中的每个字符串/变量名称，然后您编译它，而原始代码在单独的位置安全地保持不变。
现在这是一些想法。
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.
实际上，代码级混淆不如混淆器安全。 这主要是因为混淆器可以利用语言编译器不允许的严格的 CLI 实现细节。 例如，私有字段具有相同的名称是完全合法的 - 但没有一个编译器可以让您这样做。
Actually code level obfuscation is less secure than 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.
您可以使用这样的技术： http://g.palem.in/SecureAssembly.html使用它，您可以在 .net 中编写，但可以将 .net 可执行文件嵌入到 C++ 可执行文件中，
you can use a technique like this : http://g.palem.in/SecureAssembly.html using this you write in .net but you embed into a c++ executable your .net executable ,
就维护而言，混淆源代码将会弄巧成拙。
如果您的项目是如此“秘密”，我想您有两个选择：
将“秘密”专有代码放在您控制的服务器上的服务后面
使用不易反编译的语言（例如 C/C++）进行编码
使用
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++
也许是有争议的，但这样做会破坏可维护性。
这真的值得吗？
实际上，这只是通过默默无闻实现安全，即它根本不是安全的，它只是一种不便。 您应该假设任何有足够兴趣的一方如果可以访问您的代码，将会反编译您的代码。 为了让邪恶的黑客花费更多的时间而给自己带来的痛苦是不值得的。 处理真正的访问安全问题。
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 will decompile 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.