如何保护Exe文件免受反编译

9

4
保护可执行文件不被逆向工程是不存在的。只要可以运行,就可以被逆向工程。压缩程序和其他工具只是增加了逆向工程的门槛。 - Shi
@Ira “肯定可以制作出无法逆向工程的程序。” 这是一个假设还是事实?你能举个例子吗?你真的激起了我的兴趣。你是否指的是你可以编写一段针对某个机器的代码,使得该机器对于给定的输入产生明确定义的输出,并且 - 拥有这段代码 - 你无法得知从输入到输出的规则,因此无法重写它? - Hyperboreus
4个回答

18
防止程序被反向工程(“理解”)的唯一好方法是修改其结构,从而基本上迫使对手理解图灵机。你需要做的是:
- 选择一些通常被证明为计算难题的问题 - 合成一个版本,你知道它的结果;相对于解决一个版本,这通常相当容易 - 使正确的程序执行依赖于正确的答案 - 如果答案不正确,则使程序计算无意义的内容
现在,一个盯着你的代码的对手必须通过算法难题来确定“正确”的计算方式。40年来,文献中还没有人有效地解决大量NP-hard难题;如果你的程序依赖于其中之一,那么随意的反向工程师突然间就不会能够解决它们。
通常,这是通过转换原始程序以模糊其控制流和/或数据流来完成的。一些技术通过将一些控制流转换为基本上是数据流的形式(“跳转指针数组间接跳转”),然后实施需要精确指向分析的数据流算法来混淆控制流。这既是可证明困难的,也在实践中被证明很难。
这里有一篇文章描述了各种技术,但是浅显易懂: http://www.cs.sjsu.edu/faculty/stamp/students/kundu_deepti.pdf

这里有一篇文章,重点介绍如何确保混淆转换产生的结果在计算上保证难度: http://www.springerlink.com/content/41135jkqxv9l3xme/

这篇文章概述了各种控制流转换方法,包括那些提供安全保证的方法: http://www.springerlink.com/content/g157gxr14m149l13/

这篇论文在二进制程序中低开销地混淆控制流: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.167.3773&rank=2

现在,可以采取很多措施来防止程序被反编译。但如果反编译后的程序无法理解,你可能就不会费心去做这些;这是我会采取的方法。

如果您坚持防止反编译,可以通过考虑反编译的目的来攻击它。 反编译基本上是提出您可以将目标程序的每个字节转换为某些代码的想法。 使其失败的一种方法是确保应用程序似乎可以将每个字节用作计算机指令和数据,即使实际上并没有这样做,并且决定这样做的决策被上述方法混淆。 这种方法的一个变体是在代码中有很多条件分支,实际上这些条件分支是无条件的(使用控制流混淆方法); 分支的另一侧落入看似有效但跳转到现有代码中的疯狂位置的无意义代码。 这个想法的另一个变体是将程序实现为混淆的解释器,并将实际功能实现为一组解释的数据。 让此类程序失败的有趣方法是在运行时生成代码并在执行之前立即执行它; 大多数传统语言(如C)几乎无法表示这一点。
构建如此的程序将很难进行反编译,更不用说在事后理解它了。
声称可以很好地保护二进制代码的工具列在以下位置:https://security.stackexchange.com/questions/1069/any-comprehensive-solutions-for-binary-code-protection-and-anti-reverse-engineeri

5
打包、压缩和其他二进制保护方法只会阻碍或减慢代码反转的过程,它们从来不是也永远不会是100%安全的解决方案(尽管某些营销手段可能让你相信这一点)。你基本上需要评估你所面对的黑客的水平。如果他们只是脚本小子,那么任何需要“真正的努力和技能”(即缺少解包脚本/程序/教程的打包工具)的打包工具都会阻止他们。如果你面对的是有技能和资源的人,那么你可以忘记保护你的代码(正如很多评论所说的:如果操作系统可以读取并执行它,那么你也可以,只是需要更长的时间)。如果你关心的不是你的知识产权,而是你的程序所做的事情的安全性,那么你最好重新设计一种方式,使其即使在原始源代码下也无法受到攻击(Chrome采用了这种方法)。

+1 对于“重新设计,使其即使使用原始源代码也无法受到攻击”。安全性靠混淆从来没有起过作用,也永远不会。 - Hyperboreus
2
没有绝对安全的安全保护措施。即使我们拥有所有的加密技术,也不能保证安全。问题是,“破解安全所需的工作量是否显著,并且是否会阻止某些大规模攻击者?”如果答案是肯定的,那么这种安全方案就是有用的。 - Ira Baxter
如果安全是一个问题,最好不要使用任何软件。如果操作系统或处理器可以理解二进制代码,那么其他人也可以。+1 - user142019
@WTP:执行二进制文件与理解程序或进行任意所需更改大不相同。 - Ira Baxter

1
目前有许多解决方案可用于保护您的应用程序免受反编译,例如压缩、混淆、代码片段等。您可以寻找一家公司来帮助您实现这一点。
例如Nelpeiron,网址是:https://www.nalpeiron.com/ 它可以覆盖许多平台,包括Windows、Linux、ARM-Linux和Android。
此外,Virbox也可以考虑: 网址是:https://lm-global.virbox.com/index.html 我推荐它是因为它们有更多的选项来保护您的源代码,例如导入表保护、内存检查。

1

反编译始终是可能的。你链接网站上的声明

通过打包/压缩可执行文件(.exe),可以消除这种威胁。

纯属谎言。


我认为这太过牵强。如果程序的编码与图灵机器的成功执行相联系,你可能必须决定图灵机器是否停机才能得到正确的解码。计算机科学说你不能这样做。因此,反解编译器还有一些希望。链接网站上的那个是否好用则是另一个问题。另外请注意,OP 提出的是针对反向工程的防御,而不仅仅是反解编译。 (在过去,APL 程序已被证明具有相当的抗性 :)) - Ira Baxter
1
@Ira,我无法理解你的意思。如果执行代码的环境(无论是RE、处理器还是算盘)能够按照程序要求执行代码,那么显然代码已经被成功读取了。如果我的运行时环境可以做到这一点,那么我也可以,因此反汇编始终是可能的。或者我理解错了吗? - Hyperboreus

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接