APK反编译与回编译全流程：apktool、jadx、smali与重签名实战

APK 和 Dex 文件的反编译、回编译这件事，在移动安全审计、老项目维护、竞品功能拆解、SDK 行为分析这些场景里几乎是绕不开的基本功。我这些年接手过的活儿里，有相当一部分第一步就是"把包拆开看看里面到底装了什么"。很多人第一次接触这类工具链，以为装个图形化工具点几下就完事，结果一遇到资源混淆、多 Dex、签名校验、加固壳就卡住，来回折腾好几天。这篇东西就是把我自己反复踩坑之后沉淀下来的完整流程写清楚：从 APK 拆包、Dex 反编译成可读代码、修改后回编译、重签名到最终验证，每一步为什么这么做、参数怎么选、哪里容易翻车，都讲透。适合刚入行的移动安全测试人员、需要逆向排查线上崩溃的 Android 开发，以及想搞清楚第三方 SDK 到底干了什么的技术负责人。哪怕你之前只听说过 apktool 和 jadx 这两个名字，跟着走一遍也能独立完成一次完整的反编译与回编译闭环。

1. 整体方案设计与工具链选型思路

1.1 为什么反编译要拆成"资源层"和"代码层"两条线

Android 应用的产物结构决定了这件事必须分两条线走。一个 APK 本质上是个 zip 包，里面混着两类完全不同的东西：一类是resources.arsc、res/目录下的 XML 和图片、AndroidManifest.xml这些资源与配置，它们在打包时被编译成了二进制格式，普通文本编辑器打开全是乱码；另一类是classes.dex（可能还有classes2.dex、classes3.dex）里的字节码，这是 Java/Kotlin 源码编译后的产物，运行在 ART/Dalvik 虚拟机上。

这两类内容的处理工具完全不同。资源层用apktool最顺手，它能解码二进制 XML 和resources.arsc，还原成人类可读的 XML 和原始资源文件，而且回编译时能重新打包成二进制格式，这是它不可替代的地方。代码层则要看你的目的：如果只是想读懂逻辑，用jadx直接反编译成 Java 代码，可读性最好；如果是要修改字节码再回编译，就得用baksmali/smali走 smali 汇编这条路，因为 jadx 反编译出来的 Java 代码是"只读"的，改完没法直接编译回 Dex。

我见过不少人图省事，想用 jadx 改完代码再想办法编译回去，最后都放弃了——jadx 的输出是给人看的，不是给编译器吃的。所以正确的思路是：资源改动走 apktool，代码改动走 smali，纯分析走 jadx。三条路各司其职，别指望一个工具通吃。

1.2 工具链组合与各自职责边界

把整套流程用到的工具列清楚，避免新手一上来就乱装一堆东西却不知道谁干什么：

这张表是我建议你贴在显示器旁边的。核心逻辑一句话：apktool 管资源，smali 管代码，apksigner 管签名，zipalign 管对齐。jadx 是旁路的分析工具，不参与回编译链路。

1.3 方案选型的三个关键取舍

第一个取舍是要不要用 apktool 全量解码。apktool 解码资源很强大，但它对某些加固过的包、或者用了特殊资源混淆方案的包，解码会失败或者解出来的东西回编译报错。我的经验是：如果只是改代码不改资源，完全没必要用 apktool 全量解码，直接用 baksmali 从 APK 里抽 Dex 出来处理，改完再塞回去，这样能绕开大量资源层的坑。

第二个取舍是jadx 还是 smali 做代码分析。纯读逻辑，jadx 的 Java 输出效率高十倍；但一旦涉及"我要改这一行再跑起来"，就必须切到 smali。实际操作里我经常是先用 jadx 定位到关键类和方法，记下方法签名，再去 smali 里找对应位置改，两者配合用效率最高。

第三个取舍是签名方案。现在 Android 7.0 以上要求 APK Signature Scheme v2，Android 9 以上很多场景要求 v3，只签 v1 的包在新系统上装不上或者校验失败。所以重签名必须用 apksigner 而不是老的 jarsigner，并且要显式指定启用 v1/v2/v3。这个后面实操部分会详细讲参数。

