保护可执行文件免受逆向工程? [英] Protecting executable from reverse engineering?

问题描述

我一直在考虑如何保护我的 C/C++ 代码免遭反汇编和逆向工程.通常我不会在我的代码中容忍这种行为；然而，为了各种人的安全，我一直在研究的当前协议绝不能被检查或理解.

I've been contemplating how to protect my C/C++ code from disassembly and reverse engineering. Normally I would never condone this behavior myself in my code; however the current protocol I've been working on must not ever be inspected or understandable, for the security of various people.

现在这对我来说是一个新主题，而且互联网在防止逆向工程方面并不是真正的资源丰富，而是描述了关于如何进行逆向工程的大量信息

Now this is a new subject to me, and the internet is not really resourceful for prevention against reverse engineering but rather depicts tons of information on how to reverse engineer

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

Some of the things I've thought of so far are:

• 代码注入(在实际函数调用前后调用伪函数)
• 代码混淆(破坏二进制文件的反汇编)

• 编写我自己的启动例程(调试器更难绑定)

• 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)

功能蹦床

 void trampoline(void (*fnptr)(), bool ping = false)  
 {  
   if(ping)  
     fnptr();  
   else  
     trampoline(fnptr, true);  
 }

无意义的分配和释放(堆栈变化很大)

Pointless allocations and deallocations (stack changes a lot)

我的意思是这些是我想到的一些事情，但它们都可以解决或由代码分析师在适当的时间范围内解决.我还有其他选择吗?

I mean these are some of the things I've thought of but they can all be worked around and or figured out by code analysts given the right time frame. Is there anything else alternative I have?

推荐答案

Amber 说的完全正确.您可以使逆向工程更加困难，但您永远无法阻止它.您永远不应该相信依赖于逆向工程预防的安全性".

What Amber said is exactly right. You can make reverse engineering harder, but you can never prevent it. You should never trust "security" that relies on the prevention of reverse engineering.

也就是说，我所见过的最好的反逆向工程技术的重点不是混淆代码，而是破坏人们通常用来理解代码如何工作的工具.与仅仅生成大量可怕的意大利面条式代码相比，寻找创造性的方法来破解反汇编器、调试器等可能更有效，而且在智力上也更令人满意.这对阻止坚定的攻击者没有任何作用，但它确实增加了 J Random Cracker 徘徊并做一些更容易的事情的可能性.

That said, the best anti-reverse-engineering techniques that I've seen focused not on obfuscating the code, but instead on breaking the tools that people usually use to understand how code works. Finding creative ways to break disassemblers, debuggers, etc is both likely to be more effective and also more intellectually satisfying than just generating reams of horrible spaghetti code. This does nothing to block a determined attacker, but it does increase the likelihood that J Random Cracker will wander off and work on something easier instead.

这篇关于保护可执行文件免受逆向工程?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！