过去做 Android APK 逆向，通常意味着自己在 JADX、Apktool、ADB、Frida、Ghidra 等一堆工具之间来回切换：
先拆 APK，看 Manifest，再找 Java/Kotlin 代码；代码被混淆后换思路；遇到 native .so 又进入另一个工具链；修改之后重新打包、签名、安装；启动失败再看 Logcat；发现问题其实来自服务器验证，又重新推翻前面的判断。
真正困难的地方，很多时候并不是“不会使用 JADX”，而是：下一步到底应该做什么？什么时候应该换分析层？什么现象说明当前假设已经错了？
在大语言模型（LLM）和 Code Agent 爆发的今天，直接把一个 APK 或反编译后的 Smali/Java 代码丢给 AI，通常效果并不好，AI 缺乏具体的逆向步骤指引、常用命令示例以及针对特定框架（如 Flutter、React Native、Native SO）的标准化工作流（SOP）。
为了解决“让 AI 懂得如何一步步做 Android 逆向”的问题，社区中诞生了专门为 Agent 设计的逆向指引与 Skill 插件。
最近开源的项目 apk-reverse 正是这样的项目之一。
APK-Reverse：https://github.com/newliver666/apk-reverse
apk-reverse 并非又一个新的 APK 反编译工具，而是一套专为 Claude Code、Codex 等 AI Coding Agent 打造的 Android 逆向工程 Skill（Agent 技能库）。
项目明确聚焦于 APK 逆向分析、应用精简、DEX 修改、重打包，以及运行时与服务端行为分析，并严格采用 Agent Skills 的规范来组织内容。
apk-reverse 的核心目标是将一个经验丰富的逆向工程师在面对 APK 时形成的心智模型——从“问题判断 → 工具选择 → 实验探索 → 结果验证 → 失败回退”的整套闭环，沉淀并提炼为 AI Agent 可以严格遵循的标准化工作流（SOP）。
apk-reverse 在 README 里特别强调，SKILL.md 不是普通教程，而是一套“带闸门的执行流程”。因为 Agent 常见的问题并不是“不懂”，而是读完文档后仍然重新从头推理。
为此，apk-reverse 加入了几套很有意思的机制：
- R1–R4 覆盖规则：规则与当前计划冲突时，优先执行规则，直到有证据推翻。
- 症状索引：遇到典型失败先查 reference，不重复踩已经踩过的坑。
- G1–G4 四道 Gate：每一步都有明确动作和通过标准，“我懂了”不算通过。
- Two-strike Rule：同一种失败连续出现两次，就该怀疑假设，而不是继续调参数。
- 完成标准：日志干净不代表任务完成，必须有真实行为证据。
apk-reverse 的能力可以归纳成六类：
- 先分类问题：判断是客户端可修改，还是服务端强制；结果是独立可用，还是只在当前环境成立。
- 选择最安全的 Patch 层：例如 APK 能安装、能启动，但所有请求都失败，可能是请求签名依赖自身证书，而不一定是 DEX 修改出错。
- 区分环境问题和补丁问题：登录、支付等单一路径失败，可能来自证书、系统时间、TLS 或设备环境。
- 处理壳和复杂执行路径：包括脱壳、内存 Dump、Java2C、Native、自定义 Linker 和故意触发的 Crash。
- 交付物不一定必须是 APK：如果重打包始终被完整性检查拒绝，可以将任务判定为 blocked，改用模块、Runtime Hook、本地 RPC 或分析报告。
- 强调长期任务的证据纪律：区分“已验证、可信、推测、未知”，并在发布前检查隐私信息，同时保留工具名、CVE、协议字段等必要技术细节。
所以，apk-reverse 最值得关注的并不是它支持多少逆向工具，而是它把大量原本存在于资深工程师脑中的隐性经验，变成了：规则、Gate、症状索引、回退条件和完成标准。
前一阵在《Android Reverse Engineering Skill，开源Android逆向工程工具》介绍过Android Reverse Engineering Skill，两个项目名字接近、都自称”Android 逆向 Skill”，但目标核设计上并不一样。
android-reverse-engineering-skill 的核心目标是“逆向以理解”，apk-reverse 的核心目标是“逆向以修改”。这个目标差异，也基本决定了两者后续的设计取向。
android-reverse-engineering-skill 通过反编译 APK / XAPK / JAR / AAR，提取 Retrofit、OkHttp、硬编码 URL、鉴权方式等 HTTP API 信息，让你在没有源码的情况下理解并复现接口。它还特别针对 R8 混淆，利用 Kotlin metadata 尽量恢复 *Repository、*ViewModel、*UseCase 这类有语义的类名。Unity / IL2CPP、React Native / Hermes 则不在其主要覆盖范围内。
apk-reverse 更关注 debloat、去广告、DEX Patch、重新打包，以及运行时和服务端行为分析。重点不是“这个 API 长什么样”，而是“改完后的 APK 能不能安装、稳定运行，修改是否会被完整性校验或服务端机制否掉”。
