UEFI驱动能否拦截同权限恶意UEFI NTFS驱动的文件删除操作

1. 同权限级别的驱动能否阻止另一个驱动执行任意指令？ #

结论是理论可行，实际落地取决于执行优先级和拦截点可用性。
不管是ring 0的Windows内核驱动，还是ring -1的UEFI DXE驱动、ring -2的SMM（系统管理模式）代码，同一权限环下没有硬件级别的强制权限隔离，只要你的代码能更早执行、拿到关键函数/接口的控制权，就可以拦截、篡改同权限其他代码的操作。

2. 单个驱动能否阻止另一个驱动删除磁盘文件？ #

分两层场景说明：

• Windows内核层（ring 0）：完全可行，且有官方成熟方案
  用微软提供的文件微过滤驱动（Minifilter）框架即可实现，你只要将自己的过滤驱动挂载到高于其他驱动的海拔，就能捕获所有文件删除相关的IRP请求（对应IRP_MJ_SET_INFORMATION的FileDispositionInformation操作类），直接返回拒绝即可阻止删除，完全不需要做非官方的内核hook，稳定性有保障。你提到的用户态DeleteFileA这类API的最终操作都会走到这个流程，完全可以被拦截。
• UEFI/固件层：可行，但需要适配UEFI规范
  所有UEFI DXE阶段的驱动都是同权限运行的，你只要保证自己的防护驱动加载顺序早于恶意NTFS驱动、存储栈驱动，就可以通过hook UEFI块IO协议（Block I/O Protocol）的写操作，或者hook NTFS驱动的文件操作接口实现拦截。

3. 恶意UEFI NTFS驱动删除文件的可拦截特征 #

恶意UEFI驱动执行NTFS文件删除的操作流程是标准化的，有明确的可检测特征：

• 首先会读取NTFS卷引导扇区，定位MFT（主文件表）的物理位置
• 遍历MFT找到目标文件的对应记录项
• 修改MFT记录中的文件状态标记为删除，同时更新NTFS簇位图标记对应存储空间为可用
• 调用UEFI块IO协议的写接口，将修改后的MFT记录、簇位图写回磁盘
  你只要在块IO层拦截所有写入MFT区域、簇位图区域的请求，检查操作是否为修改文件删除标记，就能实现检测和拦截。

4. 逆向UEFI固件是否有价值 #

完全不需要全量逆向UEFI驱动，不管是微软自带的UEFI NTFS驱动还是EDK2开源实现的NTFS驱动，都遵循UEFI规范，对外导出的协议接口是公开标准化的，你只需要针对公开的协议接口做hook即可，不需要逆向具体实现逻辑，不会做无用功。

5. 硬件SATA分路器方案是否过度设计 #

普通场景下属于过度设计：

• 只有当你的防护目标是对抗全固件栈被攻陷的场景（比如攻击者会恶意删除你的UEFI防护驱动），硬件层面的拦截才有必要
• 绝大多数企业场景下，内核层minifilter+UEFI层防护驱动的组合已经足以覆盖99%的文件删除防护需求，实现成本和维护成本远低于硬件方案。

6. SMM级别rootkit的拦截补充 #

SMM（ring -2）级别的拦截门槛更高：SMM代码运行在独立的SMRAM内存区域，默认对操作系统不可见，只有同处于SMM的代码能互相访问。要拦截SMM级别的文件删除操作，你需要自己实现SMM级的拦截代码，hook SMI中断的分发流程，或者监控SATA控制器的IO寄存器操作，这部分没有统一的标准实现，需要针对不同厂商的BIOS做适配。

内容的提问来源于stack exchange，提问作者J.Todd