APK反编译工具链实战：jadx+apktool+签名全流程

简介：面向Android开发、逆向工程与安全测试场景的APK反编译工具整合包，汇集dex2jar、JD-GUI与Apktool三款主流组件，可帮助使用者查看APK内部结构、还原Java源码、提取资源文件并重新打包应用，适合需要分析第三方应用逻辑或开展安全审计的开发者与研究人员。压缩包采用7z格式封装，共109个文件，约9.69MB，内含32个bat脚本与30个sh脚本，便于在Windows和Linux环境下直接调用；28个jar包为各工具核心本体，另有少量配置、说明及示例APK文件辅助上手。借助这套工具可完成DEX转JAR、源码可视化阅读、资源修改、重新签名打包等完整逆向流程，尤其对理解Android应用运行机制、排查兼容性问题或进行应用本地化定制有直接帮助。目前已有152人学习下载，适合具备一定Android基础并希望深入了解反编译原理的读者参考使用。

1. 最新apk反编译软件到底是什么：一个工具组合，不是一个 App

很多人搜“最新apk反编译软件”，其实想找的是一个点一下就能把 APK 变成 Android Studio 工程的万能工具。实话说，现在没有这种东西，也不该有。反编译在安卓生态里是一整套工具链的组合：DEX 字节码要还原成 Java 源码，资源表要解出来能改能回编，smali 层要能编辑，最后还要重新签名——任何一个单一 App 都扛不住这四个环节。你需要的是一个固定组合：jadx 负责看代码，apktool 负责拆资源和 smali，签名交给 apksigner。这套方案能解决的具体诉求是：接手离职同事只留下的 APK、找回自己公司丢失的源码逻辑、安全评估时快速定位某个功能的实现方式，以及搞清楚一个包到底有没有被加固。适合安卓开发、逆向分析、测试和做应用安全评估的人。下面从选型开始，把这条链路完整跑一遍。

2. 先做选型：jadx / apktool / AndroidKiller 各管哪一层

2.1 为什么要拆成三层：DEX、资源、smali

APK 本质是个 zip 包，里面真正有技术含量的就三部分：classes.dex（以及多个 dex 文件）、resources.arsc加res/目录、AndroidManifest.xml。DEX 是安卓的字节码，JVM 不认识，得先转成可读形式；资源表是二进制编译过的，字符串都抽到resources.arsc里，直接解压出来是一堆乱码；清单文件也是二进制 XML，不能像看普通文本一样打开。反编译工具干的活，就是分别把这三层还原。

所以当你问“哪个软件最好”的时候，真正的问题是：你要看代码，还是要改资源，还是要改完再打包回去？这三个诉求对应不同的工具，硬用一个工具吃两头，最后一定翻车。jadx 把 DEX 还原成接近工程结构的 Java 源码，适合读逻辑；apktool 把资源解出来并支持回编译，适合改图标、改文案、改 smali；而签名则要单独用 apksigner，因为旧时代的 jarsigner 在 Android 7 以上版本会掉链子。

2.2 主流工具能力和边界

这个表说白了就是给你划边界：想快速读懂一个包的逻辑，jadx 是第一选择；想改东西再装回去，apktool 是唯一靠谱的入口；AndroidKiller 适合在 Windows 上做快速改 smali 的场景，但它不是全能的，遇到编码问题会把你坑到怀疑人生。

2.3 我的选型结论：jadx 主看代码，apktool 负责回编译

实际干活时我一般只保留两件套：jadx 加 apktool。jadx 打开 APK，导出源码目录，顺着AndroidManifest.xml里的入口 Activity 往下看，基本能还原一个 App 的核心逻辑。apktool 做资源回编译，改图标、改字符串、改 smali，然后重新打包。AndroidKiller 这类集成工具我也装，但只用来做“快速改个 smali 然后一键回编”的小操作，主力流程不用它。

