将SYSCALL函数存储在函数指针数组中

概述我正在开发一个项目,我必须在OSX(10.10.5)上挂钩80％-90％的系统调用函数.我是从内核扩展中做到这一点的.由于我必须(un)挂钩许多函数,我想将原始内核函数存储到函数指针数组中,我可以快速查找数组,以便在取消时恢复原始函数. int (*kern_open)(struct proc *, struct open_args *, int *); int mon_open(stru 我正在开发一个项目,我必须在OSX(10.10.5)上挂钩80％-90％的系统调用函数.我是从内核扩展中做到这一点的.由于我必须(un)挂钩许多函数,我想将原始内核函数存储到函数指针数组中,我可以快速查找数组,以便在取消时恢复原始函数.

int (*kern_open)(struct proc *,struct open_args *,int *);    int mon_open(struct proc *p,struct open_args *uap,int *retval) {    kern_open = sysent[SYS_open].sy_call;    sysent[SYS_open].sy_call = mon_open;

这样可行,kern_open函数用于存储调用系统调用的原始内核函数. mon_open是我的挂钩功能.

我想要实现的目标如下：因此,在取消挂钩时,我可以通过KernSysCall数组进行迭代并恢复功能.

// global array of function pointers that all have the same func def.    static int (*KernSysCall[SYS_MAXSYSCALL])(struct proc *,struct args *,int *);    KernSysCall[SYS_open] = sysent[SYS_open].sy_call;    sysent[SYS_open].sy_call = mon_open;

恢复：sysent [SYS_open] .sy_call = KernSysCall [SYS_open];

但是,将原始内核函数存储在函数指针数组中会导致内核崩溃.由于错误,我还无法附加lldb：KDP_REATTACH失败错误.我希望有人知道导致内核恐慌的原因.

下面是内核恐慌的日志.

Anonymous UUID:       052D64D2-A43C-99F8-D221-B591991E54AFWed Nov 11 12:55:06 2015*** Panic Report ***panic(cpu 0 caller 0xffffff80093f0024): Kernel trap at 0x0000000000000000,type 14=page fault,registers:CR0: 0x0000000080010033,CR2: 0x0000000000000000,CR3: 0x00000000769bb018,CR4: 0x00000000001606e0RAX: 0x0000000000000000,RBX: 0xffffff80115e3fc0,RCX: 0x0000000000000001,RDX: 0xffffff80115e3fc0RSP: 0xffffff8068dabaf8,RBP: 0xffffff8068dabf50,RSI: 0xffffff80115e3f80,RDI: 0xffffff8010059cf0R8:  0xffffff7f8afaccdf,R9:  0xffffff8009ae2a18,R10: 0xffffff8009939740,R11: 0x0000000000000000R12: 0xffffff8010059cf0,R13: 0x0000000000000005,R14: 0xffffff80115e3f80,R15: 0xffffff801188b480RFL: 0x0000000000010282,RIP: 0x0000000000000000,CS:  0x0000000000000008,SS:  0x0000000000000010Fault CR2: 0x0000000000000000,Error code: 0x0000000000000010,Fault cpu: 0x0 VMMBacktrace (cpu 0),Frame : Return Address0xffffff8068dab790 : 0xffffff80092e4ed1 mach_kernel : _panic + 0xd10xffffff8068dab810 : 0xffffff80093f0024 mach_kernel : _kernel_trap + 0x6640xffffff8068dab9e0 : 0xffffff800940de53 mach_kernel : trap_from_kernel + 0x260xffffff8068daba00 : 0x0 0xffffff8068dabf50 : 0xffffff800982c0c1 mach_kernel : _unix_syscall64 + 0x2f10xffffff8068dabfb0 : 0xffffff800940e656 mach_kernel : _hndl_unix_scall64 + 0x16BSD process name corresponding to current thread: xpcproxyBoot args: deBUG=0x14e kext-dev-mode=1 -v keepsyms=1 kmem=1Mac OS version:14F27Kernel version:Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/DEVELOPMENT_X86_64Kernel UUID: C75BDFDD-9F27-3694-BB80-73CF991C13D8Kernel slIDe:     0x0000000009000000Kernel text base: 0xffffff8009200000__HIB  text base: 0xffffff8009100000System model name: VMware7,1 (Mac-66F35F19FE2A0D05)System uptime in nanoseconds: 251264993940last loaded kext at 249789197520: my.kext   1 (addr 0xffffff7f8afa9000,size 57344)last unloaded kext at 116769666233: com.apple.driver.ApplefileSystemDriver  3.0.1 (addr 0xffffff7f8aed3000,size 16384)loaded kexts:my.kext 1[more kexts here]

在请求中,mon_open()的代码：

intmon_open(struct proc *p,int *r) {    int error;    char processname[MAXCOMLEN+1];    char intercepted_path[MAXPATHLEN];    pID_t pID = proc_pID(p);    proc_name(pID,processname,sizeof(processname));    size_t dummy = 0;    error = copyinstr((voID *)uap->path,(voID *)intercepted_path,MAXPATHLEN,&dummy);    if (!error) {        printf("[MYKEXT] open called with path: %s,PID: %d,processname: %s\n",intercepted_path,pID,processname);    }    return kern_open(p,uap,r);}

非常感谢你提前！

解决方法 恐慌日志中的0x0行表示正在调用NulL函数指针(在这种情况下更可能)或者您已经破坏了堆栈并且已经用NulL覆盖了返回指针.你确定你没有“恢复”你从未迷上过的系统调用吗？

为了让lldb使用虚拟机,需求取决于不同的虚拟化环境.假设您正在使用“仅主机网络”或桥接模式,那么使用VMWare Fusion就可以正常工作.使用VirtualBox时,我上次尝试时只能使用Virtio网络设备,而且我无法在Parallels上使用它,但那是在几年前.

请注意,如果您向VM添加串行端口,写入文本文件,则可以使用kprintf()登录到该文件 – 这可能对您有帮助,因为您可以在挂钩和取消挂钩时打印出指针值.

总结

以上是内存溢出为你收集整理的将SYSCALL函数存储在函数指针数组中全部内容，希望文章能够帮你解决将SYSCALL函数存储在函数指针数组中所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。