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.

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

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

起初，虚拟机中受保护的代码似乎不可能进行逆向工程。Themida封隔器

但它不再那么安全了。无论你如何打包你的代码，你总是可以对任何加载的可执行文件进行内存转储，并使用任何反汇编程序(如IDA Pro)进行反汇编。

IDA Pro还提供了一个漂亮的汇编代码到C源代码转换器，尽管生成的代码看起来更像一个指针/地址数学混乱。如果你把它与原来的比较，你可以修复所有的错误，并撕下任何东西。

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

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

通过不公开来保证安全并不像比他聪明得多的人所证明的那样有效 我们两个。如果你必须保护你的客户的通信协议，那么你是 道德上有义务使用最好的代码，这些代码是公开的，并由专家全面审查。

这适用于人们可以检查代码的情况。如果您的应用程序是在嵌入式微处理器上运行的，那么您可以选择一个具有密封功能的微处理器，这使得在运行时不可能检查代码或观察更多的琐碎参数，例如当前使用情况。(是的，除了硬件入侵技术，你要小心地拆卸芯片，使用先进的设备来检查单个晶体管上的电流。)

我是x86逆向工程汇编程序的作者。如果你准备感冒的话 惊喜，寄给我你竭尽全力的结果。(通过我的网站联系我。) 在我所看到的答案中，很少有人会给我带来实质性的障碍。如果你想看的话 如何复杂的逆向工程代码工作，你真的应该研究网站 逆向工程挑战。

你的问题需要澄清一下。你怎么能保守协议的秘密，如果 计算机代码可以进行逆向工程吗?如果我的协议是发送一个RSA加密消息(甚至是公钥)，通过保持协议的秘密，你能得到什么? 出于所有实际目的，检查器将面对一系列随机比特。

问候阿尔伯特

正如很多人已经说过的:在一个普通的CPU上，你不能阻止它们，你只能延迟它们。就像我以前的密码学老师告诉我的那样:你不需要完美的加密，破解密码的代价肯定比获得的代价更大。你的困惑也是一样。

但还有3个注意事项:

It is possible to make reverse engineering impossible, BUT (and this is a very very big but), you cant do it on a conventional cpu. I did also much hardware development, and often FPGA are used. E.g. the Virtex 5 FX have a PowerPC CPU on them, and you can use the APU to implement own CPU opcodes in your hardware. You could use this facility to really decrypt incstuctions for the PowerPC, that is not accessible by the outside or other software, or even execute the command in the hardware. As the FPGA has builtin AES encryption for its configuration bitstream, you could not reverse engineer it (except someone manages to break AES, but then I guess we have other problems...). This ways vendors of hardware IP also protect their work. You speak from protocol. You dont say what kind of protocol it is, but when it is a network protocol you should at least protect it against network sniffing. This can you indeed do by encryption. But if you want to protect the en/decryption from an owner of the software, you are back to the obfuscation. Do make your programm undebuggable/unrunnable. Try to use some kind of detection of debugging and apply it e.g. in some formula oder adding a debug register content to a magic constant. It is much harder if your program looks in debug mode is if it where running normal, but makes a complete wrong computation, operation, or some other. E.g. I know some eco games, that had a really nasty copy-protection (I know you dont want copyprotection, but it is similar): The stolen version altered the mined resources after 30 mins of game play, and suddenly you got just a single resource. The pirate just cracked it (i.e. reverse engineered it) - checked if it run, and volia released it. Such slight behaviour changings are very hard to detect, esp. if they do not appear instantly to detection, but only delayed.

所以最后我想建议: 估算逆向工程人员的收益，将其转化为一些时间(例如，使用最便宜的印度工资)，并进行逆向工程，使时间成本更大。

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

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

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

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

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

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

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

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