混淆基于 C 的二进制文件以避免反编译
是否有某种方法可以混淆基于 C 的可执行文件或库以防止反编译？
Is there some way to obfuscate C-based executables or libraries to prevent decompilation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
不。您可以使反编译变得更加困难，但您无法阻止它。我的建议是停止浪费时间，而是专注于提供具有不断改进功能的出色产品。
那么人们就会愿意为此付出代价。
您的主要问题是使代码无法破译的唯一方法是使其无法运行。任何可以加载到 PC 中的东西都可以被破解。为了乐趣、利润或名誉而进行逆向工程的人通常非常很擅长，并且不会因为你试图阻止他们所做的任何事情而受到影响。
他们可以使用一些工具，使破译您的代码的工作比您混淆代码的工作容易得多:-)更好地让全世界相信您的软件值得购买，并将盗版视为可能转换的机会对正版用户来说是“小偷”。
例如，找出他们不为您的软件付费的原因并尝试解决该问题。你永远不可能 100% 地转变人们，有些人会盗用你的代码只是为了好玩。
查看 techdirt 上有关 CwF+RtB 的系列文章（与粉丝联系以及购买理由） 。我发现那里提出的许多观点都适用于软件行业。
No. You can make it more difficult to decompile but you cannot prevent it. My advice is to stop wasting your time and instead concentrate on delivering a fantastic product with ever-improving features.
Then people will be willing to pay for it.
Your main problem is that the only way to make your code un-decipherable is to make it un-runnable. Anything that can be loaded into a PC can be cracked. The people that do reverse engineering for fun, profit or fame are generally very good at it and will really not be the least bit phased by anything you do to try and stop them.
They have access to tools that make the job of deciphering your code far easier than the job you will have obfuscating it :-) Far better to convince the world at large that your software is worth buying, and seeing piracy as an opportunity to possibly convert "thieves" to genuine users.
For example, find out why they're not paying for your software and try to fix that. You'll never convert 100% of the people, some will pirate your code just for the fun of it.
Check out the series of articles running over on techdirt concerning CwF+RtB (connect with fans plus reason to buy). I've found many of the points raised there could be applicable to the software industry.
简单的方法：购买加壳器/加密器/混淆器产品。有些价格昂贵并用于游戏，有些则不然。通过“复制保护”等流行词进行 Google 搜索。
快速方法：使用 UPX 然后在某处修改标头，以便它仍然会加载到内存中并正常运行，但 upx 实用程序将失败并出现错误（尝试版本字段）。如果 upx 实用程序失败，95% 的人会放弃。
困难的方法：编写自己的加壳器。
哦，我忘了：
真正的简单方法：按原样发货。不，真的 - 无论你做什么，人们仍然可以对你的代码进行逆向工程。你付出的努力只会限制有多少人可以逆转它。
The easy way: Buy a packer/cryptor/obfuscator product. Some are expensive and used in games, some are not. Google for them by buzzwords like "copy protection", etc.
The fast way: pack with UPX and then mangle the header somewhere so it will still be loaded in memory and run fine, but the upx utility will fail with an error (try the version field). 95% will give up if the upx utility fails.
The hard way: Write your own packer.
oh, I forgot:
The real easy way: Just ship it as it is. No really - whatever you do people can still reverse engineer your code. The amount of effort you put it in just restricts how many can reverse it.
全面优化编译。
compile with full optimization.
反编译（不再需要）和混淆实践（Flowtables）和理论（不可区分性混淆）是活跃的研究领域，因此没有解决方案 - 只有工具、技术和专业知识。如果您确实希望您的代码不受反编译影响，请创建一个 Web 应用程序，并将敏感代码放在服务器端。但是，如果您坚持向某人提供二进制文件的模式，那么您必须明智地判断您想要在安全性和性能之间做出的权衡。混淆是有代价的，而且永远不会是完美的。一些选项
不要因为 Barak 等人关于黑盒混淆的不可能性的开创性工作而气馁。他只是证明了黑盒混淆器的不可能性，而不是许多实用且有价值的混淆器的不可能性。 （黑盒混淆是程序的内部运作完全难以理解）也不要被盗版者气馁。如果你的产品好的话，总会有人愿意购买。
Decompilation (No More Gotos) and both obfuscation practice (Flowtables) and theory (Indistinguishability Obfuscation) are active areas of research and therefore there are no solutions - only tools, techniques and expertise. If you really want your code to be impervious to decomplilation, create a web app, and put the sensitive code server side. But if you're stuck to the model of giving someone a binary, then you must wisely judge the trade-off you want to make between security and performance. Obfuscation comes at a cost, and still is never perfect. Some options
Don't be discouraged by Barak et al's seminal work on the impossibility of black box obfuscation. He only proves the impossibility of black box obfuscators, not the impossibility of many practical and worthwhile obfuscations. (Black box obfuscation being the inner workings of the program are completely unintelligible) Also don't be discouraged by pirates. There's always people who make it a point to buy your product if it is good.
我认为如果你谈论编译的二进制文件，你无能为力，（也许只适用 UPX 或相关工具）这没有多大意义，因为它可以逆转。
如果您谈论编写新代码，请尝试 自我修改 C 代码 这可能是最难的方法重新设计您的应用程序。
I think if you speak about compiled binary there is not much you can do, (perhaps only apply UPX or related tool) which does not make a lot of sence since it can be reversed.
If you talk about writing new code, try Self Modyfing C Code which will probably be the hardest way to re engineer your application.
使用优化编译器编译 C 代码使得无法恢复原始源代码或任何与其远程相似的代码。它比当今流行的任何 Java 或 .NET 混淆器安全得多。如果您想在发布之前缩小可执行文件并隐藏任何符号名称，请务必剥离可执行文件。但是，请注意，这也使得调试（当应用程序崩溃时）几乎不可能。
即便如此，如果有人真的想破解您的软件，他会在汇编级别上这样做，可能会使用加载软件或其他欺骗手段 - 无论您尝试如何阻止他。许多公司都曾尝试过，但没有一家成功。使用这样的黑客行为只会让最终用户感到沮丧，因为他们可能会导致应用程序崩溃，甚至导致 Windows 的内置调试器崩溃。
不要浪费时间思考混淆，而应该改进程序。
Compiling C code with an optimizing compiler makes it impossible to restore the original source code or anything that even remotely resembles it. It is far more secure than any of the Java or .NET obfuscators that are popular these days. Be sure to strip the executable if you want to make it smaller and hide any symbol names before release. However, notice that this also makes debugging (when the application crashes) pretty much impossible.
Even so, if someone really wants to hack your software, he will do so on assembly level, possibly with loader software or other trickery - no matter what you try and do to prevent him. Many companies have tried, yet none have succeeded. Using hacks like this only frustrate the end-user as they may crash the application or even crash the built-in debugger of Windows.
Quit wasting your time thinking about obfuscation while you should be improving the program instead.
为了让事情变得更难？当然。请不要这样做。
为了防止它？不会。任何要运行二进制文件的系统都需要该软件来解密您提出的任何方案。他们将能够反编译它，然后看看你的模糊二进制文件是如何被解释的。
To make it harder? Sure. Please don't do that.
To prevent it? No. Any system that's going to run your binary will need the software to decrypt whatever scheme you come up with. And they'll be able to decompile that and then see how your obscured binaries get interpreted.
“混淆的可执行文件”没有任何意义。硬件必须能够“理解”代码才能执行它，如果硬件可以理解它，逆向工程人员也可以理解它。你最多能做的就是让理解变得更加乏味，但可能不会太多，而且要付出代价。
"obfuscated executables" makes no sense. The hardware has to be able to "understand" the code in able to to execute it, and it the hardware can understand it, a reverse engineering human can understand it. The most you can do will be make it more tedious to understand, but probably not by much, and at a cost.
如果可以从中获得商业利益，为什么还要混淆代码呢？老实说，假设商业代码经过充分优化和混淆，并且可以工作，然后发生了一件令人尴尬的事情之母 - 一个小故障......你被困住了恕我直言，因为生产二进制代码被混淆了，使得更难调试发生故障且难以复制的地方，它将永远卡在 BUGS 列表中......
例如，试图找到堆栈跟踪，你最终会失去更多的头发，然后再试图找出问题所在- 计算出 WTF 的汇编代码就在那里发生，无穷无尽的意大利面条循环。简而言之，不要！
你最终会在尝试调试故障时赔钱......要么你必须成为一名出色的汇编专家才能读取内存转储并从混淆的代码中解决它......不要扔掉它，只是让你漂亮的产品发挥作用并出售它...当然，有很多人有时间通过逆向工程代码来破解它...
击败它的秘诀是遵循原则 - 经常发布，经常发布，在经常发布的同时进行改进，这样最新和最好的功能将比黑客拆解它所花费的时间更及时锻炼！查看 Linux 源代码，补丁进来，然后发布......如果您牢记这一原则，通过以更快的速度发布具有更多功能的新版本，那么您就赢了！
Why obfuscate the code if there's a commercial gain from it? To be honest, suppose the commercial code is optimized enough and obfuscated, and works, then the mother of a all embarrassing thing happened - a glitch....you are stuck imho, as the production binary code is obfuscated, making it harder to debug where the glitch is happening and difficult to replicate, it will be stuck on the BUGS list forever...
For instance, trying to find the stack trace, you'll end up with losing more hairs then ever trying to figure out the dis-assembled code to work out WTF is happening in there, endless reams of spaghetti loops. In short, don't!
You'll end up with losing money in trying to debug the glitch...either you have to be a brilliant assembler expert to read up the memory dumps and work it out from obfuscated code... Don't throw it away, just get your beautiful product working and sell it...Sure, there's plenty of people that have time on their hands to break it by reverse-engineering the code...
The secret to beating that is following the principle - release frequently, release often, make improvements as you release often, in that way the latest and greatest features would be more up-to-date then the time it takes for a cracker to disassemble it and work out! Look at the linux source code, the patches come in, then it gets released...if you keep that principle in mind, by releasing new version with more features at a far more faster pace then you're winning!
让事情变得稍微困难的一种方法是打包它们。 UPX 将打包您的二进制文件，这使得开箱即用的反编译变得更加困难。从技术上讲，可以先解压然后反编译，但这会稍微提高标准。假设您正在普通用户操作系统上运行，那么如果不使用令人讨厌的技巧，您就无法采取很多措施来防止反编译。
One way to make things slightly more difficult is to pack them. UPX will pack your binaries which makes it harder to decompile out of the box. Technically it's possible to unpack and then decompile but it will raise the bar a bit. Assuming you're running on a vanilla user operating system there isn't a whole lot you can do to prevent decompilation without using nasty tricks.
如果你真的想把它搞乱，你需要一个单独的程序来完成它。作为开发人员，您以最干净、最易读的形式编写代码。编译后，您运行单独的应用程序来进行混淆。您可以花费大约 10 万美元购买此类应用程序。
如果您的目的是阻止代码被逆向工程，那么这可能会起作用。如果您的目的是阻止某人破解安全性，那么仅靠混淆并不能阻止坚定的攻击者。在某些时候，有一个是/否的决定，他们不需要理解代码来找到它或规避它。
If you really want to jumble it up you need a separate program to do it. As a developer you write your code in the cleanest, and most readable form. Post compilation you run the separate application to do the obfuscation. You can buy such applications for about $100K.
If your intention is to stop the code from being reversed engineered that will probably work. If your intention is to stop someone from cracking the security then obfuscation alone won't stop a determined attacker. At some point there is a yes/no decision they don't need to understand the code to find that nor to circumvent it.
经过修改的微型 C 编译器可生成模糊代码：http://blogs.conus.info/node/58
Tiny C compiler modified to produce obfuscated code: http://blogs.conus.info/node/58
为此处的答案提供一些理论支持：2001 年 Barak 等人。 al. 证明了程序混淆一般来说是不可能的。
To provide some theoretical support for the answers here: in 2001 Barak et. al. proved that program obfuscation is impossible in general.