正式混淆

逆向工程 混淆 去混淆
2021-07-05 21:10:25

我的问题是有关这个问题与@Rolf罗尔斯的出色答卷。由于MD Preda 等人的论文很有技术,所以我想知道我是否理解他们的想法。论文中引用了以下语句:

基本思想是将攻击者建模为具体程序行为的抽象解释,即具体程序语义。在这个框架中,当不透明谓词的抽象检测等同于其具体检测时,攻击者能够破解不透明谓词。

据我所知,他们给出了一个正式的攻击者模型,因为有人试图使用声音近似作为抽象解释 (AI) 来获取程序的属性。如果 AI 过程完成,攻击者将成功(非正式地说,抽象域中获得的不动点也“映射”回具体域中的不动点)。

具体来说,他们的模型可以被认为是一种基于人工智能的解决不透明谓词的算法。事实上,这个想法无处不在(例如在这篇论文中,作者已经证明了 SMT 求解器中使用的 DPLL 算法也是一种抽象的解释)。

显然,在抽象解释不完整的最坏情况下,攻击者可能永远无法恢复所需的属性(例如,他可以近似但永远无法恢复设计良好的不透明谓词的确切解决方案)。

所以我想知道攻击者作为抽象域的模型可能有一些限制,因为我们仍然不确定所有的攻击都可以在 AI 中建模。然后我想到了一个直截了当的问题:“如果攻击者使用其他一些方法来解决不透明谓词会发生什么?。”

举个简单的例子,攻击者可以简单地使用动态分析绕过不透明谓词(他接受一些不正确,但最终他可能能够得到他想要的属性)。

有人能给我一些建议吗?

2个回答

任何混淆技术(或其形式化)都针对某类分析 A 做出的一个或多个假设——本质上,混淆将程序 P0 转换为不同的表示 P1,该表示与 P0 具有相同的执行行为,但违反了所做的假设通过分析 A。在这样做时,混淆必然定义了一类它可以有效对抗的攻击;它没有说明不属于该类别的攻击。

抽象解释是程序分析的一种形式化,它假定合理的静态分析(例如,考虑强加在抽象域和抽象/具体化功能上的要求)。因此,抽象解释有助于使做出这些假设的混淆形式化,并帮助我们推理满足这些假设的分析/攻击。它没有描述所有可能的混淆——例如,任何依赖于运行时代码生成或修改的混淆——并且不涉及不满足这些假设的攻击。因此,如您所建议的,使用动态分析或潜在不可靠技术的攻击者基本上会回避抽象解释所假定的规则。

如果我理解正确,您实际上已经自己回答了您的问题:

...攻击者可以简单地使用动态分析绕过不透明谓词(他接受了一些错误,但最终他可以获得他想要的属性)。

不透明谓词、反调试技术、反反转技术和其他保护机制旨在使反转更难,但绝不是不可能的。有时,某物究竟是如何设计的,其实际作用并不重要。有时,优秀的逆向者比设计它的人更了解代码和设计,这允许实施攻击或创建补丁。