首先让我先说读任意内核内存是一件棘手的事！并且有很多方法可以做到这一点,它们的复杂程度和灵活性各不相同.

1)硬编码地址.

在内核版本的System.map文件中搜索它：

# grep sys_call_table /boot/System.map-2.6.18-238.12.1.el5

c06254e0 R sys_call_table

有了这个,硬编码地址：

unsigned long *syscall_table = (unsigned long *)0xc06254e0;

然后,假设您#include< linux / syscalls.h>,您可以使用__NR_syscall定义来获取代码中这些系统调用的地址：

syscall_table[__NR_close]

这是最简单的方法,但到目前为止灵活性最低.该模块仅适用于该确切的内核.如果你将它发送到另一个内核,你就有可能得到一个内核OOP.

2)对表格进行强力扫描

看看这个：

他使用一种方法来强制内核内存地址范围来查找sys_call_stable.原样,它只适用于32位(64位具有不同的内核内存地址范围).

这种方法有点灵活,但随着内核语义的改变可能会破坏道路.

3)动态搜索System.map加载时间

加载模块时,可以读取内核的System.map文件.我在我写的tpe-lkm模块中演示了这一点.该项目托管在github上.

看看这个文件中的find_symbol_address_from_file()：

非常灵活,因为你可以找到你想要的任何符号,但是从内核空间读取文件是一个很大的“不可以”.不要问我为什么,但人们总是告诉我.您还冒着它看到的System.map无效的风险,并可能导致内核OOP.此外,代码是……凌乱.

4)使用kallsyms_on_each_symbol()

从内核版本2.6.30开始,内核导出kallsyms_on_each_symbol().我们可以感谢ksplice人员.有了这个,你找不到sys_call_table(由于某些原因它不在那里),但你可以找到大多数其他符号.

非常灵活,非常稳定的查找符号地址的方法,但理解起来有些复杂;)

我在tpe-lkm项目中证明了这一点.看看这个文件中的find_symbol_callback()和find_symbol_address()函数：