检测并移除隐藏内核模块的实战方案 #

作为常年和内核模块、Rootkit防御打交道的开发者，我来拆解一下你遇到的这个问题——你提到的“两行代码隐藏模块”，本质上就是篡改了内核维护的modules双向链表，把自身从用户态可见的模块列表中移除了，常规工具自然找不到它，rmmod也就失效了。下面分检测和移除两部分给你具体方案：

一、检测隐藏内核模块的方法 #

• 直接遍历内核原始模块链表
  常规工具（lsmod//proc/modules）都是读取内核导出的modules链表，但Rootkit会篡改这个链表的指针。你可以通过cat /proc/kallsyms | grep " modules"找到这个链表的物理地址，然后写一个小型内核模块或者用内核调试工具（比如crash）直接遍历内存中的原始链表——这里的链表节点是不会被Rootkit完全抹除的，因为内核自身还需要用它管理模块资源。
• 对比多源日志与系统状态
  模块加载时会触发内核日志（除非Rootkit同时篡改了dmesg缓冲区），你可以用dmesg | grep -i "insmod\|module"找加载痕迹；另外，/sys/module的目录项和/proc/modules的输出如果有差异，也能暴露隐藏模块；还可以用perf top观察内核中异常的函数调用，比如Rootkit植入的钩子函数。
• 利用内核调试与追踪机制
  开启kprobes或ftrace，监控sys_init_module（模块加载入口）和sys_delete_module（模块卸载入口）的调用情况，任何绕过常规流程的模块操作都会被捕获；如果系统允许，用gdb连接内核（需要开启CONFIG_DEBUG_INFO和CONFIG_KGDB），直接查看内存中的模块元数据。
• 内核完整性校验
  用IMA（Integrity Measurement Architecture）或者内核自带的完整性校验工具，对比内核符号表的预期值和实际值——比如kallsyms中某个函数的地址被Rootkit篡改，就能被检测到；也可以扫描内存中符合内核模块特征的内存区域（比如带有.modinfo段的内存块）。

二、移除隐藏内核模块的方法 #

• 编写清理型内核模块
  这是最安全的方式：写一个内核模块，遍历原始的modules链表，通过模块名、内存特征码或者加载地址定位目标模块，然后调用内核标准的卸载流程：先检查模块的state是否为MODULE_STATE_LIVE，再调用sys_delete_module（需要CAP_SYS_MODULE权限）。注意不要手动强制修改链表或直接释放内存，否则极易触发内核panic。
• 内核调试工具强制卸载
  在测试环境中，可以用crash工具加载内核转储，找到目标模块的地址后，调用module_put减少其引用计数，再执行module_unload；或者用gdb连接运行中的内核，手动调用卸载函数。这种方法风险极高，只适合在可控环境下使用。
• 修复被篡改的模块链表
  如果Rootkit只是修改了modules链表的前后指针，你可以先恢复链表的完整性：找到被跳过的模块节点，重新连接前后指针，让lsmod能重新识别它，然后再用常规的rmmod命令卸载。
• 内核热补丁修复
  利用kpatch或livepatch技术，热补丁被Rootkit篡改的内核函数（比如恢复sys_delete_module的原始逻辑，或者添加对隐藏模块的监控），然后触发模块卸载。这种方法不需要重启系统，适合生产环境，但需要内核支持热补丁功能。

注意事项 #

• 强制卸载隐藏模块可能导致内核panic，因为这类模块往往会篡改内核关键数据结构或持有锁资源，操作前一定要备份数据，优先在测试环境验证。
• 部分高级Rootkit会禁用内核调试接口、篡改内存校验机制，这时候可能需要直接读取物理内存，或者使用硬件辅助的调试工具（比如Intel PT）来检测。

内容的提问来源于stack exchange，提问作者sinkmanu