linux2.4内核 挂钩子,往linux内核挂钩子--什么应该什么不应该

总是在网上看到有人讨论拦截linux的系统调用，方法数量可谓海量，几乎都是自己写的内核模块，可是这种方式有什么意义呢，模块都能加载了还有什么做不 到的呢，要知道linux的可加载内核模块功能十分强大，再加上linux内核本身就是开放源代码的，如果说你能加载模块了，那么就可以说你完全控制了内核，你再搞什么拦截系统调用实际上一点意义都没有，用模块别说拦截系统调用了，拦截任何函数都小菜一碟，当然如果内核导出的函数你可以直接拦截，没有导出 的函数有很多办法可以找到，比如/proc/kallsyms，大不了一个一个对，肯定能找到其地址。

在网上我几乎看到了两种方法来拦截，对于2.4以前的内核，内核导出了大部分的函数，这样在模块中拦截很方便，可到了2.4内核以及2.6内核中，很多以 前导出的函数现在不再导出了，于是就要费一番周折了，常见的方式有搜索内核符号表。在所有的拦截动作中，以拦截文件操作的动作居多，我们想象一下真的需要那么麻烦的从符号表找没有导出的函数地址吗(这个操作实际上一点也不麻烦)？想想看sys_read,sys_write等操作仅仅是一个二传手，执行绪只是经过它们一下，它们的地址不再导出不是为了更加安全，你都通过模块进入内核了就说明没有什么是安全的了。linux具有的虚拟文件系统是一个很好的机制

，这说明真正做事情的就是vfs中的回调函数们，你直接拦截回调函数不就结了，每个打开的文件在内存中都有一个file结构体，而此结构体中有 file_operations结构，该结构就是该文件的回调函数集合，现在问题是你要拦截一个回调函数不得先打开该文件找到这个 file_operations结构吗？如果有此疑问的，说明这位兄弟还是对内核不熟悉，仔细看一下内核，所有的file_operations都是以全 局的静态方式提供，也就是说所有的一类文件公用一个file_operations结构体，这就好办了，随便打开一个文件，将其替换了就可以了。上面说的所有的file_operations被公用可以从以下代码看出来：

void ext2_read_inode (struct inode * inode)