最近打 ctf 的时候感觉有点遇到瓶颈,就来 fuzz 这块看看. AFL 全称为 American huzzy loop,是 Fuzzing 最高级的测试工具之一.这个工具对有源码和无源码的二进制程序均可以进行 fuzz 测试. alf 各位自行安装即可,值得注意的是,在我本机 glibc2.31 的环境下,编译 alf 前要对 AFL/llvm_mode/afl-clang-fast.c修改一下,否则会出现报错,只需把部分内容注释掉即可 输入 afl-fuzz 出现下图即安装成功 我们先看对

关于AFL fuzz AFL fuzz是一个模糊测试工具,它封装了一个GCC/CLang编译器,用于对被测代码重新编译的过程中进行插桩.插桩完毕后,AFL fuzz就可以给其编译过的代码输入不同的参数参数,跟踪被测代码的执行路径,并判定对输入的变异能否触发新的已知或未知执行路径. 某些情况下,你可能不想重新编译被测代码,或者根本没有被测程序的源代码,因此无法用编译的方式插桩.针对这种情况,AFL fuzz提供了QEMU模式,QEMU即“user emulation”的缩写,相当于是黑盒测试,主要

CVE-2009-3895 首先在NVD找到漏洞描述如下: 大致意思是说:libexif 0.6.18 中的 libexif/exif-entry.c 中的 exif_entry_fix 函数中基于堆的缓冲区溢出允许远程攻击者导致拒绝服务或可能通过无效的 EXIF 图像执行任意代码 接下来找到libexif 0.6.18 ,官方在0.6.19版本修复了此漏洞: CVE-2012-2836 同样在NVD中找到漏洞描述: 大致意思:0.6.21 之前的 EXIF 标签解析库(又名 libexif)中

CVE-2019-13288 目前漏洞在正式版本已经被修复,本文章仅供学习Fuzz过程,不存在漏洞利用的内容 这是一个pdf查看器的漏洞,可能通过精心制作的文件导致无限递归,由于程序中每个被调用的函数都会在栈上分配一个栈帧,如果一个函数被递归调用太多次,就会导致栈内存耗尽和程序崩溃.因此,远程攻击者可以利用它进行 DoS 攻击. 练习目的 使用检测编译目标应用程序 运行Fuzzer (afl-fuzz) 使用调试器 (GDB) 对崩溃进行分类 环境构建 环境使用Ubuntu 20.04.2 LT

Fuzzing Apache httpd server with American Fuzzy Lop + persistent mode 小结:AFL主要以文件作为输入进行fuzz,本文介绍如何对网络通信程序进行fuzz.需要对程序做出以下更改: 1.保证程序从命令行支持输入文件参数,也就是从本地文件读取字符串buf. 2.从main函数到被fuzz的函数存在一条路径,fuzz(buf)(即被fuzz的函数)会对buf进行处理.更简单说,afl-fuzz给main函数一个文件,fuzz函数要处

转:http://www.tuicool.com/articles/j2eqym6 小结:找到感兴趣的函数,计算偏移,自动化fuzz. 这是一篇客座文章,作者是乌云二进制漏洞挖掘白帽子 k0shl .其实上个月17号,本文就已经写完了,但是我们一直“捂”到了今天.算是给二进制方向的白帽子的七夕礼物吧 : ) 0x01 什么是 winafl 其实说的 afl-fuzz 大家都不会很陌生, afl-fuzz 是 Linux 用于 fuzz 文件格式,协议等二进制漏洞的神器,而 winafl 则是 a

afl 实战 前言 像 libFuzzer, afl 这类 fuzz 对于 从文件 或者 标准输入 获取输入的程序都能进行很好的 fuzz, 但是对于基于网络的程序来说就不是那么方便了. 这篇文章介绍用 afl 来 fuzz 网络应用程序. 介绍 afl 是一个非常厉害的 fuzz,最近几年炒的火热.它是基于代码插桩来生成测试用例,这样生成的样本就比较的好,而且针对 linux 做了许多性能优化使得速度也非常快. 使用 afl 的常规步骤 如果有源码,用 afl-gcc 或者 afl-clang

前言 前面介绍了通过静态读代码的方式去发现问题,这里介绍两种 fuzz 目标软件的方式. 相关文件 链接:https://pan.baidu.com/s/1l6BuuL-HPFdkFsVNOLpjUQ 提取码:erml 使用winafl winafl 是 afl 在 windows 上的移植版本,这里首先尝试使用 winafl 去 fuzz 一下目标软件中感兴趣的函数. 为了学习 winafl 的使用,可以先写一个 demo 程序来学习一下 winafl 的用法. 示例 为了做示范,这里我们开发

Honggfuzz实战 前言 本文介绍 libfuzzer 和 afl 联合增强版 honggfuzz .同时介绍利用 honggfuzz 来 fuzz 网络应用服务. 介绍 honggfuzz 也是 google 开发的一款 fuzz . 其设计思路 和 libfuzzer 和 afl 类似 ,感觉就是 libfuzzer + afl 的 增强版. 编译 git clone https://github.com/google/honggfuzz.git cd honggfuzz make ho

前言 本文以 libfuzzer-workshop 为基础 介绍 libFuzzer 的使用. libFuzzer简介 libFuzzer 是一个in-process,coverage-guided,evolutionary 的 fuzz 引擎,是 LLVM 项目的一部分. libFuzzer 和 要被测试的库 链接在一起,通过一个模糊测试入口点(目标函数),把测试用例喂给要被测试的库. fuzzer会跟踪哪些代码区域已经测试过,然后在输入数据的语料库上进行变异,来使代码覆盖率最大化.代码覆盖率

