修改sys_call_table后调用参数获取失败<已解决>

13706808

环境是内核2.6.22，发行版为ubuntu7.10
模块的源代码如下：

1. #include <linux/sched.h>
   
2. #include <linux/module.h>
   
3. #include <linux/kernel.h>
   
4. #include <linux/init.h>
   
5. #include <linux/fs.h>
   
6. #include <linux/file.h>
   
7. 
   
8. MODULE_AUTHOR("-[email]2@163.com[/email]");
   
9. MODULE_DESCRIPTION("By hook system call table, this module can capture system calls.");
   
10. MODULE_LICENSE("GPL");
    
11. 
    
12. typedef int (*alarm_t)(int);
    
13. void** sys_call_table = (void **)0xc02fc540;
    
14. alarm_t old_func;
    
15. 
    
16. int hook(int arg)
    
17. {
    
18. printk(KERN_ALERT "<1>You got me partner: %d!\n",arg);
    
19. return arg*6;
    
20. }
    
21. static int patch_init(void)
    
22. {
    
23.     old_func=(alarm_t)sys_call_table[__NR_alarm];
    
24.     sys_call_table[__NR_alarm]=(alarm_t)hook;
    
25.     printk(KERN_ALERT "<1>SCT is patched!\n");
    
26.     return 0;
    
27. }
    
28. static void patch_cleanup(void)
    
29. {
    
30.     sys_call_table[__NR_alarm]=old_func;
    
31.     printk(KERN_ALERT "<1>SCT is unpatched!\n");
    
32. }
    
33. module_init(patch_init);
    
34. module_exit(patch_cleanup);

复制代码

附上module编译过程
文件名为sct.c
makefile内容为：object_m := sct.o
gcc -c sct.c -I/usr/src/linux-x.x.x/include SUBDIRS=$(PWD)  modules

编译成功后加载到内核空间：sudo insmod ./sct.ko
经过lsmod查看确认加载成功，同时用例程序（NASM风格）如下：

1. ; tiny.asm
   
2. BITS 32
   
3. GLOBAL _start
   
4. SECTION .text
   
5. _start:
   
6. mov eax, 27
   
7. mov ebx, 9
   
8. int 0x80
   
9. push eax
   
10. mov eax, 1
    
11. pop ebx
    
12. int 0x80

复制代码

编译：
nasm -f elf test.s
gcc -Wall -s -nostdlib test.o
编译成功后测试：./a.out ; echo $?
显示为：162
查看内核调试信息：dmesg |tail -3可以看见：
[24495.490900] SCT is patched!
[24539.639316] You got me partner: 27!
[24549.111889] SCT is unpatched!
可以发现系统调用已经被替换了，但是参数获取却出错了，上例中参数为9，却显示获得的为27（貌似是系统调用号）；
用C语言的测试结果一样（证明测试程序没有问题）
请问是为什么？？？
先谢过了！！！

[ 本帖最后由 13706808 于 2007-12-19 17:48 编辑 ]

13706808

顶一下
不要沉啊~~~

qtdszws

我在rh7.2(v2.4.7)上试了一下,没有问题啊,不知道什么原因

13706808

谢谢楼上的了
我的运行的确有问题，但是看代码又没有问题
所以很郁闷啊

继续等待
看看有没有和我有相同情况的。

honggaoyan

void** sys_call_table = (void **)0xc02fc540;怎么出来的

13706808

原帖由 honggaoyan 于 2007-12-16 02:00 发表
void** sys_call_table = (void **)0xc02fc540;怎么出来的

cat /boot/System.map-2.6.22.9|grep sys_call_table

13706808

原帖由 qtdszws 于 2007-12-14 19:04 发表
我在rh7.2(v2.4.7)上试了一下,没有问题啊,不知道什么原因

我在网上查看了不少的资料
大家都是这么写的（sys_call_table的获取方式不同）
但是我就是不对。。。。。

关键就是那个参数的问题
sys_call已经跳转到我的函数了
有记录：[24539.639316] You got me partner: 27!
可是参数却始终是27不变
想问问大家是为什么？？？
或者谁可以告诉我怎么找这个问题？
第一次写module，谢谢了

已经折腾了6天了~~~

附上module编译过程
文件名为sct.c
makefile内容为：object_m := sct.o
gcc -c sct.c -I/usr/src/linux-x.x.x/include SUBDIRS=$(PWD)  modules

