Android平台从上到下，无需ROOT/解锁/刷机，应用级拦截框架的最后一环 —— SVC系统调用拦截。
☞ Github ☜
400.png (118.34 KB, 下载次数: 0)
下载附件
2024-9-19 09:17 上传
由于我们虚拟化产品的需求，需要支持在普通的Android手机运行。我们需要搭建覆盖应用从上到下各层的应用级拦截框架，而Abyss作为系统SVC指令的调用拦截，是我们最底层的终极方案。
01. 说明
tracee： 被ptrace附加的进程，通常为目标应用进程。
tracer： 用来ptrace其他进程的进程，在该进程里处理系统调用。
本框架利用Android的Provider组件启动拦截处理的服务进程，进程启动后创建独立的一个线程循环处理所有拦截的系统调用回调。由于本工程只是演示方案的可行性并打印日志，所以业务逻辑处理比较简单，可以根据需要的自行扩展。
若要接入具体业务，可能需要改成多线程的方式进行处理，提升稳定性。不过我们实测多线切换也有一定损耗，性能提升有限，但确实稳定性有提升，防止某个处理耗时导致应用所有进程阻塞。
02. 处理流程
应用进程tracee被附加流程如下：
401.png (105.67 KB, 下载次数: 0)
下载附件
2024-9-19 09:17 上传
tracer过程如下：
402.png (142.81 KB, 下载次数: 0)
下载附件
2024-9-19 09:17 上传
说明： 使用fork()的目的是为了让工作线程去附加。ptrace有严格的限制，只有执行附加attach的线程才有权限操作对应tracee的寄存器。
03. 系统调用处理
03.01 忽略库机制
由于业务的需要，为了提升性能，我们需要忽略某些库中的系统调用，如：libc.so。
在find_libc_exec_maps()中找到libc.so可执行代码在maps中的内存地址区间，需要处理的系统调用：
//enable_syscall_filtering()
FilteredSysnum internal_sysnums[] = {
{ PR_ptrace, FILTER_SYSEXIT },
{ PR_wait4, FILTER_SYSEXIT },
{ PR_waitpid, FILTER_SYSEXIT },
{ PR_execve, FILTER_SYSEXIT },
{ PR_execveat, FILTER_SYSEXIT },
{PR_readlinkat, FILTER_SYSEXIT}, //暂时没有处理
};
set_seccomp_filters针对不同的arch，设置系统调用的ebpf。不同架构的ebpf语句会填充到一起，ebpf的组成伪代码如下：
for (每一种架构) {
start_arch_section;
for (每一个当前架构下的系统调用)
add_trace_syscall;
end_arch_section;
}
finalize_program_filter;
start_arch_section;// 架构相关处理的ebpf,包括libc筛选的语句
add_trace_syscall;// 增加匹配要处理系统调用的ebpf语句
end_arch_section;// 尾部的ebpf语句(语句含义:匹配到系统调用则返回)
finalize_program_filter;// 最后面的ebpf语句,杀死其他异常情况下的线程
最终，调用如下语句，设置ebpf。
status = prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &program);
03.02 PR_ptrace
因为一个tracee只能有一个tracer，所以需要处理该系统调用，在应用本身使用了ptrace的时候进行仿真。
系统调用进入前，将系统调用替换为PR_void,不做真正的ptrace，后续仿真。
退出系统调用后，针对ptrace的仿真。针对请求是PTRACE_ATTACH、PTRACE_TRACEME等做各种不同的处理。同时也处理PTRACE_SYSCALL、PTRACE_CONT、PTRACE_SETOPTIONS、PTRACE_GETEVENTMSG等各种ptrace操作。
ptrace有各种各样的请求，完整的处理逻辑比较复杂（我们还在消化中）。
03.03 PR_wait4、PR_waitpid
配合PR_ptrace使用，如果当前的tracee不是一个tracer，则不处理直接透传给系统。或者wait的第一个参数不为-1，则去集合里找看等待的这个线程是否存在并且是否是当前处理线程的tracee，如果不是，则不处理直接透传给系统。
处理的逻辑如下：
系统调用进入前，将系统调用替换为PR_void，不实际传给内核。
退出系统调用后，仿真tracer里wait的处理逻辑。主要为基于当前处理的这个tracer（代码里定义为ptracer），去遍历它的tracee，看是否有事件需要被处理，如有，则填充好寄存器，唤醒当前正在被处理的这个tracer。
03.04 PR_execve、PR_execveat
主要是在USE_LOADER_EXE开启时，将native程序替换为使用一个固定的loader来加载程序。
03.05 拦截日志
E INTERCEPT/SYS: vpid 2: got event 7057f
E INTERCEPT: vpid 2,secomp_enabled 0,
E INTERCEPT/SYS: (null) info: vpid 2: sysenter start: openat(0xffffff9c, 0xb4000073c72fcd60, 0x0, 0x0, 0xb4000073c72fcd88, 0xb4000073c72fcde8) = 0xffffff9c [0x7367d45e80, 0]
E INTERCEPT/SYS: vpid 2: open path:/system/fonts/NotoSansMalayalamUI-VF.ttf
E INTERCEPT/SYS: syscall_number:216
E INTERCEPT/SYS: vpid 2,openat: /system/fonts/NotoSansMalayalamUI-VF.ttf
E INTERCEPT/SYS: (null) info: vpid 2: sysenter end: openat(0xffffff9c, 0xb4000073c72fcd60, 0x0, 0x0, 0xb4000073c72fcd88, 0xb4000073c72fcde8) = 0xffffff9c [0x7367d45e80, 0]
E INTERCEPT/SYS: vpid 2: open path:/system/fonts/NotoSansMalayalamUI-VF.ttf
E INTERCEPT/SYS: (null) info: vpid 2: restarted using 7, signal 0, tracee pid 32222,app_pid 32162
E/INTERCEPT/SYS: (null) info: vpid 3: sysenter start: close(0x90, 0x0, 0x7492d0d088, 0x6, 0x73b7b82860, 0x73b7b82880) = 0x90 [0x73633faae0, 0]
E/INTERCEPT/SYS: syscall_number:41
E/INTERCEPT/SYSW: noting to do,sn:41
E/INTERCEPT/SYS: (null) info: vpid 3: sysenter end: close(0x90, 0x0, 0x7492d0d088, 0x6, 0x73b7b82860, 0x73b7b82880) = 0x90 [0x73633faae0, 0]
E/INTERCEPT/SYS: (null) info: vpid 3: restarted using 7, signal 0, tracee pid 32223,app_pid 32162
E/INTERCEPT/SYS: vpid 3: got event 7057f
04. 附
额外模块：
由于本框架会在原应用中增加一个处理进程，并且会trace到应用进程中，因此在实际使用时，还需要对新增进程和trace痕迹进行隐藏，防止与应用检测模块冲突，支持完整的应用自身trace调用的仿真。
这是附加的应用对抗模块，后面会作为单独文章分享给大家。
参考项目：
https://github.com/proot-me/proot
https://github.com/termux/proot
