在Linux下用gdb检测内核rootkit

　　我们也可以通过系统调用名打印出系统调用的地址：

　　(gdb) x/x sys_ni_syscall

　　0xc01261a0 : 0xffffdab8

　　((gdb) x/x sys_fork

　　0xc01078a0 : 0x8b10ec83

　　要打印出当前运行系统中的系统调用地址我们必须给gdb加两个参数：

　　a.第一个参数是内核映像文件vmliux-2.4.x

　　b.第二个参数是/proc/kcore二进制文件

　　#gdb /boot/vmlinux-2.4.* /proc/kcore

　　(gdb) x/255x 0xc0302c30

　　0xc0302c30 : 0xc01261a0 0xc011e1d0 0xc01078a0 0xc88ab11a <<--

　　0xc0302c40 : 0xc013fcb0 0xc013f0e0 0xc013f230 0xc011e5b0

　　0xc0302c50 : 0xc013f180 0xc014cb10 0xc014c670 0xc0107940

　　0xc0302c60 : 0xc013e620 0xc011f020 0xc014bcd0 0xc013e9a0

　　...

　　我们注意到第一行最后的0xc88ab11a这个地址明显不正常，这是系统调用号为3的系统调用，即sys_read (系统调用从0开始) 。

　　我们说它不正常的显著标志是它的地址高于0xc8xxxxxx，Linux默认4GB线性地址，其中最高1GB0x00000000-0xffffffff为内核保留，当一个模块被插入内核时，vmalloc函数为其分配一段地址空间，这个地址通常从0xc8800000开始...到这里已经很明显了吧？

　　系统调用劫持

　　劫持系统调用与上一种方法不同之处在于：它并不直接修改系统调用表中的入口地址，即指向每个系统调用的跳转指针，而是在想要hook的系统调用之前加一段跳转代码，使执行流重定向到入侵者自己的内核态函数，这些被hook的系统调用前部通常有call,jmp之类的汇编指令。

　　要检测这种攻击，同样使用gdb加vmlinux-2.4.*及/proc/kcore两个参数，然后反汇编系统调用：

　　#gdb /boot/vmlinux-2.4.* /proc/kcore

　　(gdb) disass sys_read

　　Dump of assembler code for function sys_read:

　　0xc013fb70 : mov $0xc88ab0a6,%ecx

　　0xc013fb73 : jmp *%ecx <<--

　　0xc013fb77 : mov %esi,0x1c(%esp,1)

　　0xc013fb7b : mov %edi,0x20(%esp,1)

　　0xc013fb7f : mov $0xfffffff7,%edi

　　...

　　我们注意"mov $0xc88ab0a6,%ecx -- jmp *%ecx"这两条指令，他跳转到了其他的地方去执行了。

　　然后再来看一下被hook之前的系统调用指令：

　　#gdb /boot/vmlinx-2.4.*

　　(gdb) disass sys_read

　　Dump of assembler code for function sys_read:

　　0xc013fb70 : sub $0x28,%esp

　　0xc013fb73 : mov 0x2c(%esp,1),%eax

　　0xc013fb77 : mov %esi,0x1c(%esp,1)

　　0xc013fb7b : mov %edi,0x20(%esp,1)

　　0xc013fb7f : mov $0xfffffff7,%edi

　　...

　　看到了吧，不一样的。

　　更改系统调用处理例程

　　入侵者可能修改一些重要的内核函数，比如系统调用处理例程system_call函数，顾名思义，这个函数对用户请求的系统调用作出响应，在系统调用表中寻找对应的入口地址，然后跳转到那里执行，这个函数中保存了系统调用表的地址。攻击者能做什么呢？另辟一块内存空间，在那里攻击者伪造自己的系统调用表，然后修改system_call函数中的系统调用表地址指向那里就可以了。