我一直在思考如何保护我的C/ c++代码不被反汇编和逆向工程破坏。通常情况下,在我的代码中,我绝不会宽恕这种行为;然而,为了各种人的安全,我目前正在研究的协议决不能被检查或理解。

现在这对我来说是一个新的主题,互联网并没有真正的资源来防止逆向工程,而是描述了大量关于如何逆向工程的信息

到目前为止我想到的一些事情是:

Code injection (calling dummy functions before and after actual function calls) Code obfustication (mangles the disassembly of the binary) Write my own startup routines (harder for debuggers to bind to) void startup(); int _start() { startup( ); exit (0) } void startup() { /* code here */ } Runtime check for debuggers (and force exit if detected) Function trampolines void trampoline(void (*fnptr)(), bool ping = false) { if(ping) fnptr(); else trampoline(fnptr, true); } Pointless allocations and deallocations (stack changes a lot) Pointless dummy calls and trampolines (tons of jumping in disassembly output) Tons of casting (for obfuscated disassembly)

我的意思是,这些是我想过的一些事情,但它们都可以在适当的时间框架内由代码分析师解决。我还有别的选择吗?


当前回答

要了解自己,请阅读有关代码混淆的学术文献。亚利桑那大学的克里斯蒂安·科尔伯格是这一领域的著名学者;哈佛大学的Salil Vadhan也做了一些不错的工作。

我在这方面落后了,但我知道的基本思想是,你不能阻止攻击者看到你将执行的代码,但你可以用没有执行的代码包围它,攻击者花费指数级的时间(使用最知名的技术)来发现你的代码的哪些片段被执行了,哪些没有。

其他回答

但只要有合适的时间框架,代码分析人员都可以解决这些问题。

如果你给人们一个他们能够运行的程序,那么只要有足够的时间,他们也能够对它进行逆向工程。这就是程序的本质。一旦二进制文件可供想要破译它的人使用,您就无法阻止最终的逆向工程。毕竟,计算机必须能够破译它才能运行它,而人类只是一台较慢的计算机。

有一件事到目前为止还没有被提及:

您可以在自己的端(服务器端,例如由REST API调用)运行部分代码。这样,逆向工程师就完全无法访问代码。

当然,这只适用于

延迟 交通量 计算和I/O功率 隐私问题

不会阻止服务器端执行(部分)您的代码。

安全网哨兵(原阿拉丁)。不过要注意的是——他们的API很烂,文档也很烂,但与他们的SDK工具相比,这两者都很棒。

I've used their hardware protection method (Sentinel HASP HL) for many years. It requires a proprietary USB key fob which acts as the 'license' for the software. Their SDK encrypts and obfuscates your executable & libraries, and allows you to tie different features in your application to features burned into the key. Without a USB key provided and activated by the licensor, the software can not decrypt and hence will not run. The Key even uses a customized USB communication protocol (outside my realm of knowledge, I'm not a device driver guy) to make it difficult to build a virtual key, or tamper with the communication between the runtime wrapper and key. Their SDK is not very developer friendly, and is quite painful to integrate adding protection with an automated build process (but possible).

Before we implemented the HASP HL protection, there were 7 known pirates who had stripped the dotfuscator 'protections' from the product. We added the HASP protection at the same time as a major update to the software, which performs some heavy calculation on video in real time. As best I can tell from profiling and benchmarking, the HASP HL protection only slowed the intensive calculations by about 3%. Since that software was released about 5 years ago, not one new pirate of the product has been found. The software which it protects is in high demand in it's market segment, and the client is aware of several competitors actively trying to reverse engineer (without success so far). We know they have tried to solicit help from a few groups in Russia which advertise a service to break software protection, as numerous posts on various newsgroups and forums have included the newer versions of the protected product.

最近,我们在一个较小的项目上尝试了他们的软件许可解决方案(HASP SL),如果您已经熟悉HL产品,那么这个解决方案就足够简单了。它似乎有效;目前还没有关于盗版事件的报道,但这款产品的需求要低得多。

