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

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

关于隐藏代码要记住的第一件事:不是所有的代码都需要隐藏。

最终目标:我对大多数软件程序的最终目标是能够出售不同的许可证，这些许可证将打开和关闭我的程序中的特定功能。

最佳技术:我发现构建一个像WordPress提供的钩子和过滤器系统，绝对是迷惑对手的最佳方法。这允许您加密某些触发器关联，而无需实际加密代码。

这样做的原因是，您希望加密尽可能少的代码。

了解你的破解者:了解这一点:破解代码的主要原因不是因为恶意分发许可，实际上是因为需要更改你的代码，而他们真的不需要分发免费副本。

入门:撇开少量要加密的代码，其余的代码应该尝试塞到一个文件中，以增加复杂性和可理解性。

准备加密:你将在我的系统中分层加密，这也将是一个非常复杂的过程，所以构建另一个程序来负责加密过程。

第一步:使用base64名称来混淆所有内容。完成之后，将混淆的代码base64，并将其保存到一个临时文件中，该文件稍后将用于解密和运行此代码。有意义吗?

我重复一遍，因为你会一次又一次地这样做。您将创建一个base64字符串，并将其保存到另一个文件中，作为将被解密和呈现的变量。

第二步:您将把这个临时文件作为一个字符串读入并混淆它，然后将它作为base64并将其保存到第二个临时文件中，该文件将用于解密并为最终用户呈现它。

第三步:重复第二步，你想重复多少次都行。一旦你让它正常工作，没有解密错误，然后你就会想要开始为你的对手埋地雷。

雷区一:你一定要把你收到通知这件事绝对保密。因此，在第2层构建一个破解尝试安全警告邮件系统。这将让你知道你的对手的细节，如果有任何事情是错误的。

地雷二:依赖。你不希望你的对手能够运行第1层，而没有第3层、第4层或第5层，甚至没有实际设计的程序。因此，请确保在第一层中包含某种终止脚本，如果程序不存在，该脚本将被激活，或在其他层中。

我相信你能想出你自己的地雷，玩得开心。

需要记住的事情:你可以加密你的代码，而不是base64。这样，简单的base64就不会解密程序。

奖励:记住，这实际上是你和对手之间的一种共生关系。我总是在第一层里面放一条评论，评论祝贺破解者，并给他们一个促销码，以便从你那里获得现金奖励。

让现金奖励意义重大，但不涉及偏见。我通常会说500美元左右。如果你的男朋友是第一个破解密码的人，那就付钱给他，成为他的朋友。如果他是你的朋友，他就不会分发你的软件。问问他是怎么做到的，你可以如何改进!

好运！

传统的逆向工程技术依赖于智能代理使用反汇编程序回答关于代码的问题的能力。如果你想要更强的安全性，你必须做一些事情，可以证明阻止代理得到这样的答案。

您可以通过依赖停止程序(“程序X停止吗?”)来做到这一点，这通常是无法解决的。向程序中添加难以推理的程序，会使程序难以推理。构建这样的程序要比拆解它们容易。你也可以在程序中添加推理难度不同的代码;一个很好的候选程序是关于别名(“指针”)的推理程序。

Collberg等人有一篇论文(“制造廉价、弹性和隐形的不透明结构”)讨论了这些主题，并定义了各种“不透明”谓词，这些谓词会使对代码的推理变得非常困难:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.1946&rep=rep1&type=pdf

我还没有看到Collberg的具体方法应用于产品代码，尤其是C或c++源代码。

DashO Java混淆器似乎使用了类似的想法。 http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/

使代码难以进行逆向工程称为代码混淆。

你提到的大多数技术都很容易解决。他们专注于添加一些无用的代码。但是无用的代码很容易被发现和删除，留下一个干净的程序。

为了有效地混淆，您需要使程序的行为依赖于正在执行的无用部分。例如，与其这样做:

a = useless_computation();
a = 42;

这样做:

a = complicated_computation_that_uses_many_inputs_but_always_returns_42();

