User:Holmeszry

From Trusted Cloud Group
Jump to: navigation, search

Contents

张若愚 ( Zhang Ruoyu )

Ruoyu Pic.jpg

  • 程序分析组
  • 2008级工程硕士研究生
  • Email: markzhang1986@gmail.com

Publications

[1] Ruoyu Zhang, Shan Huang, Zhengwei Qi. Efficient Taint Analysis with Taint Behavior Summary. CMC 2011
[2] Ruoyu Zhang, Yudi Zheng, Shan Huang, Zhengwei Qi. Structured Dynamic Program Slicing. CAMAN 2011
[3] Gengbiao Chen, Zhuo Wang, Ruoyu Zhang, Kan Zhou, Shiqiu Huang, Kangqi Ni, Zhengwei Qi, Kai Chen, Haibing Guan. A Refined Decompiler to Generate C Code with High Readability. WCRE 2010.

毕业论文

题目

[静态程序分析辅助的动态漏洞挖掘] 打开
Static Program Analysis Assisted Dynamic Software Vulnerability Discovery

摘要

  随着计算机技术高速普及和发展,大量的计算机应用正在越来越深入地影响着人们的工作生活,也带来了日益严重和广泛的安全问题及隐患。这些年来对于程序分析技术的研究方兴未艾,目前已经存在许多工具能够通过对目标代码的分析,对其中可能引发安全问题的设计缺陷进行识别和保护。大多数的此类工具是通过动态软件测试技术或是静态的程序分析技术来达到目的。其中前者虽然具有较高的准确率但是每个用例只能覆盖有限的代码,一次很难提供较为完备的分析结果。而后者虽然能够覆盖所有代码,但在准确率上有所欠缺,存在大量的误报情况。针对目前同类技术的缺陷,本文通过综合静态以及动态程序分析各的特性,提出了一种新方法,做到了既能覆盖绝大多数的程序中路径,也在准确性上超越了传统的静态分析。论文中实现了一个静态程序分析辅助的动态污染传播跟踪机制,在传统的污染跟踪过程中,同时进行函数级的静态代码的控制流图补全,并以路径为单位实施静态的污染传播分析,以达到动静结合的分析效果。

  本文的研究主要包含了如下贡献和具体工作:
  1) 提出了一种新颖的结合动态与静态程序分析的方法,综合两者的优点,对其缺点进行互补,达到代码覆盖率,准确率和效率的提高。
  2)基于前面提出的动静态分析结合方法,本毕业论文实现了一个软件漏洞挖掘工具SDCF。该系统针对二进制代码,在动态污染行为分析的同时,对并未得到执行的指令也实施静态的控制流信息补全和污染相关分析。
  3)文章提出了一种基于污染行为总结的效率优化机制,通过对一些行为可以预测的系统调用的污染相关行为的规约,简化整个污染分析过程。
  实验表明通过静态程序分析辅助的动态污染跟踪机制,SDCF 在仅仅引入4.16 倍的运行时负荷的情况下,不但能够对目标程序实施基于动态污染跟踪的运行时保护,也能够在某些软件漏洞被恶意用户利用之前实施挖掘,其分析的平均代码覆盖率达到90%以上。

参考文献

[1][V. Ganesh, T. Leek, M. C. Rinard. Taint-based directed whitebox fuzzing. ICSE, 2009.]
[2][James Newsome, Dawn Xiaodong Song. Dynamic Taint Analysis for Automatic Detection, Analysis, and Signature Generation of Exploits on Commodity Software. NDSS 2005.]

[3][Feng Qin, Cheng Wang, Zhenmin Li, Ho-Seop Kim, Yuanyuan Zhou, Youfeng Wu. LIFT: A Low-Overhead Practical Information Flow Tracking System for Detecting Security Attacks. MICRO 2006.]

[4][Dawn Xiaodong Song, David Brumley, Heng Yin, Juan Caballero, Ivan Jager, Min Gyung Kang, Zhenkai Liang, James Newsome, Pongsin Poosankam, Prateek Saxena. BitBlaze: A New Approach to Computer Security via Binary Analysis. ICISS 2008.]

[5][Derek Bruening , Timothy Garnett , Saman Amarasinghe. An infrastructure for adaptive dynamic optimization. In International Symposium on Code Generation and Optimization(CGO), 2003.]

