最近接了个有点意思的活儿要把一整条 Android 逆向分析流程从人肉点工具、人肉读日志、人肉写报告改造成 AI Agent 能自主调度的完整工作流。项目名字就叫 apk-reverse核心不是某一个逆向工具而是把 JADX、apktool、Frida、ADB 这一堆散装兵器全部封装成 Agent 可调用的原子能力再用工作流引擎把它们串成一条生产线。这篇文章就把这套体系的架构思路、模块拆解、关键实现和一些踩坑经验整理出来给同样想搞AI 辅助逆向或逆向自动化的朋友做个参考。无论你是准备用 Dify、Coze 这类现成平台编排还是想基于 Rust、Python 自己搭 Agent 框架这篇文章里讲的模块划分和工具封装逻辑都能直接迁移。1. 逆向工程工作流化不是写脚本而是搭生产线很多做逆向的朋友听到AI Agent 执行逆向的第一反应是这不就是写个自动化脚本把命令一个个跑一遍吗说实话我一开始也是这么想的但真正动手之后发现两者之间隔着一条很深的沟。1.1 传统命令行脚本和 Agent 工作流的本质区别传统脚本是确定性执行你规定好第一步干嘛、第二步干嘛顺序写死遇到异常就中断。但逆向分析恰恰是高度不确定的过程——同一个 APK可能第一步反编译就报错了可能 Manifest 里什么都没藏着可能 so 文件加壳了需要先脱壳。脚本面对这些情况只能死给你看。AI Agent 工作流不一样它的核心是目标驱动 动态规划。Agent 拿到一个样本先拆包看看情况再决定下一步是静态分析还是动态调试。过程中的每个工具调用都是一次决策而不是机械执行。这才是把逆向工程工作流化的关键不是把操作步骤录制成宏而是把分析师的决策逻辑编码成 Agent 的策略。apk-reverse 这个项目的核心目标就是把逆向分析里那些可标准化的动作——反编译、字符串提取、API 调用分析、Activity 枚举、so 文件解析、动态调试、文件系统访问——全部抽象成独立模块再让 Agent 根据样本特征自主编排调用顺序。1.2 工作流总览从 APK 样本到分析报告的五个环节我在设计 apk-reverse 时把整个流程分成五个大模块对应逆向分析的五种基本姿势模块核心职责底层工具Agent 看到的输入/输出拆包与信息提取解压 APK、解析 Manifest、枚举组件apktool、aaptAPK 路径 → 包名、版本、权限、组件列表静态代码分析反编译 DEX、类与方法关系、字符串提取JADX、dex2jar、CFR代码路径 → 类结构、关键方法、硬编码信息资源与配置挖掘资源文件、so 库、assets、网络配置binwalk、readelf、strings资源目录 → so 导出函数、URL、加密密钥线索动态运行时分析启动应用、Hook 关键函数、抓取运行时数据ADB、Frida、objection目标包名 → 调用栈、参数值、返回值、内存数据报告聚合汇总所有模块产物生成结构化分析报告自研聚合层各模块 JSON → Markdown/结构化报告这五个环节之间不是严格线性的。Agent 的工作流里经常出现从静态分析发现可疑的 native 方法 → 转入动态调试 Hook 这个 native 函数 → 拿到结果后回填到静态分析上下文这种来回跳跃。所以工作流引擎必须支持动态跳转不能做成死板的 DAG。2. 静态分析模块让 Agent 真正读懂APK 的内容静态分析是整个工作流的地基也是最容易被跑了个 JADX 就当分析完了糊弄过去的环节。Agent 要真正读懂代码而不是仅仅生成一堆反编译结果这里面的差距就在于我们怎么处理和表达这些数据。2.1 拆包工具选型apktool、JADX、dex2jar 各管哪一段三个工具怎么分工我直接给结论apktool负责拆资源 转 Smali。它的强项是资源解码和 Manifest 可读化Smali 是给人看或者给动态修改用的Agent 直接读 Smali 效率太低。JADX负责出 Java 伪代码。它自带 GUI 但也可以命令行批处理输出 Java 代码的质量在同类工具里算最好的。JADX 还有一个隐藏优点是会自动处理部分混淆比如把混淆后的类名统一成 short name。dex2jar CFR/JD-Core是 JADX 失败的备选方案。有些样本 JADX 直接崩——内存溢出、解析异常都遇到过——这时候用 d2j-dex2jar 转 jar再用 CFR 出 Java 代码。我实测下来的建议是主流程走 JADX失败自动降级到 dex2jar CFRapktool 永远跑一份用于资源分析和 Smali 级补丁。这种多级降级策略对 Agent 特别重要因为 Agent 不是人它不会换个工具试试必须在编排层就把备胎逻辑写死。# 静态分析子工作流JADX 失败自动降级 def analyze_static(apk_path): try: jadx_output run_jadx(apk_path) # 主路径JADX return parse_jadx_jobs(jadx_output) except JADXException: jar_file run_dex2jar(apk_path) # 降级路径1dex2jar java_code run_cfr(jar_file) # 降级路径2CFR return parse_cfr_jobs(java_code)2.2 代码语义化如何把反编译产物变成 Agent 可消费的结构化信息这一节是整个静态模块的灵魂。JADX 输出的是人可读的 Java 代码但 Agent 是模型它处理的是 Token。一万行 Java 代码直接塞给模型上下文一下就爆了——别忘了热词里大家都在纠结dify工作流 上下文超长的问题。所以 apk-reverse 在 JADX 输出和 Agent 之间加了一层代码语义化管道。它的工作包括提取类关系图把继承、接口实现、内部类关系从代码里捞出来生成结构化 JSON。Agent 看到的不再是源码而是一张类地图。筛选高风险调用重点标注Runtime.exec()、System.load()、Cipher.getInstance()、Intent.setData()这类涉及代码执行、动态加载、加密和组件通信的 API 调用点。抽取字符串常量池把代码里所有长字符串、base64 码、URL、IP 抽出来单独建索引。逆向分析里很多关键信息服务器地址、加密密钥、API Key就藏在字符串里。关联 Analysis 记录JADX 自带 Analysis 模式会把常量传播、调用关系计算出来命令行里用--analysis-mode参数打开输出质量提升明显。这样处理之后一份 20MB 的 APK 静态分析结果最终喂给 Agent 的结构化摘要可能只有几千 Token但信息密度远超直接贴源码。2.3 AndroidManifest 的挖掘点入口、权限、组件是 Agent 的第一步侦察Manifest 是 Agent 理解一个 App 的第一份情报我专门封装了一个 Manifest Digest 工具。它要抓的不仅是包名和版本号更关键的是这几样exported 组件android:exportedtrue的 Activity、Service、Receiver 是外部可直接触达的入口也是安全分析的高价值目标。自定义权限App 定义的permission标签和protectionLevel能看出 App 的权限隔离设计。网络配置usesCleartextTraffic、networkSecurityConfig对应的 XML直接暴露了 App 是否允许明文通信、有没有证书固定。ContentProvider authorities所有 provider 的 authority 字符串要收进清单后面动态分析里要拿content://URI 去访问。每次提取完Agent 会拿到一份结构化的 Manifest 摘要包含组件总数、exported 组件列表、权限列表、provider authority 列表。Agent 接下来往哪个方向深入——是分析登录逻辑、还是调查某个 provider 的数据暴露——就靠这份摘要来决定。3. 动态调试与运行时交互模块Agent 的手和眼睛静态分析只能看出可能有什么问题要验证实际问题是什么还必须把 App 跑起来看。这个模块是整个工作流里工程复杂度最高的部分因为涉及真机/模拟器、进程管理、UI 自动化、Hook 注入这一大堆容易翻车的环节。3.1 ADB 能力封装与设备抽象层Agent 本身不知道什么叫设备离线什么叫USB 调试未授权它看到的应该是统一的设备抽象。apk-reverse 里我封装了一个 ADB 网关层把设备相关的琐碎操作全部打包成高层的 Agent Tool# ADB 网关工具的典型接口设计 def adb_shell(device_id, command) - ShellOutput def adb_install(device_id, apk_path) - InstallResult def adb_am_start(device_id, component) - ActivityStartResult def adb_forward(device_id, local_port, remote_port) - ForwardResult def adb_current_focus(device_id) - str # 返回当前前台 Activity设备层要处理的状态包括多设备连接时的-s device_id选择、root 权限有无的判断、SELinux 状态很多 Hook 操作受 SELinux 限制、以及/system/bin下可用命令集的探测。我踩过最大的坑是无 root 环境下的动态分析。测试机上很多 App 跑在非 root 环境su命令不可用Frida 的frida-server推不进去。后来改用frida-gadget注入模式通过重打包 APK 加入 gadget so 库来接管 App 进程。这个方案对强度一般的壳有效而且重打包本身也是逆向工作流里常见的分支动作Agent 需要会给 APK 做植入手术再装回去。3.2 Frida 脚本的动态生成与调用封装Frida 是动态分析的核心武器。但在 Agent 工作流里直接让 Agent 写 Frida 脚本是不现实的——模型写 JavaScript 的水平写个小功能没问题写复杂的 hook 逻辑非常容易翻车而且 Frida 脚本是跑在目标 App 进程里的调试成本极高。稳妥的做法是预置一批高频 Hook 模板Agent 只需要填参数。我在 apk-reverse 里预置了这些脚本hook_activity_lifecycle.js自动跟踪所有 Activity 的 onCreate/onResume/onPause输出生命周期调用序列。用于分析启动流程。hook_method_by_name.js按类名方法名 Hook打印参数、返回值、调用栈。这是最常用的比如 Agent 想查某个加密函数的入参出参直接调用。hook_ssl_pinning_bypass.jsSSL Pinning 绕过模板配合抓包用。hook_shared_preferences.js拦截 App 对 SharedPreferences 的读写输出 key-value 变化记录。hook_okhttp_interceptor.jsHook OkHttp 的请求/响应把 URL、Header、Body 全部打印出来。很多 App 的网络层集成 OkHttp这个模板命中率极高。// hook_method_by_name.js 的核心逻辑 Java.perform(function() { var targetClass Java.use({{CLASS_NAME}}); var targetMethod targetClass.{{METHOD_NAME}}.overload({{ARG_TYPES}}); targetMethod.implementation function() { console.log([CALL] {{CLASS_NAME}}.{{METHOD_NAME}}); console.log([ARGS] JSON.stringify(Array.prototype.slice.call(arguments))); var ret this.{{METHOD_NAME}}.apply(this, arguments); console.log([RET] ret); return ret; }; });Agent 调用这个工具时传参格式是class_namecom.example.LoginManagermethod_namegetTokenarg_typesjava.lang.String工具层负责把参数填进模板、push 到设备、拉起 frida 并收集输出。这样 Agent 完全不碰 JavaScript也能实现精准 hook。3.3 UI 自动化的取舍什么时候用坐标什么时候该放弃动态分析经常需要模拟用户操作比如点开某个页面、输入账号密码、触发某个按钮。UI 自动化的标准方案是 UIAutomator 或 Appium但它在上工作流里有几个致命问题坐标易变不同分辨率、不同系统版本控件坐标全变纯粹用坐标点击翻车率极高。控件树可能为空某些 WebView 页面或自绘 View用 Flutter/Unity 开发的 App获取不到标准控件节点。弹窗打断隐私弹窗、更新弹窗、广告弹窗随时出现Agent 根本预判不了。我的处理思路是轻量驱动 状态回读。不到万不得已不模拟点击优先用 ADB 直接启动 Activity 或用广播触发组件。如果必须点击用uiautomator dump先拿控件树再按 text 或 resource-id 定位实在找不到控件再用坐标兜底。每次点击后强制回读当前焦点 Activity 和应用崩溃状态一旦发现 App 崩了立刻终止自动化并保存现场。4. 文件系统与 Content Provider 访问绕过沙盒的数据获取动态分析绕不开数据层。App 自己的私有目录、外部存储目录、跨应用共享的 ContentProvider都是高价值数据源。但 Android 的权限管控这些年越来越严每个版本都在堵路这里边的门道值得单独开一节。4.1 /storage/emulated/0/Android/data/ 的访问权限变化与处理热词里有很多content://和/storage/emulated/0/Android/data/相关的路径说明大家在实际逆向中都被这个目录卡过。以com.tencent.tmgp.sgame某款MOBA手游的路径/storage/emulated/0/Android/data/com.tencent.tmgp.sgame/files/pandora/为例这类目录在 Android 11 之后默认是访问不了的——即便有 root 权限App 的私有数据也在 CE 存储加密分区里普通文件管理器看不到全貌。在 apk-reverse 的动态模块里我封装了一个文件系统访问层按优先级排列root adb shell su -c有 root 就暴力直接读/data/data/package/下的 databases、shared_prefs、files。注意加chmod 755或先copy出来再读。adb backup提取对于非 root 设备如果 App 在 Manifest 里声明了android:allowBackuptrue可以用adb backup -f backup.ab -noapk package拉取应用私有数据再用脚本解开备份文件。这个方法对很多应用仍然有效是个隐蔽的后门。模拟器 Xposed/LSPosed 模块在模拟器里用 Xposed 模块挂钩File.listFiles()等 API绕过框架层的路径过滤。重打包加 frida-gadget最通用的方案用 gadget 注入后通过 Frida 的filesystemAPI 直接读文件。注意第 2 种方案在 Android 12 之后做了调整部分 App 即使声明了 allowBackup 也会在运行时检测备份行为。实战中 Agent 应该按顺序尝试哪种通了就用哪种每个方案成功后要做标记便于下次优先。4.2 content:// URI 的跨应用访问兼容热词里有content://com.baidu.searchbox.fileprovider/...和content://com.tencent.wework.fileprovider/...这类 FileProvider 路径。分析某个应用读取其他应用共享文件的场景时Agent 需要主动构造或解析这些 URI。FileProvider 的特点是通过authorities和paths的映射关系把真实的file://路径映射成content://URI避免直接暴露绝对路径。逆向时我们常需要拿到content://后反向推导真实的file://路径。方法是找反编译产出里的file_paths.xml通常在res/xml/下它定义了files-path、cache-path、external-path等映射规则。用adb shell content query --uri content://authority/path检测目标 provider 是否可访问、有哪些字段。如果是跨应用数据窃取的评估场景需要模拟一个恶意 App 来验证 exported provider 是否存在权限绕过。Agent 拿到 URI 之后不应该自己去猜工具层应该把content query、content read、content call这些命令全部封装好Agent 只需要声明我想读这个 URI。4.3 Android 进度条与耗时的 UI 反馈热词里有个有意思的android进度条。在工作流自动化里进度条不是 UI 细节而是一个逻辑信号。很多 App 在进行耗时操作登录、加载、下载时会显示进度条或 Loading 动画。Agent 动态分析时如果只是点完按钮就立刻 dump 数据经常会抓到半成品状态。我在 UI 自动化工具里专门做了一个等待条件参数支持三种模式等待控件出现循环uiautomator dump直到某个 resource-id 出现。等待网络空闲用adb shell dumpsys connectivity或读取/proc/net/判断网络请求是否还在进行。等待文本出现比如等登录成功或加载失败文本出现再截图。这相当于给 Agent 的手装了一双会等反馈的眼睛避免为了赶进度抓瞎。5. AI Agent 编排层把散装工具串成一条主动工作的流水线前面几个章节是臂膀编排层才是 apk-reverse 的大脑。Agent 怎么选工具、怎么在不同模块间跳转、怎么恢复状态全在这一层决定。这也是跟 Dify、Coze 这些平台对接时的核心接口面。5.1 Agent 的记忆分层与上下文压缩最先要解决的就是热词里反复出现的上下文超长问题。逆向分析一次会话产生的数据量非常惊人反编译日志几百 MB 不夸张Frida 脚本输出几万行也常见。全塞给大模型是愚蠢的。我的方案是三层记忆短期记忆会话内当前分析目标、最近 10 条工具调用结果摘要。每轮的对话上下文只保留必要内容。工作区记忆文件层每次工具运行的完整输出写到工作目录Agent 需要时通过读取文件片段工具去查而不是直接灌进上下文。这一步非常关键——把上下文记忆变成文件系统记忆理论上 Token 消耗与数据量脱钩。长期记忆跨会话样本特征、包名、壳类型、常用入口点等元信息存进 SQLite下次拿到类似样本先查历史记录很可能直接复用之前的分析路径。5.2 工具调用Function Calling与 Workflow 的协作模式现在的 Agent 框架不管是用 Rust 还是 Python 自建还是用 Dify、Coze 这类平台核心机制基本是 Model 发出 Function Call → 平台执行工具 → 返回结果 → Model 决定下一步。apk-reverse 在应用这个模式时定义了一套标准的工具规范。工具规范的几个关键字段{ name: static_analyze_dex, description: 对 APK 中的 DEX 进行反编译与结构化提取输入为 APK 路径输出为类/方法/字符串的结构化索引, parameters: { type: object, properties: { apk_path: {type: string, description: APK 文件绝对路径}, focus_keywords: {type: array, items: {type: string}, description: 重点关注的类名/关键词非必填} } } }描述信息要写的像给一个没见过工具的新同事交代事情一样清楚——这个工具干什么、输入什么、输出什么、什么时候用。我见过太多工作流失败是因为工具 description 写得含糊模型根本不知道什么时候该调这个工具。提示工具粒度要控制好。太细了 Agent 频繁调用Token 损耗大太粗了模型不知道内部逻辑没法做精确决策。一般粒度的判断标准是一个正常分析师完成这个动作大约需要几步。比如提取 Manifest算一步反编译整个 APK算一步拉取 Frida 输出算一步。5.3 AI Agent 怎么扛并发任务队列与去重策略热词里有人搜ai agent 怎么扛并发这确实是个大坑。Agent 工作流不是普通 Web 服务它的每个任务都是长连接 多步决策数据库里能开一万个连接但一万个 Agent 同时在调 JADX 跑 Frida机器直接就没了。我的方案是两级并发控制任务队列层所有请求先进 Celery/RQ 队列按优先级出队。下载和分析是两个不同优先级——下载是高频 IO分析是高频 CPU/内存。队列分别设置最大并发数。工具进程池重工具JADX、Frida 起进程用进程池限制最大实例数。比如同一台机器最多同时跑 3 个 JADX、5 个 ADB 会话。超出就排队等待这个等待动作要显式暴露给 Agent让它知道分析任务在排队不要重复提交。并发问题的根因是工具有状态反向轮询Agent 主动查任务状态比正向推送工具完成后回调 Agent更容易实现且更稳定。我最终用的是Agent 提交任务 → 获取任务 ID → 轮询任务状态 → 拿到最终产物的流程每一步都是独立 HTTP 接口天然扛并发。5.4 错误恢复与多轮重试Agent 工作流最被低估的能力一个 Agent 工作流好不好用不看它顺利时跑得多快看它出错时死得多惨。我系统梳理了 apk-reverse 里常见的错误类型针对性地设计了恢复策略错误类型典型场景恢复策略环境错误设备离线、JADX 内存溢出、磁盘写满换备用设备、降低 JADX 内存参数、清理工作区后重试工具错误反编译失败、frida 注入失败走降级链换工具组合JADX → dex2jarCFR应用状态错误App 崩溃、闪退、ANR重启 App、清除数据后冷启动最多重试 3 次逻辑错误Agent 选错工具、参数传错记录错误上下文在下一轮决策前注入上一步失败原因引导换策略我把失败原因回灌做成了一个独立的工具inject_error_context它会把上一步的错误信息摘要追加到当前上下文中让模型意识到自己刚才的决策有问题。这个机制比单纯重试效果好得多——模型在看到JADX 内存不足之后下次智能地换用 dex2jar而不是继续傻乎乎地重试 JADX。6. 游戏逆向场景从样本定位到逻辑破解的完整走查热词中出现大量游戏逆向相关内容逆向工程游戏逆向、com.tencent.tmgp.sgame说明这是实际需求最密集的场景。就拿一款 Unity3D 手游样本做一次走查展示 apk-reverse 工作流怎么一步步找到关键逻辑。6.1 一例 MOBA 手游样本的完整走查拿到一个 APK 样本工作流自动启动阶段一拆包与侦察Agent 先调decompile_apk跑 apktool 拆开资源提取 Manifest 摘要。看到的信息包括包名com.tencent.tmgp.sgame、包含libil2cpp.so说明是 Unity IL2CPP 架构、libtersafe.so有企业级加固、主入口是标准的 Unity 入口 Activity。这里 Agent 做的关键决策是因为检测到 IL2CPP放弃传统的 DEX 分析为主路线把重心放到 so 层。传统逆向思维关注 DEXJava 层逻辑但 IL2CPP 游戏的核心逻辑全部在libil2cpp.so里DEX 里只剩框架代码。阶段二Il2Cpp 符号还原这一步是游戏逆向的核心痛点。libil2cpp.soglobal-metadata.dat的组合里metadata 文件保存了所有类名、方法名、字符串信息但它本身是加密的。工作流里的il2cpp_dumper工具负责从 so 里 dump 出符号信息还原出完整的方法列表。Agent 拿到还原后的符号表用关键词搜索login、auth、token、AES定位到认证相关的类提取出关键函数。随后把函数地址列表交给下一步。阶段三动态 Hook 关键函数Frida 模板工具根据 Agent 传入的参数类名、方法偏移生成 hook 脚本。这里注意 IL2CPP 的 hook 不能用常规的Java.use()得用Il2Cpp.perform()配合Il2Cpp.Api来调用。apk-reverse 里专门封装了il2cpp_hook_template.jsIl2Cpp.perform(function() { var targetClass Il2Cpp.Domain.assembly(Assembly-CSharp) .image.class({{CLASS_NAME}}); var targetMethod targetClass.method({{METHOD_NAME}}); targetMethod.overload().invokeHook(function(args) { console.log([Il2Cpp CALL] {{CLASS_NAME}}.{{METHOD_NAME}}); this.invoke.apply(this, arguments); }); });实际运行时这个 hook 成功捕获到了登录函数的参数构造过程和返回值格式进而确认了客户端加密方式以及是否有人在客户端本地做签名校验。阶段四资源访问与文件提取游戏运行后会在外部目录写入热词里那种/storage/emulated/0/Android/data/pkg/files/pandora/路径下的热更新资源。工作流的文件系统模块把该目录内容列出来发现资源版本配置和部分未加密的 Lua 脚本。这一步直接揭示了游戏的资源更新策略也为后续做资源定制提供了入口。6.2 加固与混淆对抗工作流怎么识别和拆除保护壳热词里提到的游戏逆向大多涉及企业级加固。apk-reverse 里有一个独立的shell_detector工具通过特征匹配识别壳类型检测libDexHelper.so→ 某大型加固方案检测libshell*.solibexec*.so→ 某免费壳检测libprotectClass.so→ 某企业壳检测libjiagu.so→ 某老牌加固识别出壳之后工作流有两种路线脱壳路线对强度不高的壳用 Frida 的dump_so和dump_dex脚本在内存中还原真正的 DEX 和 so。这一操作的本质是趁 App 运行时把解密后的代码从内存中抠出来。流程是启动 App → 等壳完成解密 → Frida dump 内存镜像 → 用 dump 出来的 DEX 替换原先的空壳 DEX → 重新走静态分析。行为分析路线对强度高、dump 不出来的壳暂时放弃静态完全走动态。通过 Frida 在 App 运行过程中拦截所有类加载行为ClassLoader.loadClass点记录真实被加载并执行的高价值类再对这些类做反射调用探测。虽然效率低但作为兜底方案可靠。加固对抗的关键经验不要一上来就想着脱壳。很多样本的壳强度并不需要脱它的核心加密逻辑在 Java 层动态 hook 一下就看到了。脱壳是最后手段不是常规武器。Agent 在决策时应该优先尝试轻量方案只有确认 Java 层逻辑确实在加密的 Dex 里、不脱壳完全无法分析时才进入脱壳分支。6.3 模拟器与真机的选择逻辑游戏逆向里最大的变量之一就是运行环境。热词里有android tvAndroid TV 设备的动态分析也被频繁提到——电视端的逆向逻辑和手机端差异很大没有触摸交互只靠遥控器按键UI 自动化基本失灵。apk-reverse 在设备选择上有一个决策规则集首选模拟器性能可控、支持快照、root 方便、支持 Xposed。但注意很多游戏有模拟器检测需要过检测后才能跑起来。次选真机兼容性好、检测少适合调试和验证阶段的场景但 root 麻烦且容易炸机。Android TV / 车机类Automotive OS真机或对应模拟器分析重点在系统应用和 Service 交互UI 自动化要偏向按键导航adb shell input keyevent。模拟器方案我强烈推荐带 Xposed 模块的定制镜像比如雷电模拟器 LSPosed因为它们可以同时兼顾隐蔽性和可控性。真机上做frida-gadget注入要处理签名校验很多 App 有 signature 校验保护重打包后直接闪退这时候需要配合hook_signature_verify.js绕过。这些脚本都要作为工具库预置不要让 Agent 现场写。7. 实战中的意外情况与补充经验写到这里分享几个只有实际操作过才会注意到的细节这些细节在项目规划阶段通常想不到但往往决定工作流能不能稳定跑下去。Java 版本与工具兼容性。JADX 新版本要求 JDK 11apktool 在 JDK 17 上有一些反射相关警告CFR 对高版本字节码要加参数。如果工作流跑在容器里没配好 Java 版本就会出现工具装好了但全打不开的尴尬。我在工作流初始化时加了一步env_check把所有工具的版本和 JDK 版本一次性打出来给 Agent 确认。文件路径里不能有中文和空格。这个太老套了但真的会踩JADX 和 dex2jar 对带空格路径的容忍度极差Agent 在处理外部上传的 APK 时经常把文件放在带空格的目录里导致后续工具全部报路径错误。工作流里的文件接收模块要统一做一次路径净化——重命名、去空格、统一目录层级。工作区空间管理。一次完整的逆向分析可能产生 10GB 级别的中间文件反编译输出、内存 dump、抓包文件。工作流的清理策略不能一刀切删要留最近一次任务的文件供人工复查。我用的是保留最新任务完整产物 其余任务只留报告的策略。这个策略 Agent 是感知不到但也必须内置的否则跑几天磁盘就爆了。模型选择对工作流质量的影响。不同模型在 Function Calling 上的表现差异巨大。实测下来推理能力强的模型比如 GPT-4o、Claude 3.5 Sonnet、DeepSeek 的强推理模型在工具选型和错误恢复上的表现明显优于普通模型。 如果公司有成本压力可以把简单动作提取、解析交给轻量模型把决策环节下一步做什么交给强推理模型混合调度能显著降低成本。我自己习惯的做法是在这条工作流上做验证时先用强推理模型跑通全链路再把高频的子流程比如提取 Manifest 摘要下沉到轻量模型这样平衡了成本和质量。Agent 工作流不是越智能越好而是该智能的地方智能、该机械的地方机械。8. 从工具到体系把 apk-reverse 用起来的三条建议项目走到一定阶段我发现真正难的不是写工具而是怎么把它变成团队/个人能持续信任的分析基础设施。分享几条收尾的体会。第一先跑通最小闭环再谈大而全。最开始不要试图把逆向 Agent一步到位做完整先挑一个高频场景比如自动提取 APK 的 Manifest 摘要 高危 API 列表打通APK 上传 → 工具调用 → 报告输出的全流程。这个小闭环能跑通之后再逐步加入 Frida Hook、脱壳、UI 自动化这些重工具。第二工具封装比模型聪明更值钱。Agent 工作流的瓶颈很多时候不是模型不够聪明而是工具封装得太粗糙——参数定义不清、错误反馈不全、并发控制缺失。你把工具封装的越好用模型的决策质量就越高。这个投入是复利式的每个工具打磨一点整条工作流的稳定性上一个台阶。第三保留人工复核的出口。任何自动化逆向工作流最后都必须有一位分析师做结论性判断。自动化的价值在于把分析师从高频重复劳动里解放出来而不是取代分析判断。apk-reverse 在所有关键节点都会产出可供人工复查的日志和中间产物这个设计让团队接受度大幅提升。如果你正在搭建类似的 AI Agent 逆向工作流或者是准备用 Dify、Coze 编排逆向自动化流程这里面的模块划分和踩坑经验希望能帮你少走几段弯路。等手里这个项目再跑一段时间我打算把工具封装规范和几段实际的分析日志整理出来单独写一篇到时候再见。
AI Agent驱动的Android逆向自动化工作流：架构与实战
最近接了个有点意思的活儿要把一整条 Android 逆向分析流程从人肉点工具、人肉读日志、人肉写报告改造成 AI Agent 能自主调度的完整工作流。项目名字就叫 apk-reverse核心不是某一个逆向工具而是把 JADX、apktool、Frida、ADB 这一堆散装兵器全部封装成 Agent 可调用的原子能力再用工作流引擎把它们串成一条生产线。这篇文章就把这套体系的架构思路、模块拆解、关键实现和一些踩坑经验整理出来给同样想搞AI 辅助逆向或逆向自动化的朋友做个参考。无论你是准备用 Dify、Coze 这类现成平台编排还是想基于 Rust、Python 自己搭 Agent 框架这篇文章里讲的模块划分和工具封装逻辑都能直接迁移。1. 逆向工程工作流化不是写脚本而是搭生产线很多做逆向的朋友听到AI Agent 执行逆向的第一反应是这不就是写个自动化脚本把命令一个个跑一遍吗说实话我一开始也是这么想的但真正动手之后发现两者之间隔着一条很深的沟。1.1 传统命令行脚本和 Agent 工作流的本质区别传统脚本是确定性执行你规定好第一步干嘛、第二步干嘛顺序写死遇到异常就中断。但逆向分析恰恰是高度不确定的过程——同一个 APK可能第一步反编译就报错了可能 Manifest 里什么都没藏着可能 so 文件加壳了需要先脱壳。脚本面对这些情况只能死给你看。AI Agent 工作流不一样它的核心是目标驱动 动态规划。Agent 拿到一个样本先拆包看看情况再决定下一步是静态分析还是动态调试。过程中的每个工具调用都是一次决策而不是机械执行。这才是把逆向工程工作流化的关键不是把操作步骤录制成宏而是把分析师的决策逻辑编码成 Agent 的策略。apk-reverse 这个项目的核心目标就是把逆向分析里那些可标准化的动作——反编译、字符串提取、API 调用分析、Activity 枚举、so 文件解析、动态调试、文件系统访问——全部抽象成独立模块再让 Agent 根据样本特征自主编排调用顺序。1.2 工作流总览从 APK 样本到分析报告的五个环节我在设计 apk-reverse 时把整个流程分成五个大模块对应逆向分析的五种基本姿势模块核心职责底层工具Agent 看到的输入/输出拆包与信息提取解压 APK、解析 Manifest、枚举组件apktool、aaptAPK 路径 → 包名、版本、权限、组件列表静态代码分析反编译 DEX、类与方法关系、字符串提取JADX、dex2jar、CFR代码路径 → 类结构、关键方法、硬编码信息资源与配置挖掘资源文件、so 库、assets、网络配置binwalk、readelf、strings资源目录 → so 导出函数、URL、加密密钥线索动态运行时分析启动应用、Hook 关键函数、抓取运行时数据ADB、Frida、objection目标包名 → 调用栈、参数值、返回值、内存数据报告聚合汇总所有模块产物生成结构化分析报告自研聚合层各模块 JSON → Markdown/结构化报告这五个环节之间不是严格线性的。Agent 的工作流里经常出现从静态分析发现可疑的 native 方法 → 转入动态调试 Hook 这个 native 函数 → 拿到结果后回填到静态分析上下文这种来回跳跃。所以工作流引擎必须支持动态跳转不能做成死板的 DAG。2. 静态分析模块让 Agent 真正读懂APK 的内容静态分析是整个工作流的地基也是最容易被跑了个 JADX 就当分析完了糊弄过去的环节。Agent 要真正读懂代码而不是仅仅生成一堆反编译结果这里面的差距就在于我们怎么处理和表达这些数据。2.1 拆包工具选型apktool、JADX、dex2jar 各管哪一段三个工具怎么分工我直接给结论apktool负责拆资源 转 Smali。它的强项是资源解码和 Manifest 可读化Smali 是给人看或者给动态修改用的Agent 直接读 Smali 效率太低。JADX负责出 Java 伪代码。它自带 GUI 但也可以命令行批处理输出 Java 代码的质量在同类工具里算最好的。JADX 还有一个隐藏优点是会自动处理部分混淆比如把混淆后的类名统一成 short name。dex2jar CFR/JD-Core是 JADX 失败的备选方案。有些样本 JADX 直接崩——内存溢出、解析异常都遇到过——这时候用 d2j-dex2jar 转 jar再用 CFR 出 Java 代码。我实测下来的建议是主流程走 JADX失败自动降级到 dex2jar CFRapktool 永远跑一份用于资源分析和 Smali 级补丁。这种多级降级策略对 Agent 特别重要因为 Agent 不是人它不会换个工具试试必须在编排层就把备胎逻辑写死。# 静态分析子工作流JADX 失败自动降级 def analyze_static(apk_path): try: jadx_output run_jadx(apk_path) # 主路径JADX return parse_jadx_jobs(jadx_output) except JADXException: jar_file run_dex2jar(apk_path) # 降级路径1dex2jar java_code run_cfr(jar_file) # 降级路径2CFR return parse_cfr_jobs(java_code)2.2 代码语义化如何把反编译产物变成 Agent 可消费的结构化信息这一节是整个静态模块的灵魂。JADX 输出的是人可读的 Java 代码但 Agent 是模型它处理的是 Token。一万行 Java 代码直接塞给模型上下文一下就爆了——别忘了热词里大家都在纠结dify工作流 上下文超长的问题。所以 apk-reverse 在 JADX 输出和 Agent 之间加了一层代码语义化管道。它的工作包括提取类关系图把继承、接口实现、内部类关系从代码里捞出来生成结构化 JSON。Agent 看到的不再是源码而是一张类地图。筛选高风险调用重点标注Runtime.exec()、System.load()、Cipher.getInstance()、Intent.setData()这类涉及代码执行、动态加载、加密和组件通信的 API 调用点。抽取字符串常量池把代码里所有长字符串、base64 码、URL、IP 抽出来单独建索引。逆向分析里很多关键信息服务器地址、加密密钥、API Key就藏在字符串里。关联 Analysis 记录JADX 自带 Analysis 模式会把常量传播、调用关系计算出来命令行里用--analysis-mode参数打开输出质量提升明显。这样处理之后一份 20MB 的 APK 静态分析结果最终喂给 Agent 的结构化摘要可能只有几千 Token但信息密度远超直接贴源码。2.3 AndroidManifest 的挖掘点入口、权限、组件是 Agent 的第一步侦察Manifest 是 Agent 理解一个 App 的第一份情报我专门封装了一个 Manifest Digest 工具。它要抓的不仅是包名和版本号更关键的是这几样exported 组件android:exportedtrue的 Activity、Service、Receiver 是外部可直接触达的入口也是安全分析的高价值目标。自定义权限App 定义的permission标签和protectionLevel能看出 App 的权限隔离设计。网络配置usesCleartextTraffic、networkSecurityConfig对应的 XML直接暴露了 App 是否允许明文通信、有没有证书固定。ContentProvider authorities所有 provider 的 authority 字符串要收进清单后面动态分析里要拿content://URI 去访问。每次提取完Agent 会拿到一份结构化的 Manifest 摘要包含组件总数、exported 组件列表、权限列表、provider authority 列表。Agent 接下来往哪个方向深入——是分析登录逻辑、还是调查某个 provider 的数据暴露——就靠这份摘要来决定。3. 动态调试与运行时交互模块Agent 的手和眼睛静态分析只能看出可能有什么问题要验证实际问题是什么还必须把 App 跑起来看。这个模块是整个工作流里工程复杂度最高的部分因为涉及真机/模拟器、进程管理、UI 自动化、Hook 注入这一大堆容易翻车的环节。3.1 ADB 能力封装与设备抽象层Agent 本身不知道什么叫设备离线什么叫USB 调试未授权它看到的应该是统一的设备抽象。apk-reverse 里我封装了一个 ADB 网关层把设备相关的琐碎操作全部打包成高层的 Agent Tool# ADB 网关工具的典型接口设计 def adb_shell(device_id, command) - ShellOutput def adb_install(device_id, apk_path) - InstallResult def adb_am_start(device_id, component) - ActivityStartResult def adb_forward(device_id, local_port, remote_port) - ForwardResult def adb_current_focus(device_id) - str # 返回当前前台 Activity设备层要处理的状态包括多设备连接时的-s device_id选择、root 权限有无的判断、SELinux 状态很多 Hook 操作受 SELinux 限制、以及/system/bin下可用命令集的探测。我踩过最大的坑是无 root 环境下的动态分析。测试机上很多 App 跑在非 root 环境su命令不可用Frida 的frida-server推不进去。后来改用frida-gadget注入模式通过重打包 APK 加入 gadget so 库来接管 App 进程。这个方案对强度一般的壳有效而且重打包本身也是逆向工作流里常见的分支动作Agent 需要会给 APK 做植入手术再装回去。3.2 Frida 脚本的动态生成与调用封装Frida 是动态分析的核心武器。但在 Agent 工作流里直接让 Agent 写 Frida 脚本是不现实的——模型写 JavaScript 的水平写个小功能没问题写复杂的 hook 逻辑非常容易翻车而且 Frida 脚本是跑在目标 App 进程里的调试成本极高。稳妥的做法是预置一批高频 Hook 模板Agent 只需要填参数。我在 apk-reverse 里预置了这些脚本hook_activity_lifecycle.js自动跟踪所有 Activity 的 onCreate/onResume/onPause输出生命周期调用序列。用于分析启动流程。hook_method_by_name.js按类名方法名 Hook打印参数、返回值、调用栈。这是最常用的比如 Agent 想查某个加密函数的入参出参直接调用。hook_ssl_pinning_bypass.jsSSL Pinning 绕过模板配合抓包用。hook_shared_preferences.js拦截 App 对 SharedPreferences 的读写输出 key-value 变化记录。hook_okhttp_interceptor.jsHook OkHttp 的请求/响应把 URL、Header、Body 全部打印出来。很多 App 的网络层集成 OkHttp这个模板命中率极高。// hook_method_by_name.js 的核心逻辑 Java.perform(function() { var targetClass Java.use({{CLASS_NAME}}); var targetMethod targetClass.{{METHOD_NAME}}.overload({{ARG_TYPES}}); targetMethod.implementation function() { console.log([CALL] {{CLASS_NAME}}.{{METHOD_NAME}}); console.log([ARGS] JSON.stringify(Array.prototype.slice.call(arguments))); var ret this.{{METHOD_NAME}}.apply(this, arguments); console.log([RET] ret); return ret; }; });Agent 调用这个工具时传参格式是class_namecom.example.LoginManagermethod_namegetTokenarg_typesjava.lang.String工具层负责把参数填进模板、push 到设备、拉起 frida 并收集输出。这样 Agent 完全不碰 JavaScript也能实现精准 hook。3.3 UI 自动化的取舍什么时候用坐标什么时候该放弃动态分析经常需要模拟用户操作比如点开某个页面、输入账号密码、触发某个按钮。UI 自动化的标准方案是 UIAutomator 或 Appium但它在上工作流里有几个致命问题坐标易变不同分辨率、不同系统版本控件坐标全变纯粹用坐标点击翻车率极高。控件树可能为空某些 WebView 页面或自绘 View用 Flutter/Unity 开发的 App获取不到标准控件节点。弹窗打断隐私弹窗、更新弹窗、广告弹窗随时出现Agent 根本预判不了。我的处理思路是轻量驱动 状态回读。不到万不得已不模拟点击优先用 ADB 直接启动 Activity 或用广播触发组件。如果必须点击用uiautomator dump先拿控件树再按 text 或 resource-id 定位实在找不到控件再用坐标兜底。每次点击后强制回读当前焦点 Activity 和应用崩溃状态一旦发现 App 崩了立刻终止自动化并保存现场。4. 文件系统与 Content Provider 访问绕过沙盒的数据获取动态分析绕不开数据层。App 自己的私有目录、外部存储目录、跨应用共享的 ContentProvider都是高价值数据源。但 Android 的权限管控这些年越来越严每个版本都在堵路这里边的门道值得单独开一节。4.1 /storage/emulated/0/Android/data/ 的访问权限变化与处理热词里有很多content://和/storage/emulated/0/Android/data/相关的路径说明大家在实际逆向中都被这个目录卡过。以com.tencent.tmgp.sgame某款MOBA手游的路径/storage/emulated/0/Android/data/com.tencent.tmgp.sgame/files/pandora/为例这类目录在 Android 11 之后默认是访问不了的——即便有 root 权限App 的私有数据也在 CE 存储加密分区里普通文件管理器看不到全貌。在 apk-reverse 的动态模块里我封装了一个文件系统访问层按优先级排列root adb shell su -c有 root 就暴力直接读/data/data/package/下的 databases、shared_prefs、files。注意加chmod 755或先copy出来再读。adb backup提取对于非 root 设备如果 App 在 Manifest 里声明了android:allowBackuptrue可以用adb backup -f backup.ab -noapk package拉取应用私有数据再用脚本解开备份文件。这个方法对很多应用仍然有效是个隐蔽的后门。模拟器 Xposed/LSPosed 模块在模拟器里用 Xposed 模块挂钩File.listFiles()等 API绕过框架层的路径过滤。重打包加 frida-gadget最通用的方案用 gadget 注入后通过 Frida 的filesystemAPI 直接读文件。注意第 2 种方案在 Android 12 之后做了调整部分 App 即使声明了 allowBackup 也会在运行时检测备份行为。实战中 Agent 应该按顺序尝试哪种通了就用哪种每个方案成功后要做标记便于下次优先。4.2 content:// URI 的跨应用访问兼容热词里有content://com.baidu.searchbox.fileprovider/...和content://com.tencent.wework.fileprovider/...这类 FileProvider 路径。分析某个应用读取其他应用共享文件的场景时Agent 需要主动构造或解析这些 URI。FileProvider 的特点是通过authorities和paths的映射关系把真实的file://路径映射成content://URI避免直接暴露绝对路径。逆向时我们常需要拿到content://后反向推导真实的file://路径。方法是找反编译产出里的file_paths.xml通常在res/xml/下它定义了files-path、cache-path、external-path等映射规则。用adb shell content query --uri content://authority/path检测目标 provider 是否可访问、有哪些字段。如果是跨应用数据窃取的评估场景需要模拟一个恶意 App 来验证 exported provider 是否存在权限绕过。Agent 拿到 URI 之后不应该自己去猜工具层应该把content query、content read、content call这些命令全部封装好Agent 只需要声明我想读这个 URI。4.3 Android 进度条与耗时的 UI 反馈热词里有个有意思的android进度条。在工作流自动化里进度条不是 UI 细节而是一个逻辑信号。很多 App 在进行耗时操作登录、加载、下载时会显示进度条或 Loading 动画。Agent 动态分析时如果只是点完按钮就立刻 dump 数据经常会抓到半成品状态。我在 UI 自动化工具里专门做了一个等待条件参数支持三种模式等待控件出现循环uiautomator dump直到某个 resource-id 出现。等待网络空闲用adb shell dumpsys connectivity或读取/proc/net/判断网络请求是否还在进行。等待文本出现比如等登录成功或加载失败文本出现再截图。这相当于给 Agent 的手装了一双会等反馈的眼睛避免为了赶进度抓瞎。5. AI Agent 编排层把散装工具串成一条主动工作的流水线前面几个章节是臂膀编排层才是 apk-reverse 的大脑。Agent 怎么选工具、怎么在不同模块间跳转、怎么恢复状态全在这一层决定。这也是跟 Dify、Coze 这些平台对接时的核心接口面。5.1 Agent 的记忆分层与上下文压缩最先要解决的就是热词里反复出现的上下文超长问题。逆向分析一次会话产生的数据量非常惊人反编译日志几百 MB 不夸张Frida 脚本输出几万行也常见。全塞给大模型是愚蠢的。我的方案是三层记忆短期记忆会话内当前分析目标、最近 10 条工具调用结果摘要。每轮的对话上下文只保留必要内容。工作区记忆文件层每次工具运行的完整输出写到工作目录Agent 需要时通过读取文件片段工具去查而不是直接灌进上下文。这一步非常关键——把上下文记忆变成文件系统记忆理论上 Token 消耗与数据量脱钩。长期记忆跨会话样本特征、包名、壳类型、常用入口点等元信息存进 SQLite下次拿到类似样本先查历史记录很可能直接复用之前的分析路径。5.2 工具调用Function Calling与 Workflow 的协作模式现在的 Agent 框架不管是用 Rust 还是 Python 自建还是用 Dify、Coze 这类平台核心机制基本是 Model 发出 Function Call → 平台执行工具 → 返回结果 → Model 决定下一步。apk-reverse 在应用这个模式时定义了一套标准的工具规范。工具规范的几个关键字段{ name: static_analyze_dex, description: 对 APK 中的 DEX 进行反编译与结构化提取输入为 APK 路径输出为类/方法/字符串的结构化索引, parameters: { type: object, properties: { apk_path: {type: string, description: APK 文件绝对路径}, focus_keywords: {type: array, items: {type: string}, description: 重点关注的类名/关键词非必填} } } }描述信息要写的像给一个没见过工具的新同事交代事情一样清楚——这个工具干什么、输入什么、输出什么、什么时候用。我见过太多工作流失败是因为工具 description 写得含糊模型根本不知道什么时候该调这个工具。提示工具粒度要控制好。太细了 Agent 频繁调用Token 损耗大太粗了模型不知道内部逻辑没法做精确决策。一般粒度的判断标准是一个正常分析师完成这个动作大约需要几步。比如提取 Manifest算一步反编译整个 APK算一步拉取 Frida 输出算一步。5.3 AI Agent 怎么扛并发任务队列与去重策略热词里有人搜ai agent 怎么扛并发这确实是个大坑。Agent 工作流不是普通 Web 服务它的每个任务都是长连接 多步决策数据库里能开一万个连接但一万个 Agent 同时在调 JADX 跑 Frida机器直接就没了。我的方案是两级并发控制任务队列层所有请求先进 Celery/RQ 队列按优先级出队。下载和分析是两个不同优先级——下载是高频 IO分析是高频 CPU/内存。队列分别设置最大并发数。工具进程池重工具JADX、Frida 起进程用进程池限制最大实例数。比如同一台机器最多同时跑 3 个 JADX、5 个 ADB 会话。超出就排队等待这个等待动作要显式暴露给 Agent让它知道分析任务在排队不要重复提交。并发问题的根因是工具有状态反向轮询Agent 主动查任务状态比正向推送工具完成后回调 Agent更容易实现且更稳定。我最终用的是Agent 提交任务 → 获取任务 ID → 轮询任务状态 → 拿到最终产物的流程每一步都是独立 HTTP 接口天然扛并发。5.4 错误恢复与多轮重试Agent 工作流最被低估的能力一个 Agent 工作流好不好用不看它顺利时跑得多快看它出错时死得多惨。我系统梳理了 apk-reverse 里常见的错误类型针对性地设计了恢复策略错误类型典型场景恢复策略环境错误设备离线、JADX 内存溢出、磁盘写满换备用设备、降低 JADX 内存参数、清理工作区后重试工具错误反编译失败、frida 注入失败走降级链换工具组合JADX → dex2jarCFR应用状态错误App 崩溃、闪退、ANR重启 App、清除数据后冷启动最多重试 3 次逻辑错误Agent 选错工具、参数传错记录错误上下文在下一轮决策前注入上一步失败原因引导换策略我把失败原因回灌做成了一个独立的工具inject_error_context它会把上一步的错误信息摘要追加到当前上下文中让模型意识到自己刚才的决策有问题。这个机制比单纯重试效果好得多——模型在看到JADX 内存不足之后下次智能地换用 dex2jar而不是继续傻乎乎地重试 JADX。6. 游戏逆向场景从样本定位到逻辑破解的完整走查热词中出现大量游戏逆向相关内容逆向工程游戏逆向、com.tencent.tmgp.sgame说明这是实际需求最密集的场景。就拿一款 Unity3D 手游样本做一次走查展示 apk-reverse 工作流怎么一步步找到关键逻辑。6.1 一例 MOBA 手游样本的完整走查拿到一个 APK 样本工作流自动启动阶段一拆包与侦察Agent 先调decompile_apk跑 apktool 拆开资源提取 Manifest 摘要。看到的信息包括包名com.tencent.tmgp.sgame、包含libil2cpp.so说明是 Unity IL2CPP 架构、libtersafe.so有企业级加固、主入口是标准的 Unity 入口 Activity。这里 Agent 做的关键决策是因为检测到 IL2CPP放弃传统的 DEX 分析为主路线把重心放到 so 层。传统逆向思维关注 DEXJava 层逻辑但 IL2CPP 游戏的核心逻辑全部在libil2cpp.so里DEX 里只剩框架代码。阶段二Il2Cpp 符号还原这一步是游戏逆向的核心痛点。libil2cpp.soglobal-metadata.dat的组合里metadata 文件保存了所有类名、方法名、字符串信息但它本身是加密的。工作流里的il2cpp_dumper工具负责从 so 里 dump 出符号信息还原出完整的方法列表。Agent 拿到还原后的符号表用关键词搜索login、auth、token、AES定位到认证相关的类提取出关键函数。随后把函数地址列表交给下一步。阶段三动态 Hook 关键函数Frida 模板工具根据 Agent 传入的参数类名、方法偏移生成 hook 脚本。这里注意 IL2CPP 的 hook 不能用常规的Java.use()得用Il2Cpp.perform()配合Il2Cpp.Api来调用。apk-reverse 里专门封装了il2cpp_hook_template.jsIl2Cpp.perform(function() { var targetClass Il2Cpp.Domain.assembly(Assembly-CSharp) .image.class({{CLASS_NAME}}); var targetMethod targetClass.method({{METHOD_NAME}}); targetMethod.overload().invokeHook(function(args) { console.log([Il2Cpp CALL] {{CLASS_NAME}}.{{METHOD_NAME}}); this.invoke.apply(this, arguments); }); });实际运行时这个 hook 成功捕获到了登录函数的参数构造过程和返回值格式进而确认了客户端加密方式以及是否有人在客户端本地做签名校验。阶段四资源访问与文件提取游戏运行后会在外部目录写入热词里那种/storage/emulated/0/Android/data/pkg/files/pandora/路径下的热更新资源。工作流的文件系统模块把该目录内容列出来发现资源版本配置和部分未加密的 Lua 脚本。这一步直接揭示了游戏的资源更新策略也为后续做资源定制提供了入口。6.2 加固与混淆对抗工作流怎么识别和拆除保护壳热词里提到的游戏逆向大多涉及企业级加固。apk-reverse 里有一个独立的shell_detector工具通过特征匹配识别壳类型检测libDexHelper.so→ 某大型加固方案检测libshell*.solibexec*.so→ 某免费壳检测libprotectClass.so→ 某企业壳检测libjiagu.so→ 某老牌加固识别出壳之后工作流有两种路线脱壳路线对强度不高的壳用 Frida 的dump_so和dump_dex脚本在内存中还原真正的 DEX 和 so。这一操作的本质是趁 App 运行时把解密后的代码从内存中抠出来。流程是启动 App → 等壳完成解密 → Frida dump 内存镜像 → 用 dump 出来的 DEX 替换原先的空壳 DEX → 重新走静态分析。行为分析路线对强度高、dump 不出来的壳暂时放弃静态完全走动态。通过 Frida 在 App 运行过程中拦截所有类加载行为ClassLoader.loadClass点记录真实被加载并执行的高价值类再对这些类做反射调用探测。虽然效率低但作为兜底方案可靠。加固对抗的关键经验不要一上来就想着脱壳。很多样本的壳强度并不需要脱它的核心加密逻辑在 Java 层动态 hook 一下就看到了。脱壳是最后手段不是常规武器。Agent 在决策时应该优先尝试轻量方案只有确认 Java 层逻辑确实在加密的 Dex 里、不脱壳完全无法分析时才进入脱壳分支。6.3 模拟器与真机的选择逻辑游戏逆向里最大的变量之一就是运行环境。热词里有android tvAndroid TV 设备的动态分析也被频繁提到——电视端的逆向逻辑和手机端差异很大没有触摸交互只靠遥控器按键UI 自动化基本失灵。apk-reverse 在设备选择上有一个决策规则集首选模拟器性能可控、支持快照、root 方便、支持 Xposed。但注意很多游戏有模拟器检测需要过检测后才能跑起来。次选真机兼容性好、检测少适合调试和验证阶段的场景但 root 麻烦且容易炸机。Android TV / 车机类Automotive OS真机或对应模拟器分析重点在系统应用和 Service 交互UI 自动化要偏向按键导航adb shell input keyevent。模拟器方案我强烈推荐带 Xposed 模块的定制镜像比如雷电模拟器 LSPosed因为它们可以同时兼顾隐蔽性和可控性。真机上做frida-gadget注入要处理签名校验很多 App 有 signature 校验保护重打包后直接闪退这时候需要配合hook_signature_verify.js绕过。这些脚本都要作为工具库预置不要让 Agent 现场写。7. 实战中的意外情况与补充经验写到这里分享几个只有实际操作过才会注意到的细节这些细节在项目规划阶段通常想不到但往往决定工作流能不能稳定跑下去。Java 版本与工具兼容性。JADX 新版本要求 JDK 11apktool 在 JDK 17 上有一些反射相关警告CFR 对高版本字节码要加参数。如果工作流跑在容器里没配好 Java 版本就会出现工具装好了但全打不开的尴尬。我在工作流初始化时加了一步env_check把所有工具的版本和 JDK 版本一次性打出来给 Agent 确认。文件路径里不能有中文和空格。这个太老套了但真的会踩JADX 和 dex2jar 对带空格路径的容忍度极差Agent 在处理外部上传的 APK 时经常把文件放在带空格的目录里导致后续工具全部报路径错误。工作流里的文件接收模块要统一做一次路径净化——重命名、去空格、统一目录层级。工作区空间管理。一次完整的逆向分析可能产生 10GB 级别的中间文件反编译输出、内存 dump、抓包文件。工作流的清理策略不能一刀切删要留最近一次任务的文件供人工复查。我用的是保留最新任务完整产物 其余任务只留报告的策略。这个策略 Agent 是感知不到但也必须内置的否则跑几天磁盘就爆了。模型选择对工作流质量的影响。不同模型在 Function Calling 上的表现差异巨大。实测下来推理能力强的模型比如 GPT-4o、Claude 3.5 Sonnet、DeepSeek 的强推理模型在工具选型和错误恢复上的表现明显优于普通模型。 如果公司有成本压力可以把简单动作提取、解析交给轻量模型把决策环节下一步做什么交给强推理模型混合调度能显著降低成本。我自己习惯的做法是在这条工作流上做验证时先用强推理模型跑通全链路再把高频的子流程比如提取 Manifest 摘要下沉到轻量模型这样平衡了成本和质量。Agent 工作流不是越智能越好而是该智能的地方智能、该机械的地方机械。8. 从工具到体系把 apk-reverse 用起来的三条建议项目走到一定阶段我发现真正难的不是写工具而是怎么把它变成团队/个人能持续信任的分析基础设施。分享几条收尾的体会。第一先跑通最小闭环再谈大而全。最开始不要试图把逆向 Agent一步到位做完整先挑一个高频场景比如自动提取 APK 的 Manifest 摘要 高危 API 列表打通APK 上传 → 工具调用 → 报告输出的全流程。这个小闭环能跑通之后再逐步加入 Frida Hook、脱壳、UI 自动化这些重工具。第二工具封装比模型聪明更值钱。Agent 工作流的瓶颈很多时候不是模型不够聪明而是工具封装得太粗糙——参数定义不清、错误反馈不全、并发控制缺失。你把工具封装的越好用模型的决策质量就越高。这个投入是复利式的每个工具打磨一点整条工作流的稳定性上一个台阶。第三保留人工复核的出口。任何自动化逆向工作流最后都必须有一位分析师做结论性判断。自动化的价值在于把分析师从高频重复劳动里解放出来而不是取代分析判断。apk-reverse 在所有关键节点都会产出可供人工复查的日志和中间产物这个设计让团队接受度大幅提升。如果你正在搭建类似的 AI Agent 逆向工作流或者是准备用 Dify、Coze 编排逆向自动化流程这里面的模块划分和踩坑经验希望能帮你少走几段弯路。等手里这个项目再跑一段时间我打算把工具封装规范和几段实际的分析日志整理出来单独写一篇到时候再见。