1. 项目概述与核心价值最近在安全研究圈子里关于终端安全软件的内核驱动分析一直是个热门且颇具挑战性的话题。很多朋友想深入理解安全软件如何实现其核心防护功能比如文件监控、行为拦截、网络过滤等但面对复杂的驱动模块往往无从下手。今天分享的这个“逆向火绒安全软件驱动——sysdiag”项目就是一个非常难得的、聚焦于实战的切入点。sysdiag.sys 是火绒安全软件的核心内核驱动文件它承载了绝大部分主动防御和底层监控的逻辑。通过逆向分析这个驱动我们不仅能一窥顶级安全厂商的驱动开发与防护思路更能极大地提升自己对 Windows 内核机制、驱动通信、回调函数、过滤框架等核心知识的理解深度。这个项目的价值远不止于“看懂一个驱动”。对于安全研究人员来说它是学习现代终端安全产品防御体系的绝佳标本对于驱动开发初学者它能提供一个工业级、结构清晰的代码参考对于逆向爱好者则是一个充满细节和技巧的实战演练场。整个过程涉及静态分析、动态调试、结构体恢复、函数逻辑梳理等一系列标准逆向工程流程能系统性地锻炼你的逆向能力。接下来我将结合自己的实操经验为你拆解这个项目的核心思路、关键步骤以及那些容易踩坑的细节。2. 逆向环境与工具链的精心准备工欲善其事必先利其器。逆向分析一个像 sysdiag 这样复杂且与系统深度交互的驱动一个稳定、隔离且工具齐全的环境是成功的第一步。盲目在物理机或主力开发机上操作极易导致系统蓝屏BSOD或环境污染。2.1 虚拟机环境搭建要点我强烈建议在虚拟机VM中完成所有分析工作。这不仅能提供完美的系统快照和回滚功能还能方便地进行双机内核调试。虚拟机软件选择VMware Workstation Pro 或 VirtualBox 都是不错的选择。我个人更倾向于 VMware因为其对 Windows 内核调试的支持更成熟稳定。操作系统版本需要与驱动兼容的系统。根据网络片段提示该项目排除了 XP 以下版本。因此建议安装Windows 7 x64或Windows 10 x64系统。选择 x64 系统是因为现代安全软件驱动基本都是 64 位的且 64 位系统的驱动签名、PatchGuard 等机制更具学习价值。在虚拟机中安装时记得安装 VMware Tools 或 VirtualBox Guest Additions 以提升操作体验。系统快照在安装任何分析工具或目标驱动之前务必创建一个干净的快照命名为“Clean Base”。在后续安装调试器、配置符号路径等步骤后再创建新的快照。这样一旦分析过程中系统崩溃或配置混乱可以迅速回退到可用状态。2.2 核心逆向分析工具选型与配置驱动逆向是逆向工程中的“重工业”工具的选择直接决定了分析效率和深度。静态分析利器IDA ProIDA Pro 无疑是静态反汇编的行业标准。对于 sysdiag.sys 这样的 PE 文件IDA 能出色地完成反汇编、函数识别、交叉引用分析等工作。版本选择建议使用IDA Pro 7.7 或更高版本其对 64 位二进制文件的分析和 Python 3 插件的支持更好。关键配置加载驱动文件将 sysdiag.sys 拖入 IDA 时在加载对话框里处理器类型选择 “Intel 80x86” 家族下的 “metapc”并确认是64-bit模式。符号文件PDB这是提升逆向效率的关键。火绒官方不会提供其驱动的 PDB 文件。我们需要通过其他方式恢复符号信息。一个常见的方法是利用驱动中可能存在的调试信息或通过动态调试获取函数名然后手动在 IDA 中重命名函数、定义结构体。也可以尝试使用工具如pdbdump的变种或基于启发式的符号恢复脚本从驱动文件中提取有限的符号但这成功率不定。更务实的方法是在动态调试过程中将内核调试器WinDbg识别的函数地址和名称同步到 IDA 中。插件准备安装Hex-Rays Decompiler俗称 F5 插件是必须的它能将汇编代码反编译为更易读的 C 伪代码极大降低理解逻辑的难度。此外可以配置IDA Python环境用于编写自动化分析脚本。动态调试王牌WinDbg Preview双机调试要理解驱动的运行时行为、跟踪数据流、验证猜测动态调试不可或缺。对于内核驱动我们通常采用“双机调试”模式被调试的系统Target运行 sysdiag 的虚拟机通过虚拟串口或网络向运行调试器的主机Host你的物理机发送调试信息。Host 机配置物理机从微软商店安装WinDbg Preview。它界面更现代对源码和符号的支持更好。配置符号路径在 WinDbg Preview 的 “File” - “Symbol File Path” 中设置。一个基础的路径是SRV*C:\SymCache*https://msdl.microsoft.com/download/symbols。这会将微软官方符号缓存到本地C:\SymCache目录。对于分析 sysdiag我们主要需要ntoskrnl.exe、hal.dll、ndis.sys等系统模块的符号来理解其调用的内核 API。Target 机配置虚拟机启用调试启动以管理员身份打开虚拟机中系统的命令提示符执行bcdedit /debug on bcdedit /dbgsettings serial debugport:1 baudrate:115200配置虚拟机串口关闭虚拟机系统。在 VMware 的虚拟机设置中添加一个“串行端口”。将其设置为“输出到命名管道”管道名称例如\\.\pipe\com_1另一端是“服务器”模式为“轮询时主动放弃”。这是建立虚拟串口调试通道的关键。启动虚拟机在 WinDbg Preview 中通过 “File” - “Attach to Kernel” - “COM” 选项卡选择之前配置的管道名如\\.\pipe\com_1和波特率 115200 进行连接。连接成功后你会看到调试器中断在系统初始断点这表示双机内核调试环境搭建成功。辅助工具集Process Explorer / Process Hacker用于查看进程、线程、句柄、加载的 DLL/驱动模块。可以快速定位 sysdiag 驱动加载后的设备对象、符号链接以及它创建的内核线程。WinObj (Sysinternals Suite)用于浏览内核对象管理器命名空间。可以查看\Device\和\DosDevices\下由 sysdiag 创建的设备对象这是理解驱动与用户态通信接口的第一步。DriverView (Sysinternals Suite)列出当前加载的所有内核驱动查看其地址、大小、路径确认 sysdiag 是否已加载及其基址。HxD 或 010 Editor十六进制编辑器用于直接查看和编辑二进制文件验证文件头、节区等信息。注意在虚拟机中安装和运行火绒安全软件或仅加载其驱动时请务必在完全可控、无网络连接的环境中进行并明确仅用于学习研究目的遵守相关法律法规和软件许可协议。3. 驱动文件初步分析与结构探索拿到 sysdiag.sys 文件后不要急于用 IDA 打开就一头扎进汇编代码。先进行一轮“体检”能帮助我们建立宏观认识。3.1 文件基础信息探查首先使用file命令Linux/Mac或通过 PE 工具查看其基本属性确认它是 64 位的 PE 文件Driver。使用dumpbin /headers sysdiag.sysWindows SDK 工具可以获取更详细的信息子系统应为 Native (Driver)。入口点DriverEntry 函数的 RVA相对虚拟地址。节区Sections查看.text代码、.data初始化数据、.rdata只读数据可能包含字符串、导入函数名、.pdata异常处理信息等。驱动通常还会有.INIT段存放初始化后即可丢弃的代码。3.2 静态导入表IAT分析驱动通过导入表调用其他内核模块如 ntoskrnl.exe, hal.dll, ndis.sys提供的函数。分析 IAT 是理解驱动功能范围的第一步。 在 IDA 中查看 “Imports” 窗口。你会看到一系列来自ntoskrnl.exe的函数例如IoCreateDevice,IoCreateSymbolicLink表明驱动会创建设备对象供用户态通信。PsSetCreateProcessNotifyRoutine,PsSetLoadImageNotifyRoutine表明驱动注册了进程/模块加载回调这是进程行为监控的基石。ObRegisterCallbacks对象回调用于监控进程/线程句柄操作。CmRegisterCallbackEx注册表过滤回调。FltRegisterFilter如果看到这个说明驱动可能使用了文件系统微过滤驱动Minifilter框架进行文件监控。NdisFRegisterFilterDriver来自 ndis.sys表明可能涉及网络过滤NDIS Filter Driver。从网络片段提到的“初始化6个Ndis读写锁”和“初始化2个资源变量”来看ndis.sys和ExInitializeResourceLite、ExAcquireResourceExclusiveLite等同步函数肯定会出现在导入表中。这些信息为我们后续分析指明了重点方向。3.3 字符串与常量挖掘在 IDA 的 “Strings” 窗口或使用Strings工具中搜索可读字符串。你能发现很多有价值的信息设备名和符号链接如\Device\HrSysDiag、\DosDevices\HrSysDiag这验证了驱动创建的通信接口。调试输出信息驱动可能使用DbgPrint输出调试信息字符串里会有诸如“[HrSysDiag] DriverEntry started”、“Failed to create device”等这些是理解驱动执行流程和错误处理的宝贵线索。内部函数名或变量名前缀有时字符串中会包含类似g_pHrMonitorList、HrFilterIrpDispatch这样的名称这可能是内部全局变量或函数名的一部分可以辅助我们重命名。IO控制码IOCTL定义驱动与用户态通过DeviceIoControl通信控制码CTL_CODE的定义字符串可能以IOCTL_或HR_IOCTL_为前缀出现或者你能找到其对应的十六进制值如0x222000。在 IDA 中交叉引用这些字符串或值可以定位到驱动中处理用户态请求的分发函数Dispatch Function。4. 核心逆向流程与关键技术点拆解完成了前期侦察现在可以深入驱动内部开始真正的逆向工程。这个过程是迭代和螺旋上升的需要静态分析与动态调试相互印证。4.1 定位并分析 DriverEntry 函数DriverEntry 是驱动的入口点相当于main函数。在 IDA 中通常可以通过查看入口点Entry Point或搜索对IoCreateDevice的引用来找到它。分析 DriverEntry 时重点关注以下逻辑版本检查网络片段提到“排除xp以下版本”和“获取当前正在运行的操作系统例程返回版本信息”。这对应着调用RtlGetVersion或PsGetVersion等函数然后对返回的版本号进行判断。如果版本过低DriverEntry 可能直接返回STATUS_UNSUCCESSFUL。在 IDA 中你会在函数开头看到一系列cmp指令和条件跳转。创建设备对象调用IoCreateDevice创建设备对象\Device\HrSysDiag并可能调用IoCreateSymbolicLink创建符号链接\DosDevices\HrSysDiag或\??\HrSysDiag以便用户态程序如火绒的托盘程序通过CreateFile(“\\\\.\\HrSysDiag”, ...)打开句柄进行通信。设置分发函数表在创建设备对象时或之后会设置DRIVER_OBJECT结构体中的MajorFunction数组。最重要的几个分发函数索引是IRP_MJ_CREATE当用户态调用CreateFile时触发。IRP_MJ_CLOSE当用户态调用CloseHandle时触发。IRP_MJ_DEVICE_CONTROL当用户态调用DeviceIoControl时触发。这是驱动与用户态交互的核心需要重点分析。IRP_MJ_CLEANUP清理相关。 在 IDA 中你会看到类似DriverObject-MajorFunction[IRP_MJ_DEVICE_CONTROL] HrDispatchDeviceControl;的赋值操作。找到这些赋值语句就找到了关键的分发函数。初始化同步对象网络片段明确提到了“初始化6个Ndis读写锁”和“初始化2个资源变量”。NDIS 读写锁这强烈暗示驱动实现了网络过滤组件。NDIS 读写锁NDIS_RW_LOCK用于保护共享数据结构在多线程多CPU环境下的读写安全。你会看到对NdisAllocateRWLock的调用通常在一个循环或连续代码段中出现6次每次返回的锁指针存储在不同的全局变量中。这些锁可能分别保护网络连接列表、过滤规则表、数据包处理队列等。资源变量ERESOURCE资源是内核中另一种更通用的读写锁。调用ExInitializeResourceLite进行初始化。这两个资源可能用于保护更宏观的、非NDIS特有的全局数据结构例如驱动配置表、事件日志缓冲区等。注册回调函数这是安全驱动实现监控功能的关键。DriverEntry 中会注册一系列系统回调进程/线程通知PsSetCreateProcessNotifyRoutineEx、PsSetCreateThreadNotifyRoutineEx。镜像加载通知PsSetLoadImageNotifyRoutine用于监控 DLL 加载。注册表回调CmRegisterCallbackEx。对象回调ObRegisterCallbacks用于监控进程/线程句柄操作。文件系统微过滤驱动注册如果使用了 Minifilter这里会调用FltRegisterFilter。NDIS 过滤驱动注册调用NdisFRegisterFilterDriver。 找到这些注册调用就找到了驱动监控功能的“钩子”安装点。记下这些回调函数的地址在 IDA 中是函数指针它们是我们下一步分析的重点目标。4.2 深入剖析关键分发函数以 IRP_MJ_DEVICE_CONTROL 为例用户态程序如火绒主程序通过DeviceIoControl向驱动发送控制请求传递指令码IOCTL和输入/输出缓冲区。驱动在对应的分发函数中处理这些请求。定位分发函数通过 DriverEntry 中设置的函数指针在 IDA 中找到HrDispatchDeviceControl假设名函数。解析 IOCTL函数开头会从IRP结构或IO_STACK_LOCATION中获取 IOCTL 代码。你会看到类似IoGetCurrentIrpStackLocation(Irp)-Parameters.DeviceIoControl.IoControlCode的代码。然后通常是一个大的switch-case或一系列if-else判断。识别功能模块每个 IOCTL 代码对应一个具体的功能。通过分析缓冲区内容、调用的子函数以及结合字符串信息可以推断出功能。例如一个 IOCTL 可能用于查询或更新驱动内部配置如监控规则开关。另一个 IOCTL 可能用于从驱动获取监控到的事件日志如拦截到的恶意行为记录。还可能用于向驱动提交扫描任务或控制驱动的过滤行为如临时禁用网络过滤。缓冲区处理与验证安全驱动的缓冲区处理非常严谨。注意观察驱动如何验证用户态传入的输入/输出缓冲区长度InputBufferLength,OutputBufferLength是否使用ProbeForRead/ProbeForWrite检查缓冲区可访问性以及如何利用Irp-AssociatedIrp.SystemBuffer或MmGetSystemAddressForMdlSafe来安全地访问缓冲区数据。这些是驱动安全编程的典范值得学习。逆向子功能函数对于每个 IOCTL 分支深入分析其调用的子函数。这些子函数实现了具体的业务逻辑如解析网络数据包、匹配行为规则、记录日志等。使用 IDA 的交叉引用Xrefs功能可以追踪数据流和函数调用链。4.3 动态调试验证与行为捕捉静态分析建立了模型动态调试则用于验证模型并观察运行时状态。加载驱动并设置断点在 WinDbg连接了 Target 虚拟机中你可以使用.reload加载符号然后使用lm查看已加载模块。如果 sysdiag 尚未加载你需要先在虚拟机中通过sc create和sc start或者使用一个加载工具来加载它。加载后使用lm m sysdiag获取其基址。假设基址是fffff80112345000。在 DriverEntry 函数设断点bp sysdiag!DriverEntry。如果符号未加载可以使用地址bp fffff80112345000 DriverEntry的RVA。重新加载驱动或启动相关服务WinDbg 会在 DriverEntry 处中断。此时可以单步t或步过p执行观察函数调用顺序、参数传递验证静态分析中对版本检查、设备创建、回调注册的推断。跟踪回调函数执行找到进程创建回调函数的地址假设叫HrProcessNotify。在 WinDbg 中对其设断点bp sysdiag!HrProcessNotify。在虚拟机中启动一个记事本notepad.exe进程。WinDbg 会立即中断在HrProcessNotify。使用k查看调用栈确认是来自nt!PspCallProcessNotifyRoutines。使用dv查看局部变量使用dt查看结构体如_EPROCESS。回调函数的参数通常包含进程ID、父进程ID、创建标志等。你可以观察驱动在这个回调里做了什么是记录日志、检查进程路径还是进行某种拦截决策通过p或t跟进关键判断分支。拦截与观察通信在设备控制分发函数HrDispatchDeviceControl上设断点。在虚拟机中运行火绒的用户态程序或自己编写一个简单的测试程序调用DeviceIoControl向驱动发送指令。当断点触发时使用dd命令查看 IOCTL 代码使用db或dq查看输入/输出缓冲区的内容。这能直观地看到用户态和内核态之间传递的数据格式是理解通信协议的关键。观察网络过滤行为如果存在在 NDIS 过滤驱动的接收/发送处理函数上设断点。在虚拟机中进行网络活动如 ping 一个地址访问一个网页。观察断点是否触发查看网络数据包NET_BUFFER_LIST的结构分析驱动是放行、修改还是丢弃了数据包。实操心得动态调试内核驱动风险较高一个错误的断点或单步操作可能导致系统死锁。务必频繁使用虚拟机快照。在单步跟踪进入不熟悉的系统函数如KeAcquireSpinLock时要格外小心最好步过p而不是步入t。另外善用 WinDbg 的条件断点bp /w和日志命令.printf可以减少手动中断的次数并记录特定条件下的执行流。5. 结构体恢复与代码重构随着分析的深入你会发现很多函数操作着复杂的数据结构。恢复这些自定义的结构体定义是让伪代码F5变得可读的关键。识别全局变量在 IDA 的 “Structures” 窗口中可以创建新的结构体。首先关注那些在多个函数中被频繁引用的全局变量地址。在反汇编或伪代码中你会看到类似mov rax, cs:g_pHrFilterRules的指令。分析访问模式查看访问该全局变量的代码。如果看到mov [rax18h], rcx那么偏移0x18处可能是一个指针成员。如果看到mov dword ptr [rax28h], 1那么偏移0x28可能是一个 DWORD 类型的标志位。通过交叉引用收集所有对该地址的读写操作推断出每个偏移处的数据类型和大小。在 IDA 中定义结构体在 “Structures” 窗口添加新结构比如HR_FILTER_RULES。然后根据推断在相应偏移处添加成员如PVOID pNextRule在0x0DWORD dwRuleId在0x8UNICODE_STRING TargetProcessPath在0x10等等。定义好后回到反汇编视图右键点击相应的内存访问指令选择 “Convert to struct offset”并应用你定义的结构体。IDA 会立即将晦涩的偏移量显示为直观的成员名如[raxHR_FILTER_RULES.dwRuleId]。恢复函数原型对于内部函数和回调函数可以根据其调用约定通常是__fastcall和参数的使用方式在 IDA 的 “Local Types” 或直接编辑函数声明来恢复其原型。例如进程通知回调的函数原型可能是void HrProcessNotify(PEPROCESS Process, HANDLE ProcessId, PPS_CREATE_NOTIFY_INFO CreateInfo)。正确的函数原型能帮助 Hex-Rays 生成质量高得多的伪代码。重命名与注释这是提升代码可读性最有效的方法。将分析出的函数功能、全局变量的用途、关键数据结构的含义通过重命名快捷键N和添加注释快捷键:记录下来。一个良好的命名规范如HrNetFilter_PacketInspect、g_HrActiveThreadList能让后续分析事半功倍。这个过程非常耗时但每恢复一个关键结构体或函数你对整个驱动架构的理解就会清晰一分。它就像在拼一张巨大的拼图。6. 常见问题、排查技巧与深度思考在逆向 sysdiag 这类复杂驱动的过程中你一定会遇到各种挑战。以下是我总结的一些常见问题及解决思路。6.1 静态分析中的难题与破解问题代码混淆或控制流平坦化。现代安全驱动可能会使用混淆技术增加逆向难度。对策首先混淆在商业安全驱动中不如在恶意软件中常见但部分逻辑可能被复杂化。观察是否存在大量间接跳转jmp rax或无意义的指令序列。可以尝试使用 IDA 的“图形视图”模式如果控制流图异常复杂且呈现“网状”或“扁平”结构可能是混淆。可以尝试使用 de4dot 等去混淆工具的变种如果适用或者更耐心地动态跟踪记录下真实执行路径然后在静态分析中标记出有效路径忽略混淆块。问题函数指针调用众多调用关系难以理清。对策驱动中常用函数指针表来实现类似“插件”架构或状态机。在初始化函数中如 DriverEntry 或某个 Setup 函数搜索对全局函数指针数组的赋值操作。动态调试时在这些赋值语句后设置内存访问断点ba w4 address当函数指针被调用时就会中断从而知道在什么上下文中使用了哪个函数。问题字符串被加密或哈希存储。对策在数据段看到非明文字符串而是一些看似随机的数据。搜索对这些数据的引用会发现它们被传递给一个特定的解密函数。动态调试时在这个解密函数出口处设断点dump 出解密后的缓冲区内容。或者在 IDA 中模拟执行这个解密函数如果逻辑不复杂编写 IDAPython 脚本批量解密。6.2 动态调试中的陷阱与应对问题一加载驱动或下断点就导致系统蓝屏BSOD。对策这通常是因为断点设置在了关键路径或持有锁的代码段。绝对避免在以下位置直接下普通断点中断服务例程ISR、DPC 例程、持有自旋锁SpinLock的代码段内部、以及某些关键的系统回调内部。可以先在更上层的函数如 DriverEntry 入口下断单步跟进到目标函数附近再下断。或者使用硬件断点ba命令代替软件断点它对代码的修改更小。最安全的方法是使用非侵入式的方法如通过DbgPrint输出日志如果驱动有或者修改代码跳转到你自己的日志函数这属于更高级的破解需谨慎。问题双机调试连接不稳定或响应极慢。对策确保虚拟机串口配置正确波特率 115200。在 WinDbg 中使用.breakin命令强制中断目标机检查连接。如果仍然很慢可能是符号服务器下载超时。尝试在 WinDbg 中先.reload /f强制加载已知模块符号或者暂时禁用符号路径仅使用本地已知符号。分析驱动本身时对系统模块ntoskrnl的符号依赖最大确保这部分符号已缓存好。问题无法触发特定的回调函数如某个IOCTL处理分支。对策你需要构造能触发该路径的用户态输入。首先通过静态分析确定该 IOCTL 的功能和所需的缓冲区格式。然后编写一个简单的用户态测试程序使用CreateFile打开设备再用DeviceIoControl发送构造好的数据。可以从火绒安装目录如C:\Program Files (x86)\Huorong\SysDiag\bin下的用户态组件入手尝试理解其通信协议或者使用 API Monitor 等工具监控火绒主程序对驱动的调用从而复现其行为。6.3 对安全防护设计的深度思考逆向的最终目的不仅是理解“它怎么工作”更是思考“为什么这样设计”以及“如何防御或绕过”。多层次的防御体系通过分析 sysdiag你会看到一套立体的防御方案。进程/模块加载回调用于监控程序启动和 DLL 注入注册表回调防御持久化攻击和配置篡改文件系统微过滤驱动实时监控文件创建、读写、执行NDIS 过滤驱动实现网络层的入侵检测和防火墙功能对象回调可能用于防止进程被非法打开、注入。这种纵深防御Defense in Depth思想值得在自身的安全方案设计中借鉴。性能与安全的平衡驱动中大量使用读写锁NDIS_RW_LOCK,ERESOURCE而非更粗暴的自旋锁是为了在读取频繁、写入较少的场景下提升并发性能。网络数据包处理路径Data Path上的代码必定经过高度优化可能使用无锁队列、批处理等技术来减少对网络吞吐量的影响。在分析时可以注意哪些操作在快速路径Fast Path哪些在慢速路径Slow Path。对抗逆向与篡改作为安全软件自身的驱动sysdiag 可能包含一些反逆向或自我保护措施例如检测调试器可能调用PsIsProcessBeingDebugged或直接查询KdDebuggerEnabled标志。校验代码完整性可能在运行时计算自身关键代码段的哈希与预存值比较。混淆关键数据结构核心的规则表、配置数据在内存中可能是加密的使用时才解密。 在逆向过程中如果发现某些逻辑分支永远走不到或者某些数据看起来毫无意义就要考虑是否存在这类保护机制。动态调试时注意观察是否有线程周期性检查这些点。逆向分析像 sysdiag 这样的工业级驱动是一场对耐心、技术和系统知识的综合考验。它没有捷径需要你反复在静态的汇编海洋和动态的调试风暴中穿梭。每一个疑难问题的解决每一个结构体的恢复都会带来巨大的成就感并让你的底层编程与系统安全理解力提升一个档次。这个过程本身就是安全研究员能力淬炼的最佳熔炉。当你最终能够清晰地勾勒出这个驱动从初始化、监控、过滤到通信的完整脉络时你所获得的远不止于对火绒产品的了解而是对整个 Windows 内核安全机制和驱动开发范式的深刻洞察。