分享一下我的漏洞挖掘经验

    最近看到了一篇 Google 的模糊测试文章，发现其模糊测试的方法与我的思路有相似之处，也触发我个人想做一次总结和分享。

    在进行漏洞挖掘时，我主要专注于Windows内核和应用层的模糊测试，尚未在其他方向进行太多拓展。因此我想分享一下对模糊测试 Windows 内核的经验。

    目前，Windows 内核的模糊测试缺乏有效的覆盖率反馈工具。我的模糊测试方法是基于对内核代码的理解和逆向工程来打造针对性的模糊测试工具。代码路径和覆盖率的提升主要依赖于我对某些模块的逆向和深入理解，都是苦功夫，没有太多高级技术。

我的模糊测试框架大致分为以下几个步骤：

1. 构造模糊测试底座

• 通过 MSDN 文档理解相关模块的架构，掌握相关函数的特性和参数意义，以达到能够正确调用某些函数的目标。

• 通过逆向工程和调试驱动代码，深入理解具体系统调用（syscall）的业务实现逻辑。

    通过上述两步，构建一个模糊测试框架底座。这个底座对一些非透明结构有所了解，能够正确调用相关函数，并且具有完整的 API 调用链。它可以将参数正确地传递给内核，使内核能够正确解析并实现对应的业务逻辑。总之，这个底座能够正确调用某些 API。

2. 选取相关特性或函数进行模糊测试

    在第一步的基础上，对相关模块已经比较熟悉，接下来就可以进入模糊测试阶段。一个模块通常包含许多特性和对应的一系列 API(比如对NT模块熟悉了，选取ALPC的函数进行FUZZ)。基于以下方法选取想要进行模糊测试的特性/函数：

• 基于 MSDN 了解的原理：参考 MSDN 文档中提供的信息,根据函数名称、函数特征和函数原理进行选择。

• 公开的 PoC 学习：研究公开的POC代码,选定模糊测试方向。

• 驱动文件代码理解：通过逆向分析驱动文件的代码来确定方向。

• PoC 分析/敏感 API：通过代码审计查找溢出类漏洞和信息泄露问题，回溯以确定要模糊测试的函数。

3. 变异

变异部分我将其分为四个部分：

参数模糊测试

• 针对单个函数的参数进行局部变异，验证是否可能引发崩溃。除了网上公开的一些参数变异方式外，更多地涉及基于函数特性的参数变异。

单函数模糊测试

• 复杂的函数在内核中通常涉及线程池、锁竞争、全局内存的申请和释放等操作，有时仅对一个函数进行模糊测试也可能会在内核中引发崩溃，此处可以结合参数变异进行fuzz，也可结合函数特性进行fuzz。

多函数关联模糊测试

• 一个 C 函数的成功执行往往涉及 A->B->C 的调用链，而 C 函数的实现通常在内核中。如果有 D 函数和 E 函数与 C 函数的业务逻辑存在交互，那么这些函数之间的关联性可以从锁、内存等角度进行模糊测试，通常只需要正确调用即可。

系统特性模糊测试

• 这类特性是基于偶然发现的漏洞经验总结。调用一个系统调用（syscall）在内核中可能涉及多种业务实现，某些函数可能会与内核线程的共享变量进行交互。例如，SubmitCommand 这类函数将任务提交到内核，内核以线程池的形式处理任务，某些干扰可能会导致任务崩溃或失败。这类模糊测试更多是基于对某个模块深入研究后得出的经验。

逆向->提升覆盖率，加深代码路径

• 通过逆向和调试去辅助模糊测试框架可以去深入更多的代码路径，比如不同的flag会走走入不同的分支，但是每个分支可能有不同的检查要通过，这些都需要处理，其次成熟驱动代码的实现往往都有一套框架，理解模块的实现框架通过梳理数据流增加更多的覆盖率，总而言之下苦功夫去加深探测的深度，我在所熟悉的模块到后期基本看一眼就知道大概的实现逻辑。

• 有个小tips，如果一些检查不知道怎么过，直接硬patch掉也是没问题的，只要是合理的崩溃就会被认可。

    总之就是形成正确调用->模糊测试->逆向理解的闭环，多读blackhat的paper和优秀文章，就能挖出漏洞，毫无疑问我做的这些工作挺苦逼的，期望有更优秀的工具和方法可以辅助闭源内核的漏洞挖掘。

    以上就是我在一年多时间内挖掘到大约 30 个内核bug的经验和总结，希望对大家有所帮助。

参考:

https://googleprojectzero.blogspot.com/2025/05/breaking-sound-barrier-part-i-fuzzing.html

原文始发于微信公众号（xiaoliangliu）：分享一下我的漏洞挖掘经验