当然,没有什么保护措施是完美的。如果有人有足够的动机,并且有大量的现金可以烧,我相信HASP提供的保护是可以规避的。

Take, for example, the AES algorithm. It's a very, very public algorithm, and it is VERY secure. Why? Two reasons: It's been reviewed by lots of smart people, and the "secret" part is not the algorithm itself - the secret part is the key which is one of the inputs to the algorithm. It's a much better approach to design your protocol with a generated "secret" that is outside your code, rather than to make the code itself secret. The code can always be interpreted no matter what you do, and (ideally) the generated secret can only be jeopardized by a massive brute force approach or through theft.

我认为一个有趣的问题是“为什么你想让你的代码变得模糊?”你想让攻击者难以破解你的算法?让他们更难在你的代码中发现可利用的漏洞?如果代码一开始就不可破解,那么您就不需要混淆代码。问题的根源在于易破解的软件。解决问题的根源,不要只是混淆它。

而且,你的代码越混乱,你就越难找到安全漏洞。是的,这对黑客来说很难,但你也需要找到漏洞。从现在开始,代码应该很容易维护,即使是编写良好的清晰代码也很难维护。不要让事情变得更糟。

关于隐藏代码要记住的第一件事:不是所有的代码都需要隐藏。

最终目标:我对大多数软件程序的最终目标是能够出售不同的许可证,这些许可证将打开和关闭我的程序中的特定功能。

最佳技术:我发现构建一个像WordPress提供的钩子和过滤器系统,绝对是迷惑对手的最佳方法。这允许您加密某些触发器关联,而无需实际加密代码。

这样做的原因是,您希望加密尽可能少的代码。

了解你的破解者:了解这一点:破解代码的主要原因不是因为恶意分发许可,实际上是因为需要更改你的代码,而他们真的不需要分发免费副本。

入门:撇开少量要加密的代码,其余的代码应该尝试塞到一个文件中,以增加复杂性和可理解性。

准备加密:你将在我的系统中分层加密,这也将是一个非常复杂的过程,所以构建另一个程序来负责加密过程。

第一步:使用base64名称来混淆所有内容。完成之后,将混淆的代码base64,并将其保存到一个临时文件中,该文件稍后将用于解密和运行此代码。有意义吗?

我重复一遍,因为你会一次又一次地这样做。您将创建一个base64字符串,并将其保存到另一个文件中,作为将被解密和呈现的变量。

第二步:您将把这个临时文件作为一个字符串读入并混淆它,然后将它作为base64并将其保存到第二个临时文件中,该文件将用于解密并为最终用户呈现它。

第三步:重复第二步,你想重复多少次都行。一旦你让它正常工作,没有解密错误,然后你就会想要开始为你的对手埋地雷。

雷区一:你一定要把你收到通知这件事绝对保密。因此,在第2层构建一个破解尝试安全警告邮件系统。这将让你知道你的对手的细节,如果有任何事情是错误的。

地雷二:依赖。你不希望你的对手能够运行第1层,而没有第3层、第4层或第5层,甚至没有实际设计的程序。因此,请确保在第一层中包含某种终止脚本,如果程序不存在,该脚本将被激活,或在其他层中。

我相信你能想出你自己的地雷,玩得开心。

需要记住的事情:你可以加密你的代码,而不是base64。这样,简单的base64就不会解密程序。

奖励:记住,这实际上是你和对手之间的一种共生关系。我总是在第一层里面放一条评论,评论祝贺破解者,并给他们一个促销码,以便从你那里获得现金奖励。

让现金奖励意义重大,但不涉及偏见。我通常会说500美元左右。如果你的男朋友是第一个破解密码的人,那就付钱给他,成为他的朋友。如果他是你的朋友,他就不会分发你的软件。问问他是怎么做到的,你可以如何改进!

好运!