2. 环境准备与工具安装的实操细节

2.1 基础运行环境搭建

这套工具链主体是 Java 生态，所以第一步是把 JDK 装对。apktool、jadx、baksmali/smali、apksigner 全都依赖 Java 运行时。我建议用JDK 11 或 JDK 17，这两个版本兼容性最好。JDK 8 虽然也能跑大部分工具，但新版 apktool 和 apksigner 对高版本字节码支持更好，用 8 偶尔会遇到Unsupported class file major version之类的报错。

装完之后务必验证：

java -version javac -version

两条命令输出的版本号要一致，且都是 11 或 17。我踩过的坑是机器上装了多个 JDK，java指向 17 但JAVA_HOME指向 8，导致某些工具启动时加载错版本，报一堆莫名其妙的错。所以装完一定要echo $JAVA_HOME（Windows 下echo %JAVA_HOME%）确认环境变量和实际 java 版本对得上。

Android SDK 里的build-tools也要装，因为 apksigner 和 zipalign 都在里面。不需要装完整的 Android Studio，用命令行工具单独下 build-tools 就行。装好后把build-tools/<版本号>/目录加到 PATH，这样 apksigner 和 zipalign 能直接调用。版本建议选 30.0.0 以上，太老的 build-tools 里的 apksigner 不支持 v3 签名。

2.2 apktool 安装与版本选择

apktool 有两个东西要下：一个是apktool.jar主程序，一个是包装脚本（Windows 是apktool.bat，Linux/macOS 是apktool脚本）。很多人只下了 jar，然后每次都要java -jar apktool.jar，很麻烦。正确做法是把 jar 和脚本放同一目录，脚本里指向 jar 的路径改对，之后直接敲apktool就能用。

版本选择上，优先用最新稳定版。apktool 对 Android 新版本的资源格式支持是逐步跟进的，用老版本解新包经常报Could not decode arsc file或者解出来的resources.arsc结构不对导致回编译失败。我一般去官方发布页拿最新的apktool_x.x.x.jar，重命名成apktool.jar覆盖旧的。

验证安装：

apktool --version

能打印出版本号就说明脚本和 jar 都通了。如果报Error: Unable to access jarfile，八成是脚本里的 jar 路径写错了，打开脚本看一眼那行java -jar后面的路径。

2.3 jadx 与 smali 工具的准备

jadx 直接用 release 包里的jadx和jadx-gui脚本即可，同样依赖 Java。jadx-gui 是图形界面，适合人工浏览；jadx命令行适合批量导出。我平时分析用 gui，需要把整个工程导出成 Java 文件时用命令行：

jadx -d output_dir target.apk

baksmali 和 smali 是两个独立的 jar，官方发布里通常叫baksmali-x.x.x.jar和smali-x.x.x.jar。这两个工具的版本必须严格配对，用 2.5.2 的 baksmali 反汇编出来的 smali，必须用 2.5.2 的 smali 汇编回去，版本不一致会报语法错误或者生成错误的 Dex。这是新手最容易忽略的点，我见过有人拿 2.4 的 smali 去汇编 2.5 baksmali 的产物，折腾一下午找不到原因。

2.4 一个容易忽略的前置检查：APK 是否加固

在动手反编译之前，先花两分钟判断这个包有没有加固。方法很简单：用 unzip 列出 APK 内容，看classes.dex的大小和数量。如果classes.dex只有几十 KB，但 APK 总体积好几 MB，且lib/目录下有一堆.so文件，那基本可以判定是加固过的——真正的业务代码被抽到 so 里或者加密藏在别处，dex 只是个壳。

unzip -l target.apk | grep -E "classes.*dex|\.so"

加固包直接走常规反编译流程，解出来的 Dex 里全是壳代码，看不到真实逻辑。这种情况要么放弃，要么走脱壳路线（那是另一个话题，涉及运行时 dump，复杂度高很多）。提前判断能帮你省下大量无效操作。

3. APK 拆包与 Dex 反编译的核心操作

3.1 用 apktool 解码资源与清单

标准解码命令：