[ 本帖最后由 13706808 于 2007-12-17 11:08 编辑 ]

qtdszws

你能否把sct.o的反汇编代码贴出来？
objdump -D sct.o

petsatan

2.4.7导出了sys_call_table   , 所以qtdszws  试没问题,
在2.4.18后就不导出了.
我想很可能是这个问题.

13706808

原帖由 qtdszws 于 2007-12-17 12:02 发表
你能否把sct.o的反汇编代码贴出来？
objdump -D sct.o

Disassembly of section .text: 00000000 <cleanup_module>:    0:    83 ec 04                 sub    $0x4,%esp    3:    8b 15 00 00 00 00        mov    0x0,%edx    9:    a1 00 00 00 00           mov    0x0,%eax    e:    89 50 6c                 mov    %edx,0x6c(%eax)   11:    c7 04 24 00 00 00 00     movl   $0x0,(%esp)   18:    e8 fc ff ff ff           call   19 <cleanup_module+0x19>   1d:    83 c4 04                 add    $0x4,%esp   20:    c3                       ret      21:    eb 0d                    jmp    30 <init_module>   23:    90                       nop      24:    90                       nop      25:    90                       nop      26:    90                       nop      27:    90                       nop      28:    90                       nop      29:    90                       nop      2a:    90                       nop      2b:    90                       nop      2c:    90                       nop      2d:    90                       nop      2e:    90                       nop      2f:    90                       nop    00000030 <init_module>:   30:    83 ec 04                 sub    $0x4,%esp   33:    8b 15 00 00 00 00        mov    0x0,%edx   39:    83 c2 6c                 add    $0x6c,%edx   3c:    8b 02                    mov    (%edx),%eax   3e:    a3 00 00 00 00           mov    %eax,0x0   43:    c7 02 00 00 00 00        movl   $0x0,(%edx)   49:    c7 04 24 19 00 00 00     movl   $0x19,(%esp)   50:    e8 fc ff ff ff           call   51 <init_module+0x21>   55:    31 c0                    xor    %eax,%eax   57:    83 c4 04                 add    $0x4,%esp   5a:    c3                       ret      5b:    90                       nop      5c:    8d 74 26 00              lea    0x0(%esi),%esi 00000060 <hacked_alarm>:   60:    53                       push   %ebx   61:    89 c3                    mov    %eax,%ebx   63:    83 ec 08                 sub    $0x8,%esp   66:    89 44 24 04              mov    %eax,0x4(%esp)   6a:    c7 04 24 30 00 00 00     movl   $0x30,(%esp)   71:    e8 fc ff ff ff           call   72 <hacked_alarm+0x12>   76:    8d 04 5b                 lea    (%ebx,%ebx,2),%eax   79:    01 c0                    add    %eax,%eax   7b:    83 c4 08                 add    $0x8,%esp   7e:    5b                       pop    %ebx   7f:    c3                       ret    Disassembly of section .data: 00000000 <sys_call_table>:    0:    40                       inc    %eax    1:    c5 2f                    lds    (%edi),%ebp    3:    c0                       .byte 0xc0 Disassembly of section .bss: 00000000 <orig_alarm>:    0:    00 00                    add    %al,(%eax)     ...

Disassembly of section .debug_abbrev:
Disassembly of section .debug_info:
Disassembly of section .debug_line:
Disassembly of section .rodata.str1.1:
Disassembly of section .modinfo:
Disassembly of section .debug_frame:
Disassembly of section .debug_loc:
Disassembly of section .debug_pubnames:
Disassembly of section .debug_aranges:
Disassembly of section .debug_str:
Disassembly of section .comment:
上面这几个我觉得没有什么关系，没有贴出来，如果需要，我可以补上

原帖由 petsatan 于 2007-12-17 16:03 发表
2.4.7导出了sys_call_table   , 所以qtdszws  试没问题,
在2.4.18后就不导出了.
我想很可能是这个问题.

在2.4.18后的确不导出sys_call_table了，但是我们可以通过其他方式得到这个地址
我用的是grep sys_call_table System.map的方法，简单但是可移植性差
而且的确已经正确的用我们的函数替换了原有的函数，记录中可以看见
[24539.639316] You got me partner: 27!
但是参数获取却出错了