这篇文章上次修改于 353 天前，可能其部分内容已经发生变化，如有疑问可询问作者。

前言

众所周知，stackplz的调用栈对java层的显示不是很好，有时候甚至没有

不过stackplz的--kill选项可以帮助我们将进程挂起，挂起后有的是办法查看调用栈

其他：termux + lldb

案例

案例一：

首先我们通过下面的命令看看有没有/sbin/su的访问操作：

./stackplz -n com.chinarainbow.tft -s %file | grep "/sbin/su"

Amazing啊！可以看到有使用faccessat访问/sbin/su

接下来，我们配合过滤和--kill发信号这两个功能，将进程在通过faccessat访问/sbin/su时挂起

./stackplz -n com.chinarainbow.tft -s faccessat:f0 -f w:/sbin/su --kill SIGSTOP

进程已经是挂起状态了，现在我们使用lldb直接附加，这样的堆栈是不是很明显了呢？

刚才还有一个进程，切换附加到这个进程看看，注意这里附加后需要切换下线程，可以看到是Java层的函数在检查

还有一个进程，也是一样的调用栈

案例二：

这是会闪退的APP，还是一样的操作

rk3588_syf:/data/local/tmp # ./stackplz -n com.starbucks.cn -s %file | grep "/sbin/su"
[29712|29712|om.starbucks.cn] openat(dirfd=-100, *pathname=0x7fc25f3df9(/sbin/su), flags=0x0, mode=0o000) LR:0x7661b0fe34 PC:0x7661b52838 SP:0x7fc25f3b00
^C
130|rk3588_syf:/data/local/tmp # ./stackplz -n com.starbucks.cn -s openat:f0 -f w:/sbin/su --kill SIGSTOP --stack
findBTFAssets btf_file=rock5b-5.10-arm64_min.btf
warn, no running process of com.starbucks.cn
hook syscall count:1
ConfigMap{stackplz_pid=29757,thread_whitelist=0}
uid => whitelist:[10083];blacklist:[]
pid => whitelist:[];blacklist:[]
tid => whitelist:[];blacklist:[]
start 2 modules
[29780|29780|om.starbucks.cn] openat(dirfd=-100, *pathname=0x7fc25f3df9(/sbin/su), flags=0x0, mode=0o000) LR:0x7661b0fe34 PC:0x7661b52838 SP:0x7fc25f3b00, Backtrace:
  #00 pc 000000000009d838  /apex/com.android.runtime/lib64/bionic/libc.so (__openat+8)
  #01 pc 000000000005ae30  /apex/com.android.runtime/lib64/bionic/libc.so (open+212)
  #02 pc 00000000000b9a8c  /data/app/~~keEJcFzTQnBMnL2csvgW9A==/com.starbucks.cn-T8YBKMLJ1VwyP62I2slt-g==/lib/arm64/libDexHelper.so

[29780|29780|om.starbucks.cn] openat(dirfd=-100, *pathname=0x7fc25f3df9, flags=0x0, mode=0o000, ret=60)

总结

总之，过滤 + 发信号挂起进程，再用lldb等调试器附加上去打堆栈，这样得到的java堆栈会比较完整

1. hook syscall不会被检查到
2. lldb附加的时候进程已经是挂起状态，它什么也做不了
3. lldb处理完之后，detach取消附加，stackplz输入c回车，进程恢复运行

APP: 好像有谁来过，但它是谁...

这就是时停的快乐，事了拂衣去，深藏身与名...