公告
#1 2022-10-09 12:47:58
linux源码解读（十三）：内核驱动module加载kprobe&字节跳动Elkied简要分析
要想在计算机里干点事，权限肯定是越高越好的。正常情况下，cpu硬件层面保证了运行在0环的操作系统和运行在3环的用户app互相隔离，3环app要想进入0环执行代码只能通过中断或系统调用的形式，执行最多代码的应该就是硬件的驱动了，常见的屏幕打印、磁盘读写、网卡/wifi收发数据都要执行硬件驱动。因为需要被保护（防止被恶意篡改），同时也需要在多个3环进程间互斥，所以驱动都是被操作系统加载到0环的，天然拥有和操作系统其他内核代码一样的权限，因此很多需要高权限运行的功能都是以驱动的形式落地的。这里先以window为例：
windows早期防护措施不够，杀毒或逆向外挂等软件都喜欢hook SSDT来监控3环的应用程序；SSDT被hook多了容易导致蓝屏，严重影响用户体验；微软直接怒了，搞了驱动签名来严控操作系统对驱动的加载（还有pathguard监控内核代码，一旦发现被更改，直接蓝屏）；同时如果发现厂家还在通过驱动恶意hook SSDT，直接吊销签名执照，不再给驱动签名；但是部分厂家从正常的业务角度考虑确实需要hook SSDT咋办了？ 比如杀毒软件、驱动保护等业务确实需要监控系统调用，如果一刀切不让hook了，怎么保证windows系统和3环应用的安全了？微软也没赶尽杀绝，提供了回调注册的接口ObRegisterCallbacks，让厂家注册自己的回调函数。每当系统调用被执行时，就调用用户注册的回调函数执行，由此达到和hook一样的效果！
1、回到linux，毕竟也是和windows齐名的os，也是基于x86硬件架构的os，原理和windows是一样的：驱动是以模块（module）的形式加载到内核0环的，代码和操作系统内核其他代码拥有同样的权限，自然也能读写内核其他代码，这就让通过驱动hook内核代码的方式水到渠成了！那么linux面临了和早期windows一样的问题：如果放任开发人员通过驱动随意hook系统调用，可能造成的恶果：（1）不同的hook程序可能会“互相踩踏”，导致hook失效，甚至错误修改内核代码；（2）hook的代码如果没能完整地还原被破坏的机器码，或则跳转回来的地址填写出错，都会导致内核执行出错。为了避免开发人员hook内核带来的出错，linux和windows一样提供了完整的内核驱动代码hook机制：kprobe，它可以在任意的位置放置探测点（就连函数内部的某条指令处也可以），它提供了探测点的调用前、调用后和内存访问出错3种回调方式，分别是pre_handler、post_handler和fault_handler，其中pre_handler函数将在被探测指令被执行前回调，post_handler会在被探测指令执行完毕后回调（注意不是被探测函数），fault_handler会在内存访问出错时被调用；主要优势特点：
允许在同一个被探测位置注册多个kprobe，避免多个第三方程序同时hook同一段内核代码时发生“互相踩踏”，做到“有序hook”；
除了kernel/kprobes.c和arch/*/kernel/kprobes.c程序中用于实现kprobes自身的函数，外加do_page_fault和notifier_call_chain外，其他内核函数都能hook；do_page_fault和notifier_call_chain被调用太频繁，hook会降低操作系统的运行效率；并且这两个都是在中断的handler代码，需要尽快执行完毕；而且hook的业务意义也不大，所以没必要hook了！
同一个hook点的回调只会被执行一次，比如hook printk后在回调函数中再调用printk，回调函数只执行一次，避免无限嵌套递归，导致栈资源耗尽；
kprobes的注册和注销过程中不会使用mutex锁和动态的申请内存，避免占用mutex阻塞其他线程，或sleep让出cpu，导致回调长时间执行，严重影响原函数的效率；
2、kprobe工作hook流程总结如下：
当用户注册一个探测点后，kprobe首先备份被探测点的对应指令，然后将原始指令的入口点替换为断点指令，该指令是CPU架构相关的，如i386和x86_64是int3，arm是设置一个未定义指令（目前的x86_64架构支持一种跳转优化方案Jump Optimization，内核需开启CONFIG_OPTPROBES选项，该种方案使用跳转指令来代替断点指令）；
当CPU流程执行到探测点的断点指令时（把原机器码用int 3替代），就触发了一个trap，在trap处理流程中会保存当前CPU的寄存器信息并调用对应的trap处理函数，该处理函数会设置kprobe的调用状态并调用用户注册的pre_handler回调函数，kprobe会向该函数传递注册的struct kprobe结构地址以及保存的CPU寄存器信息；
随后kprobe单步执行前面所拷贝的被探测指令，具体执行方式各个架构不尽相同，arm会在异常处理流程中使用模拟函数执行，而x86_64架构则会设置单步调试flag并回到异常触发前的流程中执行；
在单步执行完成后，kprobe执行用户注册的post_handler回调函数；
最后，执行流程回到被探测指令之后的正常流程继续执行。
和其他内核功能类似，kprobe功能的实现也是由结构体+函数构成了（这里顺便多说几句：C语言没有对象的语法，所以类的继承采用了结构体包含结构体的形式；也没有成员函数的语法，只能采用结构体包含指针函数的形式实现），结构体字段如下：
struct kprobe {
struct hlist_node hlist：//被用于kprobe全局hash，索引值为被探测点的地址；
struct list_head list：//用于链接同一被探测点的不同探测kprobe；
kprobe_opcode_t *addr：//被探测点的地址；
const char *symbol_name：//被探测函数的名字；
unsigned int offset：//被探测点在函数内部的偏移，用于探测函数内部的指令，如果该值为0表示函数的入口；
kprobe_pre_handler_t pre_handler：//在被探测点指令执行之前调用的回调函数；
kprobe_post_handler_t post_handler：//在被探测指令执行之后调用的回调函数；
kprobe_fault_handler_t fault_handler：//在执行pre_handler、post_handler或单步执行被探测指令时出现内存异常则会调用该回调函数；
kprobe_break_handler_t break_handler：//在执行某一kprobe过程中触发了断点指令后会调用该函数，用于实现jprobe；
kprobe_opcode_t opcode：//保存的被探测点原始指令；
struct arch_specific_insn ainsn：//被复制的被探测点的原始指令，用于单步执行，架构强相关（可能包含指令模拟函数）；
u32 flags：//状态标记。
}最关键的字段：addr、symbol_name、offset、handler、opcode等；这里居然还有list，明显是用来连接其他hook点的！相关配套初始化、使用、卸载探测点的函数如下：
int register_kprobe(struct kprobe *kp) //向内核注册kprobe探测点
void unregister_kprobe(struct kprobe *kp) //卸载kprobe探测点
int register_kprobes(struct kprobe **kps, int num) //注册探测函数向量，包含多个探测点
void unregister_kprobes(struct kprobe **kps, int num) //卸载探测函数向量，包含多个探测点
int disable_kprobe(struct kprobe *kp) //临时暂停指定探测点的探测
int enable_kprobe(struct kprobe *kp) //恢复指定探测点的探测3、由于需要hook内核代码，权限也必须是0环的，所以也要被加载到内核。windows下的api是driver_entry和driver_exit，linux类似，用的api是module_init和moud_exit；这里以字节跳动的Elkied工具为例，在driver\LKM\src\init.c文件中，加载驱动的module的代码如下：
static int __init do_kprobe_initcalls(void)
{
int ret = 0;
struct kprobe_initcall const *const *initcall_p;
for (initcall_p = __start_kprobe_initcall;
initcall_p < __stop_kprobe_initcall; initcall_p++) {
struct kprobe_initcall const *initcall = *initcall_p;
if (initcall->init) {
ret = initcall->init();
if (ret < 0)
goto exit;
}
}
return 0;
exit:
while (--initcall_p >= __start_kprobe_initcall) {
struct kprobe_initcall const *initcall = *initcall_p;
if (initcall->exit)
initcall->exit();
}
return ret;
}
static void do_kprobe_exitcalls(void)
{
struct kprobe_initcall const *const *initcall_p =
__stop_kprobe_initcall;
while (--initcall_p >= __start_kprobe_initcall) {
struct kprobe_initcall const *initcall = *initcall_p;
if (initcall->exit)
initcall->exit();
}
}
static int __init kprobes_init(void)
{
int ret;
ret = do_kprobe_initcalls();
if (ret < 0)
return ret;
return ret;
}
static void __exit kprobes_exit(void)
{
do_kprobe_exitcalls();
}
module_init(kprobes_init);
module_exit(kprobes_exit);上面的代码只看到了通过驱动加载和初始化kprobe，但是具体hook了哪些系统调用了还不清楚，继续看driver\LKM\src\smith_hook.c代码就能发现端倪了：重要的系统调用都被hook了，https://github.com/bytedance/Elkeid/blob/main/driver/README-zh_CN.md 这里也有hook的系统调用列举；
struct kretprobe execve_kretprobe = {
.kp.symbol_name = P_GET_SYSCALL_NAME(execve),
.entry_handler = execve_entry_handler,
.data_size = sizeof(struct execve_data),
.handler = execve_handler,
};
struct kprobe call_usermodehelper_exec_kprobe = {
.symbol_name = "call_usermodehelper_exec",
.pre_handler = call_usermodehelper_exec_pre_handler,
};
struct kprobe rename_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(rename),
.pre_handler = rename_pre_handler,
};
struct kprobe renameat_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(renameat),
.pre_handler = renameat_pre_handler,
};
#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,15,0)
struct kprobe renameat2_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(renameat2),
.pre_handler = renameat_pre_handler,
};
#endif
struct kprobe link_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(link),
.pre_handler = link_pre_handler,
};
struct kprobe linkat_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(linkat),
.pre_handler = linkat_pre_handler,
};
struct kprobe ptrace_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(ptrace),
.pre_handler = ptrace_pre_handler,
};
struct kretprobe udp_recvmsg_kretprobe = {
.kp.symbol_name = "udp_recvmsg",
.data_size = sizeof(struct udp_recvmsg_data),
.handler = udp_recvmsg_handler,
.entry_handler = udp_recvmsg_entry_handler,
};
#if IS_ENABLED(CONFIG_IPV6)
struct kretprobe udpv6_recvmsg_kretprobe = {
.kp.symbol_name = "udpv6_recvmsg",
.data_size = sizeof(struct udp_recvmsg_data),
.handler = udp_recvmsg_handler,
.entry_handler = udpv6_recvmsg_entry_handler,
};
struct kretprobe ip6_datagram_connect_kretprobe = {
.kp.symbol_name = "ip6_datagram_connect",
.data_size = sizeof(struct connect_data),
.handler = connect_handler,
.entry_handler = ip6_datagram_connect_entry_handler,
};
struct kretprobe tcp_v6_connect_kretprobe = {
.kp.symbol_name = "tcp_v6_connect",
.data_size = sizeof(struct connect_data),
.handler = connect_handler,
.entry_handler = tcp_v6_connect_entry_handler,
};
#endif
struct kretprobe ip4_datagram_connect_kretprobe = {
.kp.symbol_name = "ip4_datagram_connect",
.data_size = sizeof(struct connect_data),
.handler = connect_handler,
.entry_handler = ip4_datagram_connect_entry_handler,
};
struct kretprobe tcp_v4_connect_kretprobe = {
.kp.symbol_name = "tcp_v4_connect",
.data_size = sizeof(struct connect_data),
.handler = connect_handler,
.entry_handler = tcp_v4_connect_entry_handler,
};
struct kretprobe connect_syscall_kretprobe = {
.kp.symbol_name = P_GET_SYSCALL_NAME(connect),
.data_size = sizeof(struct connect_syscall_data),
.handler = connect_syscall_handler,
.entry_handler = connect_syscall_entry_handler,
};
struct kretprobe accept_kretprobe = {
.kp.symbol_name = P_GET_SYSCALL_NAME(accept),
.data_size = sizeof(struct accept_data),
.handler = accept_handler,
.entry_handler = accept_entry_handler,
};
struct kretprobe accept4_kretprobe = {
.kp.symbol_name = P_GET_SYSCALL_NAME(accept4),
.data_size = sizeof(struct accept_data),
.handler = accept_handler,
.entry_handler = accept4_entry_handler,
};
struct kprobe do_init_module_kprobe = {
.symbol_name = "do_init_module",
.pre_handler = do_init_module_pre_handler,
};
struct kretprobe update_cred_kretprobe = {
.kp.symbol_name = "commit_creds",
.data_size = sizeof(struct update_cred_data),
.handler = update_cred_handler,
.entry_handler = update_cred_entry_handler,
};
struct kprobe security_inode_create_kprobe = {
.symbol_name = "security_inode_create",
.pre_handler = security_inode_create_pre_handler,
};
struct kretprobe bind_kretprobe = {
.kp.symbol_name = P_GET_SYSCALL_NAME(bind),
.data_size = sizeof(struct bind_data),
.handler = bind_handler,
.entry_handler = bind_entry_handler,
};
struct kprobe mprotect_kprobe = {
.symbol_name = "security_file_mprotect",
.pre_handler = mprotect_pre_handler,
};
struct kprobe setsid_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(setsid),
.pre_handler = setsid_pre_handler,
};
#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 17, 0)
struct kprobe memfd_create_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(memfd_create),
.pre_handler = memfd_create_kprobe_pre_handler,
};
#endif
struct kprobe prctl_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(prctl),
.pre_handler = prctl_pre_handler,
};
struct kprobe open_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(open),
.pre_handler = open_pre_handler,
};
struct kprobe kill_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(kill),
.pre_handler = kill_pre_handler,
};
struct kprobe tkill_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(tkill),
.pre_handler = tkill_pre_handler,
};
struct kprobe nanosleep_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(nanosleep),
.pre_handler = nanosleep_pre_handler,
};
struct kprobe exit_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(exit),
.pre_handler = exit_pre_handler,
};
struct kprobe exit_group_kprobe = {
.symbol_name = P_GET_SYSCALL_NAME(exit_group),
.pre_handler = exit_group_pre_handler,
};
struct kprobe security_path_rmdir_kprobe = {
.symbol_name = "security_path_rmdir",
.pre_handler = security_path_rmdir_pre_handler,
};
struct kprobe security_path_unlink_kprobe = {
.symbol_name = "security_path_unlink",
.pre_handler = security_path_unlink_pre_handler,
};这里就看的很清楚了，下面找几个重点函数的回调分析；
（1）execve_handler：execve可以执行指定位置的文件，hook execve后可以监控操作系统运行的所有文件，属于大杀器级别的hook，整个操作系统在干啥看得一清二楚，特别适合监控病毒、木马的运行！
int execve_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
{
int sa_family = -1;
int dport = 0, sport = 0;
__be32 dip4;
__be32 sip4;
pid_t socket_pid = -1;
char *pname = DEFAULT_RET_STR;
char *tmp_stdin = DEFAULT_RET_STR;
char *tmp_stdout = DEFAULT_RET_STR;
char *buffer = NULL;
char *pname_buf = NULL;
char *pid_tree = NULL;
char *socket_pname = "-1";
char *socket_pname_buf = NULL;
char *tty_name = "-1";
char *exe_path = DEFAULT_RET_STR;
char *pgid_exe_path = "-1";
char *stdin_buf = NULL;
char *stdout_buf = NULL;
struct in6_addr dip6;
struct in6_addr sip6;
struct file *file;
struct execve_data *data;
struct tty_struct *tty;
data = (struct execve_data *)ri->data;
buffer = kzalloc(PATH_MAX, GFP_ATOMIC);
/*当前进程所执行文件的路径*/
exe_path = smith_get_exe_file(buffer, PATH_MAX);
tty = get_current_tty();//得到当前终端
if(tty && strlen(tty->name) > 0)
tty_name = tty->name;
//exe filter check and argv filter check
if (execve_exe_check(exe_path) || execve_argv_check(data->argv))
goto out;
/*得到当前进程的socket，从这里也可以看出是不是中了木马的反弹webshell*/
get_process_socket(&sip4, &sip6, &sport, &dip4, &dip6, &dport,
&socket_pname, &socket_pname_buf, &socket_pid,
&sa_family);
//if socket exist,get pid tree
if (sa_family == AF_INET6 || sa_family == AF_INET)
pid_tree = smith_get_pid_tree(PID_TREE_LIMIT);
else
pid_tree = smith_get_pid_tree(PID_TREE_LIMIT_LOW);
// get stdin
file = fget_raw(0);
if (file) {
stdin_buf = kzalloc(256, GFP_ATOMIC);
tmp_stdin = smith_d_path(&(file->f_path), stdin_buf, 256);
fput(file);
}
//get stdout
file = fget_raw(1);
if (file) {
stdout_buf = kzalloc(256, GFP_ATOMIC);
tmp_stdout = smith_d_path(&(file->f_path), stdout_buf, 256);
fput(file);
}
pname_buf = kzalloc(PATH_MAX, GFP_ATOMIC);
pname = smith_d_path(¤t->fs->pwd, pname_buf, PATH_MAX);
/*打印收集到的各种数据*/
if (sa_family == AF_INET) {
execve_print(pname,
exe_path, pgid_exe_path, data->argv,
tmp_stdin, tmp_stdout,
dip4, dport, sip4, sport,
pid_tree, tty_name, socket_pid, socket_pname,
data->ssh_connection, data->ld_preload,
regs_return_value(regs));
}
#if IS_ENABLED(CONFIG_IPV6)
else if (sa_family == AF_INET6) {
execve6_print(pname,
exe_path, pgid_exe_path, data->argv,
tmp_stdin, tmp_stdout,
&dip6, dport, &sip6, sport,
pid_tree, tty_name, socket_pid, socket_pname,
data->ssh_connection, data->ld_preload,
regs_return_value(regs));
}
#endif
else {
execve_nosocket_print(pname,
exe_path, pgid_exe_path, data->argv,
tmp_stdin, tmp_stdout,
pid_tree, tty_name,
data->ssh_connection, data->ld_preload,
regs_return_value(regs));
}
out:
if (pname_buf)
kfree(pname_buf);
if (stdin_buf)
kfree(stdin_buf);
if (stdout_buf)
kfree(stdout_buf);
if (buffer)
kfree(buffer);
if (data->free_argv)
kfree(data->argv);
if (pid_tree)
kfree(pid_tree);
if (data->free_ld_preload)
kfree(data->ld_preload);
if (data->free_ssh_connection)
kfree(data->ssh_connection);
if(tty)
tty_kref_put(tty);
return 0;
}（2）mprotect_pre_handler：hook了security_file_mprotect的回调函数，这个函数可能不出名，她是在do_mprotect_pkey中被调用的，整个mprotect的调用链如下：
SYSCALL_DEFINE3(mprotect, .., start, .., len, .., prot)
-> do_mprotect_pkey(start, len, prot, pkey=-1)
-> mprotect_fixup(vma, .., start, end, newflags)
-> change_protection(vma, start, end, newprot, cp_flags)
-> change_protection_range(vma, addr, end, newprot, cp_flags)
-> change_p4d_range(vma, pgd, add, end, newprot, cp_flags)
-> change_pmd_range(vma, pud, addr, end, newprot, cp_flags)
-> change_pte_range(vma, pmd, addr, end, newprot, cp_flags)从底层的change_pte_rang、change_pmd_range、change_p4d_range可以看出，mprotect函数最终改变的是页属性，这个也可以用来做反调试的：把关键的代码地址改为可读可执行，但是不可写，就没法下断点调试了；正常情况下，代码也只会被读，然后执行。如果被改写，肯定不是正常情况，所以可以hook这个链条上的方法来监控关键代码是否被调试了。如果页面不可写，强行更改数据会报SIGSEGV错，用ida调试x音的时候没少遇到这种弹窗吧？不过从公开的资料看，Elkeid貌似并没用在x音客户端的防护，只是在字节内部的生产环境，监控的是服务器操作系统的运行；回调函数代码如下：
int mprotect_pre_handler(struct kprobe *p, struct pt_regs *regs)
{
int target_pid = -1;
unsigned long prot;
char *file_path = "-1";
char *file_buf = NULL;
char *vm_file_path = "-1";
char *vm_file_buff = NULL;
char *exe_path = "-1";
char *abs_buf = NULL;
char *pid_tree = NULL;
struct vm_area_struct *vma;
//only get PROT_EXEC mprotect info
//The memory can be used to store instructions which can then be executed. On most architectures,
//this flag implies that the memory can be read (as if PROT_READ had been specified).
prot = (unsigned long)p_regs_get_arg2(regs);
if (prot & PROT_EXEC) {
abs_buf = kzalloc(PATH_MAX, GFP_ATOMIC);
exe_path = smith_get_exe_file(abs_buf, PATH_MAX);//当前进程对应文件的路径
vma = (struct vm_area_struct *)p_regs_get_arg1(regs);
if (IS_ERR_OR_NULL(vma)) {
mprotect_print(exe_path, prot, "-1", -1, "-1", "-1");
} else {
rcu_read_lock();
if (!IS_ERR_OR_NULL(vma->vm_mm)) {
if (!IS_ERR_OR_NULL(&vma->vm_mm->exe_file)) {
if (get_file_rcu(vma->vm_mm->exe_file)) {
file_buf = kzalloc(PATH_MAX, GFP_ATOMIC);
file_path = smith_d_path(&vma->vm_mm->exe_file->f_path, file_buf, PATH_MAX);
fput(vma->vm_mm->exe_file);
}
}
#ifdef CONFIG_MEMCG
target_pid = vma->vm_mm->owner->pid;
#endif
}
if (!IS_ERR_OR_NULL(vma->vm_file)) {
if (get_file_rcu(vma->vm_file)) {
vm_file_buff =
kzalloc(PATH_MAX, GFP_ATOMIC);
vm_file_path = smith_d_path(&vma->vm_file->f_path, vm_file_buff, PATH_MAX);
fput(vma->vm_file);
}
}
rcu_read_unlock();
/*被修改内存属性的pid树，从这里可以看到关键进程是不是在被调试等*/
pid_tree = smith_get_pid_tree(PID_TREE_LIMIT);
mprotect_print(exe_path, prot, file_path, target_pid, vm_file_path, pid_tree);
}
if (pid_tree)
kfree(pid_tree);
if (file_buf)
kfree(file_buf);
if (abs_buf)
kfree(abs_buf);
if (vm_file_buff)
kfree(vm_file_buff);
}
return 0;
}（3）ptrace：调试全靠它了，frida和ida这俩卧龙凤雏用的都是这个。要想监控自己的进程是不是被调试了，必须监控ptrace了！回调代码如下：
int ptrace_pre_handler(struct kprobe *p, struct pt_regs *regs)
{
long request;
request = (long)p_get_arg1(regs);
//only get PTRACE_POKETEXT/PTRACE_POKEDATA ptrace
//Read a word at the address addr in the tracee's memory,
//returning the word as the result of the ptrace() call. Linux
//does not have separate text and data address spaces, so these linux居然没区分代码和数据空间
//two requests are currently equivalent. (data is ignored; but
//see NOTES.)
/*PTRACE_PEEKTEXT或PTRACE_PEEKDATA:从addr参数指示的地址开始读取一个WORD的长度的数据并通过返回值传递回来*/
if (request == PTRACE_POKETEXT || request == PTRACE_POKEDATA) {
long pid;
void *addr;
char *exe_path = DEFAULT_RET_STR;
char *buffer = NULL;
char *pid_tree = NULL;
pid = (long)p_get_arg2(regs);
addr = (void *)p_get_arg3(regs);
if (IS_ERR_OR_NULL(addr))
return 0;
buffer = kzalloc(PATH_MAX, GFP_ATOMIC);
/*得到当前文件路径*/
exe_path = smith_get_exe_file(buffer, PATH_MAX);
/*得到当前进程的进程树*/
pid_tree = smith_get_pid_tree(PID_TREE_LIMIT);
/*打印结果*/
ptrace_print(request, pid, addr, "-1", exe_path, pid_tree);
if(buffer)
kfree(buffer);
if(pid_tree)
kfree(pid_tree);
}
return 0;
} 不过和ida有点不同，frida使用ptrace attach到进程之后，往进程中注入一个frida-agent-32.so模块，此模块是frida和frida-server通信的重要模块，所以frida不会一直占用ptrace，注入模块完成后便detach，所以ptrace回调函数收集到的数据可能不会太多！
目前所有的handler仅仅是收集进程名称、进程id树、文件路径、文件名或其他相关信息，貌似并未才取任何反制措施。也难怪，这个是用在后台服务端的，不是客户端，没必要才取exit或其他反制措施.....
4、大家平时用frida hook native代码的时候，有onEnter和onLeave两个分支，分别是进入native函数和离开native函数时挂钩，前者一般用来查看或修改函数的参数，后者一般用来查看和修改函数返回值，其实在linux底层已经提供了相应的方式来达到同样的目的：jprobe和kretprobe，并且这两个都是基于kprobe实现的！
参考：
1、https://cloud.tencent.com/developer/article/1874723?from=15425%20%20%20L Linux内核调试技术——kprobe使用与实现
2、https://yaotingting.net/2021/05/09/mprotect-analysis/ Linux/mprotect源码分析
3、https://github.com/bytedance/Elkeid/blob/main/driver/README-zh_CN.md About Elkeid(AgentSmith-HIDS) Driver
4、https://zhuanlan.zhihu.com/p/347313289 systemtap介绍
离线