工作笔记

最新推荐文章于 2021-01-10 01:18:13 发布

silence_stone

最新推荐文章于 2021-01-10 01:18:13 发布

阅读量489

点赞数

文章标签：工作

本文链接：https://blog.csdn.net/silence_stone/article/details/45150467

版权

工作笔记专栏收录该内容

2 篇文章 0 订阅

订阅专栏

2015-4-20

ctags的使用：ctags -R --fields=+iaS --extra=+q

使用gun cflow列举函数的调用关系，如:cflow pngtest.c -T，详细的可以参看cflow --help。

存在的疑问，在不存在调用关系的函数之间如何确定其出现的前后顺序？如果采用函数所需的参数来确定的话，存在一个问题，如libpng中，png_create_read_struct_2和png_create_read_struct都可以完成png_structp read_ptr的初始化，那么该如何选择呢？

2015-4-22

阅读论文《Industrial Application of Concolic Testing Approach:A Case Study on libexif by Using CREST-BV and KLEE》这也是对一个lib库进行检测，它使用了三种工具：CREST-BV 、KLEE、Coverity Prevent。在对测试对象的选择上，使用了lib库自带的test-mnote.c，在思路上也没什么新的东西，这片文章在最开始的时候就说是对exif中的maker note tags进行检测，这是很有针对性的，前期应该做了很多相应的工作。在检测结果的对比上，作者得出的结论是CREST-BV优于KLEE，主要表现test case的生成速度和覆盖率上。对test case的生成速度上的差别，文中给出了解释：klee在检测的时候，不仅检测了目标程序，而且还检测了目标程序调用的c库；另一个klee支持符号化的数组，对这些数组的操作会增加求解难度。文中提到test-mnote.c中使用的函数为206个函数，libexif中函数总数为238，调用比达到了86.5%，这个比例还是很高的。文中在对CREST-BV和Coverity Prevent的结果进行比较的时候，提到了Coverity Prevent报了一个bug，而CREST-BV没有报，因为test-mnote.c没有调用exif_loader_get_buf()这个函数。所以在使用lib库自带的程序对lib进行测试的时候，存在不充分。这个问题该如何解决呢？？？？？

2015-4-23

阅读论文《Heuristics for Scalable Dynamic Test Generation》。这篇论文主要描述了三种路径选择算法，并对算法的性能进行了比较。

Bounded Depth-First Search算法，根据程序的cfg，从最开始的地方往下走，遇到第一个分支（如：l1和l2为一对if的两条路径，如果最开始选择了l1,在现在就强迫选择l2）进行反向选择，得到下一条路径。

Control-Flow Directed Search算法。先要确定一条未被执行到的指令（如l1），然后从l1延着cfg回溯，没经过一个有两条路径的节点时，设置该节点的权值，从1开始，每次增加1.后面根据权值的大小作为路径选择的依据（小优先）。

Uniform Random Search算法，和Bounded Depth-First Search算法有些相似，只不过不是每次遇到分支节点都会强迫反向选择，而是采用50%的概率决定是否反向，所以在理论上，如果全反向，则变成了Bounded Depth-First Search算法。

Random Branch Search算法，这个算法像Bounded Depth-First Search和Control-Flow Directed Search的一种折中，它不是从前到后或者从后到前，而是随即选择一对有分支的节点，进行反向选择。

通过实验结果的比较，Control-Flow Directed Search算法表现最优。

2015-4-24

阅读论文《Targeted Automatic Integer Overflow Discovery Using Goal-Directed Conditional Branch Enforcement》。该论文介绍了一种整型溢出检测工具，其基本原理是：1、找出程序中所有的malloc，通过污点分析，确定malloc的size是否能够被污染；2、抽取约束条件，通过符号执行，确定到达目标的约束，该约束分为状态约束和路径约束两种；3、使用Z3进行约束求解，生成可触发溢出的输入；4、目标直接路径约束，如果前面不能生成正确的输入，则进行这一步。通过对比种子输入和生成的输入在路径上的区别，将这些区别上的条件加入到约束求解中，再次进行求解，以此类推。导致需要进行目标路径约束，很有可能是因为对输入参数有relevant sanity checks和blocking checks。本文还提到了一种自动打补丁的工具CodePhage,这个是需要源码支持的，是通过分析补丁前的程序和donor application在执行路径上的区别，确定补丁的位置，然后进行修补的（方法不太确定）。后面以Dillo浏览器进行了举例，该浏览器使用了libpng，这个例子是对libpng中数据的检测流程进行了说明，最后，Dillo的漏洞是因为自己代码中错误使用了检测条件导致的，和libpng没什么关系，libpng的数据整型溢出检测是很完备的。第三章Goal-Directed Conditional Branch Enforcement Algorithm，未完待续。。。。。。