[6][Ashish Aggarwal, Pankaj Jalote. Integrating static and dynamic analysis for detecting vulnerabilities. COMPSAC 2006.]

[7][J. A. Clause, W. Li, A. Orso. Dytan: a generic dynamic taint analysis framework. In Proceedings of the 2007 international symposium on Software testing and analysis, 2007.]

[8][James Newsome, David Brumley, Jason Franklin, Dawn Xiaodong Song. Replayer: automatic protocol replay by binary analysis. ACM Conference on Computer and Communications Security 2006.]

开题材料

中期材料

答辩ppt

个人历史记录

10.26.10

  • c-decompiler中库函数识别的方法:
1.耿标的库函数识别采取的是二进制比对,将每一个遇到的函数调用都与相应的,由c-decompiler中提供的二进制代码形式的库函数签名进行比对以辨别库函数。
2.这种方法的优点在于可以辨别编译到目标代码中的静态库;缺点在于效率低,每一个调用都去比对一次代价太大。
  • 基于IAT查询的库函数识别方法:
1.通过从IAT中的表项得到call目标地址处函数的ID信息,并根据我们所创建的库函数信息表对该call进行识别。
2.这种方法的优点在于效率很高,只用查一次表就能得到该函数的信息;缺点在于只能识别动态库,不能识别静态库。
3.由于我们针对的是系统库(比如ntdll.dll,kernel32.dll,msvcrt.dll)所以这种方法是可行的。
  • 目前的工作:
1.由于大多数的call并不是call立即数,所以对call的对象进行分析取值还需完成。(完成)
2.对于各个系统库的api信息还需整理。(进行中)
3.与dsvd整合。(基本完成)
4.论文撰写。(进行中)

9.28.10

8.11.10

  • 目前需要完成的工作
1.将目前的静态补全部分整合到DSVD中。
2.实现使用动静结合的方法检测脆弱点.
a.记录污染状态。
b.逐一遍历静态补全路径寻找潜在脆弱点。
c.根据动态得到的临时污染状态以及潜在脆弱点所在的静态路径的污染传播行为对潜在脆弱点是否有可能被利用进行判断。
3.找到能够被动静结合方法分析的软件漏洞的实际程序以实验之。

7.28.10

  • 当前基于污染传播的软件脆弱点检测工具大多采取以下策略
1.控制转移地址为受污染数据;
2.字符串处理函数使用受污染的数据作为参数;
3.SYSTEM CALL使用受污染的数据作为参数;
4.针对某些已知容易被利用的第三方库的某些参数使用到受污染数据

由于控制转移地址太为宽泛,难以定位,目前暂定将针对字符串处理函数视为潜在脆弱点并进行分析。

7.21.10

  • 基本完成call graph构建以及跨函数的cfg绘制。
  • 开始研究如何结合静态补全制定Taint Sink Assertion策略来挖掘潜在的vulnerrabilies。

7.14.10

  • 对当前静态补全手段进行修改。
  • 构建调用图。
  • 在静态过程中调用图构建进度

7.7.10

  • 对当前静态补全手段进行修改。
  • 构建调用图。
  • 在静态过程中API调用识别

5.19.10

  • 基本完成单函数内的cfg补全工作
  1. 有部分细节问题会造成cfg的不精确,正在调试修改之中。
  2. 继续进行Call Graph的构建,以完成跨函数的分析。

5.5.10

  • 与黄实秋对当前的cfg数据结构进行改进
  • 做模块过滤方面工作
  • 对原来的代码的结构方面整合
  • ZRY_ISSUES

4.28.10

  • gcc源代码阅读
对gcc中cfg相关的数据结构以及操作作了较为详细的阅读,详见Holmeszry:GCC_CFG_NOTE
  • 与黄实秋对当前的cfg数据结构进行改进
  • 静态补全部分的基本块构建以及cfg生成
目前继续做基本块构建
  • 了解程序切片具体实现的手法

4.21.10

  • 关于栈的模拟
