可能最好的选择仍然是使用虚拟化，这引入了另一层需要绕过的间接/混淆，但正如SSpoke在他的回答中所说，这种技术也不是100%安全的。

关键是你不会得到终极保护，因为根本就没有这种东西，即使有，也不会持续太久，这意味着它一开始就不是终极保护。

凡是人组装起来的东西，都可以拆卸。

通常情况下，(正确的)拆卸通常是(一点或更多)更困难的任务，所以你的对手必须更熟练，但你可以假设总有这样的人，这是一个安全的赌注。

如果您希望保护某些内容不受REs的影响，那么您必须至少了解REs使用的常见技术。

这样的话

互联网并不是真正的资源预防逆向工程，而是描述了大量关于如何逆向工程的信息

表现出你的坏态度。我并不是说要使用或嵌入保护，你必须知道如何打破它，但要明智地使用它，你应该知道它的弱点和陷阱。你应该明白这一点。

(有一些软件以错误的方式使用保护，使得这种保护实际上不存在。为了避免含糊，我给你举一个在网上简单描述的例子:牛津英语词典第二版CD-ROM - v4。您可以在以下页面了解SecuROM使用失败的原因:16、32或64位Windows环境下CD-ROM上的牛津英语词典(OED):硬盘安装、错误、字处理宏、网络、字体等)

每件事都需要时间。

如果你是这门学科的新手，没有几个月甚至几年的时间来学习正则表达式，那么就使用其他人提供的可用解决方案。这里的问题很明显，它们已经在那里了，所以你已经知道它们不是100%安全的，但制作自己的新保护只会给你一种被保护的错误感觉，除非你非常了解逆向工程和保护的艺术状态(但你不知道，至少目前不知道)。

软件保护的目的是吓唬新手，拖延常见的正则，并让经验丰富的正则在她/他(希望很有趣)到达应用程序中心后面带微笑。

在商业谈话中，你可能会说这都是为了尽可能地推迟竞争。

(看看Philippe Biondi和Fabrice Desclaux在Black Hat 2006上展示的Skype中的银针)。

你知道有很多关于RE的东西，所以开始阅读吧。：）

我说过虚拟化，所以我将给你一个链接到EXETOOLS论坛的一个示例线程:最佳软件保护:Themida还是Enigma protector ?这可能会对你进一步的搜索有所帮助。

最好的反反汇编技巧，特别是在可变字长指令集上，是在汇编程序/机器代码中，而不是在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.

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

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

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

为了能够做出正确的选择，你应该考虑以下几个方面:

有没有可能“新用户”不愿意花钱而是使用你的软件? 现有客户是否有可能需要比他们拥有的更多的许可证? 潜在用户愿意支付多少钱? 你想按用户/并发用户/工作站/公司发放许可证吗? 你的软件需要培训/定制才能有用吗?

如果问题5的答案是“是”，那么就不用担心非法拷贝。反正也没用。

如果问题1的答案是“是”，那么首先考虑定价问题(见问题3)。

如果你回答问题2“是”，那么“按使用付费”模式可能会 适合你。

从我的经验来看，按使用付费+定制和培训是最好的保护 为您的软件，因为:

新用户被定价模式所吸引(很少使用->很少付费) 几乎没有“匿名用户”，因为他们需要培训和定制。 没有软件限制会吓跑潜在客户。 现有客户源源不断地提供资金。 由于长期的业务关系，您可以从客户那里得到有价值的发展反馈。

在您考虑引入DRM或混淆之前，您可能会考虑这些要点，以及它们是否适用于您的软件。

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

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

安全网哨兵(原阿拉丁)。不过要注意的是——他们的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提供的保护是可以规避的。