基于eBPF的安卓逆向辅助工具—

前言

stackplz是一款基于eBPF技术实现的追踪工具，目的是辅助安卓native逆向，仅支持64位进程，主要功能如下：

hardware breakpoint 基于pref_event实现的硬件断点功能，在断点处可读取寄存器信息，不会被用户态探测到
- 前提是需要内核启用CONFIG_HAVE_HW_BREAKPOINT，5.10+内核默认开启
uprobe hook 即在用户态对动态库下断点，在断点处可读取寄存器等上下文信息
trace syscall 即在内核态对syscall进行追踪，输出syscall信息，无视任何反调试
自动追踪fork产生的进程，可按pid/uid/tid/package等组合进行过滤
在命中hook的时候可发送信号，例如发送SIGSTOP可挂起进程（硬件断点暂未实现发送信号
- 几乎无视反调试，并且此时可以使用lldb等调试器附加到进程，获取上下文内容
- 如果进程已经处于相互ptrace的状态，则调试器不可附加，但此时还是可以通过dd等手段获取上下文内容
使用上述功能时，均可回溯堆栈

使用要求：内核 5.10+（开发板+ReDroid也是可以的，当前支持rock5b），该限制主要来自于需要使用bpf_probe_read_user接口

stackplz最初是受到定制bcc/ebpf在android平台上实现基于dwarf的用户态栈回溯启发，加上自己对eBPF技术略有一点研究，然后决定开发这样一款工具

当时核心目的是寻求一种门槛低、不依赖额外环境、能实际落地的方案开发eBPF程序

受限于当时高版本内核安卓设备的普及程度，只实现了寄存器获取与堆栈回溯，限制是内核要求4.14+

经过一年左右的发展，GKI 2.0设备多了起来，各类eBPF相关的内容不断涌现，加上之前自己立了flag

于是最近几个月把之前给stackplz立的flag给陆续落地，加上了许多功能，以期能真正将eBPF技术投入实际的安卓逆向分析中

另外KernelSU近期也发布了新的计划：

su 使用日志；通过在内核中跟踪 fork, execve 等系统调用，给出调用 su 的进程调用的日志，如时间，命令行参数等。
集成支持硬件断点并提供用户空间接口，为开发和调试提供便利。
在 kernel 中集成 Lua 解释器并为用户空间提供接口；这样可以让内核运行 lua 脚本，等同于无限制的 eBPF，成为 tracing 好帮手。

什么，无限制的eBPF？那真的是太好了！ 所以本文再不出，stackplz就要凉啦(>_<)

再次说明要求与限制：内核 5.10+，仅支持64位进程

请前往Releases或者Actions下载使用

adb push stackplz /data/local/tmp

chmod +x /data/local/tmp/stackplz

cd /data/local/tmp && ./stackplz --prepare

注意：每次更新版本请手动执行一次./stackplz --prepare

功能演示

本文演示过程中没有任何APP受到伤害！

写原理太枯燥你们可能就划走了，下次再写，还是先看看实际效果吧~

1. 硬件断点

硬件断点支持四种类型，即r,w,x,rw，断点长度为4字节

命令中必须提供pid，断点绝对地址或者断点偏移+动态库名，下面是两个示例效果：

1	`./stackplz` `-p 37919 --brk 0xf3a4:x --brk-lib libnative-lib.so --stack`

1	`./stackplz` `-p 37919 --brk 0x763e6103a4:x --regs --stack --stack-size 4096`

说明：

--regs 输出寄存器信息
--stack 默认获取用户态8192字节的栈上数据用于回溯堆栈
--stack-size 可以用于指定要获取的栈上数据大小，必须是8的倍数

如果要给内核空间的地址下硬件断点，可以使用pid+绝对地址的方式，pid给定一个存在的进程即可（不过目前没有回溯内核堆栈的功能，所以给内核空间地址下硬件断点聊胜于无

2. uprobe hook

其原理是替换目标位置动态库的指令为brk指令，执行到目标位置的时候会陷入内核，执行eBPF虚拟机中的代码

美中不足的是，这个brk指令是可以被扫描出来的，但优势也是只有这一个brk指令，没有inlinehook那么多特征

如果确实担心被扫描，那么可以采用硬件断点先检查下^_^

基于该能力，stackplz可以在断点位置读取上下文的内容，在逆向时以最小的侵入力度获取想要的内容，尽可能避开检测

下面是具体效果：

1	`./stackplz` `-n com.sfx.ebpf --point strstr[str,str] --getoff --stack`

1	`./stackplz` `-n com.sfx.ebpf -l libnative-lib.so -w _Z5func4i[int] --regs`

./stackplz -n com.sfx.ebpf -w open64[str,int] -f w:/data

./stackplz -n com.sfx.ebpf -w open64[str.f0,int] -f w:/data

./stackplz -n com.sfx.ebpf -w open64[str.f0.f1.f2,int] -f w:/data -f b:/sys -f w:/proc

