如何在Linux中进程隐藏 Linux内核模块技巧

P粉602998670

发布时间：2025-08-30 12:33:01

870人浏览过

来源于php中文网

原创

核心在于通过内核模块修改task_struct链表或钩取系统调用，使进程对ps、top等工具不可见，同时需隐藏模块自身以避免被发现。

如何在linux中进程隐藏 linux内核模块技巧

在Linux中隐藏进程，尤其是使其对常规工具（如

ps

、

top

）不可见，核心在于深入到内核层面，利用Linux内核模块的强大能力去修改或欺骗系统对进程状态的感知。这并非简单的用户空间操作，而是一场与内核数据结构和系统调用机制的“捉迷藏”游戏。

解决方案

要实现进程隐藏，我们主要依赖于Linux内核模块（LKM）来操作内核的内部状态。这通常涉及以下几种策略，它们可以单独使用，也可以组合起来以达到更全面的隐藏效果：

修改
```
task_struct
```
链表： 每个Linux进程在内核中都由一个
```
task_struct
```
结构体表示。这些结构体通过
```
tasks
```
字段（一个
```
list_head
```
类型）链接成一个双向循环链表，这个链表是调度器和许多进程管理工具遍历进程的基础。通过加载一个内核模块，我们可以找到目标进程的
```
task_struct
```
，然后利用
```
list_del_init()
```
宏将其从这个全局链表中移除。这样一来，当
```
ps
```
或
```
top
```
等工具试图遍历所有进程时，它们就无法“看到”这个被移除的进程了。但需要注意的是，进程本身仍在运行，只是从枚举视图中消失了。它依然占用CPU、内存，并能执行其任务。
钩取系统调用（System Call Hooking）： 这种方法更复杂，但效果也更彻底。许多用户空间工具，特别是那些读取
```
/proc
```
文件系统的工具，最终都会调用一些特定的系统调用。例如，
```
ls /proc
```
或
```
ps
```
会间接调用
```
getdents64
```
（或
```
getdents
```
）来读取目录项。通过钩取
```
sys_call_table
```
中的相应系统调用，我们可以拦截对
```
/proc
```
目录的读取请求。当这些请求试图列出进程目录（如
```
/proc/12345
```
）时，我们的钩子函数可以过滤掉目标进程的PID目录，从而让它在文件系统层面也“消失”。这需要找到
```
sys_call_table
```
的地址，并修改其条目指向我们自己的函数，这在现代Linux内核中通常需要绕过写保护，并可能导致系统不稳定。
隐藏内核模块本身： 一个隐藏进程的内核模块如果自己被发现，那么一切努力都白费了。因此，通常还会伴随着隐藏模块自身的技巧。这类似于隐藏进程，通过修改
```
module
```
链表，让
```
lsmod
```
等工具也无法列出这个模块。

一个简单的概念性代码片段（仅为说明原理，非完整可运行代码）：

// 假设我们找到了目标进程的task_struct指针：target_task
// 并且已经找到了当前内核的sys_call_table地址：syscall_table_ptr

// 1. 隐藏进程（从task_struct链表中移除）
// 这段操作需要非常小心，并且在适当的时机执行，以避免竞态条件。
// list_del_init(&target_task->tasks); 
// 移除后，如果需要，可以保留指向该task_struct的指针，以便后续恢复或管理。

// 2. 钩取 getdents64 系统调用
// 这是一个更高级的技巧，需要修改内核内存保护，并替换系统调用表中的函数指针。
// old_getdents64 = (void *)syscall_table_ptr[__NR_getdents64];
// syscall_table_ptr[__NR_getdents64] = new_getdents64; 
// new_getdents64 函数内部会检查目录项，如果发现是目标进程的PID目录，则跳过不返回。

为什么常规的进程隐藏方法效果不佳？

说实话，我个人觉得很多初学者在尝试隐藏进程时，往往会从用户空间的一些“小把戏”入手，比如使用

nohup

让进程在后台运行，或者干脆把进程名改成一个不那么显眼的名字。但这些方法，从专业的角度来看，几乎是无效的。

为什么呢？因为

ps

、

top

、

htop

这些工具，它们并不是靠“猜”进程名来工作的。它们的核心原理是去读取

/proc

文件系统下的信息。

proc

文件系统是一个虚拟文件系统，它直接映射了内核中的进程信息。每一个运行中的进程，在

/proc

下都有一个以其PID命名的目录（例如

/proc/12345

），里面包含了进程的各种状态文件（

cmdline

、

status

、

exe

等等）。

当

ps

命令执行时，它实际上是在遍历

/proc

status

文件来获取进程信息。如果你只是改了进程名，或者让它在后台跑，它的PID目录依然在那里，内核依然知道它的存在。所以，这些用户空间的“障眼法”根本无法欺骗到内核，也自然无法瞒过那些直接与内核打交道的工具。真正的隐藏，必须在内核层面动手脚，让内核自己“假装”看不到这个进程。

Linux内核模块隐藏进程的原理是什么？

