1. 为什么我会把 Android 逆向工程交给 AI Agent先讲一个让我下定决心做这个项目的场景。上个月我需要分析一个第三方 App 的资源文件结构和签名信息整个流程说起来不复杂解包、看 AndroidManifest、拉签名、确认目标 SDK 版本和权限声明再定位几个关键字符串。但真正动手的时候我发现自己在一遍又一遍地重复敲同样的命令而且每换一个目标 App都得重新走一遍这串流程。当时我脑子里冒出来的想法是这套流程明明已经高度固定了为什么不把它写成一个 AI Agent 可以理解、可以执行的工作流让 Agent 自己跑命令、读产物、做判断我只负责给方向和审核结果。事实上apk-reverse这个方向并不是什么新东西把单个 ApkTool 命令或者 jadx 反编译脚本写出来的人很多。但把整条逆向链路——从解包、配置解析、代码反编译、资源提取、签名校验到最终报告生成——作为一条可编排、可复现、可被 Agent 驱动的工作流来做目前还很少有人系统性地整理。这篇内容就是想把这套工作流完整拆开讲清楚每一步为什么这么做、底层逻辑是什么、实际跑起来会遇到哪些坑以及如何把它接入你自己的 AI Agent 架构里。适合谁来读如果你正在做 Android 逆向分析、移动安全测试、竞品 App 研究或者你手里已经有一个 AI Agent 项目正发愁怎么让它去执行真实世界里的复杂任务这篇文章都能给你一套可以落地的参考实现。先给个结论把逆向工程工作流交给 AI Agent核心价值不在于让 Agent 替你做安全研究而在于让那些套路固定、重复度高、出错成本低的环节自动化把人的精力释放到真正需要判断力的地方。2. apk-reverse 工作流整体架构与核心模块拆解2.1 不是让你写死脚本而是让 Agent 可理解、可决策很多第一次接触AI Agent 逆向工程的人会有一个误解Agent 工作流不就是把原来写好的脚本用自然语言包装一下吗其实差别很大。传统脚本是确定性的——输入一个 APK跑 ApkTool输出反编译结果完事。Agent 工作流则要求每一步都有感知-决策-执行-反馈的闭环。比如解包之后Agent 需要主动读取 AndroidManifest.xml识别主 Activity、申请的敏感权限、目标 SDK 版本然后根据这些信息决定下一步是去做代码审计还是做资源分析。这就意味着整个工作流的每一步都要有明确的输入、输出和判断条件而不是简单地把命令串起来。我整理了一下一个完整的 apk-reverse Agent 工作流至少需要这几个模块模块职责关键产出物Agent 决策点环境探测确认工具链可用性、APK 基本信息文件类型、大小、MD5判断是否需要换工具解包模块提取 APK 资源与 smali 代码目录结构、Manifest识别组件与权限配置分析解析 AndroidManifest 与签名信息组件清单、权限列表确定分析优先级代码反编译将 smali 转为可读 Java 代码Java 源码定位核心逻辑资源提取拉取资源文件、资源表图片、布局、字符串发现隐藏资源报告生成汇总各阶段产物分析报告判断分析闭环程度2.2 用 Rust 还是用 Python 做底座我的取舍我的实现里底座语言选择了 Rust。这里有个背景AI Agent 的指令执行往往需要低延迟、高可靠、内存安全的运行环境Python 虽然生态丰富、写起来快但一旦涉及大型 APK 的文件解析和二进制处理性能瓶颈很明显。Rust 在内存管理和并发上有天然优势也能直接编译成单二进制文件丢到任何 Linux 环境里跑对 Agent 的部署非常友好。当然这不代表完全抛弃 Python。实际架构里笨重的语义分析、报告格式化这类任务仍可以外抛给 Python 脚本Rust 只负责核心链路的编排和文件处理。这种Rust 主流程 Python 辅助分析的组合是我实测下来性能和开发效率比较平衡的方案。有人会问为什么不能直接用现成的 Frida、ApkTool 那些工具非要自己做一套工作流我的回答是工具是原子操作工作流是编排。ApkTool 只负责把 APK 解开但解开之后做什么、怎么做、结果怎么解读这些是需要你自己定义的。AI Agent 的价值恰恰在编排层。2.3 两个核心 Agent 角色的划分我的工作流里拆了两个角色分析 Agent和执行 Agent。分析 Agent 负责理解任务目标、拆解分析计划、读取中间产物并做推理判断执行 Agent 负责调用具体的命令工具比如 apkanalyzer、aapt2、jadx、ApkTool 等。为什么拆成两个因为它们在职责边界、运行环境、失败处理上的需求完全不同。分析 Agent 需要大模型上下文窗口、需要能看到多次执行的输出因此采用大模型 API 或本地模型推理执行 Agent 则是轻量级进程管理器负责命令的启停、超时控制、退出码检查。这样就算执行 Agent 跑挂了任务失败分析 Agent 也能根据错误信息重新生成指令再次下发执行形成真正的反馈闭环。实际开发中我会让执行 Agent 返回一个统一格式的执行结果结构退出码、标准输出、错误输出、执行耗时。分析 Agent 拿到这个结构后判断是继续还是纠错。这一步是整个工作流能不能活起来的关键。3. 从零实现工作流APK 信息采集与解包实操3.1 基础环境配置在写任何逻辑之前先把环境拾掇干净。这个环节容易翻车——很多人以为装个 ApkTool 就能干活真正解包的时候才发现要用的工具链比想象中多。我目前在 Ubuntu 22.04 上跑这套工作流核心工具清单如下JDK 11 或以上ApkTool、jadx 都是 Java 生态Android SDK 构建工具提供 aapt2、apkanalyzerApkTool资源与 smali 解码jadxsmali 转 Java 的可读源码jadx-gui人肉审计时用来浏览Agent 模式下可不装keytool 与 apksigner签名校验file、md5sum 等基础系统工具安装那几步本身不难但有一个细节必须提醒环境变量要统一。比如 aapt2 在不同版本里的默认行为有差异我碰到过明明装了 build-tools 30但临时输入文件路径带空格导致 aapt2 直接挂掉的情况。所以路径统一走环境变量注入别写死在脚本里。3.2 第一步确认这个 APK 到底是什么这是最容易被跳过的步骤但恰恰是最重要的。拿到一个 APK 文件先不要急急忙忙解包先确认三件事文件本身是不是合法的 zip 结构。APK 本质是 zip 压缩包用 file 命令和 magic bytes 校验一下能在早期拦截掉很多伪装成 APK 的勒索病毒或直接改名的不良文件。我见过有人拿到的样本根本不是 Android 安装包结果后面每一步都在做无用功。第二步是计算哈希值并记录。这一步看起来对分析没什么用但对工作流的可复现性和核查很重要。你在逆向过程中得到的每一份报告对应的样本必须是唯一确定的哈希就是那个指纹。第三步是用 aapt2 dump badging 快速拿包名、版本号、原生平台等基础信息。这一步的输出是整个工作流的第一层结构化数据分析 Agent 后面做任何判断都依赖它。3.3 解包ApkTool 和 apkanalyzer 到底该选谁解包这一步我一般同时跑两套命令产出物用途不同ApkTool 做完整资源解码主要是拿到可读的 AndroidManifest.xml、资源和 smali 代码。命令很简单apktool d -f -o output_dir target.apk其中-f是强制覆盖-o指定输出目录。实测里一个 50MB 左右的 APKApkTool 跑完大概在 10~40 秒之间取决于机器的磁盘和 CPU。apkanalyzer 则是 Android 官方工具适合拿结构化元数据。比如apkanalyzer manifest target.apk apkanalyzer files list target.apk它输出的格式更加规整方便 Agent 做后续解析。相比之下 ApkTool 输出的 AndroidManifest.xml 虽然可读性好但遇到一些混淆过的资源命名或者特殊编码时解析起来会麻烦些。所以我的习惯是用 ApkTool 做资源级解码用 apkanalyzer 做结构级信息采集两者互补。很多教程只讲 ApkTool 一条路等你想自动化的时候就会哭。3.4 动态授权目录的处理从路径读出的攻防线索近两年 Android 应用里大量出现一类路径/storage/emulated/0/Android/data/包名/files/...比如com.tencent.tmgp.sgame王者荣耀下的 pandora 目录。这类路径消息其实隐含了大量信息。/storage/emulated/0是可共享外部存储的根路径Android/data是应用私有外部目录files是应用自己的文件子目录。一个应用把资源或缓存放到这个位置一是为了绕过内部存储大小的限制二是为了跨 App 共享某些数据。所以当你逆向时在代码、资源、日志里频繁看到这类路径基本可以判断这个 App 存在文件级数据交换逻辑。再注意一个点/storage/emulated/0/Android/data/其实屏蔽了内部路径细节而且新版 Android 对这块目录的访问限制越来越严。Agent 在分析这类路径的时候不只是识别字符串还要判断这个 App 是否有能力访问沙盒外的敏感目录这就需要结合 Manifest 中的权限声明。我在工作流中为这类路径专门配置了正则识别和大数据归类模块用于判断该 App 是否存在敏感数据搬运行为。这里有个可复现经验任何一个从外部读文件写文件的 App都值得你重点观察它的文件读写对儿。4. AndroidManifest 与签名信息的深度解析4.1 Manifest 不是一张清单而是一张地图很多人觉得 Manifest 解析就是把所有 Activity、Service、Receiver 列出来。这没错但只做到了 20% 的价值。AndroidManifest.xml 在逆向分析里更像一张地图你需要在上面找到入口、找到暗道、找到权限边界。分析 Agent 在读完 Manifest 之后至少要输出以下几类决策数据Main ActivityApp 的启动入口往往是核心业务代码的挂载点exported 组件能被外部应用调起的组件这是攻击面最大的地方Application 类自定义 Application 常常承载全局初始化逻辑权限申请列表与业务无关的高危权限是典型的风险信号URL scheme / service 声明深链入口也是注入点比如看到一个 App 申请了android.permission.QUERY_ALL_PACKAGES查询所有已安装应用却没申请任何存储权限紧接着在代码里发现它遍历了所有应用信息并写入了某个/files/下的数据库那这个 App 的行为就很值得放在显微镜下看。所以我让分析 Agent 在拿到 Manifest 后先做一个组件重要性排序再决定从哪个组件开始深挖。这一步能让整个分析过程聚焦不会在读无关代码上浪费时间。4.2 签名信息验证来源与判断篡改签名校验是很多人会忽略的环节尤其是自动化分析时。我总结过一句话每次解包之前都应该知道这份 APK 是谁签的名、用的是 v1 还是 v2 签名方案因为签名方案直接决定了某些注入手法是否可行。用 apksigner 校验apksigner verify --print-certs test.apk输出中能看到签名证书的 SHA-256 指纹。Agent 拿到指纹后可以对比在线数据库判断这个签名的归属。如果一份 APK 的签名信息和官方版本不一致那要么是第三方篡改包要么是恶意重打包。分析价值完全不同。这里有一个很常见的坑待分析的样本可能同时包含 v1 和 v2 签名。v1 签名在 Android 7.0 以下生效v2 在 Android 7.0 以上生效。如果你在验证的时候不看签名方案版本直接用 v2 校验逻辑去处理会得到一个看似校验失败的结果实际只是因为样本没有 v2 签名而已。这个细节在你做 Agent 自动化时很重要因为你不可能每次都人工去判断签名方案。4.3 资源文件里藏着大量线索不要直奔代码很多新手做逆向分析总喜欢第一时间奔着反编译出来的 Java 代码去读。我实测下来发现真正花时间读代码之前应该先花半小时把 res 资源目录扫一遍。资源里静态字符串经常比代码本身更能暴露业务逻辑。举个例子我在某个样本里发现一张文件名为cron_secret_key.png的图片资源你以为它是图片实际里面藏了一段 base64 编码的密钥。把这些密钥组合起来配合外部 URL 的域名特征基本可以拼出整个 App 的通信架构。这部分的实现方式我让分析 Agent 关注几个关键点资源命名规律是否混淆、硬编码的 URL 与 key、so 库的命名与来源。lib/下的 so 文件命名特别有讲究比如直接叫libprotect.so的那基本是把壳或保护逻辑写进去了值得优先看。4.4 从 Android Studio 角度反视项目结构既然在做 APK 逆向很多人会顺手把反编译产物导入 Android Studio 里看。这招确实好用但有个大坑Android Studio 是基于 Gradle 工程结构的本身不是为 smali 或反编译产物设计的。如果你把 jadx 输出的 Java 代码直接丢进 Android Studio工程结构大概率要报错。我的做法是用 jadx-gui 做浏览参考真正可编译、可查询的工程还是靠 apktool 解出来的 smali 资源去搭。当然 Agent 模式下不需要 IDE它只需要能可编程地读取、检索、全文搜索这些代码数据。但反过来看理解 Android Studio 的项目结构反而能帮你更好地设计反编译产物的目录组织哪些目录放哪类文件、哪些文件是资源的、哪些是代码的都应该在设计工作流时预先规划好。Agent 不会像人一样乱点它只能跟着你定义好的结构走所以结构设计的合理性直接决定分析效率。5. 代码反编译与关键逻辑定位让 Agent 学会找鱼5.1 反编译链路的选择与衔接反编译是整个逆向流程中算力最密集的步骤。我主要用 jadx 来负责代码转换但它不是银弹。之前遇到过一个混淆得很凶的样本jadx 的反编译结果缺失了大量方法体很多逻辑都是空的。后来我把 smali 反编译链路加进去用 ApkTool 产出 smali再用脚本把对应类的 smali 字段、指令流结构化配合 Agent 去分析。smali 虽然读起来痛苦但它是保真的——不像 jadx 会因为混淆而漏掉代码。有些情况下smali 的分析结果是唯一可靠的信息来源。所以我目前的链路是jadx 反编译 Java 源码给 Agent 一个大体框架smali 结构化指令流用于 jadx 失效时的深挖交叉引用分析根据字符串、类名、包名反查逻辑位置三条链路互相印证Agent 就不会被单一失真结果带偏。5.2 关键字命中不只是搜字符串让 Agent 在几万行代码里定位关键逻辑最常用的手段就是关键字检索。我预置了一批模式每次解包后都会全量扫描网络相关http://、https://、socket、websocket、grpc数据存储sqlite、SharedPreferences、FileOutputStream、encrypted安全相关root、su、Magic、Hook、frida、xposed组件调度Intent、startActivity、content://、file://、Bindercontent://这个值得多说一句。比如搜索热点词里出现的content://com.baidu.searchbox.fileprovider/baiddpath/...这种 FileProvider 的 content URI 意味着该 App 对外开放了文件访问能力。攻击者如果能控制传入的 URI 的路径部分就可能造成任意文件读取。工作流里必须对content://资源做高优匹配并转成分析报告。我实际跑的时候将关键字命中结果按风险等级分组匹配到高危关键字后Agent 会直接定位到对应代码块再读取上下文。整个过程完全脚本化不需要人工点开代码一行行看。这一步是 Agent 工作流里省人效果最明显的。5.3 硬编码信息的提取与自动化隐藏在各种字符串表、资源文件、代码常量里的硬编码信息往往是高效分析的富矿。比如API endpoints加密密钥Token / Secret证书指纹第三方 SDK 的 appId我在工作流里集成了一个基于正则与启发式规则的提取器专门负责挑这些字段。它有几个规则是固定保留的[a-zA-Z0-9/]{40,} - 疑似 base64 密钥 eyJ[a-zA-Z0-9_-]\.eyJ[a-zA-Z0-9_-] - JWT AIza[0-9A-Za-z_-]{35} - Google API Key sk-[0-9a-zA-Z]{20,} - OpenAI 风格密钥这套提取器跑完以后会生成一个结构化 JSONAgent 读 JSON 来决定这些信息的用途。有一次我拿到一个样本里面直接搜出来一个硬编码的 MySQL 连接串这属于让我比较意外的发现——正常 App 很少会在客户端带数据库连接串。5.4 对逆向样本中游戏型 App如 tmgp.sgame的分析侧重热点词里反复出现com.tencent.tmgp.sgame这是一类很典型的游戏 App。游戏类逆向和普通应用逆向的重心差异很大游戏的重点分析区域包括 Lua/脚本资源目录、so 库里的热更新逻辑、内购支付的校验点、风控系统与登录态校验等。特别是 pandora 这个文件路径频繁出现结合搜索词我判断游戏场景中经常会有一类模块化资源加载框架脚本和数据都是动态拉下来的。Agent 在分析这类路径时要重点盯动态加载入口比如遇到loadLibrary、DexClassLoader、PathClassLoader就得高亮。这类逻辑在实际安全工作流里我做的是红线提示即告知分析者这个位置可能涉及动态代码加载需要人工二次确认Agent 不直接下结论。这种Agent 预判 人工复审的分工是做安全向工作流时比较稳妥的取舍。6. 常见问题与踩坑记录我替你把弯路走完6.1 反编译后代码不全是工具问题还是样本问题这个问题频率极高。先说结论大部分情况下不是工具坏了而是样本做了混淆或去符号化处理。jadx 在遇到指令无法映射为 Java 语法时往往直接跳过方法体导致代码缺失。我有一次碰到一个样本某个 Activity 的所有方法都为空以为是 jadx 的 bug后来把 apktool 拉出来看 smali发现这个类被整体保护了——里面有大量的 native 方法调用实际的逻辑全在 so 库里。所以如果你也遇到代码不全马上切 smali 层面看再盯一下对应的 so。Agent 处理这个问题的逻辑可以这样写当反编译结果里某个类 or 方法体为空时执行 Agent 自动补充跑一遍 jadx --show-bad-code 或者直接拉 smali 片段让分析 Agent 从这些片段里重新推理。6.2 大型 APK 解包超时与内存溢出一个复杂的 APK 解包瞬时内存占用很夸张。我碰过最大的样本jadx 内存占用跑到了 6GB 以上。如果 Agent 的执行环境内存限制了 4GB那么任务就会因为 OOM 直接中断。这里给几个可操作的优化方案使用 jadx 的--decompilation-mode simple降低 CPU 占用设置合理的 JVM 堆大小-Xmx2g或-Xmx4g对超大 APK 优先做分模块反编译比如只反编译某个包路径下的类命令统一加超时控制别让 Agent 吊死在一个任务上我在工作流里专门加了一组任务级别超时的配置默认单命令 120 秒超时整个解包任务 300 秒超时。一旦超时就返回错误给 Agent由它在预算范围内决定重试还是换方案。这个机制的引入让工作流的稳定性提高了一个量级。6.3 Android 文件系统访问限制导致的分析盲区如今 Android 11 对Android/data目录的限制越来越死这意味着用户设备本身很难直接读取某些应用的私有数据目录。但逆向分析的对象是 APK 文件本身那是不是就不受影响了其实影响很大。因为很多逆向工作需要动态调试在设备或模拟器上安装目标 App、运行时查看文件写入、抓取网络包。如果设备系统版本太高沙盒外的路径不让碰动态分析难度直接翻倍。所以我的建议是工作流的静态分析可以兼容任何系统但动态调试部分严格限定在 Android 10 及以下或专门调试的模拟器镜像里跑。这也是很多分析团队还在保留 Android 9/10 老设备的原因。6.4 带壳/加固样本的处理思路市面上主流加固厂商的壳腾讯乐固、360、爱加密、梆梆等会把 dex 整体加密直接跑 ApkTool 解出来的代码全是壳的入口看不到业务逻辑。Agent 在面对这种情况时要有明确的特征识别—策略切换逻辑。我的处理路径是先解包看是否存在加壳特征——比如libjiagu.so、libDexHelper.so、libshell*.so等文件名然后查Application类是不是壳的加载类。确认加壳之后静态层面基本到此为止直接进入脱壳配置dump 运行时内存中的 dex 再分析。这一步我没法给一个全自动的银弹方案因为壳的版本和样本场景差异太大。完全自动化的脱壳仍然是一个深度研究的课题。人工介入 Agent 辅助是这个阶段的最优解。6.5 工作流编码Agent 的记忆与上下文管理最后一个常被忽略的问题是上下文。AI Agent 分析一个大工程时如果每一步结果都塞进同一个上下文窗口那很快就会被撑爆。我的做法是把每一阶段的产出物持久化分析 Agent 只在需要时读取指定路径work_space/ meta.json # APK 基本信息 manifest.json # Manifest 解析结果 signature.json # 签名信息 reverse_source/ # 反编译产物 analysis_notes.md # 分析推理过程这个结构也让 Agent 在断点恢复时更方便。当它跑挂了只要拿到工作目录路径就可以接着上一次的分析继续干不用从头开始。这算是 Agent 化工作流和纯脚本化工具链一个很大的体验差异。7. 让工作流接入 AI Agent 架构与后续扩展7.1 一个最小可运行的接入示例为了让你更直观地理解工作流如何被 Agent 驱动我给出一个简化但可运行的接入逻辑用 Python 写一个 Agent 调度器调用工作流的 CLI 命令并处理返回结果import json import subprocess def run_reverse_workflow(apk_path, model_api, workspace): # 第一步初始化执行环境 env_ready subprocess.run( [apk-reverse, env-check], capture_outputTrue, textTrue ) if env_ready.returncode ! 0: return {status: failed, step: env-check, error: env_ready.stderr} # 第二步执行完整工作流 workflow_result subprocess.run( [apk-reverse, run, apk_path, --workspace, workspace], capture_outputTrue, textTrue, timeout600, ) if workflow_result.returncode ! 0: return {status: failed, step: workflow, error: workflow_result.stderr} # 第三步读取元数据与报告交给模型做推理 meta json.load(open(f{workspace}/meta.json)) manifest json.load(open(f{workspace}/manifest.json)) report open(f{workspace}/report.md).read() prompt f 这是一次 Android 逆向分析的结果。 包名: {meta[package]} 版本: {meta[version]} 组件信息: {json.dumps(manifest, ensure_asciiFalse)[:2000]} 分析报告: {report[:4000]} 请给出行为总结与风险等级评估。 reasoning model_api(prompt) return {status: success, reasoning: reasoning, artifacts: workspace}这个例子的核心思想是工作流产出结构化中间文件Agent 只负责根据这些中间文件做推理与判断。这比让 Agent 一个命令一个命令地原生执行可靠得多因为中间文件的格式是稳定的、可验证的不会因为命令行输出格式的改变而让 Agent 误解。7.2 接入 Dify / Coze 这类工作流平台的思路有不少读者问我自己不想写代码层能不能直接把 apk-reverse 拼接到 Dify 或 Coze 这种可视化的 Agent 工作流平台上答案是完全可以。思路是把你本地的 apk-reverse 封装成一个 HTTP 服务提供一个预执行 反馈任务的接口。Dify 的自定义工具节点或 Coze 的插件系统都能直接调用它。大致流程是Dify/Coze 收到用户的自然语言指令例如分析这个 APK 的隐私风险工作流调用 apk-reverse HTTP API上传文件并启动分析任务服务端执行工作流返回 JSON 格式的结果大模型解读结果生成面向用户的分析报告这样做的好处是复用平台上已有的 LLM 编排能力和人工审核组件同时不用在平台里硬编码复杂的命令行逻辑。7.3 后续扩展方向n8n 等其他编排器的兼容n8n 这类自动化编排工具也可以作为调用方来使用。它的优势在于强大的定时触发和消息通知能力比如让你每周自动对一批 APK 做例行安全扫描产出报告后直接推送到企业微信或者邮件列表。这块只要把 apk-reverse 的 CLI 或 HTTP 接口暴露出来接入成本很低。我目前已经拿 n8n 跑通了一个简单的场景监听一个 Dropbox 目录有新 APK 上传就自动触发逆向分析与报告生成结果回传到 Notion 数据库。整个过程的稳定性让我比较满意之后可以考虑加上增量分析——只分析和上一次签名的差异部分大幅节省算力。7.4 关于 Token 消耗怎么让 Agent 更省AI Agent 跑逆向分析最烧钱的是 Token。尤其是把几百 KB 的反编译代码一次性塞进上下文Token 费用会让你怀疑人生。我的优化经验有三条全程只让 Agent 读取分层摘要先读 Manifest 结构摘要再按需读单个类的代码摘要不要全量加载对代码块做摘要化处理用本地脚本先把方法体压成行为描述再丢给大模型设置分析深度等级浅层分析只用规则匹配 正则提取只有深层分析才启用大模型推理这样一套下来一次完整逆向分析的 Token 花费能被压缩到原来的五分之一左右。8. 复盘与建议哪些地方值得你多花时间最后分享一点我在整体设计里的心得不做总结只说判断。第一点这套工作流的价值上限在于你对目标 App 的理解深度而不在于工具多花哨。如果连 Android 四大组件、dex 加载流程、APK 打包结构都搞不清楚写出来的 Agent 指令大概率也是错的。先夯实基础再追求自动化。第二点Rust 底座一定能提升执行效率但初期原型阶段我建议先用 Python 把工作流跑通。函数式原型跑通了再往 Rust 迁移会省掉大量重构痛苦。我一开始就用 Rust 写踩了不少还没想明白流程就把实现写死了的坑。第三点安全边界一定要控制好。Agent 一旦真正拥有执行命令的权限它就是一个有手和脚的工具。我建议至少做三层限制一是只允许操作指定的工作目录与命令白名单二是所有命令默认加沙箱限制禁止网络外联三是高风险行为比如脱壳、Hook 注入必须人工确认后才能放行。这不是技术洁癖而是你只要让 Agent 跑过一次高危样本就会明白那扇门一旦打开意味着什么。目前 apk-reverse 这个项目还在持续迭代我的重心已经转向动态分析的 Agent 化也就是让 Agent 自主完成安装-运行-抓包-内存提取的闭环。等那部分稳定了再整理出来分享。如果你也在做 Android 逆向或者 Agent 应用落地欢迎在评论区聊聊你遇到的那些明明很简单就是自动化不了的环节说不定下一个版本就是为你的场景做的。
1. 为什么我会把 Android 逆向工程交给 AI Agent先讲一个让我下定决心做这个项目的场景。上个月我需要分析一个第三方 App 的资源文件结构和签名信息整个流程说起来不复杂解包、看 AndroidManifest、拉签名、确认目标 SDK 版本和权限声明再定位几个关键字符串。但真正动手的时候我发现自己在一遍又一遍地重复敲同样的命令而且每换一个目标 App都得重新走一遍这串流程。当时我脑子里冒出来的想法是这套流程明明已经高度固定了为什么不把它写成一个 AI Agent 可以理解、可以执行的工作流让 Agent 自己跑命令、读产物、做判断我只负责给方向和审核结果。事实上apk-reverse这个方向并不是什么新东西把单个 ApkTool 命令或者 jadx 反编译脚本写出来的人很多。但把整条逆向链路——从解包、配置解析、代码反编译、资源提取、签名校验到最终报告生成——作为一条可编排、可复现、可被 Agent 驱动的工作流来做目前还很少有人系统性地整理。这篇内容就是想把这套工作流完整拆开讲清楚每一步为什么这么做、底层逻辑是什么、实际跑起来会遇到哪些坑以及如何把它接入你自己的 AI Agent 架构里。适合谁来读如果你正在做 Android 逆向分析、移动安全测试、竞品 App 研究或者你手里已经有一个 AI Agent 项目正发愁怎么让它去执行真实世界里的复杂任务这篇文章都能给你一套可以落地的参考实现。先给个结论把逆向工程工作流交给 AI Agent核心价值不在于让 Agent 替你做安全研究而在于让那些套路固定、重复度高、出错成本低的环节自动化把人的精力释放到真正需要判断力的地方。2. apk-reverse 工作流整体架构与核心模块拆解2.1 不是让你写死脚本而是让 Agent 可理解、可决策很多第一次接触AI Agent 逆向工程的人会有一个误解Agent 工作流不就是把原来写好的脚本用自然语言包装一下吗其实差别很大。传统脚本是确定性的——输入一个 APK跑 ApkTool输出反编译结果完事。Agent 工作流则要求每一步都有感知-决策-执行-反馈的闭环。比如解包之后Agent 需要主动读取 AndroidManifest.xml识别主 Activity、申请的敏感权限、目标 SDK 版本然后根据这些信息决定下一步是去做代码审计还是做资源分析。这就意味着整个工作流的每一步都要有明确的输入、输出和判断条件而不是简单地把命令串起来。我整理了一下一个完整的 apk-reverse Agent 工作流至少需要这几个模块模块职责关键产出物Agent 决策点环境探测确认工具链可用性、APK 基本信息文件类型、大小、MD5判断是否需要换工具解包模块提取 APK 资源与 smali 代码目录结构、Manifest识别组件与权限配置分析解析 AndroidManifest 与签名信息组件清单、权限列表确定分析优先级代码反编译将 smali 转为可读 Java 代码Java 源码定位核心逻辑资源提取拉取资源文件、资源表图片、布局、字符串发现隐藏资源报告生成汇总各阶段产物分析报告判断分析闭环程度2.2 用 Rust 还是用 Python 做底座我的取舍我的实现里底座语言选择了 Rust。这里有个背景AI Agent 的指令执行往往需要低延迟、高可靠、内存安全的运行环境Python 虽然生态丰富、写起来快但一旦涉及大型 APK 的文件解析和二进制处理性能瓶颈很明显。Rust 在内存管理和并发上有天然优势也能直接编译成单二进制文件丢到任何 Linux 环境里跑对 Agent 的部署非常友好。当然这不代表完全抛弃 Python。实际架构里笨重的语义分析、报告格式化这类任务仍可以外抛给 Python 脚本Rust 只负责核心链路的编排和文件处理。这种Rust 主流程 Python 辅助分析的组合是我实测下来性能和开发效率比较平衡的方案。有人会问为什么不能直接用现成的 Frida、ApkTool 那些工具非要自己做一套工作流我的回答是工具是原子操作工作流是编排。ApkTool 只负责把 APK 解开但解开之后做什么、怎么做、结果怎么解读这些是需要你自己定义的。AI Agent 的价值恰恰在编排层。2.3 两个核心 Agent 角色的划分我的工作流里拆了两个角色分析 Agent和执行 Agent。分析 Agent 负责理解任务目标、拆解分析计划、读取中间产物并做推理判断执行 Agent 负责调用具体的命令工具比如 apkanalyzer、aapt2、jadx、ApkTool 等。为什么拆成两个因为它们在职责边界、运行环境、失败处理上的需求完全不同。分析 Agent 需要大模型上下文窗口、需要能看到多次执行的输出因此采用大模型 API 或本地模型推理执行 Agent 则是轻量级进程管理器负责命令的启停、超时控制、退出码检查。这样就算执行 Agent 跑挂了任务失败分析 Agent 也能根据错误信息重新生成指令再次下发执行形成真正的反馈闭环。实际开发中我会让执行 Agent 返回一个统一格式的执行结果结构退出码、标准输出、错误输出、执行耗时。分析 Agent 拿到这个结构后判断是继续还是纠错。这一步是整个工作流能不能活起来的关键。3. 从零实现工作流APK 信息采集与解包实操3.1 基础环境配置在写任何逻辑之前先把环境拾掇干净。这个环节容易翻车——很多人以为装个 ApkTool 就能干活真正解包的时候才发现要用的工具链比想象中多。我目前在 Ubuntu 22.04 上跑这套工作流核心工具清单如下JDK 11 或以上ApkTool、jadx 都是 Java 生态Android SDK 构建工具提供 aapt2、apkanalyzerApkTool资源与 smali 解码jadxsmali 转 Java 的可读源码jadx-gui人肉审计时用来浏览Agent 模式下可不装keytool 与 apksigner签名校验file、md5sum 等基础系统工具安装那几步本身不难但有一个细节必须提醒环境变量要统一。比如 aapt2 在不同版本里的默认行为有差异我碰到过明明装了 build-tools 30但临时输入文件路径带空格导致 aapt2 直接挂掉的情况。所以路径统一走环境变量注入别写死在脚本里。3.2 第一步确认这个 APK 到底是什么这是最容易被跳过的步骤但恰恰是最重要的。拿到一个 APK 文件先不要急急忙忙解包先确认三件事文件本身是不是合法的 zip 结构。APK 本质是 zip 压缩包用 file 命令和 magic bytes 校验一下能在早期拦截掉很多伪装成 APK 的勒索病毒或直接改名的不良文件。我见过有人拿到的样本根本不是 Android 安装包结果后面每一步都在做无用功。第二步是计算哈希值并记录。这一步看起来对分析没什么用但对工作流的可复现性和核查很重要。你在逆向过程中得到的每一份报告对应的样本必须是唯一确定的哈希就是那个指纹。第三步是用 aapt2 dump badging 快速拿包名、版本号、原生平台等基础信息。这一步的输出是整个工作流的第一层结构化数据分析 Agent 后面做任何判断都依赖它。3.3 解包ApkTool 和 apkanalyzer 到底该选谁解包这一步我一般同时跑两套命令产出物用途不同ApkTool 做完整资源解码主要是拿到可读的 AndroidManifest.xml、资源和 smali 代码。命令很简单apktool d -f -o output_dir target.apk其中-f是强制覆盖-o指定输出目录。实测里一个 50MB 左右的 APKApkTool 跑完大概在 10~40 秒之间取决于机器的磁盘和 CPU。apkanalyzer 则是 Android 官方工具适合拿结构化元数据。比如apkanalyzer manifest target.apk apkanalyzer files list target.apk它输出的格式更加规整方便 Agent 做后续解析。相比之下 ApkTool 输出的 AndroidManifest.xml 虽然可读性好但遇到一些混淆过的资源命名或者特殊编码时解析起来会麻烦些。所以我的习惯是用 ApkTool 做资源级解码用 apkanalyzer 做结构级信息采集两者互补。很多教程只讲 ApkTool 一条路等你想自动化的时候就会哭。3.4 动态授权目录的处理从路径读出的攻防线索近两年 Android 应用里大量出现一类路径/storage/emulated/0/Android/data/包名/files/...比如com.tencent.tmgp.sgame王者荣耀下的 pandora 目录。这类路径消息其实隐含了大量信息。/storage/emulated/0是可共享外部存储的根路径Android/data是应用私有外部目录files是应用自己的文件子目录。一个应用把资源或缓存放到这个位置一是为了绕过内部存储大小的限制二是为了跨 App 共享某些数据。所以当你逆向时在代码、资源、日志里频繁看到这类路径基本可以判断这个 App 存在文件级数据交换逻辑。再注意一个点/storage/emulated/0/Android/data/其实屏蔽了内部路径细节而且新版 Android 对这块目录的访问限制越来越严。Agent 在分析这类路径的时候不只是识别字符串还要判断这个 App 是否有能力访问沙盒外的敏感目录这就需要结合 Manifest 中的权限声明。我在工作流中为这类路径专门配置了正则识别和大数据归类模块用于判断该 App 是否存在敏感数据搬运行为。这里有个可复现经验任何一个从外部读文件写文件的 App都值得你重点观察它的文件读写对儿。4. AndroidManifest 与签名信息的深度解析4.1 Manifest 不是一张清单而是一张地图很多人觉得 Manifest 解析就是把所有 Activity、Service、Receiver 列出来。这没错但只做到了 20% 的价值。AndroidManifest.xml 在逆向分析里更像一张地图你需要在上面找到入口、找到暗道、找到权限边界。分析 Agent 在读完 Manifest 之后至少要输出以下几类决策数据Main ActivityApp 的启动入口往往是核心业务代码的挂载点exported 组件能被外部应用调起的组件这是攻击面最大的地方Application 类自定义 Application 常常承载全局初始化逻辑权限申请列表与业务无关的高危权限是典型的风险信号URL scheme / service 声明深链入口也是注入点比如看到一个 App 申请了android.permission.QUERY_ALL_PACKAGES查询所有已安装应用却没申请任何存储权限紧接着在代码里发现它遍历了所有应用信息并写入了某个/files/下的数据库那这个 App 的行为就很值得放在显微镜下看。所以我让分析 Agent 在拿到 Manifest 后先做一个组件重要性排序再决定从哪个组件开始深挖。这一步能让整个分析过程聚焦不会在读无关代码上浪费时间。4.2 签名信息验证来源与判断篡改签名校验是很多人会忽略的环节尤其是自动化分析时。我总结过一句话每次解包之前都应该知道这份 APK 是谁签的名、用的是 v1 还是 v2 签名方案因为签名方案直接决定了某些注入手法是否可行。用 apksigner 校验apksigner verify --print-certs test.apk输出中能看到签名证书的 SHA-256 指纹。Agent 拿到指纹后可以对比在线数据库判断这个签名的归属。如果一份 APK 的签名信息和官方版本不一致那要么是第三方篡改包要么是恶意重打包。分析价值完全不同。这里有一个很常见的坑待分析的样本可能同时包含 v1 和 v2 签名。v1 签名在 Android 7.0 以下生效v2 在 Android 7.0 以上生效。如果你在验证的时候不看签名方案版本直接用 v2 校验逻辑去处理会得到一个看似校验失败的结果实际只是因为样本没有 v2 签名而已。这个细节在你做 Agent 自动化时很重要因为你不可能每次都人工去判断签名方案。4.3 资源文件里藏着大量线索不要直奔代码很多新手做逆向分析总喜欢第一时间奔着反编译出来的 Java 代码去读。我实测下来发现真正花时间读代码之前应该先花半小时把 res 资源目录扫一遍。资源里静态字符串经常比代码本身更能暴露业务逻辑。举个例子我在某个样本里发现一张文件名为cron_secret_key.png的图片资源你以为它是图片实际里面藏了一段 base64 编码的密钥。把这些密钥组合起来配合外部 URL 的域名特征基本可以拼出整个 App 的通信架构。这部分的实现方式我让分析 Agent 关注几个关键点资源命名规律是否混淆、硬编码的 URL 与 key、so 库的命名与来源。lib/下的 so 文件命名特别有讲究比如直接叫libprotect.so的那基本是把壳或保护逻辑写进去了值得优先看。4.4 从 Android Studio 角度反视项目结构既然在做 APK 逆向很多人会顺手把反编译产物导入 Android Studio 里看。这招确实好用但有个大坑Android Studio 是基于 Gradle 工程结构的本身不是为 smali 或反编译产物设计的。如果你把 jadx 输出的 Java 代码直接丢进 Android Studio工程结构大概率要报错。我的做法是用 jadx-gui 做浏览参考真正可编译、可查询的工程还是靠 apktool 解出来的 smali 资源去搭。当然 Agent 模式下不需要 IDE它只需要能可编程地读取、检索、全文搜索这些代码数据。但反过来看理解 Android Studio 的项目结构反而能帮你更好地设计反编译产物的目录组织哪些目录放哪类文件、哪些文件是资源的、哪些是代码的都应该在设计工作流时预先规划好。Agent 不会像人一样乱点它只能跟着你定义好的结构走所以结构设计的合理性直接决定分析效率。5. 代码反编译与关键逻辑定位让 Agent 学会找鱼5.1 反编译链路的选择与衔接反编译是整个逆向流程中算力最密集的步骤。我主要用 jadx 来负责代码转换但它不是银弹。之前遇到过一个混淆得很凶的样本jadx 的反编译结果缺失了大量方法体很多逻辑都是空的。后来我把 smali 反编译链路加进去用 ApkTool 产出 smali再用脚本把对应类的 smali 字段、指令流结构化配合 Agent 去分析。smali 虽然读起来痛苦但它是保真的——不像 jadx 会因为混淆而漏掉代码。有些情况下smali 的分析结果是唯一可靠的信息来源。所以我目前的链路是jadx 反编译 Java 源码给 Agent 一个大体框架smali 结构化指令流用于 jadx 失效时的深挖交叉引用分析根据字符串、类名、包名反查逻辑位置三条链路互相印证Agent 就不会被单一失真结果带偏。5.2 关键字命中不只是搜字符串让 Agent 在几万行代码里定位关键逻辑最常用的手段就是关键字检索。我预置了一批模式每次解包后都会全量扫描网络相关http://、https://、socket、websocket、grpc数据存储sqlite、SharedPreferences、FileOutputStream、encrypted安全相关root、su、Magic、Hook、frida、xposed组件调度Intent、startActivity、content://、file://、Bindercontent://这个值得多说一句。比如搜索热点词里出现的content://com.baidu.searchbox.fileprovider/baiddpath/...这种 FileProvider 的 content URI 意味着该 App 对外开放了文件访问能力。攻击者如果能控制传入的 URI 的路径部分就可能造成任意文件读取。工作流里必须对content://资源做高优匹配并转成分析报告。我实际跑的时候将关键字命中结果按风险等级分组匹配到高危关键字后Agent 会直接定位到对应代码块再读取上下文。整个过程完全脚本化不需要人工点开代码一行行看。这一步是 Agent 工作流里省人效果最明显的。5.3 硬编码信息的提取与自动化隐藏在各种字符串表、资源文件、代码常量里的硬编码信息往往是高效分析的富矿。比如API endpoints加密密钥Token / Secret证书指纹第三方 SDK 的 appId我在工作流里集成了一个基于正则与启发式规则的提取器专门负责挑这些字段。它有几个规则是固定保留的[a-zA-Z0-9/]{40,} - 疑似 base64 密钥 eyJ[a-zA-Z0-9_-]\.eyJ[a-zA-Z0-9_-] - JWT AIza[0-9A-Za-z_-]{35} - Google API Key sk-[0-9a-zA-Z]{20,} - OpenAI 风格密钥这套提取器跑完以后会生成一个结构化 JSONAgent 读 JSON 来决定这些信息的用途。有一次我拿到一个样本里面直接搜出来一个硬编码的 MySQL 连接串这属于让我比较意外的发现——正常 App 很少会在客户端带数据库连接串。5.4 对逆向样本中游戏型 App如 tmgp.sgame的分析侧重热点词里反复出现com.tencent.tmgp.sgame这是一类很典型的游戏 App。游戏类逆向和普通应用逆向的重心差异很大游戏的重点分析区域包括 Lua/脚本资源目录、so 库里的热更新逻辑、内购支付的校验点、风控系统与登录态校验等。特别是 pandora 这个文件路径频繁出现结合搜索词我判断游戏场景中经常会有一类模块化资源加载框架脚本和数据都是动态拉下来的。Agent 在分析这类路径时要重点盯动态加载入口比如遇到loadLibrary、DexClassLoader、PathClassLoader就得高亮。这类逻辑在实际安全工作流里我做的是红线提示即告知分析者这个位置可能涉及动态代码加载需要人工二次确认Agent 不直接下结论。这种Agent 预判 人工复审的分工是做安全向工作流时比较稳妥的取舍。6. 常见问题与踩坑记录我替你把弯路走完6.1 反编译后代码不全是工具问题还是样本问题这个问题频率极高。先说结论大部分情况下不是工具坏了而是样本做了混淆或去符号化处理。jadx 在遇到指令无法映射为 Java 语法时往往直接跳过方法体导致代码缺失。我有一次碰到一个样本某个 Activity 的所有方法都为空以为是 jadx 的 bug后来把 apktool 拉出来看 smali发现这个类被整体保护了——里面有大量的 native 方法调用实际的逻辑全在 so 库里。所以如果你也遇到代码不全马上切 smali 层面看再盯一下对应的 so。Agent 处理这个问题的逻辑可以这样写当反编译结果里某个类 or 方法体为空时执行 Agent 自动补充跑一遍 jadx --show-bad-code 或者直接拉 smali 片段让分析 Agent 从这些片段里重新推理。6.2 大型 APK 解包超时与内存溢出一个复杂的 APK 解包瞬时内存占用很夸张。我碰过最大的样本jadx 内存占用跑到了 6GB 以上。如果 Agent 的执行环境内存限制了 4GB那么任务就会因为 OOM 直接中断。这里给几个可操作的优化方案使用 jadx 的--decompilation-mode simple降低 CPU 占用设置合理的 JVM 堆大小-Xmx2g或-Xmx4g对超大 APK 优先做分模块反编译比如只反编译某个包路径下的类命令统一加超时控制别让 Agent 吊死在一个任务上我在工作流里专门加了一组任务级别超时的配置默认单命令 120 秒超时整个解包任务 300 秒超时。一旦超时就返回错误给 Agent由它在预算范围内决定重试还是换方案。这个机制的引入让工作流的稳定性提高了一个量级。6.3 Android 文件系统访问限制导致的分析盲区如今 Android 11 对Android/data目录的限制越来越死这意味着用户设备本身很难直接读取某些应用的私有数据目录。但逆向分析的对象是 APK 文件本身那是不是就不受影响了其实影响很大。因为很多逆向工作需要动态调试在设备或模拟器上安装目标 App、运行时查看文件写入、抓取网络包。如果设备系统版本太高沙盒外的路径不让碰动态分析难度直接翻倍。所以我的建议是工作流的静态分析可以兼容任何系统但动态调试部分严格限定在 Android 10 及以下或专门调试的模拟器镜像里跑。这也是很多分析团队还在保留 Android 9/10 老设备的原因。6.4 带壳/加固样本的处理思路市面上主流加固厂商的壳腾讯乐固、360、爱加密、梆梆等会把 dex 整体加密直接跑 ApkTool 解出来的代码全是壳的入口看不到业务逻辑。Agent 在面对这种情况时要有明确的特征识别—策略切换逻辑。我的处理路径是先解包看是否存在加壳特征——比如libjiagu.so、libDexHelper.so、libshell*.so等文件名然后查Application类是不是壳的加载类。确认加壳之后静态层面基本到此为止直接进入脱壳配置dump 运行时内存中的 dex 再分析。这一步我没法给一个全自动的银弹方案因为壳的版本和样本场景差异太大。完全自动化的脱壳仍然是一个深度研究的课题。人工介入 Agent 辅助是这个阶段的最优解。6.5 工作流编码Agent 的记忆与上下文管理最后一个常被忽略的问题是上下文。AI Agent 分析一个大工程时如果每一步结果都塞进同一个上下文窗口那很快就会被撑爆。我的做法是把每一阶段的产出物持久化分析 Agent 只在需要时读取指定路径work_space/ meta.json # APK 基本信息 manifest.json # Manifest 解析结果 signature.json # 签名信息 reverse_source/ # 反编译产物 analysis_notes.md # 分析推理过程这个结构也让 Agent 在断点恢复时更方便。当它跑挂了只要拿到工作目录路径就可以接着上一次的分析继续干不用从头开始。这算是 Agent 化工作流和纯脚本化工具链一个很大的体验差异。7. 让工作流接入 AI Agent 架构与后续扩展7.1 一个最小可运行的接入示例为了让你更直观地理解工作流如何被 Agent 驱动我给出一个简化但可运行的接入逻辑用 Python 写一个 Agent 调度器调用工作流的 CLI 命令并处理返回结果import json import subprocess def run_reverse_workflow(apk_path, model_api, workspace): # 第一步初始化执行环境 env_ready subprocess.run( [apk-reverse, env-check], capture_outputTrue, textTrue ) if env_ready.returncode ! 0: return {status: failed, step: env-check, error: env_ready.stderr} # 第二步执行完整工作流 workflow_result subprocess.run( [apk-reverse, run, apk_path, --workspace, workspace], capture_outputTrue, textTrue, timeout600, ) if workflow_result.returncode ! 0: return {status: failed, step: workflow, error: workflow_result.stderr} # 第三步读取元数据与报告交给模型做推理 meta json.load(open(f{workspace}/meta.json)) manifest json.load(open(f{workspace}/manifest.json)) report open(f{workspace}/report.md).read() prompt f 这是一次 Android 逆向分析的结果。 包名: {meta[package]} 版本: {meta[version]} 组件信息: {json.dumps(manifest, ensure_asciiFalse)[:2000]} 分析报告: {report[:4000]} 请给出行为总结与风险等级评估。 reasoning model_api(prompt) return {status: success, reasoning: reasoning, artifacts: workspace}这个例子的核心思想是工作流产出结构化中间文件Agent 只负责根据这些中间文件做推理与判断。这比让 Agent 一个命令一个命令地原生执行可靠得多因为中间文件的格式是稳定的、可验证的不会因为命令行输出格式的改变而让 Agent 误解。7.2 接入 Dify / Coze 这类工作流平台的思路有不少读者问我自己不想写代码层能不能直接把 apk-reverse 拼接到 Dify 或 Coze 这种可视化的 Agent 工作流平台上答案是完全可以。思路是把你本地的 apk-reverse 封装成一个 HTTP 服务提供一个预执行 反馈任务的接口。Dify 的自定义工具节点或 Coze 的插件系统都能直接调用它。大致流程是Dify/Coze 收到用户的自然语言指令例如分析这个 APK 的隐私风险工作流调用 apk-reverse HTTP API上传文件并启动分析任务服务端执行工作流返回 JSON 格式的结果大模型解读结果生成面向用户的分析报告这样做的好处是复用平台上已有的 LLM 编排能力和人工审核组件同时不用在平台里硬编码复杂的命令行逻辑。7.3 后续扩展方向n8n 等其他编排器的兼容n8n 这类自动化编排工具也可以作为调用方来使用。它的优势在于强大的定时触发和消息通知能力比如让你每周自动对一批 APK 做例行安全扫描产出报告后直接推送到企业微信或者邮件列表。这块只要把 apk-reverse 的 CLI 或 HTTP 接口暴露出来接入成本很低。我目前已经拿 n8n 跑通了一个简单的场景监听一个 Dropbox 目录有新 APK 上传就自动触发逆向分析与报告生成结果回传到 Notion 数据库。整个过程的稳定性让我比较满意之后可以考虑加上增量分析——只分析和上一次签名的差异部分大幅节省算力。7.4 关于 Token 消耗怎么让 Agent 更省AI Agent 跑逆向分析最烧钱的是 Token。尤其是把几百 KB 的反编译代码一次性塞进上下文Token 费用会让你怀疑人生。我的优化经验有三条全程只让 Agent 读取分层摘要先读 Manifest 结构摘要再按需读单个类的代码摘要不要全量加载对代码块做摘要化处理用本地脚本先把方法体压成行为描述再丢给大模型设置分析深度等级浅层分析只用规则匹配 正则提取只有深层分析才启用大模型推理这样一套下来一次完整逆向分析的 Token 花费能被压缩到原来的五分之一左右。8. 复盘与建议哪些地方值得你多花时间最后分享一点我在整体设计里的心得不做总结只说判断。第一点这套工作流的价值上限在于你对目标 App 的理解深度而不在于工具多花哨。如果连 Android 四大组件、dex 加载流程、APK 打包结构都搞不清楚写出来的 Agent 指令大概率也是错的。先夯实基础再追求自动化。第二点Rust 底座一定能提升执行效率但初期原型阶段我建议先用 Python 把工作流跑通。函数式原型跑通了再往 Rust 迁移会省掉大量重构痛苦。我一开始就用 Rust 写踩了不少还没想明白流程就把实现写死了的坑。第三点安全边界一定要控制好。Agent 一旦真正拥有执行命令的权限它就是一个有手和脚的工具。我建议至少做三层限制一是只允许操作指定的工作目录与命令白名单二是所有命令默认加沙箱限制禁止网络外联三是高风险行为比如脱壳、Hook 注入必须人工确认后才能放行。这不是技术洁癖而是你只要让 Agent 跑过一次高危样本就会明白那扇门一旦打开意味着什么。目前 apk-reverse 这个项目还在持续迭代我的重心已经转向动态分析的 Agent 化也就是让 Agent 自主完成安装-运行-抓包-内存提取的闭环。等那部分稳定了再整理出来分享。如果你也在做 Android 逆向或者 Agent 应用落地欢迎在评论区聊聊你遇到的那些明明很简单就是自动化不了的环节说不定下一个版本就是为你的场景做的。