选型时还有一个判断标准：看你要处理的包有多“新”。如果你拿到的是老项目、老 SDK 打的包，dex2jar 加 jd-gui 这套老组合反而更稳；但现在的 App 普遍用 Jetpack、协程、多 DEX，老方案已经跟不上了。jadx 社区活跃，对新版 DEX 格式支持好，遇到反编译失败的方法还会留注释标记，这才是“最新”这个标题下真正该选它而不是别的工具的原因。

3. 一个 APK 反编译后修改再打包：命令链与参数逐一拆解

3.1 确认 APK 类型：先别急着反编译

拿到一个 APK，我不会直接丢进 jadx，而是先用file和unzip -l看一眼包结构。这一步能避免后面走弯路：有些包根本不是标准安卓 App，而是 Unity、Cocos Creator 或 Flutter 打的包，它们的业务代码压在lib/下的 so 文件里，或者 assets 里，dex 只是个启动壳。对这种包，下面这套 jadx 加 apktool 流程只能看到壳，真正的内容在 native 层和资源包里，得换另一套思路。

file app.apk unzip -l app.apk | head -40 unzip -l app.apk | grep -E "classes[0-9]*\.dex|lib/.*/lib(jiagu|DexHelper|shell|protect)"

第一行确认 APK 文件本身没损坏。第二行看包体结构，重点观察 dex 文件数量和lib/目录下的 so 文件。第三行是加固特征检测：如果 so 文件里出现libjiagu.so（腾讯加固）、libDexHelper.so（梆梆）、libshell*.so（爱加密）这类名字，说明这个包是加固过的，直接反编译只能看到壳，后面必须在第 4 章单独处理。如果classes.dex只有一个且体积很小，而 so 文件很大，也要警惕：业务逻辑可能不在 dex 里。

3.2 用 jadx 快速拿 Java 源码

确认是可正常处理的包之后，第一步就是用 jadx 把 dex 还原成 Java 源码。这条命令是固定的，参数根据场景调整：

jadx -d out_src --deobf --show-bad-code --no-res app.apk

-d指定输出目录，会在out_src下按包名生成目录结构。--deobf是反混淆开关，会把混淆过的类名和方法名尽量还原成可读形式，但它会改变名称，如果后续要对照原始 APK 的 smali，建议先不加这个参数跑一遍，保留原始命名。--show-bad-code很有用：遇到反编译失败的方法，jadx 会在源码里保留注释标记而不是静默丢弃，这样你能知道哪些逻辑需要去 smali 层看。--no-res是让 jadx 跳过资源反编译，资源这块本来就该交给 apktool，省得两边的产物冲突。

如果你只需要快速看清单和资源结构，不想导出完整源码，可以加--no-src只反编译资源，但一般没必要。实际项目里，我只用 jadx 做代码阅读，输出的 Java 源码很少直接拿回 Android Studio 编译——它本来就不是给你编译用的，而是给你看逻辑用的。

3.3 用 apktool 拆资源与 smali

代码逻辑看完，接下来要动手改。改之前用 apktool 把 APK 完整拆开：

apktool d app.apk -o app_out -f

-o指定输出目录，-f是目录已存在时强制覆盖。拆出来的app_out目录下有几个关键子目录：smali/按包名组织 smali 代码，res/是解出来的资源文件，AndroidManifest.xml已经被转成可读的 XML 格式，还有apktool.yml记录原包的版本信息。

如果你只想改资源不动 smali，可以用-r参数跳过 smali 反编译；只想改代码不动资源，用-s。这两个参数能显著缩短解包时间，也能避免回编译时因为动了没必要的部分而多出错。我在实际项目里改图标、改 App 名称的时候就用-s，只解资源，回编译速度快很多。

3.4 回编译：改完之后的关键命令

改完 smali 或资源后，用b命令回编译：

apktool b app_out -o rebuild.apk --use-aapt2

-o指定回编译产出的 APK 路径。--use-aapt2是最近几年必须加的参数：老版本的 apktool 内置的是 aapt1，对现在 App 用的自适应图标、夜间模式资源这类新特性支持很差，加了这个开关会用新版构建工具的资源编译器，兼容性更好。回编译报错时，错误信息会直接指向具体资源文件，这时候优先看res/values/下有没有改坏的东西，而不是怀疑工具坏了。

