我一直在思考如何保护我的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)

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


当前回答

最好的反反汇编技巧,特别是在可变字长指令集上,是在汇编程序/机器代码中,而不是在c中

CLC
BCC over
.byte 0x09
over:

The disassembler has to resolve the problem that a branch destination is the second byte in a multi byte instruction. An instruction set simulator will have no problem though. Branching to computed addresses, which you can cause from C, also make the disassembly difficult to impossible. Instruction set simulator will have no problem with it. Using a simulator to sort out branch destinations for you can aid the disassembly process. Compiled code is relatively clean and easy for a disassembler. So I think some assembly is required.

I think it was near the beginning of Michael Abrash's Zen of Assembly Language where he showed a simple anti disassembler and anti-debugger trick. The 8088/6 had a prefetch queue what you did was have an instruction that modified the next instruction or a couple ahead. If single stepping then you executed the modified instruction, if your instruction set simulator did not simulate the hardware completely, you executed the modified instruction. On real hardware running normally the real instruction would already be in the queue and the modified memory location wouldnt cause any damage so long as you didnt execute that string of instructions again. You could probably still use a trick like this today as pipelined processors fetch the next instruction. Or if you know that the hardware has a separate instruction and data cache you can modify a number of bytes ahead if you align this code in the cache line properly, the modified byte will not be written through the instruction cache but the data cache, and an instruction set simulator that did not have proper cache simulators would fail to execute properly. I think software only solutions are not going to get you very far.

上面这些都是老的和众所周知的,我对当前的工具了解不够,不知道它们是否已经围绕这些事情工作了。自修改代码可能/将使调试器出错,但是人类可以/将缩小问题范围,然后看到自修改代码并解决它。

It used to be that the hackers would take about 18 months to work something out, dvds for example. Now they are averaging around 2 days to 2 weeks (if motivated) (blue ray, iphones, etc). That means to me if I spend more than a few days on security, I am likely wasting my time. The only real security you will get is through hardware (for example your instructions are encrypted and only the processor core well inside the chip decrypts just before execution, in a way that it cannot expose the decrypted instructions). That might buy you months instead of days.

另外,读读凯文·米特尼克的《欺骗的艺术》。这样的人可以拿起电话,让你或同事把秘密交给系统,以为那是公司其他部门的经理、其他同事或硬件工程师。你的安全系统也被破坏了。安全不仅仅是管理技术,还要管理人。

其他回答

看看http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against。我相信其他人可能也能给出一个更好的来源,说明为什么通过隐匿性实现安全是一件坏事。

它应该是完全可能的,使用现代加密技术,让您的系统是开放的(我不是说它应该是开放的,只是它可以是),并且仍然具有完全的安全性,只要加密算法没有漏洞(如果您选择了一个好的算法,就不太可能),您的私钥/密码保持私有,并且您的代码中没有安全漏洞(这是您应该担心的)。

自2013年7月以来,人们对密码学上健壮的混淆(以不可区分混淆的形式)重新产生了兴趣,这似乎是由Amit Sahai的原始研究激发的。

Sahai, Garg, Gentry, Halevi, Raykova, Waters,候选人 以及所有电路的功能加密(2013年7月21日)。 Sahai, Waters,《如何使用无区别模糊处理》 可否认加密,以及更多。 Sahai, Barak, Garg, Kalai, Paneth,保护混淆不受代数攻击(2014年2月4日)。

您可以在这篇Quanta Magazine文章和IEEE Spectrum文章中找到一些提炼的信息。

目前,利用这项技术所需的资源数量使其不切实际,但AFAICT的共识是对未来相当乐观。

我这么说很随意,但对于那些习惯于本能地忽视混淆技术的人来说——这是不同的。如果它被证明是真正的工作和实际,这确实是重要的,而不仅仅是为了混淆视听。

最近有一篇论文叫做“程序混淆和一次性程序”。如果你真的想保护你的应用程序。本文主要围绕使用简单通用硬件的理论不可能结果。

如果你负担不起额外的硬件,那么还有另一篇论文,在所有具有相同功能和相同大小的程序中,给出了理论上的最佳可能混淆“On最佳可能混淆”。然而,本文表明,信息理论的最佳可能意味着多项式层次结构的崩溃。

如果这些结果不能满足你的需要,这些论文至少应该给你足够的参考书目引导去查阅相关文献。

更新:一种新的混淆概念,称为不可区分混淆,可以减轻不可能性结果(论文)

有人试过codemoth: http://www.sourceformat.com/code-obfuscator.htm吗? 或者Themida: http://www.oreans.com/themida_features.php ?

晚一点看起来更有希望。

不行,你不能保护你的代码不被反汇编。你所能做的就是为业务逻辑设置服务器,并使用webservice为你的应用程序提供它。当然,这种情况并不总是可行的。