apktool d target.apk -o decoded_dir

-o指定输出目录，不加的话默认输出到以 APK 名命名的文件夹。解码成功后，decoded_dir里会有AndroidManifest.xml（已还原成可读 XML）、res/（原始资源）、smali/（如果 APK 里有 Dex，apktool 会顺带用内置 baksmali 反汇编成 smali）、apktool.yml（重打包需要的元信息）。

这里有个细节值得说：apktool 默认会把 Dex 也反汇编成 smali 放在smali/、smali_classes2/等目录。如果你只想改资源，这一步顺带产出的 smali 可以不管；但如果你要改代码，这些 smali 就是你的工作对象。不过我更推荐代码改动单独用 baksmali 处理，原因后面 3.3 会讲。

解码时常见的两个参数：

• -f：强制覆盖已存在的输出目录。反复调试时很有用，省得手动删。
• -r：跳过资源解码，只反汇编 Dex。当你只关心代码、不想被资源解码报错卡住时用这个。

-r这个参数救过我很多次。有些包的resources.arsc用了非标准格式，apktool 解码资源直接崩，但我其实只想看代码，加-r就绕过去了。

3.2 多 Dex 场景的处理

现代 APK 基本都是多 Dex，classes.dex、classes2.dex、classes3.dex……方法数超过 65536 就会分包。apktool 解码时会自动把它们分别反汇编到smali/、smali_classes2/、smali_classes3/。回编译时 apktool 也会自动按目录重新打包成多个 Dex，这部分不用你操心。

但如果你走 baksmali 手动路线，就要自己管理多个 Dex。我的做法是先解压 APK 拿到所有 dex：

unzip target.apk "classes*.dex" -d dex_workspace

然后对每个 dex 单独 baksmali：

java -jar baksmali.jar d dex_workspace/classes.dex -o smali_out/ java -jar baksmali.jar d dex_workspace/classes2.dex -o smali_out2/

改完之后再分别 smali 回 dex，最后替换回 APK。多 Dex 的关键是保持 Dex 与 smali 目录的对应关系不乱，改哪个 dex 的代码就只动哪个目录，别混着来。

3.3 baksmali 反汇编 Dex 的参数详解

单独反汇编一个 Dex：

java -jar baksmali.jar d classes.dex -o smali_out

常用参数：

• -o：输出目录。
• --debug-info：保留调试信息（行号、局部变量名）。默认是保留的，如果你想要更干净的输出可以关掉，但调试时建议保留，报错行号对定位问题很有帮助。
• -r/--no-accessor：不生成 accessor 方法，输出更接近原始字节码。一般不用动。

反汇编出来的 smali 是 Dalvik 字节码的汇编表示，语法上每个方法是一段.method ... .end method，每条指令对应一个虚拟机操作。看不懂没关系，改代码时你只需要定位到目标方法，改其中一两行指令或者常量即可，不需要通读全部。

3.4 jadx 反编译做代码定位的正确姿势

jadx 的价值在于快速定位。打开 jadx-gui 加载 APK，左侧是包结构树，中间是反编译出的 Java 代码，支持全局搜索类名、方法名、字符串常量。我通常的流程是：

1. 在 jadx 里搜关键字符串（比如某个提示文案、某个 URL、某个 SharedPreferences 的 key），定位到使用它的类和方法。
2. 记下这个方法的完整签名，比如com.example.foo.Bar.checkLicense(Ljava/lang/String;)Z。
3. 切到 smali 目录，按包路径找到对应的.smali文件，搜索方法名，定位到具体指令位置。

这个"jadx 定位、smali 修改"的组合是我用得最顺的。纯靠 smali 读逻辑太痛苦，纯靠 jadx 又改不了，两者结合效率最高。

jadx 反编译偶尔会失败，报Failed to decompile或者输出一堆// error。这通常是遇到了 jadx 不支持的字节码模式或者混淆过的控制流。这时候别死磕，直接看 smali，虽然难读但一定准确。

4. 代码修改与回编译的完整实现

4.1 smali 修改的典型场景与写法