耿标对于嵌套调用的处理是
  1. 基于api调用识别,对所有api调用都进行手动的栈平衡。比如说我上次所举的例子,耿标的反编译系统会首先识别出调用的是GetCurrentProcessID这个api,然后得到其参数大小,在进行手动平衡。
  2. 由于有的函数调用是通过函数指针,所以要对内存内容进行推断,这对于静态来说尤为困难,这点我与耿标讨论过,耿标觉得手段过于复杂,讲也讲不清楚,假如实现起来会耗费大量的时间和精力,所以暂且搁置。
  • gcc源代码阅读
  1. gcc的主体框架也是通过首先建立一张call graph对调用关系进行表示然后再在其上分别建立cfg,call graph 也是以二叉树的形式存在
  2. gcc的cfg也是以有向图的方式,以basicblock为单元构建
  • 静态补全部分的基本块构建以及cfg生成
目前正在做基本块构建

4.14.10

  • 准备论文presentation
  • 继续进行对栈的模拟
目前用函数识别的手段处理之前的问题会有新的问题
栈模拟的问题及成因推断
  • 开始CFG构建

4.7.10

  • 准备开题答辩
  • 继续进行对栈的模拟
目前已经基本完成对栈行为的模拟,绝大多数的栈行为推断已经达到准确,但是仍然有一些情况是不能准确识别的,详细请见
栈模拟的问题及成因推断
  • 对关于程序切片的新的想法的可行性及有效性进行研究。

3.31.10

  • 写开题报告;
  • 阅读各类文献对动静分析的具体手段做出更加具体的定位;
  • 通过文献和各种资料的阅读认为目前系统亟需改进的地方
1.完整的API滤过机制
目前我们所完成的系统并没有一个完整的API滤过机制,我们需要建立一张包含KERNEL32.dll,user32.dll,ntdll.dll中大多数API的污染传播行为表,否则对这些系统库中的行为进行盲目的跟踪只能使得整个系统更加复杂;
2.更有目的性的识别策略。
目前的漏洞识别策略包含了
a.jmp,call类的控制转移污染
b.rep movxs块搬移
c.strcpy,strcmp等字符串处理API
...
目前的漏洞识别策略太为广泛,缺乏针对性,从汇编层到api层的策略使得我们很难把握所针对的漏洞的特性并作出相应对策。我认为我们可以将工具定位为专门针对溢出漏洞的工具,着重对strcpy,strcmp等字符串处理API,这样对于我们的动静结合与符号分析都显得能够有的放矢,否则针对各种各样的,遍地都是的jmp语句作出针对性强的分析手段十分困难。

3.9.10

  • CFG构建

1.Call_Graph构建

a.通过跟踪所有的栈操作来模拟堆栈,以解析call-ret对应关系,主要有以下三类栈操作
push,pop,call,ret等系统推压栈操作;
add esp 04h,add esp eax等算数操作
pop esp
b.使用树形结构来建造Call_Graph。

2.函数内CFG构建

目前已经完成了路径的补全,现在所需要的是将补全的路径和动态路径结合起来并以CFG的形式表现出来。
  • 项目报告动静结合部分

File:PA COMBINATION.rar

1.15.10

  • 了解当前反汇编的研究现状与趋势
  1. 大多数论文都是通过对二进制代码的研究来做安全相关的,做反汇编的论文比较少,也比较老。
  2. 仅有的一些也一般都是针对特定问题,算法,而很少有系统级的。

1.13.10

12.31.09

上面很多问题感觉是因为静态分析得太深而造成的,所以除了上面提到的问题,以后还有这些东西要做:
  1. 想个办法做到略过值得信任的库调用,可以通过检测模块信息做到,但是现在问题就是只能检测到进去,却不知道怎么检测到出来,假如还是用现在的静态跟踪的话就达不到提高效率的结果了。
  2. 要是能够检测到回到已知代码就能够终止也能够大大提高静态检测效率(比如在目前CFG的结构及问题里面提到的冗余会减少很多),但是具体怎么做还需要多想想。

12.23.09
1.通过对源代码的调查,remove return 的过程确实是在dynamo读入basic block 和 trace之后完成的,所以对于静态代码并无影响,可先忽略。
2.静态路径补全在实际过程中遇到了会跑到??的结果,无法解析所遇到的二进制代码,具体什么原因还在调查。
3.了解了下 thin slicing。
12.16.09
1.已经去掉了dynamoRIO里面的return优化,然而从输出文件中看虽然return已经恢复了许多,但是在100个call中有大约1个还是找不到对应的return,具体什么原因还得再调查下。
2.已经完成静态分析的大多数工作,等call-return-matching做完稍作补充就能够完成。
3.最近看dynamoRIO的代码,发现dynamoRIO很有可能只是对动态执行的那部分代码做了return优化,是在读进标准块之后才做去掉return的工作,假如是这样,那么就不需要将return优化去掉也可以完成静态分析,还得在研究研究代码。


