写这篇文章的灵感来于对Windows存储设备栈的分析。截获了SCSI命令。

我们先看一张图（画的比例不好请见谅）

在3环下，一个程序发起文件读写请求，被传递给ntdll.dll，ntdll.dll对请求进行包装，成为了
IRP(I/O Request Package)，IRP通过KiFastCallEntry进入内核，这些都很熟悉了。我们着重分析一下内核层。

IO Manger
IO管理器接收来自用户态（ntdll.dll）的IRP，进行合法性校验和分发。也就是通过它的DriverDispatch向下传递IRP包，同时构建标准化的IRP结构，包含操作类型（如文件读写）、缓冲区指针等元数据。

MiniFilter
过滤驱动层位于文件系统驱动（FSD）之上，主动拦截所有IRP。这也是最常见的过滤驱动地点。可检测文件读写、进程创建等敏感操作。也可数据加密/解密，在IRP传递过程中透明处理数据（如BitLocker）。

ntfs.sys
文件系统驱动解析IRP中的文件路径，定位磁盘物理位置（簇映射）。管理元数据：NTFS主文件表（$MFT）、权限、日志等。实现缓存机制：通过内存管理器（Mm）减少磁盘访问。

这之后，才是我们需要关注的设备

Storage Driver
存储类驱动（Storage Driver）通过SCSI端口接口控制特定类型设备（如CD-ROM统一驱动、磁盘统一驱动），将IRP转换为SRB+CDB（命令描述块），成为为SCSI设备请求。
SRB/CDB是什么？
SRB
SRB：SCSI请求块（协议传输载体），可以跨层通信，是在存储类驱动 → 端口驱动 → 微端口驱动间传递命令/数据的标准化容器。
举个简化示例：SRB的结构

CDB
命令描述块，内嵌在SRB中，封装SCSI标准操作指令（如读/写/查询），为变长指令。
举个简化示例：CDB的结构

典型CDB命令示例

现代CDB支持扩展操作码（如READ(16)的0x88），应对大容量设备.

SRB+CDB 协作流程

图说得很清楚了。我就不赘述了（´v｀）

Storage Port Driver
存储端口驱动为所有Windows存储类驱动（如磁盘、磁带、DVD驱动）定义统一接口，提供硬件抽象，隔离Storage Driver与HBA（主机总线适配器）的硬件特性差异,同步管理同一HBA上所有设备的访问。
协议转换：
对SCSI设备：将SRB（SCSI请求块）直接传递至Storport微端口驱动（硬件专属）
对传统IDE/ATAPI/IEEE 1394总线：将SRB转换为适配器所需格式（如重组CDB/协议包）。

这是Windows存储设备栈的底部，也是我们拦截的地方

我们想在Storage Port Driver上挂钩，设置Filter Driver。
（这里画的有点问题，Capture Driver应该在Storage Driver和Storage Port Driver之间，Capture还打错了=￣ω￣=）
看一下windbg的输出：

storahci.sys便是Storage Port Driver，也是我们挂钩的位置。
那么如何挂钩呢
答案在DriverObject->MajorFunction中

IRP_MJ_INTERNAL_DEVICE_CONTROL
Storage Driver和Storage Port Driver之间通过DriverDispatchXxx联系，所以只要修改MajorFunction的地址我们就可以截获SRB请求。
经过调试得知，二者通过IRP_MJ_INTERNAL_DEVICE_CONTROL联系，所以只需修改MajorFunction 的IRP_MJ_INTERNAL_DEVICE_CONTROL即可。

首先打个断点看一下调用上下文，这是Call到MajorFunction的IRP_MJ_INTERNAL_DEVICE_CONTROL的上下文：

根据fastcall调用协议，rdx是指向IRP的指针，所以我们解析IRP即可。
根据Windows文档，SRB块的指针位于CurrentStackLoaction中，而CurrentStackLoaction在DeviceObject中，具体见下（也可看后面的代码）：

这里的Argument1便是指向SRB的指针，srb的结构定义在windbg 中可以看到，CDB的位置在偏移的0x048处：

于是乎，可以这样解析得到CDB地址：

现在，在Windbg里看一下CDB:

解析一下这条CDB命令：

Byte 0：0x28 表示 READ(10) 命令。用于从指定逻辑块地址 (LBA) 开始读取数据块。

Byte 1：这是一个位掩码字段，包含控制和保护标志。值 0x00 表示所有标志未设置。

Bytes 2-5 (Logical Block Address ): LBA 是一个 32 位无符号整数，表示读取起始地址（块号）。
计算：0x035567BA（大端序）。从逻辑块地址 55928762 开始读取数据。

Byte 6 (Group Number): 组号字段，通常保留，必须为 0。无特殊功能。

Bytes 7-8 ：传输长度是一个 16 位无符号整数，表示要读取的数据块数量。
计算：0x0040（大端序）。含义：读取 64 个连续数据块。每个块大小由设备定义（通常为 512 字节或 4K 字节），需结合设备参数确定总字节数。
Byte 9 (Control): 控制字段，通常用于链接、队列或供应商特定选项。值 0x00 表示：

成功！我们解析了CDB!

首先，这个DriverDispatch应该有两个功能，一是分析SRB，二是调用源函数。
微软文档解释道这个级别的驱动程序不应调用系统例程（特别是文件系统例程，Io开头的），这个在我看来可能是死锁问题。
例如，我在DriverDispatch调用了NtWriteFile，而NtWriteFile又会调用我的DriverDispatch，造成死锁。
但是DbgPrint应该没什么事。

直接看代码解释吧，在DriveEntry中完成了对原函数地址有效性的检验，所以这里不用检验地址。
在这个示例中，不需对传入的参数进行检验，因为这是被修改的原函数内部完成的， 我们自己校验可能还会画蛇添足。
无论处理结果如何，都要将SRB传递。

DispatchRoutine是用汇编写的

首先看修改MajorFunction的函数，在多核系统上还是挂一个锁比较好：

那么，如何遍历设备栈获得底层设备呢？
我们可以利用DeviceObject的AttachTo指针遍历：

遍历的起点是disk.sys，因为这个起点在绝大多数Windows上适用：
通过ObReferenceObjectByName打开disk.sys

使用ObReferenceObjectByName应注意

把以上补充在头文件中,
然后是解析CDB中的LBA

作为示例，这里只解析了READ_12命令，你也可以添加对其他命令的处理，如对Inquiry的分析

写到这里，突然想到一些ARK不是支持通过SCSI命令解析磁盘信息吗，这个理论上可以拦截，但也没试过。

从CDB逆推文件极为困难，首先是一个磁盘可以有多个卷，文件系统各不一样，
即使只有一个文件系统，以NTFS为例，MFT到LCN再到LBA可以完成，但是LBA逆推到MFT就涉及所有文件的映射，这个映射的大小堪比页表，甚至远大于页表，而且需要实时更新，所以这种方法对内存和CPU的开销都很大。

所以呢，这个项目的示例意义大于实际意义。
是一个实验性质的项目，(。・・)ノ

这份代码的健壮性是很差的，其只考虑SATA硬盘等典型情况，而对NVMe硬盘和PnP设备完全未考虑，正因如此，这份代码只作为示例实现，不可直接应用于生产环境。
同时，对系统底层的修改会带来极大的不稳定性，应该谨慎使用。至于PG，我进行了三次5min的测试，均未蓝屏。
这份代码仅作为研究使用。

欢迎提出意见

[培训]科锐逆向工程师培训第53期2025年7月8日开班！