Linux 2.6版内核中通过模块获取sys_call_table地址的方法

朱熹之

转自我的blog：
http://blog.chinaunix.net/u/27624/showart_226262.html

本文主要介绍在Linux 2.6版的内核中实现基地址修改的方法。所有代码我都在基于2.6.19版内核的Fedora Core 6上进行了测试。

Linux 2.6版的内核出于安全的考虑没有将系统调用列表基地址的符号sys_call_table导出，但要对系统调用进行替换，却必须要获取该地址，于是就有了这篇文章。

我在这里采用的基本思路是这样的，因为系统调用都是通过0x80中断来进行的，故可以通过查找0x80中断的处理程序来获得sys_call_table的地址。其基本步骤是，首先获取中断描述符表的地址，再从中查找0x80中断的服务例程，再搜索该例程的内存空间，以从其中获取sys_call_table的地址。其代码如下：

#include <linux/module.h>
#include <linux/kernel.h>

// 中断描述符表寄存器结构
struct {
    unsigned short limit;
    unsigned int base;
} __attribute__((packed)) idtr;


// 中断描述符表结构
struct {
    unsigned short off1;
    unsigned short sel;
    unsigned char none, flags;
    unsigned short off2;
} __attribute__((packed)) idt;

// 查找sys_call_table的地址
void disp_sys_call_table(void)
{
    unsigned int sys_call_off;
    unsigned int sys_call_table;
    char* p;
    int i;

    // 获取中断描述符表寄存器的地址
    asm("sidt %0":"=m"(idtr));
    printk("addr of idtr: %x\n", &idtr);

    // 获取0x80中断处理程序的地址
    memcpy(&idt, idtr.base+8*0x80, sizeof(idt));
    sys_call_off=((idt.off2<<16)|idt.off1);
    printk("addr of idt 0x80: %x\n", sys_call_off);

    // 从0x80中断服务例程中搜索sys_call_table的地址
    p=sys_call_off;
    for (i=0; i<100; i++)
    {
        if (p=='\xff' && p[i+1]=='\x14' && p[i+2]=='\x85')
        {
            sys_call_table=*(unsigned int*)(p+i+3);
            printk("addr of sys_call_table: %x\n", sys_call_table);
            return ;
        }
    }
}

// 模块载入时被调用
static int __init init_get_sys_call_table(void)
{
    disp_sys_call_table();
    return 0;
}

module_init(init_get_sys_call_table);

// 模块卸载时被调用
static void __exit exit_get_sys_call_table(void)
{
}

module_exit(exit_get_sys_call_table);

// 模块信息
MODULE_LICENSE("GPL2.0");
MODULE_AUTHOR("Xizhi Zhu");

在编译并载入该模块后，可以通过dmesg命令看到如下的输出：
addr of idtr: d0af4680
addr of idt 0x80: c0103e04
addr of sys_call_table: c03094c0

可见，上面的程序能够获取sys_call_table的地址。

在上面的代码中，最复杂的应该就是从0x80中断的服务例程中搜索sys_call_table的一段了，现解释如下。

首先，我们使用命令“gdb -q /usr/src/kernels/2.6.19/vmlinux”来反编译内核，再使用“disass system_call”和“disass syscall_call”两条gdb命令来查看内核的汇编代码，其结果如下：

(gdb) disass system_call
Dump of assembler code for function system_call:
0xc0103e04 <system_call+0>: push %eax
0xc0103e05 <system_call+1>: cld
0xc0103e06 <system_call+2>: push %es
0xc0103e07 <system_call+3>: push %ds
0xc0103e08 <system_call+4>: push %eax
0xc0103e09 <system_call+5>: push %ebp
0xc0103e0a <system_call+6>: push %edi
0xc0103e0b <system_call+7>: push %esi
0xc0103e0c <system_call+8>: push %edx
0xc0103e0d <system_call+9>: push %ecx
0xc0103e0e <system_call+10>: push %ebx
0xc0103e0f <system_call+11>: mov $0x7b,%edx
0xc0103e14 <system_call+16>: movl %edx,%ds
0xc0103e16 <system_call+18>: movl %edx,%es
0xc0103e18 <system_call+20>: mov $0xfffff000,%ebp
0xc0103e1d <system_call+25>: and %esp,%ebp
0xc0103e1f <system_call+27>: testl $0x100,0x30(%esp)
0xc0103e27 <system_call+35>: je 0xc0103e2d <no_singlestep>
0xc0103e29 <system_call+37>: orl $0x10,0x8(%ebp)
End of assembler dump.
(gdb) disass syscall_call
Dump of assembler code for function syscall_call:
0xc0103e44 <syscall_call+0>: call *0xc03094c0(,%eax,4)
0xc0103e4b <syscall_call+7>: mov %eax,0x18(%esp)
End of assembler dump.

其中，system_call是0x80中断的服务例程的入口，而syscall_call是调用指定系统调用的部分。在得到的反汇编代码中可以看到，地址0xc03094c0就是我们需要搜索的sys_call_table的地址。