回编译这个环节是整个流程里最容易碎的一环。apktool 产物能编译成功，不代表装到手机上能跑，资源表、签名校验都有可能在运行时给你颜色看。所以回编译只是第一步，后面还有签名和验证两个环节，少一个都白搭。

3.5 签名：apksigner 的参数与 v2/v3 选择

回编译出来的 APK 是没有签名的，装不上 Android 7 以上的设备。签名环节我统一用 apksigner，不用 jarsigner。jarsigner 只支持 v1 签名，在 Android 7 以上会因为缺少 v2 签名被拒。完整命令链如下：

keytool -genkey -alias devkey -keyalg RSA -keysize 2048 -validity 10000 -keystore dev.jks zipalign -p 4 rebuild.apk rebuild_aligned.apk apksigner sign --ks dev.jks --ks-key-alias devkey --ks-pass pass:123456 --out signed.apk rebuild_aligned.apk apksigner verify --print-certs signed.apk

keytool生成一个新的签名证书，-validity 10000表示有效天数，测试用没问题。zipalign -p 4对 APK 做 4 字节对齐，这步要在签名之前做。apksigner sign会自动根据目标 SDK 选择 v1、v2、v3 签名方案，不用手动指定。最后的verify --print-certs是验证签名证书是否正常，打印出来的证书信息确认是自己生成的，才说明签名环节没出错。

注意：重打包后的 APK 签名和你原来 App 的签名不一样。如果原代码里有签名校验逻辑，安装后打开会闪退。这一点不是 bug，是防御机制在起作用，后面讲踩坑会展开。

4. APK 反编译避坑与排查：乱码、重打包闪退、加固黑匣子

4.1 AndroidKiller 打开 APK 反编译过程出现乱码

我用 Windows 环境时遇到过一个高频问题：AndroidKiller 打开 APK 反编译过程出现乱码，smali 文件里的中文注释全是“鍝堝搱”这种乱码，严重的时候整个文件都打不开。

原因很明确：APK 内部的 XML 和 smali 文件都是 UTF-8 编码，而 Windows 中文系统默认的本地编码是 GBK。AndroidKiller 这类老工具没有主动做编码转换，直接用系统编码去读文件，就乱码了。

解决方式有两个。第一，在 AndroidKiller 的选项设置里找编码配置，改成 UTF-8，然后重新打开文件；第二，别在这个工具上死磕，直接用 jadx 打开同一个 APK，jadx 对编码处理更规范，不会有这个问题。我的习惯是：只要涉及中文资源或者中文注释，一律用 jadx 看代码，AndroidKiller 只在纯改英文资源的时候用。

4.2 重打包后安装闪退：先查签名校验

这是重打包场景最常见的翻车现场：apktool 回编译成功，签名成功，安装成功，但一点开 App 就闪退，甚至直接提示“应用屡次停止运行”。

原因大概率不是你的改动了什么代码，而是原 App 里有签名校验逻辑。很多应用会在启动时用PackageManager读取当前安装包的签名信息，跟内置的合法证书比对，不一致就直接退出。你重打包后用的新签名，当然过不了这一关。

排查方法是做一次对照实验：先用 apktool 只改图标、不改任何代码，重新签名安装。如果这样也闪退，那基本确定是签名校验；如果这样能跑通，说明你的代码改动有问题。确认是签名校验后，不要想着绕过，那已经不是反编译工具的问题。现实的做法是：如果能拿到原项目的签名文件，用回原签名；拿不到的话，反编译结果就只当分析材料用，不要强求重打包上线。

4.3 jadx 里只有壳类：APK 加固怎么判断

有次反编译一个包，jadx 打开后整个工程只有两三个类，一个com.stub.StubApp，其他的全在混淆名里，根本看不到项目自己的包结构。当时一脸懵，以为资源坏了。后来看 dex 体积，只有 20 多 KB，而原 APK 有 30 MB，这才反应过来是加固。