最常见的修改场景是改常量和改条件跳转。举个改常量的例子，smali 里字符串常量是这样出现的：

const-string v0, "trial_version"

改成const-string v0, "full_version"就完成了字符串替换。数字常量则是const/4 v0, 0x1这种，0x1就是值 1，改成0x0就是 0。

改条件跳转是另一个高频操作。smali 里的条件跳转长这样：

if-eqz v0, :cond_0

意思是"如果 v0 等于 0 就跳到 :cond_0"。如果你想让它无论如何都不跳，可以把if-eqz改成goto，或者把条件反过来。但要注意，改跳转很容易破坏栈平衡或者让后续指令引用到未初始化的寄存器，改完必须回编译验证，不能想当然。

注意：smali 里寄存器（v0、v1、p0、p1）的分配是编译器算好的，你新增指令时如果用到新寄存器，必须同步修改方法头的.registers或.locals声明，否则回编译会报寄存器越界。这是新手改 smali 最常见的翻车点。

4.2 smali 回汇编成 Dex

改完 smali 后，用 smali 工具汇编回 Dex：

java -jar smali.jar a smali_out -o classes_new.dex

a是 assemble 的缩写，smali_out是 smali 目录，-o指定输出的 dex 文件名。如果原包是多 Dex，就分别对每个 smali 目录执行，输出对应的classes.dex、classes2.dex。

汇编报错时，错误信息通常会指出哪个文件哪一行有问题，比如Invalid register、Label not found、Expected ...。按提示回去改就行。我遇到最多的是标签（label）问题——删了某段代码但没删对应的跳转标签，或者标签重名。smali 的标签是:cond_0、:goto_0这种，同一方法内不能重名。

4.3 替换 Dex 并重新打包 APK

拿到新的 Dex 后，要把它塞回 APK。有两种路线：

路线一：apktool 重打包。如果你是用 apktool 全量解码的，直接把新 Dex 反汇编的 smali 覆盖到smali/目录，然后：

apktool b decoded_dir -o rebuilt.apk

apktool 会自动把 smali 汇编成 Dex 并打包。这条路适合同时改了资源和代码的情况。

路线二：直接替换 Dex。如果你只改了代码没动资源，最干净的做法是拿原始 APK，用 zip 工具把新的classes.dex替换进去：

zip -j target.apk classes_new.dex

但这里有个坑：APK 里的文件顺序和压缩方式会影响签名和安装，直接zip替换可能导致某些校验失败。更稳妥的做法是用zip -X（不额外写属性）或者干脆解压整个 APK、替换 Dex、再重新打包。我一般用后者，虽然多一步但最不容易出问题。

4.4 zipalign 与 apksigner 重签名

回编译出来的 APK 是未签名的，直接装会报INSTALL_PARSE_FAILED_NO_CERTIFICATES。签名前先做字节对齐：

zipalign -v -p 4 rebuilt.apk aligned.apk

-p 4表示按 4 字节对齐，这是 Android 要求的页对齐。对齐的作用是让 APK 里的未压缩资源在内存映射时能直接按页加载，减少运行时内存拷贝。不做对齐虽然也能装，但会有性能损耗，而且某些系统版本会拒绝安装。

然后签名：

apksigner sign --ks mykey.jks --ks-key-alias myalias \ --v1-signing-enabled true --v2-signing-enabled true --v3-signing-enabled true \ --out signed.apk aligned.apk

关键参数解释：

• --ks：密钥库文件。没有的话用keytool -genkeypair生成一个，测试用途随便填信息即可。
• --v1/v2/v3-signing-enabled：显式开启三代签名方案。v1 是 JAR 签名（老系统兼容），v2 是 APK Signature Scheme v2（Android 7.0+），v3 是 v3 方案（Android 9+，支持密钥轮换）。三个都开最保险。
• --out：输出文件名。

签完验证一下：

apksigner verify --verbose signed.apk

输出里会列出 v1/v2/v3 各自的验证结果，全绿才算成功。如果 v2 或 v3 显示 false，说明签名参数没生效，检查是不是 build-tools 版本太老。