p.s. 如果不考虑可移植性，我们当然可以直接使用这个地址进行操作。但是，为了获取更好的兼容性，我们应该通过对代码段进行搜索来查找该值。

通过进一步的反汇编，我们可以发现，从system_call开始，到syscall_call结束的汇编代码如下：

0xc0103e04 <system_call+0>: push %eax
0xc0103e05 <system_call+1>: cld
0xc0103e06 <system_call+2>: push %es
0xc0103e07 <system_call+3>: push %ds
0xc0103e08 <system_call+4>: push %eax
0xc0103e09 <system_call+5>: push %ebp
0xc0103e0a <system_call+6>: push %edi
0xc0103e0b <system_call+7>: push %esi
0xc0103e0c <system_call+8>: push %edx
0xc0103e0d <system_call+9>: push %ecx
0xc0103e0e <system_call+10>: push %ebx
0xc0103e0f <system_call+11>: mov $0x7b,%edx
0xc0103e14 <system_call+16>: movl %edx,%ds
0xc0103e16 <system_call+18>: movl %edx,%es
0xc0103e18 <system_call+20>: mov $0xfffff000,%ebp
0xc0103e1d <system_call+25>: and %esp,%ebp
0xc0103e1f <system_call+27>: testl $0x100,0x30(%esp)
0xc0103e27 <system_call+35>: je 0xc0103e2d <no_singlestep>
0xc0103e29 <system_call+37>: orl $0x10,0x8(%ebp)

0xc0103e2d <no_singlestep+0>: testw $0x1c1,0x8(%ebp)
0xc0103e33 <no_singlestep+6>: jne 0xc0103ef8 <syscall_trace_entry>
0xc0103e39 <no_singlestep+12>: cmp $0x140,%eax
0xc0103e3e <no_singlestep+17>: jae 0xc0103f6b <syscall_badsys>

0xc0103e44 <syscall_call+0>: call *0xc03094c0(,%eax,4)
0xc0103e4b <syscall_call+7>: mov %eax,0x18(%esp)

我们不用关心这段代码具体执行了什么操作，值得我们注意的只有一点，就是从 system_call开始，直到正式发生系统调用时才出现了第一个call语句。我们可以利用这一点来进行搜索。再通过“x/xw (syscall_call)”命令来查看call语句的指令码为0xc03094c08514ff。这样，我们就可以利用程序中给出的代码进行查找了。

至此，我们已经成功的获得了sys_call_table地址，就可以像在以前内核版本中那样对其进行操作了。明天我会简单的讨论下最后一个小问题，就是部分发行版（包括Fedora）增加了一个内核补丁，以确保 sys_call_table所在的内存页面是只读的，需要首先修改页属性才ok。

flw2

我通常是直接去改代码,回头再看

朱熹之

这种方法主要用于在不改变原有系统调用，和不重编译内核的基础上进行操作

albcamus

汇编不够强，这种方法现在无法对execve、fork等系统调用进行截获。


x86-64上，用类似的方法，截获了ia32_sys_call_table。但运行在long模式下的程序似乎是走syscall/sysret指令的，其sys_call_table在哪里设置的还不清楚，目前还在探索阶段

朱熹之

原帖由 albcamus 于 2007-1-4 17:29 发表
汇编不够强，这种方法现在无法对execve、fork等系统调用进行截获。


x86-64上，用类似的方法，截获了ia32_sys_call_table。但运行在long模式下的程序似乎是走syscall/sysret指令的，其sys_call_table在哪里设 ...

感谢指正，我会继续看下去的

albcamus

原帖由 朱熹之 于 2007-1-4 18:16 发表


感谢指正，我会继续看下去的

啊，不是這個意思，我是說自己匯編不夠強，所以截獲execve\fork等無法處理堆棧失衡問題..

朱熹之

原帖由 albcamus 于 2007-1-5 10:31 发表


啊，不是這個意思，我是說自己匯編不夠強，所以截獲execve\fork等無法處理堆棧失衡問題..

我也没做过那两个函数的劫持，只做了下open的劫持，马上就看看这两个函数

另外，你前面说的64位下的快速系统调用的问题，我不太清楚，但我的blog上刚写了篇32位下快速调用的文章，感觉应该和64位下的有相似之处吧

http://blog.chinaunix.net/u/27624/showart_226695.html

albcamus

原帖由 朱熹之 于 2007-1-5 11:25 发表


我也没做过那两个函数的劫持，只做了下open的劫持，马上就看看这两个函数

另外，你前面说的64位下的快速系统调用的问题，我不太清楚，但我的blog上刚写了篇32位下快速调用的文章，感觉应该和64位下的 ...

2.4内核中， sys_execve可通过直接copy内核实现，也就是在自己的sys_execve中直接调用do_execve来实现，但2.6中do_execve不导出了，这种方法不再有效。  此外据我所知就只可能用汇编去平衡堆栈了，但是没有找到for 2.6的例子。


x86-64上，只做了ia32_sys_call_table的查询，代码做为附件发上来，希望有帮助