加固的原理是把真实的代码抽走，在运行时由壳程序去加载真实 dex，所以静态反编译只能看到启动壳。判断方法就是 3.1 里那行 grep 命令，搜libjiagu.so、libDexHelper.so、libshell*.so这些特征，或者看 dex 文件数量和体积是否明显不合理。

遇到加固包，正确做法是分情况处理：如果是自己公司的应用，找开发要加固前的原始包，或者找加固厂商要白包；如果是做安全评估且你有权分析目标，那就得走动态脱壳路线，属于另一个话题了。别指望用一个“最新反编译软件”绕过加固，那是不存在的。

4.4 回编译报资源编译失败：先看是不是动了资源表

apktool 回编译时报错是另一个高频坑，典型提示是aapt2 error，或者指向res/values/下某个文件编译失败。这种情况九成是资源表出了问题。

资源表是重打包里最脆弱的一环。常见操作失误是：为了改某个文案，顺手动了resources.arsc里抽出来的资源项，或者在res/values/public.xml里调整了资源 ID，导致引用错乱。aapt2 对资源 ID 的检查比 aapt1 严格，一旦冲突就直接报错。

解决方式是先还原。如果不记得改了什么，就把app_out删掉重新解包一次，然后只做单点修改：改一个资源、回编一次、签名装一次。验证链路通了再动下一个。报错信息里指向哪个文件，就先检查哪个文件，不要在回编失败时盲目升级 apktool 版本——多数情况下不是工具的问题。

4.5 签名验证失败：jarsigner 和 apksigner 的差异

自己签名的 APK 装不上，或者apksigner verify报错，我也踩过不少次。最典型的是拿旧习惯用jarsigner签完，装到 Android 7 以上的手机直接提示“安装解析失败”或者“签名无效”。

原因是jarsigner只生成 v1 签名，而 Android 7 以上设备默认要求 v2 签名，Android 11 以上还要 v3 签名。解决方式就是用apksigner，它根据目标 SDK 自动处理 v1/v2/v3 的组合，不需要手动选。另外注意操作顺序：zipalign一定要在签名前做，签名之后再对齐会导致签名失效。每次签名完，用apksigner verify --print-certs看一眼证书信息，确认签名内容是你自己的，而不是某个缓存目录里的旧包。

5. 反编译结果验证：三查一装，防止拿错代码走弯路

5.1 一查入口：从清单反推主流程

反编译完成后，第一个验证动作是打开解出来的AndroidManifest.xml，找到MAIN和LAUNCHER对应的 Activity，然后在 jadx 导出的源码里打开这个类，看onCreate里的逻辑是否和你对这个 App 的了解一致。如果这个包是你自己公司的老包，你应该能认出几个核心类名；如果是分析别人的包，至少确认入口 Activity 在源码里存在，而不是只有壳。

5.2 二查资源：比对解包后的资源结构

资源这块，我习惯把原 APK 解压一次，对照着看res/目录的层级。重点检查values/下有没有strings.xml、图标文件是不是原有的 mipmap 系列。如果你发现 apktool 解出来的资源结构和原包明显不一致，多半是在操作过程中改了不该改的资源项，先止损。

5.3 三查签名与最稳的验证动作：先只改图标再装机

我在项目里总结了一个最实用的验证方法，叫“先只改图标再装机”。具体做法是：用 apktool 拆包后，只替换res/mipmap-*下的桌面图标，然后回编译、签名、安装。如果能正常启动，说明资源链路和签名链路都是通的，再去改代码；如果这一步就闪退，说明问题在签名校验或者资源表，跟后面的代码改动无关，不用浪费时间排查。

现在拿到一个新的 APK，我的习惯永远是：先跑一遍加固检测命令，再丢给 jadx 看逻辑，最后用 apktool 拆资源。反编译工具从来不是越新越全能，而是组合越顺手越可靠。改完的产物验证完就删掉，尤其是有版权风险的样本，留在磁盘上没有任何好处。希望帮到你。

本文还有配套的精品资源，点击获取