Mocov论文概要

标题

Mocov: Model Based Fuzzing Through Coverage Guided Technology
Mocov:一个基于覆盖率引导的fuzz模型

1. 摘要

论文观点:盲目的随机的fuzz很难发现隐藏比较深的bug。所以提出了Mocov,一种基于代码覆盖率引导的fuzz技术,该技术借用了插桩和实时反馈来避免盲目性,以此来发现隐藏较深的bug。

2. 概述

Mocov的结构图
Mocov instruments the source code of the target program, including the function of getting and saving the coverage information, then compiles the program using the address-sanitizer compilation option to detect the error while the program is running. The error message will be saved in a file.
mocov在源代码中对获得和保存函数的覆盖率信息进行插桩,然后对这个程序进行编译,通过address-sanitizer
汇编探测程序的错误,这些错误信息将会保存在一个文件中。

Mocov uses an adapter to send and receive data between fuzzing system and target program. This design allows loose coupling between the target program and Mocov.
mocov使用一个adapter在fuzzing系统和目标程序之间发送和接收数据。这样的设计是的目标程序和mocov能解耦合。

Mocov detects if a new coverage file is generated using communication interface
provided by the target system. If a new coverage file generated, then Mocov analyses
the path coverage information to see if a new basic block occurred, if occurred, the seed
data will be saved as the candidate and be added to a queue where all the candidate seed
data is arranged in terms of weights. Mocov chooses the first candidate seed data in this
queue each iteration.
如果发现一个新的coverage文件,mocov分析路径覆盖信息,以此来判断是否有新的路径被发现。如果有,则种子数据将被保存,并根据权重添加到候选队列。迭代时,mocov将从queue中取出第一个种子。

After choosing the seed file, Mocov analyses the seed data using data model, if it
can be properly parsed, then mutates the seed using the default mutation strategy of
Peach. If it fails, Mocov mutates the seed using the random mutation strategy, including
sequential bit flips with varying lengths and stepovers, sequential addition and subtrac‐
tion of small integers, sequential insertion of known interesting integers.
选中种子之后,mocov通过data模型分析这个种子。如果能进一步处理,这个种子将通过Peach策略进行默认变异。如果不行,mocov通过随机变异策略,包括序列的bit翻转,加减法,插入等。

3. 设计

3.1 插桩

插桩方式和AFL相同,都是通过bitmap实现,插桩代码如下

int seq_byte = position/8;
int seq_in_byte =1<<(position%8);
blocks[seq_byte]=blocks[seq_out_byte]|seq_in_byte;

3.2 覆盖率分析

如果被测试的seed检查到能访问到新的区域,这个seed保存到候选队列进行变异。
seed插入到队列的位置按照seed的权重weight决定,weight的计算方式如下:

weight = num\_cov / (seed\_size * exec\_time * numexec)
num_cov: the number of the executed basic blocks
seed_size: the size of the seed
exec_time: the time that the seed was processed in the program.
num_exec: the number of times current seed was executed

3.3 seed变异

从队列中取出第一个seed进行变异,变异的数量有权重决定,权重越大,产生seed越多。
如果选出来的seed能被pit file处理,则通过peach策略进行随机的变异;如果不能被pit file处理,mocov会将这个seed进行变异。

4 实现和评估

略.

5. 相关工作

这个部分比较有意思,相当于一个综述,写的很全,可以看看拓展思路。因为较长,而且本身就是一两句话描述一个东西,比较精简,就不摘录了。
相关工作

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
测试的主要评测方法 简介   测试的主要评测方法包括覆盖和质量。   测试覆盖是对测试完全程度的评测,它建立在测试覆盖基础上,测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。   质量是对测试对象(系统或测试的应用程序)的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求(缺陷)的分析的基础上。 覆盖评测   覆盖指标提供了"测试的完全程度如何?"这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之,测试覆盖是就需求(基于需求的)或代码的设计/实施标准(基于代码的)而言的完全程度的任意评测,如用例的核实(基于需求的)或所有代码行的执行(基于代码的)。   系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的,指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。   如果需求已经完全分类,则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如,如果已经确定了所有性能测试需求,则可以引用测试结果来得到评测,如已经核实了 75% 的性能测试需求。   如果应用基于代码的覆盖,则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。   两种评测都可以手工得到(公式如下所示)或通过测试自动化工具计算得到。 基于需求的测试覆盖   基于需求的测试覆盖在测试生命周期中要评测多次,并在测试生命周期的里程碑处提供测试覆盖的标识(如已计划的、已实施的、已执行的和成功的测试覆盖)。   在执行测试活动中,使用两个测试覆盖评测,一个确定通过执行测试获得的测试覆盖,另一个确定成功的测试覆盖(即执行时未出现失败的测试,如没有出现缺陷或意外结果的测试)。   这些覆盖评测通过以下公式计算:   这一关于测试覆盖的陈述是有意义的,可以将其与已定义的成功标准进行对比。如果不符合该标准,则此陈述将成为预测剩余测试工作量的基础。 基于代码的测试覆盖   基于代码的测试覆盖评测测试过程中已经执行的代码的多少,与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流(语句、分支或路径)或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效,例如,数据元素在使用之前是否已作定义。   基于代码的测试覆盖通过以下公式计算: 质量评测   测试覆盖的评估提供对测试完全程度的评测,在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标,所以在这种环境中,缺陷被标识为一种更改请求,该更改请求中的测试对象与需求不符。   缺陷评估可能建立在各种方法上,这些方法种类繁多,从简单的缺陷计数到严格的统计建模不一而足。   严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性,并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模,这是一个活跃的研究领域。由于该类型的评估缺乏工具支持,所以应该慎重平衡成本与其增加价值。   缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。   对于缺陷分析,常用的主要缺陷参数有四个:   • 状态:缺陷的当前状态(打开的、正在修复或关闭的等)。   • 优先级:必须处理和解决缺陷的相对重要性。   • 严重性:缺陷的相关影响。对最终用户、组织或第三方的影响等等。   • 起源:导致缺陷的起源故障及其位置,或排除该缺陷需要修复的构件。   可以将缺陷计数作为时间的函数来报告,即创建缺陷趋势图或报告;也可以将缺陷计数作为一个或多个缺陷参数的函数来报告,如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。   例如,预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值,在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数,以允许检测"较差的模块"、"热点"或需要再三修复的软件部分,从而指示一些更基本的设计缺陷。   这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷,这是因为某些缺陷可能是扩展请求,超出了项目的规模,或描述的是已报告的缺陷。然而,需要查看并分析一下,为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷,这样做是有价值的。 缺陷报告   Rational Unified Process 以三类形式的报告提供缺陷

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值