2万字长文，写了给我累死了，本来可以直接随便写写就发的，但是还是写好一些吧，唉，我这算是完美主义者么？本文分三大部分：新手老手都能看，希望对你有用。如果是 星球 用户可以直接移步第三部分，当然建议前面也看看；我知道大家最想看啥，所以把对比放到前面来了；我把5个trace工具在同一个目标函数上跑一遍最直观。bench 用的 demo：当然有人会杠说我测试不够多啥的，对此我只能说事实胜于雄辩，不信就自己测试。哦因为介绍了我自己的trace工具，可能还会有人说软广啥的，随便说，好的工具值得拿出来宣传，而且我自己也把优化点分享出来了(我觉得做到这一步已经很好了),有动手能力的都能自己写一个trace工具。结果：注：AndroidPrybar 崩溃位置在 libtrace.so 偏移 0x510a2c–0x5666c8 之间 8 帧（SIGSEGV / SEGV_MAPERR / fault addr 0x0），作者 README 也直接写了"代码让ai改崩溃了，一些功能不太稳定"。vmtrace 接口和其他几家不同：它要求"Interceptor.replace 目标函数 → callback 里调 qbdi_vm_call(targetAddr, argsPtr, argNum, logPath, dumpMem) → 返回结果"，等于把"切入 trace VM"和"调用目标"绑成了一次调用。某种程度上更直观（一行 trace 一个函数），但只能从函数边界进入，且接入方需要自己组装参数指针数组（参数个数填错会崩）。几个观察点：当然这就是 demo 上的单点数据，实战中不同样本（深递归、大量子线程、自定义 linker、JNI 调用密集型等）相对差距会变。bench 脚本和 demo 已经放在仓库 trace_compare/bench/ 下，欢迎自己换样本复现。为什么会有这么大的差距？这就涉及指令级 trace 到底在做什么、各家选了什么底层引擎、还有 xfQTrace 在 QBDI 之上做了哪些工程化改动 —— 接下来一层层说清楚。先来一大段背景，可跳过：最近一两个月，先是休息了半个月，打打游戏啥的，然后实在是压力太大了，一天不逆向浑身难受啊，跟蚂蚁在爬一样，然后就开始逆向了。最近一个月在学习密码学经典算法的设计原理相关的内容，感觉学起来还是有点难度的，很有意思。后续会用remotion来创作高质量视频，然后发布到b站给大家补点相关基础，放心讲的会非常非常详细，设计原理/手搓实现/汇编特征/魔改怎么逆等等；然后平时偶尔逆向一下实战案例，一些安全SDK那种，过程中发现很多案例用unidbg来补会有一些问题，虽然中等难度的app大多都可以解决，但是稍微再难的就不方便处理了，与其耗时在深度魔改unidbg让其更像一个android，不如直接写一个优秀的真机trace工具；反正一个信息很全的trace日志，ai只需要使用ripgrep就可以暴力分析了，然后我们拿到分析结果之后就可以开始复现，这样可以利用ai当老师然后不断追问来进行学习，哪怕是vmp的案例也是照样逆完学习；所以就会有明显痛点了，开源的真机trace好像有很多问题，而且直接用别人开源的成品好像原理啥的我也掌握不到位呀，俺是来学习的又不是来直接用成品的。所以一周前我开始学习qbdi，然后顺便开始开发我自己用的真机trace工具，连续3天睡眠加起来不超过14小时吧，也是非常抽象了，也是压根睡不着*几发还是一样哈哈哈哈；好在最近几天已经完工了，可以美美休息几天了。然后感觉自己做的比开源的工具对比下来会有很多明显优点吧，自己也倾注了很多心血，而且后续还会支持俺的ttd；然后我认为单独收费卖感觉不太好，因为其实技术含金量不是很高，重要的是怎么思考到这些优化点，优化的点都是我一步步思考出来的； 那为啥我不打算免费发出来呢？基本上就是这三点，寒了多少愿意开源的朋友的心。所以仔细考虑下来，就打算把工具免费丢到 星球 了。当然你也可以认为我是为了引流吧，我承认有这一部分原因，但更多的是心确实已经寒了。（另外其实我在b站已经送出去很多朋友 星球 了，都是愿意分析文章或者工具或者都愿意点拨我的）那发到 星球 还有什么好处？因为诚实来说俺也没啥稳定收入，平时也不接点单，也没工作，现在就靠 星球 赚点生活费，能靠这样能引流几个人进去也算不错了；我个人认为就这样处理最妥当，如果还是被喷的话那就随他吧，反正这圈子遇到的神人确实还挺多的哈哈哈哈；但是！！有很多朋友仍然非常支持我，我觉得我也要做点什么！所以我会把这个工具的实现以及优化思考全都放出来吧，这样即使各位不愿意进 星球 的朋友依旧可以拿本文喂给ai让他对开源的真机trace进行改造，具体见后文介绍（点击跳转）；安卓逆向里，trace 是绕不开的环节。先说啥是 trace。trace 就是"跟踪"。我对 trace 的抽象理解是：站在不同角度去观察一件事的发展。举个现实生活的例子：你看到一条新闻，它就一定是正确的吗？我个人认为现在的网络环境下，很多人会拿着单方或者疑似权威的说明就当作绝对正确。总结就是：视角越深、维度越多，你看到的事实就越接近真实。trace 在逆向里也是这个道理 —— 你站在哪一层看，决定了你能看到的事实有多深。但也不是越底层越好的，要综合评估，如性能开销还有实际效果，最底层的trace并不是适用于任何场景。trace 其实有非常多种，只是现在大家提到 trace 默认指的是"指令级 trace"。下面我会从最浅到最深列一遍各级 trace，希望能帮大家拓宽一点思维 —— 这对于理解整个安卓逆向工具链的作用和发展史会很有帮助。OK，假设你拿到一个 app，目标是分析清楚它"登录"按钮背后到底做了什么，从最浅到最深一层一层下去：点击登录按钮 → loading 弹窗 → 界面跳转 → 中间可能藏着各种日志上报、设备信息收集、风控埋点。这一层我们关心"app 对外露出来什么"——不进 app 内部，只看它在外部留下的痕迹。下面是一些常见的"黑盒观测 trace":logcat：app 自身打的日志，很多 SDK / app 默认会留一堆 tag，可以选择一些常见的进行尝试，运气好可以抓到关键点，不过意义不大（一般只有在报错时会有error日志有点用）抓包：登录涉及把账号密码上传服务器，所以一定走网络协议。直接跑下来你会看到一堆 HTTP / TLS over TCP 的包，少数 app 会上 HTTP/3（也就是 QUIC over UDP）。这里就不展开抓包对抗的东西了。总之这一步价值非常的高，比如如果是http协议,你就能看到他的关键报文了；文件 IO trace：很多 app 会把 token / device id / 缓存 / dex 副本 / so 副本写到 /data/data/<pkg>/ 或 sdcard，看它读写哪些文件能直接定位关键流程（特别是脱壳、找加密本地存储的密钥）系统调用 / 内核 trace：UI 行为分析：进程 / 服务 状态：UI 层用的是 Java / Kotlin（绝大部分情况），那就把 apk / dex 拿出来反编译看，常见工具如下：加壳的话需要先脱壳，方
...(已截断)
---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-291372.htm