为什么你要混淆你的代码？
您以前曾经混淆过您的代码吗？ 这样做有正当理由吗？
Have you ever obfuscated your code before? Are there ever legitimate reasons to do so?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
您以前曾经混淆过您的代码吗？ 这样做有正当理由吗？
Have you ever obfuscated your code before? Are there ever legitimate reasons to do so?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（13）
我混淆了我的 JavaScript。 它使它更小，从而减少了下载时间。 另外，由于代码是交给客户的，所以我的公司不希望他们能够读取它。
I have obfuscated my JavaScript. It made it smaller, thus reducing download times. In addition, since the code is handed to the client, my company didn't want them to be able to read it.
是的，让逆向工程变得更加困难。
Yes, to make it harder to reverse engineer.
当然是为了确保终身工作（开玩笑）。
这是非常搞笑和有教育意义的：如何编写不可维护的代码。
To ensure a job for life, of course (kidding).
This is pretty hilarious and educational: How to Write Unmaintanable Code.
这就是所谓的“工作保障”。 这也是使用 Perl 的原因——不需要将混淆作为单独的任务进行，因此可以提高生产率，而不会失去工作保障。
如果您愿意的话，可以将其称为“通过模糊性实现安全”。
It's called "Job Security". This is also the reason to use Perl -- no need to do obfuscation as separate task, hence higher productivity, without loss of job security.
Call it "security through obsfuscability" if you will.
我不认为让逆向工程变得更加困难是一个合理的理由。
混淆代码的一个很好的理由是减少编译后的占用空间。 例如，J2ME 应用程序需要尽可能小。 如果您通过混淆器（和优化器）运行您的应用程序，那么您可以将 jar 从几 Mb 减少到几百 Kb。
上面提到的另一点是，大多数混淆器也是优化器，可以提高应用程序的性能。
I don't believe making reverse engineering harder is a valid reason.
A good reason to obfuscate your code is to reduce the compiled footprint. For instance, J2ME appliactions need to be as small as possible. If you run you app through an obfuscator (and optimiser) then you can reduce the jar from a couple of Mb to a few hundred Kb.
The other point, nestled above, is that most obfuscators are also optimisers which can improve your application's performance.
这不也是通过默默无闻来作为安全性的吗？ 当您的源代码是公开可用的（javascript 等）时，您可能希望至少有点难以理解客户端实际发生的情况。
安全总是充满妥协。 但我认为默默无闻的安全是最无效的方法之一。
Isn't this also used as security through obscurity? When your source code is publically available (javascript etc) you might want to at least it somewhat harder to understand what is actually occuring on the client side.
Security is always full of compromises. but i think that security by obscurity is one of the least effective methods.
我相信所有的有线电视盒都会混淆java代码。 这确实使事情变得更难破解，而且由于有线电视盒位于您的家中，因此理论上它们是可破解的。
我不确定这有多重要，因为有线卡仍然会控制信号加密并直接从视频源而不是 java 代码指南或 java 应用程序获得授权，但他们非常致力于这个概念。
顺便说一句，跟踪从混淆的堆栈中抛出的异常并不容易！ 我实际上记得有一次，aH 意味着特定构建的“空指针异常”。
I believe all TV cable boxes will have the java code obfuscated. This does make things harder to hack, and since the cable boxes will be in your home, they are theoretically hackable.
I'm not sure how much it will matter since the cable card will still control signal encryption and gets its authorization straight from the video source rather than the java code guide or java apps, but they are pretty dedicated to the concept.
By the way, it is not easy to trace exceptions thrown from an obfuscated stack! I actually memorized at one point that aH meant "Null Pointer Exception" for a particular build.
我记得创建了一个基于 .NET 构建的 Windows 在线备份服务应用程序。 我可以轻松地使用 Visual Studio 或 .NET Reflector 等工具来查看类及其内部的源代码。
我创建了一个新的 Visual Studio Test 应用程序并向其添加了 Windows 服务引用。 双击引用，我可以看到所有的类、命名空间（尽管不是源代码）。 任何人都可以通过查看类名来了解模块的内部工作原理。 就我而言，FTPHandler 就是这样一个类，它清楚地告诉我们备份的去向。
.NET Reflector 超越了这一点，它显示了实际的代码。 它甚至有一个导出整个项目的选项，这样你就可以获得一个 VS 项目，其中包含与开发人员相似的所有类和源代码。
我认为混淆是有道理的，至少可以让某人更难（如果不是不可能的话）拆解。 此外，我认为这对于涉及大量客户群的产品来说是有意义的，因为您不希望竞争对手过多了解您的产品。
I remember creating a Windows Service for Online Backup application that was built in .NET. I could easily use either Visual Studio or tools like .NET Reflector to see the classes and the source code inside it.
I created a new Visual Studio Test application and added the Windows Service reference to it. Double clicked on the reference and I can see all the classes, namespaces everything (not the source code though). Anybody can figure out the internal working of your modules by looking at the class names. In my case, one such class was FTPHandler that clearly tells where the backups are going.
.NET Reflector goes beyond that by showing the actual code. It even has an option to Export the whole project so you get a VS project with all the classes and source code similar to what the developer had.
I think it makes sense to obfuscate, to make it atleast harder if not impossible for someone to disassemble. Also I think it makes sense for products involving large customer base where you do not want your competitors to know much about your products.
看看我为磁盘驱动程序项目编写的一些代码，让我质疑混淆意味着什么。
或者这只是用 C 语言进行系统编程？ 或者该行应该以不同的方式写？ 问题...
Looking at some of the code I wrote for my disk driver project makes me question what it means to be obfuscated.
Or is that just system programming in C? Or should that line be written differently? Questions...
是的，也不是，我还没有提供带有易于反编译的工具的应用程序。
我确实为旧的 Basic 和 UCSD Pascal 解释器运行了类似混淆器的东西，但这是出于不同的原因，优化运行时间。
Yes and no, I haven't delivered apps with a tool that was easy decompilable.
I did run something like obfuscators for old Basic and UCSD Pascal interpreters, but that was for a different reason, optimizing run time.
如果我向客户提供 Java Swing 应用程序，我总是在分发之前混淆类文件。
你永远不会太小心 - 我曾经指出过一个不错的 Java 反编译器（我使用了 JD Java Decompiler - http://www .djjavadecompiler.com/ ）在我的类文件中，并获得了几乎完美的原始代码复制。 这相当令人不安，所以从那时起我就开始混淆我的生产代码。 我自己使用 Klassmaster (http://www.zelix.com/klassmaster/)
If I am delivering Java Swing apps to clients, I always obfuscate the class files before distribution.
You can never be too careful - I once pointed a decent Java decompiler (I used the JD Java Decompiler - http://www.djjavadecompiler.com/ ) at my class files and was rewarded with an almost perfect reproduction of the original code. That was rather unnerving, so I started obfuscating my production code ever since. I use Klassmaster myself (http://www.zelix.com/klassmaster/)
我主要混淆了 Android 应用程序的代码。 我使用 ProGuard 工具来混淆代码。
当我从事 C# 项目时，我们的团队使用了 ArmDot。 它是许可和混淆系统。
现代混淆器的使用不仅使黑客攻击过程变得困难。 他们能够保护程序和游戏免遭作弊、检查许可证/密钥，甚至优化代码。
但我认为没有必要在每个项目中都使用混淆器。
I obfuscated code of my Android applications mostly. I used ProGuard tool to obfuscate the code.
When I worked on the C# project, our team used the ArmDot. It's licensing and obfuscation system.
Modern obfuscators are used not only to make hacking process difficult. They are able to protect programs and games from cheating, check licenses/keys and even optimize code.
But I don't think it is necessary to use obfuscator in every project.
当您需要提供源代码中的某些内容时（通常是由于其构建的环境，例如没有共享库的系统，特别是当您作为卖家没有确切的系统时），最常见的情况是这样做正在构建），但您不希望您提供它的人能够显着（或根本）修改或扩展它。
这在过去比现在更为普遍。 这也导致了（已不复存在？）混淆 C 竞赛。
合法（尽管可以说不是“合法”）用途可能是发布您以模糊方式与 GPL 代码链接的应用程序的“源代码”。 它是源代码，可以修改，只是非常困难。 这将是一个更极端的版本，不加评论地发布它，或者在删除所有空白的情况下发布它，或者（这可能会推动法律依据）发布由 C 生成的汇编程序源代码（也许是手工调整的，所以你可以说它不是只是中间代码）。
It's most commonly done when you need to provide something in source (usually due to the environment it's being built in, such as systems without shared libraries, especially if you as the seller don't have the exact system being build for), but you don't want the person you're giving it to to be able to modify or extend it significantly (or at all).
This used to be far more common than today. It also led to the (defunct?) Obfuscated C Contest.
A legal (though arguably not "legitimate") use might be to release "source" for an app you're linking with GPL code in obfuscated fashion. It's source, it can be modified, it's just very hard. That would be a more extreme version of releasing it without comments, or releasing with all whitespace trimmed, or (and this would be pushing the legal grounds probably) releasing assembler source generated from C (and perhaps hand-tweaked so you can say it's not just intermediate code).