apk-reverse完整工作流从APK侦察到验证交付的8个步骤【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverseapk-reverse 是一个面向 AndroidAPK 逆向工程的开源技能包Agent Skill覆盖侦察、拆包、dex 补丁、重打包签名与真机验证全流程。本文把它沉淀的完整工作流拆成 8 个可执行的步骤带你从 APK 侦察一路走到可验证的交付物——每一步都附上了仓库内的参考文档与配套脚本新手也能照着跑通。工作流全景8个步骤一览步骤做什么核心工具/文档1预检 APK 侦察doctor.py、preflight.py、recon.md2提取字符串与接口端点dex_strings.py3定位行为归属类dex-patching.md4确定补丁所在的层ad-removal.md分层表5外科式 dex 补丁dex_patch_bytes.py6重打包 重签名repack.py、repack-and-sign.md7真机验证verification.md、dex_classdiff.py8记录经验与失败pitfalls.md 仓库内还有一张完整的文件 × 使用时机路由表建议先收藏references/routing.md步骤1预检检查与APK侦察Recon这是整个逆向工作流的起点十分钟侦察省下数小时返工。先运行 scripts/doctor.py报告本机哪些工具链可用、缺什么、安装要多久——这是最便宜的第一个命令涉及真机时再跑 scripts/preflight.py几秒钟排查时钟漂移、残留的adb forward/代理、设备上残留的 frida 进程等伪故障然后按 references/recon.md 完成侦察包名、版本、ABI、dex 数量、是否加壳、内置 SDK 清单 加壳判断口诀看AndroidManifest.xml中application android:name——是应用自己的类就是无壳可直接编辑是第三方壳类StubApp、StubShell等则必须先拆包再谈补丁。若侦察显示无壳但重签名后仍崩溃说明进入了 code-virtualization-and-custom-linkers.md 覆盖的自定义链接器层面不能想当然认为无壳可编辑。步骤2提取字符串与接口端点在动反编译器之前先用 scripts/dex_strings.py 从 dex 字符串表快速画出应用的服务接口面与 SDK 清单——不需要反编译器速度快还能顺手定位远程配置的 DTO它们的字段名会存活在 R8 混淆之后。这一步能帮你提前判断弹窗、Tab、广告位到底是客户端决定还是服务端下发——这直接决定是五分钟的补丁还是一个死胡同。步骤3追踪到归属类大多数应用会把第三方 SDK 包在一个自己的 Helper 类里。按照 references/dex-patching.md 中finding the call site一节的反查方法从接口端点字符串反向追踪找到真正拥有目标行为的类。⚠️ 这里对应核心规则R4补丁前先确认拥有该行为的层Java / dex / native / Dart / 服务端。打错层不会大声报错——它会产出一个能构建、能运行、但做了错误事情的产物。步骤4确定补丁所在的层对照 references/ad-removal.md 中的分层决策表把目标归入四类之一客户端 SDK 调用去掉初始化即可客户端渲染改 UI 消费逻辑客户端数据消费改数据入口不要让 API 返回 404 来隐藏元素服务端契约客户端补丁只是化妆需诚实降级为分析报告步骤5外科式 dex 补丁核心原则改动越小越安全。两种技术按场景二选一等长字节编辑首选用 scripts/dex_find_insn.py 定位指令再用 scripts/dex_patch_bytes.py 在现有指令槽内替换——不挪动任何字节偏移量、try/catch 块、调试指针全都安然无恙dexlib2 方法重写scripts/dexpatch/仅当改动确实需要新增指令时使用整树 smali 往返会损伤 R8 优化过的 dex且文件体积会显著膨胀无论用哪种方式改完必须重算 dex 头部的两个完整性字段——先签名signature、后校验和checksum顺序错了就是启动即崩详见 references/byte-level-patching.md。步骤6重打包、重签名与更新通道中和按 references/repack-and-sign.md 执行用 scripts/repack.py 一键完成。最大禁忌不要整个删掉META-INF/这一个错误能毁掉本来正确的构建遇到[-124]安装错误是resources.arsc未对齐需 STORED 4 字节对齐6b 中和更新路径在宣布完成前按 references/updates-and-forced-upgrade.md 做两层补丁——更新例程入口置空 版本比较强制走无更新分支。能被远端关闭或替换的构建不算交付物6c 账户门禁仅当需求涉及登录/绑定时按 references/account-gates.md 先分类客户端门可补丁vs 账户级资源屏幕为空是因为服务端没有对应账户并如实声明哪些界面会被解锁、哪些依旧空白步骤7真机验证——验证阶梯与6条交付标准能装能跑不等于功能正常。验证分两部分① 结构验证每次 dex 编辑后必做python skills/apk-reverse/scripts/dex_classdiff.py 原始.dex 补丁后.dex期望结果only_in_A0、only_in_B0、接口标志零漂移。注意它检不出 code-item 级损伤所以只是必要条件。② 运行时验证与声明阶梯references/verification.md 定义了 0~7 级的声明阶梯改字节0→ 结构完好1→ 构建签名通过2→ **安装并启动3交付底线**→ 目标行为确实变了4→ 无其他功能回归5→ 机制被独立证据证实6→ 分发的文件就是验证过的那个7发布必达。记住两条铁律对照构建同一条流水线、零补丁跑一遍。对照也失败 → 是你的流水线/环境/设备的问题别去怀疑补丁看屏幕别只看日志日志干净不是证据屏幕显示 X才是用 scripts/snap.py 启动后前 20 秒连续截图并真的去看这些截图步骤8记录经验与脱敏检查任何一次失败若耗时超过 30 分钟把它写进 references/pitfalls.md——这是整个技能包中最值钱的资产长任务同步维护 references/long-task-discipline.md 中的记录已证伪的结论、已排除的路线丢失前期发现是最贵的失败且完全可防发布任何证据文件前先跑 scripts/scan_leaks.py 做脱敏扫描方法见 references/desensitization-and-leak-scans.md卡住时的两条保命规则规则含义⛔ 两次击球规则同一形态的尝试失败两次立刻回到分类阶段而不是试第三个变体——说明模型错了不是参数没调好 症状索引出现无法解释的现象时先查 SKILL.md 里的症状索引表按行加载对应文档再执行下一条命令。每一行都是一个已经付过学费的失败四道门补丁前必须过的检查点门通过标准一句话版G1 交付物形态用一句可测试的话写清最终产物及约束四种形态重打包 APK / LSPosed 模块 / 本地 RPC 服务 / 带边界的分析报告在开工前选定G2 环境真实跑过doctor.py知道哪些能力可用、哪些缺失但可装、哪些真的够不着G3 代码定位能说出拥有目标行为的类的名字或有明确的寻找计划G4 基线与对照已跑过零补丁对照构建并记录了原始故障含死亡时间我理解这个思路了≠ 通过检查点。快速上手git clone https://gitcode.com/gh_mirrors/ap/apk-reverse总入口规则 症状索引 门 工作流SKILL.md能力边界与证据强度标签observed / inferred / unverifiedreferences/evidence-summary.md不覆盖范围Unity/IL2CPP、iOS、服务端权威等直接说不支持而非硬试references/coverage-and-limits.md自动化测试与工具验证记录tests/、docs/tool-verification/最后的提醒交付物在宣布完成前必须同时满足存在且哈希已记录、在目标环境安装启动过、目标行为被直接观察到、受影响功能实测仍正常这四项。任何一项不满足都只算检查点请如实标注剩余缺口——过早的完成会终结一次本可以解决的调查。【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考