用户模式下无法实现真正的文件系统filter hook。c#运行在用户态，而文件系统过滤必须在内核态通过fsfilter驱动完成；win32 api调用进入内核后无法被用户态hook可靠拦截，且易被绕过、触发安全软件告警；唯一合规方案是c/c++编写minifilter驱动配合c#通信服务。
用户模式下无法实现真正的文件系统 Filter Hook
不能。C# 运行在用户模式，而文件系统过滤（如拦截 CreateFile、ReadFile）必须在内核模式通过文件系统筛选器驱动（FSFilter Driver）完成。Windows 不允许用户态代码直接劫持或重定向底层 I/O 请求路径。
为什么 .NET 程序调用 FileStream 或 File.Open 无法被“Hook”
这些 API 最终都通过 Win32 CreateFileW 进入内核，但调用链在用户态已封装完毕；你看到的只是结果，不是可插桩的中间过程。试图用 Detours 或 EasyHook 注入并 hook kernel32.dll 中的 CreateFileW —— 行为不可靠：
- 仅影响当前进程，且极易被 .NET 的内部缓存、异步 I/O 路径（如
ThreadPoolBoundHandle）绕过 - 对
MemoryMappedFile、Directory.EnumerateFiles、PowerShell 的Get-Content等调用完全无效 - Windows Defender 和 EDR 会将此类 inline hook 视为可疑行为，触发拦截或报毒
- .NET 6+ 启用
NativeAOT后，符号和导入表消失，hook 失效
替代方案：哪些事 C# 用户态能做、哪些不能
明确边界比强行 hook 更实用：
- ✅ 可监控：用
FileSystemWatcher响应文件创建/修改/删除事件（注意它不捕获打开、读取、写入内容，也不保证顺序或原子性） - ✅ 可代理：自己封装
IFileProvider（ASP.NET Core）或Stream子类，在业务层拦截读写逻辑（适用于可控代码路径，比如你自己的应用加载配置文件） - ❌ 不可拦截：
NtCreateFile、ZwWriteFile等内核入口，任何未通过你代理的第三方 DLL 调用都会逃逸 - ⚠️ 伪拦截风险高：用
AppDomain.AssemblyResolve或AssemblyLoadContext.Resolving替换System.IO类型？.NET 不允许替换核心程序集类型，运行时直接抛InvalidProgramException
真要拦截，唯一合规路径是写内核驱动 + 用户态服务通信
这不是 C# 能独立完成的事。你需要：
- 用 C/C++ 编写 Minifilter 驱动（基于
FltMgr.sys），注册PreOperation/PostOperation回调 - 用
FilterConnectCommunicationPort在驱动与 C# 服务之间建命名端口通信 - C# 侧用
NamedPipeClientStream接收事件、下发策略（例如“拒绝访问C:\secret\*.log”） - 驱动签名必须通过 WHQL 认证，否则 Windows 10/11 默认禁用（尤其启用 Secure Boot 时）
这个组合里，C# 只负责策略决策和 UI，所有拦截动作都在驱动里完成。漏掉签名、权限、IRP 生命周期管理中的任意一环，就会蓝屏或静默失败。
真正难的不是写几行 hook，而是理解 Windows I/O Manager 如何调度 IRP、如何处理 fast I/O、如何与 Cache Manager 协作——这些细节出错，日志里只显示 STATUS_INVALID_PARAMETER 或直接卡死，连调试器都进不去。