时间 工作 补充 具体进度
11.18.09 1.对指令进行分析,尽量完善补齐路径,除return以及分支指令以外,分析尽可能多的路径

2.修改论文.

a.已经可以完成对每个分支点没有得到执行的那一条路径进行跟踪,但是有些细节仍存在问题。

b.路径的跟踪现在止于所有控制转移

11.4.09 1.对每个分支点进行分析,得到并没有得到执行的另一条路径。

2.准备论文讲座

1.dynamoRIO是纯动态分析的,其给出的接口中没有发现任何能对静态代码进行观察或是控制的,只能对其实际上读进来的basic block进行处理,也就是只能对实际要运行的代码进行处理。

2.根据上面的情况,现在在我看来有3条路:
a.先通过解析分支条件(比如用bddbdd),再用动态的方法来跑到原先没跑到的地方;
b.使用其他反汇编工具来补充这一不足;
c.自己通过二进制码来找。(万不得已而为之....)

10.21.09 1.根据对输出文件的调查,dynamoRIO会出现莫名其妙,并未出现的call(与ollydbg作参照),这点使得试图通过做调用栈变得不怎么现实,目前暂且考虑只跟踪分支跳转点,并通过return地址来做调用关系处理,来简化图,先做着看看效果;

2.api滤过的工作由于DynamoRIO只能跟踪native api,所以只能滤过native api,目前考虑能否在模块级上做一些简化,问题在于模块级的简化相对于函数级来说,没有参数及返回值,所以数据依赖关系难以跟踪,对于污染点跟踪来说有些难度,需要进一步研究。

10.14.09 1.调查做控制流图中出现的call-return不符问题。

2.滤过loadlibrary以及其余无关过程

1.根据对输出文件的调查,dynamoRIO会出现莫名其妙,并未出现的call(与ollydbg作参照),这点使得试图通过做调用栈变得不怎么现实,目前暂且考虑只跟踪分支跳转点,并通过return地址来做调用关系处理,来简化图,先做着看看效果;

2.api滤过的工作由于DynamoRIO只能跟踪native api,所以只能滤过native api,目前考虑能否在模块级上做一些简化,问题在于模块级的简化相对于函数级来说,没有参数及返回值,所以数据依赖关系难以跟踪,对于污染点跟踪来说有些难度,需要进一步研究。

9.30.09 1.尝试运用DynamoRIO现有API做CFG 9.24: 目前工作主要是做basic block 的标记,目前看来可以以basic block的第一句指令的地址作为basic block的ID

9.25:以目前的结果看来经过的basic block太多,必须跳过一些api来简化结果
9.27: 我建立调用堆栈,push所有的call,pop所有的return,但是以现在的试验看来,会出现return多于call的情况,太怪异了,还得研究下怎么回事

9.24.09 1.完成污染源定位部分的移植工作。
2.尝试运用DynamoRIO现有API做CFG
3.准备论文
9.10:Derek Bruening的邮箱貌似不公开,不然能发邮件问问他就好了

9.12: 采取decode 获得sys_num的手法只能截获native API,其他的是没sys_num的,所以两条途径:
a.改为截获消息或其他途径
b.截获目标在ntdll中调用的函数

9.10:目前的污染源定位出现的问题有两点:
a.在拦截部分WINDOWS API时出现问题,为什么有的API没问题,有的就有呢,个中缘由,还得好好思索思索;(见补充)
b.DynamoRIO提供的dr_open_file不能创建文件,这一点与他的Document上面写的不一样,不知道是我写的代码的问题还是他写的代码的问题,不过这一点现在可以用直接调用WINDOWS相应API解决,不过假如这个问题不解决,不但会影响效率,也会影响准确率.希望能够快点解决。

9.11:完成论文阅读和相应准备
9.13:就目前情况看来最可能的方法就是截获native api,这样的话就不能沿用以前的污染源确定方法,需要全部重做
9.16: 污染源定位部分完成.

个人经验总结

关于我的deductive dynamic approach的想法
我的ISSUES
栈模拟的问题及成因推断
GCC中CFG构建学习笔记
API调用识别
调用图构建进度

Personal tools
Namespaces
Variants
Actions
Navigation
Upload file
Toolbox