Linux内核模块隐藏进程的原理，本质上就是对内核核心数据结构的直接干预和对系统调用行为的重定向。这活儿有点像外科手术，需要精准且大胆。

核心在于

task_struct

结构体，这是Linux内核中描述一个进程所有信息的大型结构体。你可以把它想象成每个进程的“身份证”和“档案袋”。这些

task_struct

实例通过一个叫做

tasks

的

list_head

成员，被组织成一个双向循环链表。这个链表是全局的，所有活跃的进程都在上面。调度器、信号处理、以及我们前面提到的那些查看进程的工具，它们在底层都是通过遍历这个链表来获取进程列表的。

Vinteo AI

利用人工智能在逼真的室内环境中创建产品可视化。无需设计师和产品照片拍摄

下载

当我们加载一个内核模块，并且这个模块成功地找到了目标进程的

task_struct

，那么它就可以调用

list_del_init()

这样的宏，把目标进程的

tasks

成员从这个全局链表中“摘”下来。一旦被摘下来，从链表的角度看，这个进程就不再是“可见”的了。它仍然在内存中，仍然被调度器调度执行，但对于那些依赖遍历

tasks

链表来获取进程列表的程序来说，它就仿佛不存在了一样。

但这还不是全部。即使进程从

tasks

链表中消失了，它在

/proc

文件系统中的目录可能依然存在。所以，为了更彻底地隐藏，还需要进行系统调用钩取。以

getdents64

为例，它是用来读取目录项的系统调用。当一个程序（比如

ls

）尝试读取

/proc

目录时，它会调用

getdents64

。一个恶意的内核模块可以替换掉原始的

getdents64

函数指针，用自己的函数来处理。在这个自定义函数中，模块会检查每个目录项，如果发现是目标进程的PID目录，就直接跳过不返回给用户空间。这样，不仅进程在

ps

中看不见，连它的

/proc

目录也“蒸发”了。这需要对内核内存管理和系统调用机制有深入的理解，而且操作不当很容易导致内核崩溃。

编写一个简单的内核模块来隐藏进程的挑战和注意事项？

说实话，这事儿没那么简单，编写一个能稳定隐藏进程的内核模块充满了挑战，并且有很多需要注意的地方。我个人觉得，这更像是在玩火，稍有不慎就可能引火烧身，把整个系统搞崩。

主要挑战：

内核版本兼容性： Linux内核更新迭代很快，不同版本之间，
```
task_struct
```
的结构、
```
sys_call_table
```
的地址甚至系统调用的编号都可能发生变化。这意味着你为一个版本编写的模块，很可能在另一个版本上就无法工作，甚至导致内核崩溃。维护这种兼容性是一个巨大的负担。
内核态编程的复杂性： 你的代码运行在内核空间，没有任何用户态的保护机制。一个指针错误、一个内存泄漏，都可能直接导致内核恐慌（Kernel Panic），系统瞬间崩溃。调试起来也异常困难，因为你没有GDB那样方便的调试工具。
绕过安全机制： 现代Linux内核引入了许多安全特性来阻止LKM的恶意行为，例如
```
kptr_restrict
```
限制内核地址泄露，以及内核地址空间布局随机化（KASLR）使得
```
sys_call_table
```
等关键地址难以预测。此外，
```
CONFIG_STRICT_KERNEL_RWX
```
等选项会阻止内核代码段被修改，直接钩取系统调用变得更加困难。
竞态条件和死锁： 内核是多任务环境，多个CPU核心可能同时访问和修改同一个数据结构。如果你在修改
```
task_struct
```
链表或钩取系统调用时没有正确处理锁机制，很容易引入竞态条件，导致数据损坏或系统死锁。
反检测： 专业的安全工具（如
```
chkrootkit
```
、
```
rkhunter
```
）会检查常见的rootkit痕迹，包括未链接的进程、被篡改的系统调用表、隐藏的内核模块等。编写一个能躲过这些工具检测的模块，需要更高级的技巧和对检测原理的深入理解。

注意事项：

始终在虚拟机中测试： 这一点怎么强调都不过分。在物理机上直接测试这种模块，几乎可以保证你会遇到系统崩溃，甚至可能损坏文件系统。虚拟机提供了隔离的环境，可以随时快照、恢复。
最小化影响范围： 尽量只修改你需要的最小部分。例如，如果你只需要隐藏一个特定的进程，就不要去影响其他无关的系统功能。
确保可逆性： 你的模块应该提供一种机制来“撤销”其操作，例如在模块卸载时恢复被钩取的系统调用，或者将隐藏的进程重新链接回
```
task_struct
```
链表。否则，一旦模块加载，你可能无法恢复系统到正常状态。
谨慎处理内核内存： 使用
```
kmalloc
```
、
```
kfree
```
等内核内存分配函数，并确保正确释放，避免内存泄漏。
理解法律和道德风险： 进程隐藏技术虽然在某些合法场景（如安全研究、系统监控）中可能有用，但它也是恶意软件（如rootkit）的核心组成部分。在实际应用中，务必遵守法律法规和道德规范，不要将其用于非法目的。