简介这是一款面向安卓开发与安全分析人员的反编译集成工具包将安装包解包、DEX 转 JAR、Java 源码查看等常见流程整合在一起适合刚接触逆向的新手快速搭建分析环境也能提升日常应用拆解的效率对希望系统了解 APK 结构的学习者尤其友好。压缩包共 55 个文件约 42.27MB文件类型覆盖 16 个 bat 批处理、13 个 sh 脚本、12 个 jar 工具、6 个 txt 说明、3 个 exe 程序及 docx 文档等bat/sh 负责在不同系统下一键执行jar 承载 dex2jar、apktool、jd-gui 等核心组件txt/docx 提供使用说明与反编译方法参考。目前已有 145 人学习/下载可见这套工具在安卓开发者与小规模逆向学习者中有一定参考价值。资源内附《android反编译方法.docx》教程、run.bat 启动脚本并集成 dex2jar-0.0.9.9、apktool、jd-gui可以完成资源解码、dex 转换和图形化源码查看帮助读者绕过繁琐的环境配置直接体验反编译全流程是入门与日常查证应用逻辑的实用选择。 很多新手第一次接触 Android 反编译时第一反应是“把 APK 后缀改成 zip 解压”结果看到一堆classes.dex和资源文件后直接愣住。其实 Android 反编译工具发展到今天早就不是那种“看个十六进制都费劲”的阶段了。这篇文章我打算把自己这几年经常用的 Android 反编译工具按场景整个捋一遍从“想看 Java 代码”到“想改资源再回编译”每类需求对应什么工具、怎么用、坑在哪一次性说清楚。适合刚入门的朋友也适合有基础但想查漏补缺的开发者。1. 反编译之前先想清楚你要看的是哪一层APK 本质上是个 zip 压缩包里面装的东西远比想象得多classes.dex是 Java/Kotlin 字节码的集合AndroidManifest.xml是二进制 XMLresources.arsc是资源索引表lib/下可能还有一堆 so 文件。不同的分析目标对应不同的工具选错工具只会白白浪费时间。我用一张表总结一下常见分析目标对应的工具后面会逐一展开分析目标首选工具备选工具说明看 Java/Kotlin 层代码逻辑jadxGDA、dex2jar JD-GUIjadx 的搜索结果最舒服适合大范围搜索看资源文件、布局、Manifestapktooljadx、Android Studio APK Analyzerapktool 能还原可编辑的资源方便二次修改看 so 层 Native 逻辑IDA Pro / GhidraGDA、readelf strings这层很硬核一般分析业务逻辑用不到快速体检 APK 结构Android Studio APK Analyzerjadx-gui适合看 dex 数量、so 架构、版本信息分析 smali 字节码细节baksmali / smaliapktool自带 smali 目录涉及 Hook、插桩、混淆对抗时用分析加固后的 APK脱壳工具 恢复后的 dex无直接打开只会看到壳无法看到真实业务代码这个阶段最容易踩的坑是想分析某个 App 的功能逻辑却一上来就拖进 IDA 啃汇编或者打开了加固壳还以为是代码被加密成了乱码。先想清楚“我要看哪一层”再决定用哪个工具是反编译这件事最重要的一步。另外提醒一句如果你是做合规的安全研究、鲁班学院式的逆向学习或者分析自己开发的程序这些工具完全够用。但针对第三方商业 App 的绕过、去广告、破解等行为请注意授权协议和相关法律法规。2. jadx一条命令把 APK 变成可读工程日常主力如果说只允许我保留一个反编译工具我会选 jadx。它的核心价值特别朴素把你从格式、工具链的繁琐中解放出来直接面向“代码阅读”这个目标。2.1 基础用法和 GUI 跳转jadx 有两个形态命令行和图形界面。命令行反编译一个 APK 非常简单jadx -d output_dir your_app.apk这条命令会把 APK 里的 dex 反编译成 Java 源码并输出到output_dir目录。它的特点是不需要你手动解压 APK也不需要单独处理 dex 和资源只要给它一个 APK、dex 或 jar它就能自动处理。日常分析我更推荐用jadx-gui因为 GUI 模式集成了搜索和跳转功能体验很像在 Android Studio 里看代码。打开 APK 之后你可以直接按快捷键Ctrl Shift F全局搜索字符串比如你想定位一个 App 的网络请求地址搜一段 URL 或者域名很快就能跳到相关代码位置。再配合Ctrl B跳转到类、方法定义分析呼叫链路会顺畅很多。我自己的习惯是先全局搜索一些暴露的字符串比如apiKey、baseURL、bugly、umeng这类 SDK 标识快速了解这个 App 用了哪些第三方库、主站接口长什么样。这一步几乎每次都能让分析目标直接清晰一大半。2.2 用参数控制反编译范围jadx 的命令行参数里有几个值得记--no-res不反编译资源文件。如果你只看代码逻辑加这个参数能省不少时间和内存因为资源反编译在大型 APK 上很慢。--single-class只反编译指定的类。这个在已有明确目标类时非常快比如配合搜索命中后想快速确认逻辑。--deobf开启混淆恢复。对 R8/ProGuard 混淆过的名字jadx 会尝试根据调用关系恢复一些名字效果有限但偶尔能救命。-j 4指定线程数。老机器上默认全线程跑会把 CPU 吃满限制一下反而更快。我在分析一些体积特别大的 App 时通常先执行--no-res看代码再单独用 apktool 看资源这样两个工具各干各的互不拖累。2.3 反编译结果里的代码怎么读更高效jadx 输出的 Java 代码在语法上是可读的但它是由字节码推导出来的不是原始源码所以会出现一些和原始代码明显不同的特征局部变量名变成了a、b、cswitch-case 变成了大量的if-else原来用 Kotlin 写的高阶函数展开成了一堆Function0匿名内部类。遇到这种情况不要急着逐行读。我推荐一个比较高效的三步走从入口点出发先找到Application子类的onCreate或者你要分析的 Activity、Receiver、Service 的入口方法顺着调用关系往下追。用字符串和调用的 API 做锚点很多逻辑最终会调用HttpClient、SharedPreferences、ContentResolver等 API以这些调用点为锚反推它周围的数据流。配合 Android 官方文档对照比如看到一个类继承自android.app.Service但代码里全是onStartCommand、onBind这类方法很清楚它是个什么角色。这招比从头到尾看一遍要快得多也更能应对复杂的项目。3. apktool资源还原和二次打包绕不开jadx 适合看代码但如果你想分析或修改一个 APK 的资源文件、AndroidManifest、布局或者做二次打包测试apktool 才是真正的主角。它最大的价值在于能把二进制 XML 解码成普通文本并且支持反编译后再回编译出新的 APK。3.1 apktool d 能拿到什么执行apktool d your_app.apk你的工作目录下会多出一个文件夹里面最有价值的内容包括AndroidManifest.xml解码后的 XML不再是乱码可以直接看权限、四大组件、启动 Activity。res/解码后的资源目录包括layout、values、drawable等。smali/或smali_classes2/等dex 反汇编后的 smali 字节码。assets/原始 assets 目录通常包含也一些 JS、文本文件。分析一个 App 的时候我通常先用它看一遍 Manifest确认入口 Activity 和关键权限再决定从哪里下手。比如很多 App 需要申请的敏感权限其实都写在 Manifest 里看一眼就能判断它是不是真的有必要申请。3.2 回编译与重签名操作apktool 不只是“解包”还能“打包”。修改完资源或者 smali 后用下面的命令回编译apktool b your_app_dir -o new.apk回编译生成的 APK 默认不带签名安装前需要自己签一下。如果你机器上有 Android SDK用apksigner或signapk.jar都可以灵活一点也可以直接用keytool生成一个本地调试签名keytool -genkey -alias test -keyalg RSA -keystore test.keystore zipalign -v 4 new.apk aligned.apk apksigner sign --ks test.keystore --out signed.apk aligned.apk这里要注意新版 Android 对签名校验要求比较高尤其是 targetSdkVersion 30 以上的应用只签 v1 往往不够必须上 v2/v3。apksigner会默认尝试所有支持的签名方案所以推荐它而不是老旧的jarsigner。3.3 回编译里最容易翻车的坑apktool 用起来顺手但它对资源处理的要求很严格。我遇到过几个特别典型的坑资源混淆/资源压缩如果 App 开启了资源混淆res/下的文件名会变成a/layer1_a.xml这种形式回编译时经常因为引用关系缺失而失败。解决方案是谨慎改动资源文件尽量不动资源 ID 相关的 xml。resources.arsc过大或格式特殊某些 App 对 AAPT 做定制apktool 解码再编码就可能报错。这时候要么采用不修改资源、只改 smali 的方案要么放弃回编译。版本问题apktool 的版本必须和 Android Gradle Plugin 生成的资源格式匹配新格式出来后旧版 apktool 会直接解码失败。建议定期更新到最新版。3.4 分析广告 SDK 接入逻辑的合规思路很多人想去广告但直接从商业 App 里去除广告逻辑其实是刀尖上跳舞既涉及破除技术保护措施也可能踩授权红线。我更建议你把 apktool 用于学习广告 SDK 是如何被接入和调用的。比如分析一个 App 的AndroidManifest.xml可以看到它集成了哪些广告 SDK然后顺着 SDK 的初始化代码去理解广告加载、展示、回调的生命周期。这种“知其所以然”的学习方式既能学到东西也不会给自己惹麻烦。如果你是想对自己开发的应用做广告位配置排查那用 apktool 看自己的包更是再合适不过。4. dex2jar JD-GUI老组合依然有用但要会用这套组合是很多教程里的“元老级”方案流程是APK 解压后拿到classes.dex用 dex2jar 转成 jar然后用 JD-GUI 打开阅读。虽然 jadx 已经把我从这条链路里解放出来了但有些场景它依然不可替代。4.1 什么场景需要回头用这套组合你手头是一个 jar 包而不是 APK。jadx 也能打开 jar但 JD-GUI 对 jar 包的阅读体验在某些历史版本中更顺手尤其是有大量第三方依赖的传统项目。你需要在命令行环境下把 dex 转成 jar给其他 Java 分析工具用。比如有些自动化脚本基于 Java 字节码库如 ASM做分析jadx 的输出是源码反而不方便。老教程、老资料里大量操作基于这套工具你要复现别人的分析过程时按原路径走反而顺畅。换句话说jadx 是“逆向阅读”的主力而 dex2jar JD-GUI 是“Java 字节码生态”的一环两者不冲突。4.2 操作流程顺手跑一遍首先确保拿到 APK 中的 dex 文件解压即可unzip your_app.apk -d apk_extracted然后用 dex2jar 转换d2j-dex2jar.sh apk_extracted/classes.dex -o output.jar新版 dex2jar 通常也支持直接输入 APKd2j-dex2jar.sh your_app.apk -o output.jar打开 JD-GUI把output.jar拖进去就能看到反编译后的 Java 源码。4.3 JD-GUI 输出内容里的注释符号快速清理用过 JD-GUI 的人都知道它的“File - Save All Sources”会把每个类都导出成.java文件但文件头会附带一串类似/* Location: /home/user/whatever/classes.jar * Qualified Name: com.example.MainActivity * JD-Core Version: 1.6.0 */这种注释和原始代码无关纯粹是反编译工具的产物。如果只是自己看留着无所谓但如果要交个文档、贴个 patch或者导入到 IDEA 里对照 diff就非常碍眼。我一般用 VS Code 配合正则批量删除。搜索模式开启正则后把下面的模式替换成空字符串/\* Location:.*?\*/\n这个正则的核心是匹配一个以/* Location:开头的注释块然后整块删掉。实测下来在几千个文件的项目里也能跑完。如果你喜欢命令行也可以用sed批量处理find . -name *.java -exec sed -i /\/\* Location:/,/^\s*\*\//d {} \;另外说一句JD-GUI 在对较新的 Java 语法比如 lambda、部分泛型处理上经常出现失真反编译完的代码里偶尔会出现lambda$...这类奇怪方法。这时候我的习惯是立刻交叉用 jadx 打开同一个 jar 验证而不是浪费时间猜测。5. 容易被忽略的辅助工具APK Analyzer、baksmali、抓包配合除了上面三组工具还有几个“辅助切片”值得常备。它们单独拿出来不是万能的但和主工具配合起来能解决很多特定场景下的问题。5.1 Android Studio 自带的 APK Analyzer从 Android Studio 3.0 开始Build - Analyze APK...就内置了一个 APK 分析器。它能直接打开 APK展示 dex 方法数、资源大小分布、so 库支持的 ABI 架构。这个工具不是用来“读代码”的而是用来“读结构”的。比如你想知道一个 App 为什么体积这么大APK Analyzer 可以直接按文件类型排序看到哪些资源占了大头。再比如你想了解某个 so 库是否支持 arm64-v8a点击进去看支持的 ABI 列表就行。我经常在反编译大 App 之前先用它做快速体检判断这个包有没有加固、有没有特殊架构再决定后边的工具链。5.2 baksmali 和 smali从字节码层面看真相jadx 给的是 Java 层视图但遇到比较变态的混淆策略、或者你想做 Hook、插桩分析时smali 才是真正的“还原现场”。apktool 解包后的smali/目录其实就是 baksmali 的产物。简单解释一下 smali它是 dex 字节码的“汇编助记格式”指令级别比 Java 源码低一层比机器码高一层。比如一个if判断在 Java 源码里是隐式的在 smali 里却对应显式的if-eqz、goto等指令。使用场景上如果你要在onCreate方法开头插入一段日志用 jadx 改 Java 源码是做不到的它只读不写但用 apktool 解包后直接编辑 smali 是可行的。当然这属于进阶玩法我建议先用 jadx 把 Java 层逻辑读明白真有改字节码的需求再切到 smali 视图。5.3 反编译和抓包配合定位逻辑更快反编译工具解决的是“静态代码长什么样”抓包工具解决的是“App 运行时发了什么请求”。两者配合能快速定位关键方法。比如抓包看到 App 请求了一个带特定参数的接口回 jadx 里搜索这个参数名就能直接跳到构造请求的代码。如果只靠静态分析从入口一路追很容易迷失在成千上万行的调用链里。常见的抓包工具如 Charles、Fiddler、Burp Suite都是常规的 HTTP/HTTPS 调试工具。配置好代理和 HTTPS 证书后可以查看 App 的明文流量。注意这类工具应当只用于自己拥有合法授权的调试目标比如自研开发中的联调、测试环境问题排查或者合规的安全研究。5.4 遇到混淆和字符串加密怎么继续读很多现代 App 都用 R8/ProGuard 做了混淆类名、方法名变成了a.a()、b.c()这种。再配合字符串加密你在 jadx 里根本搜不到明文接口地址因为运行时才解密。我的应对思路不是死磕某一个工具而是动态和静态结合先用 drozer、Frida 这类动态分析框架在运行时 Hook 相关解密函数把解密后的字符串 dump 出来。这属于动态逆向的范畴但也反哺了整个分析流程。如果实在没有动态条件就退而求其次读 smali 理解解密函数怎么写的然后手动模拟解密算法。很多 App 的字符串加密算法并不复杂可能只是 Base64、异或、或者 AES 配合固定 key。jadx 的--deobf参数在轻度混淆下有些辅助作用但对重度混淆基本无效别指望它。说白了工具只是第一步真正的功力在于怎么把这些信息拼起来。反编译技术的核心从来不是那几条命令而是你对 Android 应用结构的理解深度。拿到一个包能快速判断该看代码、看资源、还是看 so能准确找到入口点和调用链比会十个工具都管用。上面这几组工具是我实测下来覆盖日常绝大多数场景的组合照着用至少不会在第一步就被卡住。本文还有配套的精品资源点击获取
