【Abyss】Android 平台应用级系统调用拦截框架
Android 平台从上到下,无需 ROOT/解锁/刷机,应用级拦截框架的最后一环 ——
SVC
系统调用拦截。
由于我们虚拟化产品的需求,需要支持在普通的Android
手机运行。我们需要搭建覆盖应用从上到下各层的应用级拦截框架,而Abyss
作为系统SVC
指令的调用拦截,是我们最底层的终极方案。
01. 说明
tracee: 被ptrace
附加的进程,通常为目标应用进程。
tracer: 用来ptrace
其他进程的进程,在该进程里处理系统调用。
本框架利用Android
的Provider
组件启动拦截处理的服务进程,进程启动后创建独立的一个线程循环处理所有拦截的系统调用回调。由于本工程只是演示方案的可行性并打印日志,所以业务逻辑处理比较简单,可以根据需要的自行扩展。
若要接入具体业务,可能需要改成多线程的方式进行处理,提升稳定性。不过我们实测多线切换也有一定损耗,性能提升有限,但确实稳定性有提升,防止某个处理耗时导致应用所有进程阻塞。
02. 处理流程
应用进程tracee
被附加流程如下:
tracer
过程如下:
说明: 使用fork()
的目的是为了让工作线程去附加。ptrace
有严格的限制,只有执行附加attach
的线程才有权限操作对应tracee
的寄存器。
03. 系统调用处理
03.01 忽略库机制
由于业务的需要,为了提升性能,我们需要忽略某些库中的系统调用,如:libc.so
。
在find_libc_exec_maps()
中找到libc.so
可执行代码在maps
中的内存地址区间,需要处理的系统调用:
set_seccomp_filters
针对不同的arch
,设置系统调用的ebpf
。不同架构的ebpf
语句会填充到一起,ebpf
的组成伪代码如下:
最终,调用如下语句,设置ebpf
。
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 拦截日志
04. 附
额外模块:
由于本框架会在原应用中增加一个处理进程,并且会trace
到应用进程中,因此在实际使用时,还需要对新增进程和trace
痕迹进行隐藏,防止与应用检测模块冲突,支持完整的应用自身trace
调用的仿真。
这是附加的应用对抗模块,后面会作为单独文章分享给大家。
参考项目:
https://github.com/proot-me/proot
https://github.com/termux/proot
评论