r0re 自动逆向分析工具实战记录
fyrlove
fyrlove
看雪学苑
2026年9月28日 17:59
上海
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
做 Android CTF 时经常碰到同一个问题：前面用 JADX、strings 很快能摸到入口，后面一碰到壳、动态注册 JNI、native 自解密或反调试，就开始在好几个终端和工具之间来回切。最后即便拿到一串“像答案”的内容，过几天再看，往往说不清它从哪一层来的，也不知道有没有真正走到校验点。
所以我把 Cairn 用 Java 重写，再把 Android 逆向常用的工具、提示词和验证环节接进去，做成了 r0re。它干的事情很简单：把任务拆小，把每一步看到的东西留下来；候选错了，就从错误处继续，而不是重新开一个聊天窗口。
这次用它跑完了看雪论坛公开 Android CTF 题集。AliCrackme\_2、AliCrackme\_4 都出现过首个候选不对、补 Hint 后才重新收敛的情况，我把这些过程保留下来了。对我来说，逆向 Agent 能不能第一次完成不是最关键的；更重要的是错误后能不能留下原因，并继续往下走。
说明：文中的样本仅用于公开 CTF/CrackMe 学习和授权逆向场景。源码、配置模板和测试记录随帖附件提供；发布时请将自己的模型 Key、设备地址和本机绝对路径从配置文件中移除。
一、测试结果：9 题通过
本次测试覆盖题集中的 9 道题，下图是最终记录。后面只展开 5 道：我想把篇幅留给出错后的处理、Hint 怎么生效，以及最终结果怎么验，而不是逐题堆截图。
二、我为什么从%20Cairn%20开始改
r0re%20不是凭空起的项目。它基于 Cairn 的架构思想进行%20Java%20重实现，再针对%20Android%20逆向补齐工具、提示词、运行态观测和验证环节。
Cairn%20的开发者是 淚笑，并在开源组织「起零衍迹%20/%20Oritera」发布；Bytex 是他参加腾讯云黑客松时使用的战队名。该系统在那次比赛中完成%2054/54，是该届唯一%20AK%20队伍。我参考它，主要不是因为这个成绩，而是因为它把复杂任务压缩成了一个很清楚的模型：已知 origin，设定 goal，中间路径未知，就持续补事实、拆下一步。Cairn%20源码与作者复盘在这里。
Cairn%20的核心很克制：黑板上只有%20Fact、Intent%20和%20Hint%20三种对象。Fact%20是已确认的发现；Intent%20是下一步准备探索的方向；Hint%20是人随时可以写入的判断。Worker%20围绕同一张黑板读取信息、探索、再写回事实，不靠“信息收集%20Agent%20/%20利用%20Agent%20/%20报告%20Agent”这样的固定角色切分工作。
这个思路刚好适合%20Android%20逆向。一个%20APK%20的校验路径可能横跨%20Java、资源、JNI%20和运行时内存，起手时谁也画不准流程图。先把确定的东西记下来，再盯着当前缺口往下挖，比硬规定一套“第一步、第二步、第三步”更实际。
不过，原版%20Cairn%20面向通用问题求解与渗透测试，Android%20逆向还有自己的硬约束：JADX%20和%20JNI%20映射要可回查，动态分析要能连设备，候选%20Flag%20不能只凭一段自然语言结论完成。因此%20r0re%20保留了%20Cairn%20的黑板、serve%20+%20dispatch 双进程和任务图思想，同时增加了%20Android%20CTF%20专用%20prompt、产物索引、runtime%20event、Frida/ADB%20工作路径，以及最终候选的验证门控。
所以%20r0re%20不是要另起一套理论。Cairn%20给了问题推进的骨架；我做的部分，是把它接到%20APK、so、设备和验证脚本上。
三、做%20r0re%20时，我盯着的几个问题
脚本适合把已经知道的算法批量化；大模型比较擅长在陌生二进制里找方向。两者之间还差一个能长期保存上下文、允许人中途纠偏的工作台。r0re%20就是补这个空档。
它把一个项目拆为三类可追踪对象：
- Fact
已经观察到的事实，例如%20Manifest%20入口、某个%20JNI%20映射、一次%20Frida%20hook%20的参数或已导出的%20dex；
*%20Intent
下一步可独立完成的工作，例如“定位 RegisterNatives 的注册表”或“复现%20AES%20解密链”；
*%20Hint
人为补充的约束和方向，例如“先检查 libmobisec.so”“候选必须在真机输入通过后才可结束”。
Worker%20不能只写一段长篇结论就宣布完成。它需要说明依据哪些%20Fact，产出了什么文件，哪些结论已经由真实工具输出验证。候选答案随后进入单独的%20verification/finalize%20流程；验证失败，候选会保留失败痕迹而不是悄悄覆盖。
这套设计直接针对%20Android%20CTF%20里最常见的三个坑：
- 可见字符串、Base64、Morse%20表只是线索，不等于%20Flag；
- 静态分析卡在壳或自修改%20native%20时，需要切到设备动态分析；
- 一个“看起来正确”的答案必须能通过原%20App、重建算法或独立验证器中的至少一种验证。
四、源码拆解：从创建项目到验证收口
源码仓库：github.com/fyrlove/r0re。r0re%20使用%20Java%2017、Spring%20Boot%20和%20SQLite；服务进程负责保存黑板、项目和完成状态，dispatcher%20是独立进程，按项目状态调用容器中的%20Worker。
这个拆分不是为了把架构画得复杂，而是为了把“模型调用”与“分析现场”分离：模型超时、容器退出、机器休眠，都不应该让已经得到的证据消失。
WebUI%20/%20HTTP%20API
%20 %20 %20 │
%20 %20 %20 ▼
SQLite%20黑板：projects%20/%20facts%20/%20intents%20/%20hints%20/%20runtime_events
%20 %20 %20 │
%20 %20 %20 ▼
Dispatcher：bootstrap%20→%20reason%20→%20explore%20→%20verify%20→%20finalize
%20 %20 %20 │
%20 %20 %20 ▼
Docker%20Worker：jadx%20/%20apktool%20/%20readelf%20/%20Frida%20/%20ADB%20/%20自定义%20solver
%20 %20 %20 │
%20 %20 %20 └──%20analysis%20产物、trace、报告回写到项目目录
最核心的%20schema%20在 src/main/resources/schema.sql。projects 保存项目生命周期；facts、intents、intent_sources 和 hints 组成可回放的事实图；runtime_events 记录每个%20Worker%20在什么阶段、用了什么工具、生成了什么产物；completion_candidates 与 verification_intents 则把“模型声称完成”拆成待验证的候选和独立验证任务。
这个数据结构解决了一个很现实的问题：同样一句“已找到%20Flag”，在逆向里含金量完全不同。它可能是%20strings%20里看见的值，也可能是对 memcmp 参数的%20hook%20结果，还可能是本地脚本正向/逆向都跑通的输入。r0re%20用 verified、kind 和%20artifact%20路径把这些状态分开保存。dead_end 也会作为事实保留——例如“静态%20dump%20没有解密代码页”，后续任务就不会再沿同一条路无休止搜索。
从源码看，所有黑板写入集中在 src/main/java/com/fyr/r0re/server/R0reService.java，而 DispatcherRunner 只通过%20HTTP%20API%20获取项目、认领任务和回传结果，不直接碰%20SQLite。
这样%20WebUI、dispatcher%20和%20Worker%20看到的是同一个事实来源，不会出现“页面里已经加了%20Hint，容器还在拿旧上下文”的两套状态。
src/main/java/com/fyr/r0re/dispatcher/DispatcherRunner.java 是整个系统的心脏。每次%20tick%20会回收结束任务、读取活跃项目、刷新运行态、处理容器清理，然后为可执行项目补位。任务只有三种：
bootstrap
项目刚创建时做首轮侦察，建立%20APK%20的基本认识；
*%20reason
读取当前事实图，判断目标是否达成，或生成下一批更小的%20Intent；
*%20explore
认领一个%20Intent，真正调用工具完成分析，并把结果写回为新的%20Fact。
把它写成伪代码，大致就是：
项目创建%20→%20bootstrap
新%20Fact%20/%20新%20Hint%20/%20有空闲任务槽位%20→%20reason
reason%20产生%20Intent%20→%20Worker%20认领%20→%20explore
explore%20产出%20Fact%20或%20dead_end%20→%20再次%20reason
候选答案%20→%20verifier%20→%20finalize
评论