保护可执行文件免受逆向工程的影响？

Question

我一直在思考如何保护我的C/C++代码免于拆卸和逆向工程。通常情况下，我不会在代码中宽恕这种行为；但是，为了不同的人的安全，决不能检查或理解我正在处理的当前协议。

现在，这对我来说是一个新的课题，互联网并不是真正有能力预防逆向工程，而是描述了大量关于如何逆向工程的信息

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

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

• 编写我自己的启动例程（调试程序很难绑定到）

  void startup();  
  int _start()   
  {  
      startup( );  
      exit   (0)   
  }  
  void startup()  
  {  
      /* code here */  
  }
  

• 调试程序的运行时检查（如果检测到，则强制退出）

• 功能蹦床

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

• 无意义的分配和释放（堆栈变化很大）

• 无意义的虚拟调用和蹦床（大量的反汇编输出）
• 成吨的铸件（用于模糊拆卸）

我是说，这些都是我想到的一些事情，但只要给出正确的时间框架，代码分析人员就可以解决这些问题。我还有别的选择吗？

Answer 1

Safe Net Sentinel（以前叫阿拉丁）。不过，需要注意的是，他们的API很糟糕，文档也很糟糕，而且与他们的SDK工具相比，这两种工具都很棒。

我已经使用他们的硬件保护方法（Sentinel HASP HL）很多年了。它需要一个专用的USB密钥fob作为软件的“许可证”。他们的SDK对可执行库进行加密和模糊处理，并允许您将应用程序中的不同功能与密钥中的功能绑定。没有许可方提供并激活的USB密钥，软件无法解密，因此无法运行。密钥甚至使用自定义的USB通信协议（在我的知识范围之外，我不是一个设备驱动程序人员）来使构建虚拟密钥或篡改运行时包装器和密钥之间的通信变得困难。他们的SDK对开发人员不是很友好，并且很难将添加保护与自动化构建过程集成（但可能）。

在我们实施HASP HL保护之前，已经有7个已知的盗版者从产品中删除了dotfuscator的“保护”。我们在对软件进行重大更新的同时增加了HASP保护，对视频进行了实时重计算。从分析和基准测试中我可以看出，HASP HL保护只将密集的计算速度减慢了3%左右。自从5年前该软件发布以来，还没有发现新的盗版产品。它所保护的软件在它的市场细分中需求量很大，而且客户意识到有几个竞争对手正积极地试图进行逆向工程（到目前为止还没有成功）。我们知道，他们曾试图向俄罗斯的一些团体寻求帮助，这些团体为破坏软件保护的服务做广告，因为在各种新闻组和论坛上的许多帖子都包含了受保护产品的较新版本。

最近，我们在一个较小的项目上尝试了他们的软件许可证解决方案（HASP SL），如果您已经熟悉HL产品，那么这个解决方案就足够简单了。它似乎起作用了；目前还没有关于盗版事件的报道，但是这种产品的需求量要低得多。。

当然，没有什么保护是完美的。如果有人有足够的动机，并有严重的现金燃烧，我相信哈斯提供的保护可以规避。

Answer 2

but they can all be worked around and or figured out by code analysists given the right time frame.

如果你给人们一个他们能够运行的程序，那么他们也将能够在足够的时间内对其进行逆向工程。这就是程序的本质。一旦有人想破译二进制文件，你就不能阻止最终的逆向工程。毕竟，计算机必须能够破译它才能运行，而人类只是一台速度较慢的计算机。

Answer 3

安珀说的完全正确。你可以让逆向工程变得更难，但你永远无法阻止它。你不应该信任"security" that relies on the prevention of reverse engineering。

也就是说，我所看到的最好的反逆向工程技术并不是把重点放在混淆代码上，而是打破人们通常用来理解代码工作原理的工具。找到打破反汇编程序、调试器等的创造性方法，可能比仅仅生成大量可怕的意大利面代码更有效，也更能满足智力需求。这并不能阻止一个有决心的攻击者，但它确实增加了随机破解的J游走的可能性，而不是更容易的工作。