我的问题与@Rolf Rolles的出色回答相关。由于M.D. Preda等人的论文相当熟练,所以我想知道我是否理解他们的想法。本文引用了以下短语:


基本思想是将攻击者建模为对具体程序行为(即具体程序语义)的抽象解释。 />在此框架中,当不透明谓词的抽象检测等同于其具体检测时,攻击者便可以破坏不透明谓词。



据我所知,他们已经给出了攻击者的正式模型,因为有人试图使用声音近似作为抽象解释(AI)来获取程序的属性。如果AI程序完成,则攻击者将成功(非正式地说,在抽象域中获得的定点“映射”也将返回到具体域中的定点)。他们的模型可以视为解决不透明谓词的基于AI的算法。实际上,这种想法无处不在(例如,在本文中,作者证明了SMT求解器中使用的DPLL算法也是一种抽象解释)。

显然,在最坏的情况下,抽象的解释还不完整,那么攻击者可能永远也不会恢复所需的属性(例如,他可以近似,但是他永远都无法恢复设计良好的不透明谓词的精确解)。攻击者作为抽象域可能会有一些限制,因为我们仍然不确定是否可以在AI中建模所有攻击。然后一个棘手的问题问我:“如果攻击者使用其他方法解析不透明谓词,会发生什么?”。

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

有人可以请给我有什么建议吗?

评论

请改写以使实际问题更明确和具体。

我已经重构了这个问题,但是我不确定它是否足够明确和具体。

#1 楼

任何混淆技术(或其形式化)都针对某类分析A做出的一个或多个假设-本质上,混淆将程序P0转换为具有与P0相同的执行行为,但违反了所做假设的不同表示形式P1通过分析A。这样做,混淆必定定义了一种有效的攻击类型。

抽象解释是对程序分析的形式化,它假设声音进行静态分析(例如,考虑对抽象域和抽象/具体化的要求)职能)。因此,抽象解释可用来规范化做出这些假设的混淆,并帮助我们为满足这些假设的分析/攻击做出推理。它没有描述所有可能的混淆-例如依赖于运行时代码生成或修改的任何混淆-并没有说明不符合这些假设的攻击。因此,按照您的建议,使用动态分析或可能不健全的技术的攻击者实质上避开了抽象解释所假定的规则。

#2 楼

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


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



不透明谓词,反调试技术,反反转技术和其他保护机制旨在使反转变得更加困难,但从来没有做到。有时,准确地设计某件产品然后实际进行设计并不那么重要。有时候,优秀的反向器比设计代码的人更了解代码和设计,从而可以实施攻击或创建补丁。