一个简单的示例 安装afl wget http://lcamtuf.coredump.cx/afl.tgz tar xfz afl.tgz cd afl-xxx sudo make install 用afl编译程序,以便插桩 ./afl-gcc tst.c -o tst 进行测试 ./afl-fuzz -i testcase -o output/ ./test @@ 指定一个要跑的test程序和输出的output路径即可. 查看是否有插桩符号 readelf -s ./7zDec | grep

ref:https://www.sigpwn.io/blog/2018/5/13/adding-afl-bloom-filter-to-domato-for-fun Adding AFL Bloom Filter to Domato for Fun MAY 13, 2018 So I have been playing with Domato for few weeks now and wrote a blog about it's internals along the way. Unfort

前言 本文主要介绍如果使用 qemu 和 unicorn 来搜集程序执行的覆盖率信息以及如何把搜集到的覆盖率信息反馈到 fuzzer 中辅助 fuzz 的进行. AFL Fork Server 为了后面介绍 afl 的 qemu 模式和 unicorn 模式, 首先大概讲一下 afl 的 fork server 的实现机制.afl 与 fork server 的通信流程如图所示 首先 afl-fuzz 调用 init_forkserver 函数 fork 出一个新进程作为 fork server

模糊测试(fuzz testing)是一类安全性测试的方法.说起安全性测试,大部分人头脑中浮现出的可能是一个标准的“黑客”场景:某个不修边幅.脸色苍白的年轻人,坐在黑暗的房间中,正在熟练地使用各种工具尝试进入某个系统.这种由安全人员“模拟黑客进入系统”的测试方法的确是安全性测试中的一种有效测试手段,名叫“渗透测试”.渗透测试方法完全依靠测试执行者的能力,能力强的“白客”能够发现有价值的安全性漏洞,而不具备很强的攻击能力的测试者就无法有效发现系统中的安全性漏洞.必须承认,渗透测试是一种有效的安全性

Fuzz这个词汇行内的都懂,fuzz工具我就不多说了. 今天,说说fuzz前的准备工作--如何对软件进行修改实现可自动化和无人值守fuzz. 很多软件会有试用期.弹窗.覆盖提示.人机交互等等,这些都会造成无人值守的fuzz平台无法继续. 1.对于 注册激活提醒弹窗,我们可以直接爆破掉验证函数,也可以分析注册流程,写注册机. 2.对于解压缩这种软件可能会出现覆盖提示,如果程序中有设置最好了:如果可以爆破提示框,这样也行,但是对于提示框,选项超级多的时候就麻烦了,分析每个按钮,下拉列表功能,就太麻烦

引言 写这个工具,主要有几个原因: 最近老大在尝试不同视角的测试----健壮性测试,任务下来,所以挽起袖子就开撸了 app很可能因为后端api做了变更,返回了一个异常的值而出现难以预知的问题,健壮性受到碰撞,所以这种测试是有实际价值的 思寒的一篇帖子<基于 fuzz 技术验证移动端 app 的健壮性>我觉得挺好玩,这里要非常非常感谢他提供的思路,从下面的回复也可看出来大家还是比较感兴趣,而他因为遇到一些问题尚未开源,所以我挽起袖子就开撸了 社区里最近用anyproxy的挺多,我想说我们厂应该是

问题定义 app发布后经常容易出现各种诡异的crash, 这些crash固然可以通过各种崩溃分析服务去定位. 但是的确很影响用户体验. 在crash分类中有一类是后端接口引发的. 比如常见的引发app crash的原因 接口自身变更, 接口失效或者超时, 比如用户进地铁 接口格式变更. 字段缺失 接口内容变更, int string格式搞错了. 某些字段原本是有值后来就变成了null 一旦出了问题, 后端背锅或者做兼容是常见的方案. 但是对于app自身来说,也需要加强健壮性测试. 健壮性的英文名

模糊测试(fuzz testing)是一种安全测试方法,他介于完全的手工测试和完全的自动化测试之间.为什么是介于那两者之间?首先完全的手工测试即是渗透测试,测试人员可以模拟黑客恶意进入系统.查找漏洞,这对测试人员的要求比较高.能力强的测试人员可以发现比较多或者高质量的安全性问题,但是如果测试人员的能力不够,可能就不能找到足够多.威胁大的安全漏洞.所有渗透测试对人员能力的依赖性强,成本高,难以大规模的实施. 但是想用完全的自动化来实现渗透测试也不可行,同一套测试用例和方法不可能不加修改的就用在不同

windows 下实现函数打桩:拦截API方式            近期由于工作须要,開始研究函数打桩的方法. 由于不想对project做过多的改动,于是放弃了使用Google gmock的想法. 可是也足足困扰另外我一天一宿. 经过奋战,最终有所收获.闲话少说,開始看看有什么方法. 一.基础准备 1. 函数调用的原理:通过函数名(函数的入口地址)对函数进行訪问,如果我们可以改变函数首地址指向的内存的话,使其跳转到还有一个函数去运行的话,那么就行实现函数打桩了. 2. 方法:对函数首地址出写入

内核 FUZZ 思路 内核 API  函数:是提供给 Ring3 调用,在 Ring0 完成最终功能的函数.这些函数接收 Ring3 传入的参数,如果处理参数的过程存在问题的话,很有可能成为一个内核漏洞.这样的内核 API 函数有很多,例如 SSDT.Shadow SSDT 等.Hook API的代码:很多安全软件为了防御病毒木马,对很多内核 API 进行了 Hook/Inline Hook.然而这些 Hook 内核 API 的代码也存在安全问题.如果对参数的处理不当或内部逻辑的错误,也很有可能