代码

本文为Fuzzing like a caveman学习笔记，学习这个系列文章主要出于两个目的：一是为了学习fuzzing相关知识，二是为了学习go语言。因此文章中的代码使用go进行了改写。

https://github.com/mkttanabe/exif

首先选取一个jpg格式的sample文件，从这里下载的Canon_40D.jpg

然后分别采用bitflip和magic number替换的方式生成变形的用于测试的图片文件。其中为了保证文件的格式不变，需要排除掉文件开头的0xFFD8以及结尾的0xFFD9者四个字节

由于go语言以及个人编程习惯的原因，采用的方法与原文有所差别：

bitflip

该方法会随机选取所有字节中1%的字节，再随机选取其中的一位进行反转。

运用一点数学的知识，不使用原本文章中将字符串转换为数组再转回字符串的方式。

该函数完整代码如下：

magic number

该方法源自GynvaelColdwind的‘Basics of fuzzing’ stream，将字节设置为特殊的，容易引发溢出的数值。这样如果程序中正好存在针对这几个字节的数值操作，就可能会发生溢出。

原文章的方法过于冗长，我直接把magic number做成一个二维数组，在通过随机的方式确定替换位置之后，搜索二维数组进行替换。

该函数完整代码如下：

编译生成可执行文件gcc -o exif sample_main.c exif.c，使用exec.Command执行命令并获得输出，利用panic, defer机制处理出现的错误，并将导致崩溃的图片保存在crashes目录下。

结果发现不管能不能成功，函数都会返回错误信息，然后所有测试图片都被保存到了crashes目录下

查看源码发现，在sample_main.c文件中，main函数的返回值是由createIfdTableArray函数返回的result数值决定的，大于0表示程序处理的图片正常，小于0则是发生了错误，但无论result是何值，都表示程序正常识别出了图片中可能存在的错误并执行完成。

可是如果返回值不为0，系统会认为程序发生错误，因此我写的代码会认为所有图片都可以导致崩溃

于是修改main函数，将返回值固定为0，然后再抓取出现的错误，进行1000次迭代后，找到了24个crash的图片。

该函数代码如下：

上面代码在执行的时候可以看到遇到的错误返回值都是0xc0000005

接下来使用Address Sanitizer分析crash，需要安装llvm，然后执行

如果出现Macro definition of vsnprintf conflicts with Standard Library function declaration的报错，需要删除exif.c中的#define vsnprintf _vsnprintf

得到exifsan.exe之后，用它测试一下之前得到的crash图片：

确实可以得到具体的错误信息，之后我又多测试了几个文件，发现我遇到的大多都是access-violation on unknown address 0x000000000000，而不像文章中的那样有很多heap-buffer-overflow

因为crash信息并不多，而且考虑到之后进一步学习可能还会用到这些信息，所以我在统计的时候没有像原文中那样对信息进行提取，而是全部输出到了一个文件中，方便后续使用。如果要提取的话，可能要用到正则表达式，这部分内容我不太确定，因为我的go语言学习还没有看到interface的部分，所以对于输出的处理可能会有想不到的地方。

至此，第一篇文章学习结束

这里我尝试把bitflip中原本存在的nflips计算放到了循环外部，最终result计算中的乘方操作使用一个mask数组代替，然后像文章中一样全部使用bitflip执行1000次循环，性能优化了2秒左右。但是即使是这样运行时间也在15s~，我看了一下原文章中的性能，100,000迭代才执行了256s！！！

—>因为要fuzz新的目标，转战到kali上之后，效果提升了10倍，变成了1.5s，执行100,000次迭代，花费时间为86s，

在进行fuzz之前，我在此对代码进行了一些修改:

统计输出的错误信息，只在该错误信息第一次出现的时候打印出来

但是最终没发现什么bug

在这个系列文章中的第四篇，作者提到了bitflip和byte overwriting的区别：

如果只是随机反转字节中的一位，那个一个字节可以修改的数值只有8中可能，而修改字节则可以将其修改成其他任意的255个值

