DebugMetadata深度解析android-reverse-engineering-skill如何挖出协程类名【免费下载链接】android-reverse-engineering-skillClaude Code skill to support Android apps reverse engineering项目地址: https://gitcode.com/GitHub_Trending/an/android-reverse-engineering-skillandroid-reverse-engineering-skill 是一个面向 Claude Code 的 Android 逆向工程技能反编译 APK/XAPK/JAR/AAR、提取 Retrofit/OkHttp/Ktor 等 HTTP 接口、追踪调用链。它最硬核的一招是利用DebugMetadata 注解把 R8 混淆掉的 Kotlin 类名挖回来——尤其是大量使用协程suspend 函数的类几乎能 100% 恢复*Repository、*ViewModel、*UseCase等真实类名。本文带你读懂这套Kotlin 类名恢复技术的原理与用法。一、先懂痛点R8 混淆后类名全是 a.b.c现代 Kotlin/KMP 应用几乎都会经过 R8 混淆再打包。反编译后你会看到类似a/b/c/d.java的类名——JVM 符号被全部改名人工阅读基本无从下手。你可能会问jadx 不是有--deobf吗它确实有用但只能生成合成名如p001a、C0123Foo恢复不出开发者真正写的名字。关键在于一个技术漏洞R8 会重命名 JVM 符号但无法剥离 Kotlin 元数据字符串——因为 Kotlin 运行时反射、协程、data class在运行时仍依赖这些原始全限定类名。于是原始类名就泄露在了注解里。项目文档对此有专门章节kotlin-name-recovery.md。二、核心渠道DebugMetadata 泄露协程类名几乎每个 Kotlinsuspend函数编译后都会生成一个SuspendLambda类并附带DebugMetadata注解DebugMetadata( c com.example.feature.account.AccountRepositoryImpl$fetch$1, f AccountRepositoryImpl.kt, l {42, 51}, m invokeSuspend ) public final class a extends SuspendLambda implements Function2... { ... }注意c 字段它就是原始外层类的完整限定名。带$后缀的部分是内部类/lambda 作用域取第一个$之前的内容即得到声明类com.example.feature.account.AccountRepositoryImpl。这就是标题里挖出协程类名的由来——协程用得越多DebugMetadata出现得越密集能恢复的类名就越多。三、辅助渠道Metadata.d2 与恢复优先级每个 Kotlin 类还有顶层Metadata注解其d2数组按 JVM 类型描述符Lcom/example/Foo;列出文件内部的类引用第一个非标准库描述符通常是该文件的主类。恢复脚本 recover-kotlin-names.sh 按优先级依次尝试三条线索见 recover-kotlin-names.sh 中的正则定义优先级线索来源覆盖场景1DebugMetadata(c ...)几乎所有 suspend 函数生成的类2Metadata(d2 {...})普通 Kotlin 类3jadx 的renamed from注释少量额外补充脚本还会自动跳过kotlin.、androidx.、okhttp3.等第三方框架包——它们的名字本来就是真实的无需恢复跳过的包前缀清单见 recover-kotlin-names.sh。四、两步跑通一键恢复类名映射 ️第一步生成映射表反编译完成后可用 decompile.sh 完成执行bash plugins/android-reverse-engineering/skills/android-reverse-engineering/scripts/recover-kotlin-names.sh \ output/sources/ output/names/产出三份文件mapping.tsv— 制表符分隔的混淆名 → 真实名 → 文件mapping.json— 同样数据的 JSON 版本供查询工具使用by_package/— 按真实包名分组的索引方便整包浏览第二步用 lookup-name.sh 查询配套的 lookup-name.sh 支持 4 种查询方式# 按真实类名模糊搜索如查所有 Repository bash scripts/lookup-name.sh output/names/ LoginRepository # 混淆名 → 真实名-o还会顺带列出同一类的兄弟 lambda bash scripts/lookup-name.sh output/names/ -o a.b.c # 按真实包名列举-p bash scripts/lookup-name.sh output/names/ -p com.example.feature # 搜索源码时自动标注真实类名--grep替代普通 grep bash scripts/lookup-name.sh output/names/ --grep /api/ output/sources/其中--grep模式最实用每条命中结果后都会追加// real.fqn注释你搜 URL、搜 token 时一眼就知道这段代码属于哪个真实类。五、恢复率实测够不够用对真实混淆后的 Kotlin 应用脚本能恢复30%–50% 的类但重点在于——你真正想读的那部分几乎全都能恢复类别恢复率*Repository/*Impl~100%*ViewModel~100%*UseCase/*Interactor~100%普通data classDTO~80%纯 Java 辅助类较低没有 Kotlin 元数据已知边界项目文档如实列出见 kotlin-name-recovery.md⚠️方法名、字段名不恢复——Kotlin 元数据只保留类级全限定名⚠️ 纯 Java 类没有Metadata仍是混淆名⚠️ 被重度内联的类JvmInline value class、顶层函数文件可能挂在错误的文件名下结果当作强提示而非定论好消息是对提取 HTTP 接口这个目标URL 字符串和 Retrofit 注解本来就不会被混淆类名恢复后配合 api-extraction-patterns.md 中的搜索模式基本可以拼出完整的接口清单。六、它在工作流中的位置这套能力对应技能工作流的Phase 3.5见 SKILL.md推荐执行顺序Phase 0— 用 fingerprint.sh 先分诊确认是原生 Kotlin 应用而非 Flutter/RN且混淆程度中/高Phase 2— 反编译混淆应用建议加--deobfPhase 3.5— 运行本节的两个脚本建立类名映射Phase 4— 用 call-flow-analysis.md 的技术从 Activity 追踪到 HTTP 调用Phase 5— 用 find-api-calls.sh 全面扫描并文档化接口项目官方建议在混淆应用中两者并用--deobf处理没有元数据来源的字段/方法恢复脚本负责类名。七、相关文件速查 文件用途SKILL.md完整工作流Phase 0–5kotlin-name-recovery.md本文原理的完整技术文档recover-kotlin-names.sh生成混淆 → 真实类名映射lookup-name.sh查询映射 / 带注释 grepREADME.md项目总览与安装说明setup-guide.mdJava/jadx 等依赖安装指南最后提醒本技能仅用于合法场景——授权渗透测试、恶意软件分析、互操作性研究与教学。请确保你的使用符合当地法律法规。【免费下载链接】android-reverse-engineering-skillClaude Code skill to support Android apps reverse engineering项目地址: https://gitcode.com/GitHub_Trending/an/android-reverse-engineering-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考