或者不这样做:

if (running_under_a_debugger()) abort();
a = 42;

这样做(其中running_under_a_debugger不应该很容易被识别为测试代码是否在调试器下运行的函数-它应该将有用的计算与调试器检测混合在一起):

a = 42 - running_under_a_debugger();

有效的混淆并不是仅仅在编译阶段就能做到的。编译器能做的，反编译器也能做。当然，您可以增加反编译器的负担，但这不会有太大的帮助。有效的混淆技术，就其存在而言，包括从第一天开始编写混淆的源代码。让你的代码自修改。你的代码中充斥着从大量输入中得到的计算跳跃。例如，而不是简单的调用

some_function();

这样做，你碰巧知道some_data_structure中精确的位的预期布局:

goto (md5sum(&some_data_structure, 42) & 0xffffffff) + MAGIC_CONSTANT;

如果你认真对待混淆，那就在你的计划中增加几个月的时间;混淆视听代价不菲。请务必考虑到，到目前为止，避免人们对您的代码进行逆向工程的最好方法是使其无用，这样他们就不会费心了。这是一个简单的经济考虑:如果对他们来说价值大于成本，他们就会逆向工程;但提高他们的成本也会大大提高你的成本，所以尽量降低他们的价值。

既然我已经告诉过你，混淆是困难和昂贵的，我要告诉你，无论如何，它不适合你。你写

目前我正在研究的协议绝不能被检查或理解，为了各种人的安全

这是一个危险的信号。它是通过默默无闻来保证安全的，而默默无闻的记录非常糟糕。如果协议的安全性依赖于人们不知道协议，那么你已经输了。

推荐阅读:

安全圣经:Ross Anderson的《安全工程》 混淆的圣经:由Christian Collberg和Jasvir Nagra开发的Surreptitious软件

自2013年7月以来，人们对密码学上健壮的混淆(以不可区分混淆的形式)重新产生了兴趣，这似乎是由Amit Sahai的原始研究激发的。

Sahai, Garg, Gentry, Halevi, Raykova, Waters，候选人 以及所有电路的功能加密(2013年7月21日)。 Sahai, Waters，《如何使用无区别模糊处理》 可否认加密，以及更多。 Sahai, Barak, Garg, Kalai, Paneth，保护混淆不受代数攻击(2014年2月4日)。

您可以在这篇Quanta Magazine文章和IEEE Spectrum文章中找到一些提炼的信息。

目前，利用这项技术所需的资源数量使其不切实际，但AFAICT的共识是对未来相当乐观。

我这么说很随意，但对于那些习惯于本能地忽视混淆技术的人来说——这是不同的。如果它被证明是真正的工作和实际，这确实是重要的，而不仅仅是为了混淆视听。

我不认为任何代码都是牢不可破的，但奖励必须非常棒，才能让人们愿意尝试它。

话虽如此，你还是应该做以下事情:

Use the highest optimization level possible (reverse engineering is not only about getting the assembly sequence, it is also about understanding the code and porting it into a higher-level language such as C). Highly optimized code can be a b---h to follow. Make structures dense by not having larger data types than necessary. Rearrange structure members between official code releases. Rearranged bit fields in structures are also something you can use. You can check for the presence of certain values which shouldn't be changed (a copyright message is an example). If a byte vector contains "vwxyz" you can have another byte vector containing "abcde" and compare the differences. The function doing it should not be passed pointers to the vectors but use external pointers defined in other modules as (pseudo-C code) "char *p1=&string1[539];" and "char p2=&string2[-11731];". That way there won't be any pointers pointing exactly at the two strings. In the comparison code you then compare for "(p1-539+i)-*(p2+11731+i)==some value". The cracker will think it is safe to change string1 because no one appears to reference it. Bury the test in some unexpected place.

尝试自己破解汇编代码，看看哪些是容易的，哪些是困难的。您可以尝试一些想法，使代码更难进行反向工程，并使调试更加困难。