说明：

--getoff 计算LR与PC的偏移情况，方便快速定位调用位置
-l/--lib 指定动态库路径，默认为libc.so
- 大多数情况下使用库名即可，如果遇到同名不同路径，或者找不到的情况，可手动指定为/proc/{pid}/maps中的完整路径
-w/--point 意为观测点，配合动态库指定符号或者偏移，可设置多个，上限6个
- 语法是{符号/基址偏移}{+偏移}{[参数类型{寄存器/读取地址},参数类型{.f{规则索引}}]}
- 一个观测点下最多读取10个参数
- 一个参数下最多应用6个过滤规则
- 下面是一些使用组合示例，目前支持的类型：int,uint,int64,uint64,str,ptr,buf
- -w _Z5func1v
- -w 0x9542c[str,str]
- -w strstr+0x4[str,str]
- -w strstr[str,str] -w open[str,int]
- -w 0xA94E8[int:x1,ptr:sp+0x30-0x2c]
  - 默认按寄存器顺序读取，也可以参考本示例，在第一个位置读取x1为int，在第二个位置读取sp+0x30-0x2c为指针
  - 没错，可以进行简单的计算，这样能够灵活读取栈上的内容
- -w write[int,buf:x2,int]
- -w write[int,buf:32,int]
- -w write[int,buf:0x10,int]
  - buf较为特殊，规则如下：
  - 如果:后面是寄存器表明以该寄存器大小为长度读取数据
  - 如果:后面是十进制或十六进制字符串，则表明以这个数的大小为长度读取数据
- -w write[buf:x2:x1,int,int]
  - 这里的规则表示，读取第一个参数时，读的是x1寄存器，长度为x2，即:后的第一个内容表示长度，末尾的才是要读取的寄存器
-f/--filter 字符串过滤规则，有三种，分别是w/white b/black r/replace，示例如下
- 规则位于参数的末尾，多个规则以.作为分隔符
- 替换规则涉及两个字符串，以:::作为分隔符
- 示例如下，依次为白名单规则、黑名单规则、替换规则：
  - -f w:/data
  - -f b:/sys
  - -f r:/system/bin/su:::/system/bin/zz
- -w openat[int,str.f0.f1] 意为对符号openat的第二个参数，应用规则0和规则1
- -s openat:f0 这是syscall，先在这里说了，意为对openat系统调用的第一个字符串参数应用规则0，注意分隔符为:

3. trace syscall

原理是将eBPF程序挂载到raw_tracepoint/sys_enter和raw_tracepoint/sys_exit，然后根据预设配置解析参数

追踪syscall的时候自然也是能输出堆栈的，不过限于篇幅，下面的例子中就不演示了，加--stack即可

下面是具体效果：

1	`./stackplz` `-n com.sfx.ebpf -s openat,socket,connect`

1	`./stackplz` `-n com.sfx.ebpf -s %file,%net --no-syscall openat,recvfrom`

1	`./stackplz` `-n ???.???.??? -s openat:f0.f1.f2 -f w:/system` `-f w:/dev` `-f b:/system/lib64` `-o tmp.log`

说明：

-s/--syscall 一般情况，追踪多个syscall要用,作为分隔符
- 还可以使用下面的内容进行分组追踪，避免手打大量syscall名
  - all %attr %file %exec %clone %process %net %signal %kill %stat
- 对syscall中的参数进行过滤，示例如下，使用:作为起始分隔符，使用.作为多个规则的分隔符
  - -s openat:f0.f1.f2
- syscall的参数过滤仅支持syscall的首个字符串参数

4. 进阶使用

下面将演示如何过root检查，虽然对于eBPF来说做这个事情比较鸡肋，但是还是值得演示一下

核心原理就是通过bpf_probe_write_user方法修改内存数据，这里过root检查就是简单替换下相关的字符串

再次说明：本文演示过程中没有任何APP受到伤害！

这里请一位不愿透露姓名的APP做演示，过程如下：

首先执行第一个命令，该命令意为追踪execve和openat两个系统调用
打开APP，很快啊，APP就崩溃了；这个时候已经采集到syscall的调用情况了，从日志中检查调用的参数，发现有su相关的访问
还是执行第一个命令，然后另开一个shell，执行第二个命令，将有关su的访问替换为其他字符串
打开APP，很快啊，APP还是崩溃了，不过可以发现APP执行得更久一点...
配合使用--stack、--mstack和--getoff，进行更准确的分析
以此往复，最终发现APP还会执行mount和which su等命令，而且是走的libc.so，于是再开一个shell执行第三个命令

./stackplz -n ???.???.???,iso -s execve,openat -o tmp_s.log

./stackplz -n ???.???.???,iso -s execve:f3,openat:f0.f1.f2 -f r:/sbin/su:::/xx -f r:/system/bin/su:::/xx -f r:/system/xbin/su:::/xx -f r:/system/bin/getprop:::/xx