因此重新写一个新的函数，不再采用随机反转字节中一位的方法，而是直接随机修改一个字节的值。

第四篇文章的其余部分使用一个示例漏洞程序说明了在fuzzer中引入code-coverage的重要性，改写后的go代码：

使用byteOverwrite方法，设置flipPercent值为0.02，迭代100,000次，漏洞程序只完成第一道检查，测试得到crash的图片8张；对比文章中1,000,000次迭代-88张图片的结果，两者的比例是一致的。

只做第一道检查，fuzz找到漏洞的概率≈8/100000=0.008%，如果想要通过两次检查，找到漏洞的概率成指数级下降，只有0.00000064%

因此在不检查code-coverage的情况下，完全随机进行fuzz，能够找到漏洞的概率极小

鉴于我最近对于go的熟练度有所提升，因此在学习文章内容之前，我先对之前自己写的代码进行了整理。把和实际的模糊测试工作有关的代码封装在了fuzzer包中，保留了SetConfig和Run接口（和go中的interface概念无关）

最终外部的调用代码变成了这样：

通过SetConfig设置迭代次数，模糊测试方法以及执行的命令，然后调用Run开始进行测试。

其中执行的命令那里封装的还不是特别好，mutated.jpg这个文件名还暴露在外面，因为之后的内容会放弃写入mutated.jpg文件，因此这部分内容还会有很大的变动，所以就没有解决这个问题

整理后的代码可以很清晰的看到整个模糊测试的流程：

每次迭代分为三个步骤：生成变形后数据，将变形数据写入文件，执行模糊测试

因为在对目标程序进行模糊测试的时候，采用

的方式执行命令，因此每次都需要把变形后的数据写入到文件，然后再由目标程序进行加载。上述流程在每次迭代都会发生，这也是文章中提到的导致性能下降的主要原因之一。

除此之外，文章中也提到了使用strace跟踪程序系统调用情况的方法，在使用strace检查我写的vulfunc的时候，在执行openat(AT_FDCWD, "./Canon_40D.jpg", O_RDONLY|O_CLOEXEC) = 3之前，程序执行了大量系统调用（有158行，出于篇幅考虑，不再贴出）。

因此文章中提到了利用调试器建立快照的方法。

原文提供了一篇关于ptrace的参考资料(④)，同时我找到了一篇golang调试器的文章(③)。但是参考资料③是2017年写的，对于go这门新语言来说有些过时了，原本syscall包的功能已经被移植到了sys包中，因此我同时参考了delve的源码

按照文章中的方法，需要实现一个调试器，使用调试器：

因此这个调试器需要实现的功能有：暂停程序执行、设置和取消断点、读写内存、读写寄存器、继续执行程序

这个功能的实现很简单，只需要将exec.Command的SysProcAttr属性中的Ptrace设置为true就可以：

根据文档，该操作相当于子进程执行了ptrace(PTRACE_TRACEME)

通过查找文档，找到了函数PtraceGetRegs：

测试读取RIP寄存器的值：

多次执行得到的RIP数值是一样的：

从IDA中检查vulfunc文件，可以看到地址0x45CB60就在程序开始的位置：

同理，如果需要写入寄存器，就使用函数PtraceSetRegs:

通过查找文档，找到函数PtracePeekData：

在Debug函数中添加如下代码段：

得到结果：

得到0x48d8e0处的字节值为0xeb，和IDA中显示的一样。

同理，写内存可以通过PtracePokeData。

<aside>
注意：后续测试时，发现这个方法进行大段内存读写很费时间。因此只在设置/恢复断点时采用如上方法修改内存。而在拍摄/恢复快照时选择使用ProcessVMReadv和ProcessVMWritev

func ProcessVMReadv(pid int, localIov []Iovec, remoteIov []RemoteIovec, flags uint) (n int, err error)
func ProcessVMWritev(pid int, localIov []Iovec, remoteIov []RemoteIovec, flags uint) (n int, err error)

</aside>

断点的原理就是将原本的指令修改成0xCC。所以需要1)确定设置断点的位置，2)读取该位置的数值并保存，3)将数值修改为0xCC。

