Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

Imporving Efficiency of Dynamic Analysis With Dynamic Dependence Summaries

论文下载

出处:ASE’13 作者:Vijay Krishna Palepu, Guoqing Xu, James A. Jones 单位:UCI

Abstract && Introduction

  • 功能缓存的文章
  • 为了高效的动态分析,会事先准备好组件间的依赖关系,比如记录组件间输入、输出间的关系
  • 相关方法已经有了静态版本,但比较保守,尽可能包含所有情况,增加了后续动态分析的难度,使得效率低下
  • 所以提出动态收集信息缓存功能的想法,是效率和准确度的权衡
  • (方法是对于java提出来的,炮轰静态的原因是多态,不过多态的不只是java,所以应该可以淡化方法对java的依赖性)

Motivation and Challenges

  • 静态分析存在“过度分析”的问题,静态方法会把多态方法和所有可能和该方法产生关系的指令联系起来
  • 而其中有很多信息是冗余的
  • 所以动态收集前期的信息,类似模式识别,用简单的training cases跑程序,获得依赖关系,后来动态分析算是test cases
  • Challenge: Abstracting Concrete Summaries
    • 为了后续可用,需要抽象化先期的实例信息(有点像concolic execution)
    • 把参数符号化(缺乏细节)
  • Challenge: Accounting for Varying Method Behavior
    • An important observation:同一函数,每次执行的语义类似,总结出来的数据关系类似——少数几次执行总结大多数执行的依据
    • 对于多态,记录参数信息
    • 比对抽象模型和当前执行,匹配类型
  • Challenge: Precise Handling of Array Access
    • 对于每个index都给定一个符号名

Approach and Concepts

  • 把每个组件表示成从根对象开始的可达路径:

Fig

  • (文章的前提已经是可以获得方法输入、输出的对应关系了,至于如何获得、其中策略在文章中没有涉及)
  • (个人猜测就是传统的依赖关系分析)

Evaluation

  • 对于非JDK的类,用ASM, a java bytecode manipulation framework
  • 对于standard java library,在执行前插桩
  • (利用 Java 代码,即 java.lang.instrument 做动态 Instrumentation 是 Java SE 5 的新特性,它把 Java 的 instrument 功能从本地代码中解放出来,使之可以用 Java 代码的方式解决问题)
  • 如果summary匹配成功,就使用其中总结的依赖关系,否则正常分析下去
  • i5 2.4G; 1G RAM; 32bit Ubuntu12.04; OpenJDK 6 JVM
  • Exhaustive Analysis vs. Summary-based Analysis
  • 前者是全局插桩,包括core, external components,后者只是插桩测试程序、结合sammaries from external components(事先分析好的)
  • 效率,T: running time S: trace size:

Fig

  • (实验结果理所当然,插桩策略造成的差别就足够了)
  • 准确度:
  • 对NanoXML反向切片,切片标准是已知的bug

Fig


  • 文章是动态获取信息缓存数据依赖关系,以帮助后来的分析
  • 文章的意思涉及了hot path的概念