文件系统过滤驱动同NativeAPI Hook之间的问题。

我想监视向硬盘中写入的文件，用filemon可以实现，那么用native API hook能实现么？这两者有什么联系？

filemon处理的是主要是IRP和FastIo，它们相对native API更底层一些，也就是native API调用会产生IRP请求。
好像filedisk就是使用的native API吧。

Hooking NtCreateFile is almost the same as intercepting IRP_MJ_CREATE. What you need to pay attention:

1) Do careful privilege and parameter check so that you won't break NT security and stable.
2) You need to parse the filename by yourself -- you need to find out the file system I/O you're interested in.
3) You will not able to detect those IRP_MJ_CREATEs which are created manually.

toad

既然都能够监视向硬盘中写入的文件，而且我觉得用系统调用Hook（即NativeAPI Hook）的技术实现上要比Irp Hook简单。文件系统过滤驱动要考虑的事情太多，一不小心就重启，连问题在哪都不知道。那么文件系统的过滤hook到底优势在哪，有什么系统调用hook无法实现的功能么？

native api只能拦截本地的,对于网络的请求无法拦截.

"对于网络的请求无法拦截"指的是网络机器对本地的操作，还是本地机器对网络机器的操作呢？

[编辑 -  11/28/04 by  cicada]

也是我的困惑。
还有一点，就是IFS和Hook两种技术的前景如何，比较一下？

如果hook能做的，就尽量用hook做，即使有10%的功能不能实现，通过一些弥补措施，也是值得的

如果说网络操作部分不通过 NtCreateFile,那种会通过过某个 api进行操作。

此处的hook无疑是针对 app层的

我觉得 hook好些

native api只能拦截本地的,对于网络的请求无法拦截.

这位老大的意思是通过文件系统驱动可以过滤网络文件数据（比如网络邻居等）？

native api只能拦截本地的,对于网络的请求无法拦截.

好像指的是本地机器的文件系统过滤驱动可以拦截到网络机器对本地机器的文件操作，但本地机器的NativeAPI Hook拦截不到。
是否？请高手指点。

我用hook native api 做的文件夹隐藏，如何动态指定要隐藏的文件夹呢？
即如何从应用层传入驱动要隐藏的文件夹，如 D:\test