ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

recover-kotlin-names.sh完全教程:一条命令生成混淆名到真实名的映射表

2026/9/16 19:51:41 拓冰建站 浏览量
recover-kotlin-names.sh完全教程:一条命令生成混淆名到真实名的映射表 recover-kotlin-names.sh完全教程一条命令生成混淆名到真实名的映射表【免费下载链接】android-reverse-engineering-skillClaude Code skill to support Android apps reverse engineering项目地址: https://gitcode.com/GitHub_Trending/an/android-reverse-engineering-skill本文以开源项目android-reverse-engineering-skill为例详解如何使用recover-kotlin-names.sh这个脚本反编译一个经过 R8 混淆的 Kotlin 应用后一条命令即可挖掘源码中残留的原始类名生成一张「混淆名 → 真实名」的类名映射表让满屏的a.b.c重新变回LoginRepository这样的可读代码。为什么需要恢复类名R8 混淆绕不开的坎现代 Android 应用绝大多数用 Kotlin 编写且上架前会经过 R8 / ProGuard 混淆。用 jadx 反编译后你会看到大量单字母包和单字母类名例如nq.e、a.a.b……读这种代码如同看天书。但有一个好消息R8 能改名 JVM 符号却删不掉 Kotlin 元数据字符串——Kotlin 运行时在反射、协程等场景下必须依赖原始全限定名。于是两个注解会把「开发商原本写下的类名」原样泄漏在反编译源码中注解来源出现位置泄漏的信息DebugMetadata(c ...)几乎每个suspend协程 lambda外部类的原始全限定名Metadata(d2 {...})每个 Kotlin 类文件内部类引用的 JVM 描述符如Lcom/example/Foo;/* renamed from: ... */注释jadx 偶尔输出原始类名recover-kotlin-names.sh的作用就是自动扫描这三类信号一次性生成映射表。 完整原理可参考 kotlin-name-recovery.md环境准备装好依赖再开工脚本本身只依赖Python 3纯正则扫描零额外依赖。但前提是你手上已有一份反编译好的源码目录整条链路需要Java JDK 17 和 jadx用于反编译脚本会自动检测缺失项获取项目代码git clone https://gitcode.com/GitHub_Trending/an/android-reverse-engineering-skill.git运行依赖检查脚本确认工具链完整bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/check-deps.sh缺失依赖的安装方法见 setup-guide.md。一条命令生成映射表完整三步第 1 步反编译 APKbash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/decompile.sh app.apk第 2 步运行名称恢复脚本bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/recover-kotlin-names.sh \ app-decompiled/sources/ output/names/第一个参数是反编译源码目录第二个是输出目录省略时默认写到源码目录旁的mapping/。第 3 步查看三种交付物脚本会生成三种格式的映射输出定义见 recover-kotlin-names.sh#L26-L34文件格式适合场景output/names/mapping.tsvTab 分隔混淆名 / 真实名 / 源文件人眼浏览可直接用表格软件打开output/names/mapping.json{ a.b.c: com.example.X }脚本自动化消费output/names/by_package/按真实包名拆分的索引文件快速了解某个模块的类结构mapping.tsv内容示例obf_fqn real_fqn file nq.e com.example.feature.account.AccountRepositoryImpl nq/e.java nq.f com.example.feature.account.AccountViewModel nq/f.java运行结束时脚本还会打印统计共恢复多少个类名、分别来自哪种信号源debug_meta / d2 / renamed、涉及多少个真实包。恢复率能找回多少真实类名真实项目中脚本通常能恢复30% ~ 50%的类更关键的是你真正想读的那部分类几乎能 100% 找回类类型恢复率*Repository/*Impl约 100%*ViewModel约 100%*UseCase/*Interactor约 100%普通data classDTO约 80%纯 Java 工具类较低无 Kotlin 元数据也就是说核心业务类全部恢复真名剩下的单字母类大多是 lambda 和内部类不影响阅读主线。查询映射表lookup-name.sh 的 4 种用法映射表生成后用配套脚本 lookup-name.sh 查询路径同plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/目录1️⃣ 混淆名查真名— 代码里遇到nq.e时bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/lookup-name.sh output/names/ -o nq.e # nq.e - com.example.feature.account.AccountRepositoryImpl # sibling: nq.d 同一类拆分出的 lambda / 内部类2️⃣ 按真实名模糊搜索bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/lookup-name.sh output/names/ Repository3️⃣ 列出某个真实包下的所有类bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/lookup-name.sh output/names/ -p com.example.feature4️⃣ 带真名标注的源码搜索— 最常用可替代普通 grepbash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/lookup-name.sh output/names/ --grep api/ app-decompiled/sources/ # 每条命中结果末尾自动追加 // 真实类名推荐完整工作流指纹 → 反编译 → 恢复 → 查询结合项目内置的 Phase 0–4 工作流推荐执行顺序如下先做指纹用 fingerprint.sh 几秒钟判断框架类型、HTTP 技术栈和混淆等级若报告显示中/高混淆且应用是 Kotlin务必在追调用链之前恢复类名反编译decompile.sh恢复类名recover-kotlin-names.sh一条命令查询阅读用lookup-name.sh --grep替代普通 grep遇到混淆名随时用-o解析完整工作流定义见 SKILL.md 中的 Phase 3.5 章节。局限与注意事项哪些类恢复不了方法名和字段名不会被恢复— Kotlin 元数据只保留类级别信息方法名仍需 jadx-gui 交互重命名或靠模式推断纯 Java 类没有Metadata会保持混淆状态被深度内联的类可能出现在错误的文件名之下 — 把恢复结果当作强提示而非绝对结论建议反编译时同时开启--deobf参数它处理无元数据信号的字段和方法恢复脚本处理类名两者互补相关资源速查资源路径类名恢复脚本recover-kotlin-names.sh映射查询脚本lookup-name.sh原理详解文档kotlin-name-recovery.md环境安装指南setup-guide.md完整工作流定义SKILL.md【免费下载链接】android-reverse-engineering-skillClaude Code skill to support Android apps reverse engineering项目地址: https://gitcode.com/GitHub_Trending/an/android-reverse-engineering-skill创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考