linux源码解读（十三）：内核驱动module加载kprobe&字节跳动Elkied简要分析

dummy@example.com (batsom) — Sun, 09 Oct 2022 03:47:58 +0000

要想在计算机里干点事，权限肯定是越高越好的。正常情况下，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介绍

Gentoo中文社区 / linux源码解读（十三）：内核驱动module加载kprobe&字节跳动Elkied简要分析

linux源码解读（十三）：内核驱动module加载kprobe&字节跳动Elkied简要分析