提示：重签名后 APK 的签名和原包不同，如果应用内部有签名校验（很多金融类、游戏类应用都有），会检测到签名变化而拒绝运行或闪退。这种情况要么定位并 patch 掉校验逻辑（在 smali 里找getPackageInfo配合GET_SIGNATURES的调用），要么放弃。签名校验的 patch 是另一个深坑，涉及多处校验点和 native 层校验，不在本文展开。

5. 常见问题排查与避坑经验实录

5.1 反编译阶段的典型报错

报错一：Could not decode arsc file。这是 apktool 解码resources.arsc失败，常见于资源格式被修改过或者 apktool 版本太老。解决办法：升级 apktool 到最新版；如果还不行，加-r跳过资源解码，只处理代码。

报错二：brut.androlib.AndrolibException: Could not smali file。apktool 内置的 smali 版本和 Dex 格式不匹配。升级 apktool 通常能解决，或者改用独立 baksmali 处理 Dex。

报错三：jadx 反编译大量// error。遇到不支持的字节码或者混淆控制流。不影响 smali 修改，直接看 smali 即可。

5.2 回编译阶段的典型报错

报错一：Invalid register。smali 里用了超出.registers声明范围的寄存器。检查方法头的寄存器声明，或者改用已声明的寄存器。

报错二：Label not found。跳转指令引用了不存在的标签。检查是不是删代码时把标签定义也删了，或者标签名拼错。

报错三：Expected ... but found ...。smali 语法错误，通常是某条指令的参数类型不对，比如该用寄存器的地方写了常量。按报错行号回去看。

5.3 安装与运行阶段的典型问题

问题一：INSTALL_FAILED_INVALID_APK。多半是没对齐或者签名不完整。先 zipalign 再 apksigner，且确保 v2/v3 都开了。

问题二：装上了但一启动就闪退。常见原因有三个：签名校验没 patch 掉、smali 改动破坏了逻辑、多 Dex 替换时目录对应错了。排查顺序是先看 logcat 的崩溃堆栈，定位到具体类和方法，再回 smali 检查改动点。

问题三：INSTALL_FAILED_UPDATE_INCOMPATIBLE。设备上已装了同包名但签名不同的版本。先卸载旧版再装，或者用adb install -r加-d允许降级。

5.4 一份问题速查表

5.5 几条用血换来的实操心得

第一条，每次改动前先备份原始 APK 和原始 smali 目录。我吃过亏，改到一半发现改错了想回退，结果原始文件被覆盖，只能重新从原始 APK 解一遍，浪费大量时间。养成cp -r备份的习惯，成本极低收益极高。

第二条，小步快跑，改一处验一处。不要一次性改十几个方法再回编译，一旦出错根本不知道是哪处改坏的。正确做法是改一个方法、回编译、装上去验证、通过再改下一个。虽然看起来慢，但总时间反而更短。

第三条，善用 logcat 定位崩溃点。闪退时adb logcat里的堆栈会精确到类名和方法名，拿着这个信息回 smali 找对应位置，比盲目搜索快得多。过滤命令：

adb logcat | grep -E "AndroidRuntime|FATAL"

第四条，签名校验的 patch 要全面。很多应用的签名校验不止一处，Java 层有、native 层也有，甚至服务端还会校验。只 patch 掉 Java 层的一处，往往还是闪退。判断方法是在 smali 里全局搜getPackageInfo、GET_SIGNATURES、signatures这些关键词，把所有校验点都找出来逐个处理。

第五条，注意 Android 版本差异。同一个改过的包，在 Android 8 上能跑，在 Android 12 上可能因为分区存储、权限模型变化而行为不同。测试时至少覆盖一个低版本和一个高版本设备，别只在一台机器上验证就下结论。

这套流程我从最早的单一 Dex 应用一路用到现在的多 Dex、资源混淆、部分加固的复杂包，工具在变、对抗在升级，但"资源走 apktool、代码走 smali、分析走 jadx、签名走 apksigner"这个骨架一直没变。真正花时间的从来不是工具怎么用，而是遇到报错时知道往哪个方向查——上面那些速查表和心得，就是帮你把排查方向缩到最小的那部分。