用apk-reverse破OLLVM混淆：Stalker指令级追踪与它的2种失败模式

用apk-reverse破OLLVM混淆Stalker指令级追踪与它的2种失败模式【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverseapk-reverse是一个面向 Android APK 逆向工程的 Agent Skill 仓库本文带你用它内置的Stalker 指令级追踪思路攻破 OLLVM 控制流平坦化——并提前绕开在真实 arm64 设备上实测到的2 种失败模式少踩坑、少烧时间。一、为什么 OLLVM 混淆让静态分析失明 OLLVMObfuscator-LLVM通常一次上三种变换拆开看才好对症下药变换静态形态破解它的观察手段控制流平坦化整个函数被碾平成一个 dispatcher 循环 状态变量指令级追踪dispatcher 的执行频率远高于真实代码块这个比例静态根本看不见假控制流不透明谓词条件在代数上恒真/恒假的分支不可能一侧放着垃圾代码追踪中该分支一次都不出现据此删死代码指令替换算对了但认不出的算术链MBA 变形符号执行或输入扫描追踪本身简化不了数据流关键认知静态反汇编回答的是什么能跑而真正能拆开混淆的问题其实是什么真的跑了、跑了几次。平坦化是控制流问题追踪能回答指令替换是数据流问题需要交给符号执行。两者的分工写得很清楚见 native-dbi-and-deobfuscation.md。二、Stalker 追踪三原则每条都被失败验证过仓库里的 stalker_trace.js 封装了 Frida Stalker它把目标线程执行的每个基本块重新编译一份并回报给 JS不需要符号、不需要源码、不需要宿主机反编译器——这正是它能在 stripped 的 OLLVM 产物上干活的原因。脚本头部写死了三条铁律破坏任何一条都是文档在案的失败模式只跟一个触发器不跟整个进程—— 无限制跟随一条忙碌线程会产出几 GB 日志目标被拖死过滤到一个模块—— 只有targetModule内的块会上报过滤发生在设备侧而不是事后给体积封顶——maxBlocks让追踪自己刹车DONE行记录是否发生了截断。拿到日志后用 stalker_report.py 做四种归约各回答一个问题执行直方图榜首大概率就是 dispatcher平坦化状态的心跳首访顺序骨架去重后的块集合 ≈ 剥掉状态机后的真实 CFG 骨架调用边表无符号也能画出模块内部谁在调谁折叠执行序列D → R → D → R的平坦化节奏在这里肉眼可见。配套的运行入口是 run_probe.py动手前建议先跑一遍 doctor.py 确认 frida 环境是否就位。三、从追踪到去混淆5 步路线inferred⚠️以下是方法而非实测记录该组合上追踪管线尚未跑通仓库诚实标注为 inferred找 dispatcher按执行次数排序大幅领先 前驱多 后继多三条件命中者即调度块找状态变量反汇编 dispatcher 入口窗口找间接跳转前一刻被写入的寄存器/栈槽恢复真实 CFG把dispatcher → 真实块 → dispatcher的序列转成边表符号执行补齐未覆盖路径只对 dispatcher 那几十字节求解入口用追踪给出的偏移最后才动二进制直接跳转重写要注意指令长度用 elf_plt.py 验证改写点实际跳向哪里。四、失败模式 1零事件追踪 —— follow 装上了事件却没来 这是本仓库最有价值的一条负结果observed环境frida 16.7.19 Android 11 / arm64Stalker.follow在主线程上 4 秒blocks0 blk0 calls0且前面每一行日志都健康READY、TRIG following、MOD libc.so base…换malloc导出做触发器201 个完整的 follow 周期、每一条DONE都规整却没有一个块上报。结论要窄着拿在该组合上follow 安装成功但事件到不了onReceive。它不是Stalker 全环境都坏了但教训是通用的——在相信零事件结果之前先做对照运行跟随一条你自己控制的、执行已知循环的线程确认能看到非零的BLK行。零事件可能是管线死了也可能模块根本没在跟随的线程上跑。另有一个常见误区Stalker.exclude()修不了零事件。A/B 对照记录20 个系统库排除后进程存活但依旧blocks0见 EXTENSION-stalker-exclude.md完整实测日志见 EXTENSION-native-dbi.md。五、失败模式 2高频 follow/unfollow 把目标进程撞死 用热 libc 导出每次调用就 follow、每次返回就 unfollow做触发器几百个循环之后系统 UI 进程SIGSEGV死亡崩溃帧#00落在匿名可执行区正是 DBI 翻译码缓存的形态返回路径伸进libart。配套实测还揭示了两件事不带排除直接 follow目标进程会死带 20 个系统库排除后进程存活baseline 对照排除了frida 本来就杀进程的解释——排除不是风格偏好是保命项设备本身会变成实验变量一次误入libc/libart的重追踪把 8 核手机的 load average 推到34.11同机另一个任务被连带杀死。followMs保持在几秒、给maxBlocks封顶、能 attach 就别 spawn。一句话操作准则用选定一条线程 有界时间窗的单次 follow永远别用热函数当触发器。六、什么时候该换 QBDI 或模拟器 你的问题选择真机上要块级覆盖和执行次数无需逐指令语义Stalker起步成本最低要逐指令取值、内存操作数、可重放QBDI样本拒绝在设备上运行或要调用几千次模拟unidbg / Unicorn要什么输入能到块 X符号执行angr / Triton完整决策表和 Stalker 与 ART 的兼容性问题JIT 重编译、块地址只在单次进程内有效都在 native-dbi-and-deobfuscation.md §4/§6这条路线在公开样本上的回归结果记录在 benchmark.md 的 B6 行证据强度索引见 evidence-summary.md。小结 OLLVM 平坦化是控制流问题追踪直方图里的榜首就是 dispatcher三条纪律单触发器、单模块、封顶 排除系统库是目标存活的先决条件两种失败模式先记在脑子里零事件 ≠ 目标没跑先做对照运行热函数触发 给目标上绞索负结果也有价值apk-reverse 把实测到哪一步、哪一步只是 inferred分级标注照着证据强度走不重复付学费。【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考