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

晚一点看起来更有希望。

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

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

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

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

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

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

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

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

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

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.

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

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