因此只需要使用上面提到的读写内存的功能，就可以实现设置和取消断点功能。

但是这里有一个trick需要注意，假设想要在0x1000处设置断点，将指令修改为0xCC之后，程序继续执行并中断，此时的RIP值应该是0x1001，如果想让程序继续执行，我们必须先取消断点，并把RIP减1，让程序可以继续从0x1000开始执行。这个trick会在CancelBreakPoint中实现。

断点位置的确定在之后说明，先给出函数代码。设置断点：

取消断点：

通过查找ptrace文档，找到了PTRACE_CONT信号，对应golang中的：

这个函数会重启中断的程序。

之后使用Wait4函数接收信号，

两者结合实现程序的继续执行。

至此可以得到Debug函数：

输出为：

现在只需要替换掉测试的图片数据

我不清楚原文是怎么确定的断点地址，从源码看断点是硬编码到代码中的，并且在启动子进程之前取消了ASLR。

我考虑先通过静态分析确定断点代码距离程序起始位置的偏移，然后在程序起始位置中断，获取RIP的地址，再加上偏移，就可以得到断点地址了。

上面已经确定了RIP的值是0x45cb60。

一开始我打算在循环开始之前设置断点，后来发现这样设置不太方便替换测试图像数据。

在IDA中找到函数check的调用位置，发现由于这个函数太短，已经被优化掉了：

注意到在最终的cmp语句中，其中的一个比较对象sil来自于main_checkVal再加上偏移值，它对应的就是程序中的checkVal slice数组。

因此bl中保存的就是图像数据，向上溯源，寄存器rdx中保存的就应该是测试图像数据的起始地址。

如果继续向上溯源，rdx ← [rsp+88h+var_30] ← rax ← ReadFile。

因此最终第一个断点选在ReadFile函数调用结束之后，即0x48D888。

接下来选择第二个断点，因为程序有两个中断点，一个是测试没通过到达的os.Exit()函数，一个是全部测试通过到达的main_vul函数，因此我选择设置两个断点，分别在这两个函数调用之前。断点位置为：0x48da0c和0x48da1b

得到断点位置距离程序起始位置的偏移分别为0x30d28、0x30eac和0x30ebb。

在到达第一个断点后，检查一下寄存器eax指向的地址中保存的数据是不是测试图像：

得到输出：

发现确实是测试图像的前八个字节。

然后需要确定可写内存的地址。使用文章中提到的方法，每次启动得到的内存块地址不同（不知道是不是ASLR的问题，因为我没有处理ASLR）。

我决定直接在程序中获取可读写内存块的地址:

最好的主要功能就是内存和寄存器的备份和恢复，这两个函数比较简单，没什么可说的：

最后对代码的结构又做了一些修改，得到Debug函数：

注意我把所有的断点设置都放在了循环外部，循环内部只完成数据替换，继续执行，以及快照恢复功能。

代码在逻辑上没有问题，但是最终执行失败了，通过检查Continue函数中WaitStatus变量ws的StopSignal()方法的返回值，我发现在循环迭代过程中，每次Continue函数的调用并没有让vulfunc继续执行到达程序结尾处的断点，而是由于urgent I/O condition导致程序中断执行。

之后我在循环中调用了两次Continue函数，强行让程序继续执行到达第二个断点，但是迭代数次之后，程序还是崩溃掉了。

进行了N次尝试，只有一次程序正常迭代测试，没有出现崩溃的情况。

鉴于出现了执行成功的情况，所以我认为代码本身没有问题，但是可能和golang的一些特性有冲突。在github上面找到一个issue，但是不确定是不是有关。

虽然上面的快照方法没有成功，但是覆盖率检查还是可以实现的。

在命令执行后的输出检查中，检查输出信息中是否包含strconv.Itoa(succeedCount+1)+" succeed”信息，如果包含，就将用于生成变形后数据的baseData修改为当前的mutateData，然后继续进行迭代，最终程序在迭代36939次之后成功通过三次测试，到达了漏洞位置。

至此，第四篇文章学习结束

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)