每次遇到jni接口进入高度混淆的动态库，进行静态分析是一件头疼的事情。
如果能够实时获取到整个代码的运行路径，筛选调用pc值，便可以只做局部代码分析。

目前我开发实验室里实现的一套方案是，

1.定制内核改写ptrace逻辑
2.在app端结合类xposed框架进行调试声明
3.服务端抓取声明在内核接口链接待调试线程
4.服务端写入硬件初始断点(杜绝函数头跳板特征检测)，
5.在断点处前向读取标记下一分支类代码b/bl/br/bx/be/bne/ret，
6.在分支附近进行single_step，对link级别的指令，记录调用层级+-1，整个trace过程中限制调用层级，忽略过深的调用。
7.跳转指令single_step后，判断pc值是否在当前库映射地址范围，跳出的情形不做trace。

本方案的服务端直接写的本地可执行程序，123是实现抓取场景限制，4567同时兼顾了执行效率和流程分析块的简化，限制于当前so库。

那为什么要费劲搞这个呢，因为unidbg是个瘸子！再怎么仿真的环境依旧是仿真，能够在实机上运行的代码从效率和准确度上都有不可比拟的优势。

以及本方案是 真·用户进程so库空间无侵入 的trace+hook方案，随便你怎么CRC，因为所有.text段指令内容就没有变动过。对于懒人的缺点在于，需要自己一步步地去写trace逻辑，没有frida/xposed/QBDI等那么方便完整的接口和愈发。
分析到这一步还能看下去的人，造个轮子应该也没啥，你失去了便捷的优势，但是获得了自由。

细节部分，看大家意向，如果感兴趣想讨论的人多，后续更新部分demo代码于github。

基础知识需参考：
arm64硬件断点 https://xtuly.cn/article/arm64-kernel-research-5

[注意]看雪招聘，专注安全领域的专业人才平台！