将 SYSCALL 函数存储在函数指针数组中
Storing SYSCALL functions in array of function pointers
我正在做一个项目,我必须在 OSX (10.10.5) 上挂钩 80%-90% 的系统调用函数。我正在从内核扩展中执行此操作。因为我必须(取消)挂钩许多函数,所以我想将原始内核函数存储到一个函数指针数组中,这样我就可以快速查找数组以便在取消挂钩时恢复原始函数。
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];
但是,将原始内核函数存储在函数指针数组中会导致内核恐慌。由于 error: KDP_REATTACH failed
错误,我还无法附加 lldb。我希望有人知道导致内核恐慌的原因。
下面是内核崩溃的日志。
Anonymous UUID: 052D64D2-A43C-99F8-D221-B591991E54AF
Wed 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: 0x00000000001606e0
RAX: 0x0000000000000000, RBX: 0xffffff80115e3fc0, RCX: 0x0000000000000001, RDX: 0xffffff80115e3fc0
RSP: 0xffffff8068dabaf8, RBP: 0xffffff8068dabf50, RSI: 0xffffff80115e3f80, RDI: 0xffffff8010059cf0
R8: 0xffffff7f8afaccdf, R9: 0xffffff8009ae2a18, R10: 0xffffff8009939740, R11: 0x0000000000000000
R12: 0xffffff8010059cf0, R13: 0x0000000000000005, R14: 0xffffff80115e3f80, R15: 0xffffff801188b480
RFL: 0x0000000000010282, RIP: 0x0000000000000000, CS: 0x0000000000000008, SS: 0x0000000000000010
Fault CR2: 0x0000000000000000, Error code: 0x0000000000000010, Fault CPU: 0x0 VMM
Backtrace (CPU 0), Frame : Return Address
0xffffff8068dab790 : 0xffffff80092e4ed1 mach_kernel : _panic + 0xd1
0xffffff8068dab810 : 0xffffff80093f0024 mach_kernel : _kernel_trap + 0x664
0xffffff8068dab9e0 : 0xffffff800940de53 mach_kernel : trap_from_kernel + 0x26
0xffffff8068daba00 : 0x0
0xffffff8068dabf50 : 0xffffff800982c0c1 mach_kernel : _unix_syscall64 + 0x2f1
0xffffff8068dabfb0 : 0xffffff800940e656 mach_kernel : _hndl_unix_scall64 + 0x16
BSD process name corresponding to current thread: xpcproxy
Boot args: debug=0x14e kext-dev-mode=1 -v keepsyms=1 kmem=1
Mac OS version:
14F27
Kernel version:
Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/DEVELOPMENT_X86_64
Kernel UUID: C75BDFDD-9F27-3694-BB80-73CF991C13D8
Kernel slide: 0x0000000009000000
Kernel text base: 0xffffff8009200000
__HIB text base: 0xffffff8009100000
System model name: VMware7,1 (Mac-66F35F19FE2A0D05)
System uptime in nanoseconds: 251264993940
last 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()的代码:
int
mon_open(struct proc *p, struct open_args *uap, 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 覆盖了 return 指针。您确定您不是 "restoring" 系统调用,您一开始就没有挂钩吗?
要让 lldb 与虚拟机一起工作,要求取决于不同的虚拟化环境。使用 VMWare Fusion 它应该可以正常工作,假设您使用的是 'host-only network' 或桥接模式。我上次尝试使用 VirtualBox 时它只能与 Virtio 网络设备一起使用,而我根本无法在 Parallels 上使用它,但那是几年前的事了。
请注意,如果您将串行端口添加到您的 VM,写入文本文件,您可以使用 kprintf()
登录到该文件 - 这可能对您有所帮助,因为您可以在挂钩时打印出指针值和脱钩。
笨得惊人,忘了把kern_open
(mon_open
的return值)指向数组中的函数指针。 kern_open
是 NULL
,因此这导致了 NULL
指针异常。现在函数指针数组工作正常。
@pmdj,非常感谢你的帮助。
我正在做一个项目,我必须在 OSX (10.10.5) 上挂钩 80%-90% 的系统调用函数。我正在从内核扩展中执行此操作。因为我必须(取消)挂钩许多函数,所以我想将原始内核函数存储到一个函数指针数组中,这样我就可以快速查找数组以便在取消挂钩时恢复原始函数。
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];
但是,将原始内核函数存储在函数指针数组中会导致内核恐慌。由于 error: KDP_REATTACH failed
错误,我还无法附加 lldb。我希望有人知道导致内核恐慌的原因。
下面是内核崩溃的日志。
Anonymous UUID: 052D64D2-A43C-99F8-D221-B591991E54AF
Wed 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: 0x00000000001606e0
RAX: 0x0000000000000000, RBX: 0xffffff80115e3fc0, RCX: 0x0000000000000001, RDX: 0xffffff80115e3fc0
RSP: 0xffffff8068dabaf8, RBP: 0xffffff8068dabf50, RSI: 0xffffff80115e3f80, RDI: 0xffffff8010059cf0
R8: 0xffffff7f8afaccdf, R9: 0xffffff8009ae2a18, R10: 0xffffff8009939740, R11: 0x0000000000000000
R12: 0xffffff8010059cf0, R13: 0x0000000000000005, R14: 0xffffff80115e3f80, R15: 0xffffff801188b480
RFL: 0x0000000000010282, RIP: 0x0000000000000000, CS: 0x0000000000000008, SS: 0x0000000000000010
Fault CR2: 0x0000000000000000, Error code: 0x0000000000000010, Fault CPU: 0x0 VMM
Backtrace (CPU 0), Frame : Return Address
0xffffff8068dab790 : 0xffffff80092e4ed1 mach_kernel : _panic + 0xd1
0xffffff8068dab810 : 0xffffff80093f0024 mach_kernel : _kernel_trap + 0x664
0xffffff8068dab9e0 : 0xffffff800940de53 mach_kernel : trap_from_kernel + 0x26
0xffffff8068daba00 : 0x0
0xffffff8068dabf50 : 0xffffff800982c0c1 mach_kernel : _unix_syscall64 + 0x2f1
0xffffff8068dabfb0 : 0xffffff800940e656 mach_kernel : _hndl_unix_scall64 + 0x16
BSD process name corresponding to current thread: xpcproxy
Boot args: debug=0x14e kext-dev-mode=1 -v keepsyms=1 kmem=1
Mac OS version:
14F27
Kernel version:
Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/DEVELOPMENT_X86_64
Kernel UUID: C75BDFDD-9F27-3694-BB80-73CF991C13D8
Kernel slide: 0x0000000009000000
Kernel text base: 0xffffff8009200000
__HIB text base: 0xffffff8009100000
System model name: VMware7,1 (Mac-66F35F19FE2A0D05)
System uptime in nanoseconds: 251264993940
last 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()的代码:
int
mon_open(struct proc *p, struct open_args *uap, 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 覆盖了 return 指针。您确定您不是 "restoring" 系统调用,您一开始就没有挂钩吗?
要让 lldb 与虚拟机一起工作,要求取决于不同的虚拟化环境。使用 VMWare Fusion 它应该可以正常工作,假设您使用的是 'host-only network' 或桥接模式。我上次尝试使用 VirtualBox 时它只能与 Virtio 网络设备一起使用,而我根本无法在 Parallels 上使用它,但那是几年前的事了。
请注意,如果您将串行端口添加到您的 VM,写入文本文件,您可以使用 kprintf()
登录到该文件 - 这可能对您有所帮助,因为您可以在挂钩时打印出指针值和脱钩。
笨得惊人,忘了把kern_open
(mon_open
的return值)指向数组中的函数指针。 kern_open
是 NULL
,因此这导致了 NULL
指针异常。现在函数指针数组工作正常。
@pmdj,非常感谢你的帮助。