简介：这套面向 Android 应用分析与安全审计场景的 APK 反编译工具合集，适合想读懂他人应用实现、排查自身应用漏洞或做二次开发的开发者与逆向初学者。包内以 apktool 承担解包与重打包，auto-sign 负责重签名，dex2jar 把 DEX 转为 JAR，jd-gui 图形化查看 Java 源码，四者串成从资源文件到字节码的完整链路，覆盖清单解析、布局与字符串还原、签名校验等常见环节。压缩包共 58 个文件、约 10.58MB，以 17 个 bat 与 14 个 sh 脚本为主，搭配 11 个 jar 核心程序、3 个 exe 可执行文件与 9 个说明文档，Windows 与类 Unix 双平台脚本齐备，并附签名用的 pem 证书、pk8 私钥和 cfg 配置，解压即可按目录调用，省去逐个搜集组件的时间。目前已有 13978 人学习下载，可对照练习资源还原与代码结构阅读，也适合作为自查应用调试开关、明文密钥等隐患的入门工具集。

1. 三条命令跑完一个 APK：先说结论，别把四个工具当竞品

第一次把 apktool、dex2jar、jd-gui、auto-sign 这四个名字摆在一起时，我下意识把它们当成了四个同类候选，挨个装、挨个试，折腾了一下午才发现方向从一开始就错了——它们根本不在同一个位置上竞争。apktool 管资源和 smali 的拆与装，dex2jar 管 dex 到 jar 的搬运，jd-gui 管把 jar 读成人能看懂的 Java，auto-sign 管把改完的包装回测试机。APK 反编译工具这套组合真正难的从来不是“选哪个”，而是“哪一段该用谁、接缝处为什么会断”。后面要讲清楚的就三件事：这套链路怎么分工、每个环节怎么验收、以及我踩过的那些坑到底该怎么绕。

2. 四道工序各管一段：谁替不了谁，谁只是过渡

先把分工摆明白，后面所有对比才有意义。我见过太多人拿着 jd-gui 去打资源主意，或者用 apktool 硬啃混淆后的逻辑，最后得出结论“这工具不行”——工具没不行，是位置站错了。这一章按工序拆，每一段说清楚它吃什么、吐什么、边界在哪。

2.1 apktool：资源和 smali 的入口，能回编译才是它的价值

apktool 是整个链路里唯一一个“双向”的工具：既能拆，也能装回去。拆的时候它干两件事，一是把resources.arsc和res/还原成近乎原始的目录结构和 XML，二是把classes.dex反汇编成 smali。这两件事的价值不对称——资源还原的可读性极高，基本拿到就能看懂布局、字符串、颜色、多语言；smali 的可读性则完全取决于有没有混淆，没混淆的 smali 能顺着方法名一路读到业务逻辑，混淆过的就只剩a.a.a()这种。

但 apktool 真正的护城河不是“能拆”，而是“能装回去”。这一点决定了它在链路里的位置：只要你的目标涉及改资源、改 smali、改清单文件，最后都要回到 apktool 来执行b（build）。jd-gui 读得再舒服，它也没法把你的修改写回 APK。所以我的判断标准很固定：如果这次分析只需要“看”，apktool 可以只当拆包器用；如果需要“改”，apktool 就是不可替代的主干，其它三个都是它的辅助。

它的短板也很清楚。第一，它不负责 Java 源码级还原，smali 读起来对不熟寄存器指令的人不友好；第二，它对外部框架资源有依赖，遇到厂商定制过的资源表，版本稍旧就直接解不动；第三，回编译出来的包默认是未签名、未对齐的，直接装必失败。这三点后面避坑章节会逐条展开。

2.2 dex2jar + jd-gui：只读源码这条线，快但脆

dex2jar 和 jd-gui 是一对绑定关系，拆开看没意义。dex2jar 做的是格式转换，把classes.dex转成标准.jar，它不理解 Java 语义，只做字节码层面的重打包；jd-gui 才是那个把.class反编译成 Java 源码的阅读器。两者合起来构成“只读源码线”，特点是上手极快、成品极像源码，缺点是脆弱。

脆弱体现在三个地方。一是多 dex，现代 APK 少则两个 dex 多则十几个，dex2jar 一次只吃一个文件，你得自己循环；二是混淆，ProGuard/R8 处理过的代码转出来方法名全是单字母，jd-gui 还会在控制流复杂的类上直接吐// INTERNAL ERROR //；三是 dex 版本，新版本 Android 工具链产出的 dex，老版 dex2jar 会直接报不认识的 magic。

那为什么还要用它？因为在“没混淆 + 单 dex + 逻辑不复杂”的样本上，它的效率确实高——转完双击打开就是一棵完整的类树，比在 smali 里翻寄存器快太多。我一般把它当成第一轮快速摸底的手段：先转出来扫一遍包结构和类名，心里有个地图，再决定哪些类值得回 apktool 去抠 smali 细节。它是侦察兵，不是主力。

2.3 auto-sign：不是链路核心，但没有它验证不了改动

严格说 auto-sign 不是“反编译工具”，它是签名脚本，通常由signapk.jar加一对测试密钥（testkey.pk8/testkey.x509.pem）组成，早期在定制系统圈子里流传很广。它的作用只有一个：给 apktool 回编译出来的未签名包盖个章，让测试机能装上。

放在链路里看，它是最后一公里的验收工具。你改完 smali、回编译成功、auto-sign签完装上去闪退，这时候才知道改动有问题；没有这一步，回编译成功只是“语法没错”，不等于“逻辑能跑”。所以它的价值不在功能强，而在闭环——把“我改对了”从猜测变成可验证的事实。

但它的局限必须说清楚：这套测试密钥是公开的，任何人拿到都能签，所以它只能用于本地验证，绝不能用于任何对外发布的场景；而且它对现代签名方案的支持有限，Android 7 之后 v2 签名普及，signapk.jar那套老流程在很多机型上会直接装不上。我给的建议很直接：新环境用 Android SDK 自带的apksigner，auto-sign只在维护老脚本、复现旧流程时保留。

3. 逐项对比：五个维度把四个工具排一遍

选型这件事最怕“凭感觉说好用”。我一般会先定维度再下结论，维度定了，结论基本是算出来的而不是吵出来的。下面这套维度是我反复用过、能真正区分工具边界的。

3.1 输入输出对照表：先看谁能吃谁

这张表最该看的是“是否双向”那一行。四个工具里只有 apktool 能把改动写回去，其它三个全是单向前进。这意味着链路的形状是“apktool 出发 → 中间工具辅助理解 → 回到 apktool 落地”，而不是四个工具平铺着让你挑。

第二该看的是“多 dex 支持”。dex2jar 在这一格上是明确的短板，它没有批量意识，你必须自己写循环。这一点在新版 App 上会被无限放大——现在随便一个中等规模应用，classes.dex到classes5.dex是常态，手动一个个转非常容易漏。

3.2 可读性与可回编译性：两条完全不同的路线

这两个指标经常被混为一谈，其实是两条互斥的路线。可读性追求“像源码”，可回编译性追求“结构无损”。jd-gui 在可读性上完胜——它输出的是 Java，有 if、有 for、有类继承，看一眼就懂；但它的产物是不可逆的，你没法把 jd-gui 的输出改完再编译回 APK，中间隔着一整层编译器和签名，语义早就变了。

apktool 正相反。smali 读起来费劲，但它是“一等公民”格式——你改一行 smali，回编译就是把这一行原样汇编回去，除了你自己改的地方，其余字节码结构完全不动。这种保真度在排查“某个开关默认值到底在哪”这类问题时是刚需，因为你要的是精确改动，不是大致理解。

所以我的实际用法是分工：理解逻辑走 jd-gui 这条线，落地修改走 apktool 这条线。两条线不互相替代，只互相印证——jd-gui 里看到某个方法大概是做什么的，再去 apktool 输出里搜对应方法名（未混淆的话）定位具体 smali，改完回编译验证。混淆样本上这条印证链会断，就只能纯靠 smali 硬读，这也是我为什么强调先跑一遍 dex2jar 摸清包结构。

3.3 多 dex、混淆、高版本 Resources：谁先翻车

三个压力场景下，四个工具的表现差异非常明显，这也是选型时最该拿真实样本去试的部分。

多 dex 场景，第一个翻车的是 dex2jar。它不是不支持，是不主动，得靠外层脚本兜。apktool 在这块最稳，不管几个 dex，全部反汇编到smali、smali_classes2、smali_classes3这一串目录里，一个不落，回编译时也自动按目录名重新打包成多个 dex，不需要你操心。

混淆场景，翻车最惨的是 jd-gui。R8 开启后常见的结果是大面积// INTERNAL ERROR //和空方法体，某些控制流平坦化的类甚至整个类都反编译不出来。dex2jar 会把类转出来，但方法名全变成a、b、c，阅读价值骤降。apktool 在这块反而是最坚挺的，smali 本来就带寄存器指令，混淆只能改名字改不了指令流，逻辑还是能顺着invoke-*一路跟下去——费时间，但跟得动。

高版本 Resources 场景，只有 apktool 会翻车，因为只有它碰资源表。新版本 aapt2 编译出的resources.arsc在结构与旧版有差异，apktool 版本偏旧就会报解析失败。这个坑的解法很单纯：升级 apktool，或者用-r参数跳过资源只解 smali。另外两三个工具压根不碰资源表，在这个场景里“不出错”不是本事，是没参与。

4. 可复现流程：从一份 APK 到可读源码和可装回包

讲完对比，落到能照着敲的流程。以下全程只针对自有应用、已获授权的测试样本，或公开渠道下载且明确允许分析的学习样本；任何情况下都不要把回编译产物对外分发，签名密钥和测试密钥的边界必须守住。

4.1 环境准备与版本对齐

这一节最容易被跳过，但它决定了后面 80% 的报错。我的习惯是先固定一组版本再动手，不在报错时临时升级工具——那样你会同时失去“哪一步出的问题”的判断力。

JDK 版本这块特别说明一句。apktool 对 JDK 8 到 17 基本都能跑，但 dex2jar 的老脚本在高版本 JDK 上会偶发NoSuchMethodError，这是因为它内部依赖的一些字节码库版本很老。如果你的机器上装了多个 JDK，用JAVA_HOME切到 8 跑 dex2jar，跑完再切回来，比折腾脚本依赖省事得多。

4.2 反编译资源与 smali

apktool 的三个参数组合覆盖了绝大多数场景，按目的选就行：

# 1) 完整拆：资源和 smali 都要，-f 覆盖已存在目录 apktool d -f -o ./out_full ./target.apk # 2) 只拆 smali：-r 跳过资源，遇上资源表解析失败时用它绕开 apktool d -f -r -o ./out_smali ./target.apk # 3) 只拆资源：-s 不反汇编 dex，纯看布局和字符串时最快 apktool d -f -s -o ./out_res ./target.apk

d是 decode，-f强制覆盖避免残留文件干扰，-o指定输出目录，-r和-s是两个方向相反的裁剪开关。-s这个参数我用得很多：只想确认某个字符串、某个布局文件、某个权限声明的时候，跳过 dex 反汇编能省一半以上时间。

拆完先别急着改，花两分钟做一次结构核对：AndroidManifest.xml能不能正常打开、res/values/strings.xml有没有乱码、smali目录数量和unzip -l target.apk | grep classes的结果对不对得上。这三个检查能提前发现大部分版本不兼容问题，比改到一半再回退要省事。

4.3 dex 转 jar 与源码阅读

多 dex 必须批量处理，手动一个个转必漏：

# 先把所有 dex 抽出来，注意引号防止 shell 提前展开 unzip -o ./target.apk 'classes*.dex' -d ./dex_all # 循环转换，输出文件名与源 dex 一一对应，便于回溯 for f in ./dex_all/classes*.dex; do bash ./d2j-dex2jar.sh "$f" -o "${f%.dex}-dex2jar.jar" --force done

unzip那一步的引号不能省，classes*.dex交给 unzip 自己展开才能匹配到classes2.dex这种带序号的成员，让 shell 展开就只会命中第一个。--force用于覆盖上次的产物，避免读到旧 jar。

转换完之后不要急着双击，先给 jd-gui 分够内存，大 jar 用默认堆会直接卡死：

# 3G 堆，视机器内存调整；打开大 jar 前先跑这条 java -Xmx3g -jar ./jd-gui.jar ./dex_all/classes-dex2jar.jar

阅读顺序上，我的习惯是先看AndroidManifest.xml里的application节点和四大组件声明，建立“这个 App 有哪些入口”的印象，再去 jd-gui 里按包名从外层往里钻。直接从MainActivity顺着调用链读容易陷进去，先有地图再走路效率高得多。

4.4 回编译、签名、装机验证

回编译本身一条命令，难的是顺序——对齐必须在签名之前，签名之后不能再动包：

# 1) 回编译，产物未签名未对齐 apktool b ./out_full -o ./patched_unsigned.apk # 2) 四字节对齐，-p 让 so 库也参与对齐，Android 上更稳 zipalign -p -f -v 4 ./patched_unsigned.apk ./patched_aligned.apk # 3) 签名，明确指定 v1 + v2 apksigner sign --ks ./demo.keystore --ks-pass pass:demo123 \ --ks-key-alias demo --v1-signing-enabled true \ --v2-signing-enabled true \ --out ./patched_signed.apk ./patched_aligned.apk # 4) 验签，确认两种方案都通过再装机 apksigner verify --print-certs ./patched_signed.apk

四步里最容易错的是第 2 步和第 3 步的顺序。zipalign会重写整个 zip 结构，如果先签名再对齐，v2 签名块会被破坏，装机时报“解析包时出现问题”而不是签名错误，很容易误判成 apktool 的问题。第 4 步的verify一定要跑，它是唯一能在装机前告诉你签名方案是否完整的检查。

如果你的环境里还留着老脚本，auto-sign的等价命令是这样：

# 旧流程：signapk + 公开测试密钥，仅限本地验证 java -jar ./signapk.jar ./testkey.x509.pem ./testkey.pk8 \ ./patched_unsigned.apk ./patched_test.apk

这套东西的前提是回编译产物已经对齐过，且测试机允许安装测试密钥签名的包。它的适用面正在快速收缩，新环境别用它当主力。

5. 避坑清单：五条踩过的坑和排查顺序

下面这五条都是我实际翻过车的，按“现象 → 原因 → 解决”写，遇到对应现象可以直接对号入座。排查顺序建议从上往下走，因为前面的坑会伪装成后面的坑。

5.1 反编译阶段：Could not decode arsc file

现象：apktool d跑到一半中断，报Could not decode arsc file或一串resource ... not found，输出目录里res/是空的或者只有一半。

原因：目标 APK 的资源表由较新版本的 aapt2 编译产出，本地 apktool 的资源解析器不认识新的表结构。厂商定制过的资源表会更容易触发，因为它们在标准结构之外还有额外字段。

解决：先升 apktool 到最新稳定版，这是九成情况的答案；升级后仍失败就加-r跳过资源只解 smali，先把逻辑分析做完，资源部分换台装了更新版本 apktool 的机器单独处理。如果只缺框架资源，用apktool if framework-res.apk先装框架文件再解。

5.2 回编译成功但装不上：INSTALL_FAILED_INVALID_APK

现象：apktool b显示构建成功，adb install报INSTALL_FAILED_INVALID_APK或者“解析包时出现问题”，换台机器还是同样结果。

原因：九成是没对齐或者签名方案缺失。apktool 的产物是“裸包”，既没有 zipalign 也没有任何签名；另一种情况是只做了 v1 签名，而目标targetSdk已经要求 v2，系统直接拒装。

解决：严格按 4.4 的顺序走一遍——先zipalign -p -f -v 4再apksigner sign，签完必须apksigner verify --print-certs确认 v2 通过。还有一种隐蔽情况是覆盖安装导致签名冲突，测试机上先卸载旧包再装，别在签名不一致的状态下反复重试。

5.3 签名这一环：auto-sign签完仍提示签名不一致

现象：用老脚本signapk.jar签完，安装时报签名冲突，或者装上去启动即闪退，日志里能看到签名校验相关的异常。

原因：公开测试密钥签出来的证书指纹和你机器上已装的同包名应用完全不同，系统按“不同签名”拒绝覆盖；另外老脚本只处理 v1，v2/v3 区域是空的，新系统会视为签名不完整。

解决：测试机上先卸载同包名的旧应用再装；长期方案是彻底切到apksigner，用自己的 keystore 签，别再用公开测试密钥。这里补一句边界：测试密钥签出来的包只能自己验证用，不要流传出去。

5.4 源码阅读：jd-gui 大面积// INTERNAL ERROR //

现象：dex2jar 转出来没报错，jd-gui 打开后大量方法体显示// INTERNAL ERROR //，或者方法体是空的、只有一行注释。

原因：三个可能叠加——R8 混淆改写了控制流、dex 版本高于 dex2jar 内部支持的范围、类文件里有 jd-gui 的反编译器处理不了的指令模式。多 dex 场景下还可能只是因为你打开的是其中一个 jar，另一部分类在别的包里。

解决：先确认是不是多 dex 漏转，把所有 jar 都打开对比一下；确认不是漏转，就换路线——直接上能读 APK 的工具（如 jadx 系列）绕开 dex2jar 这一层，或者在 apktool 输出的 smali 里按方法名反查。混淆严重的样本别在 jd-gui 上死磕，投入产出比极低。

5.5 阅读工具本身：jd-gui 打开大 jar 直接卡死

现象：双击 jar 之后界面卡住、风扇狂转，任务管理器里 Java 进程内存一路涨到顶然后被杀。

原因：jd-gui 默认堆内存偏小，且打开时会尝试索引 jar 内全部类，几万个类的包直接把堆吃满。

解决：用java -Xmx3g -jar jd-gui.jar显式给堆，机器内存够就给到 4G；还是慢就把 jar 拆开分批看，或者改用按需加载的阅读器。这个坑不影响分析结论，纯粹是工具配置问题，但第一次遇到很容易误以为包损坏了。

6. 收尾：一条命令模板和我的固定检查顺序

把上面所有内容压成一个可复用的动作序列，我平时就是这么跑的，一次贴完：

# 0) 先看包结构：dex 数量、so 架构、资源规模 unzip -l ./target.apk | grep -E 'classes.*dex|lib/' # 1) 完整拆包 apktool d -f -o ./out_full ./target.apk # 2) 批量转 dex → jar unzip -o ./target.apk 'classes*.dex' -d ./dex_all for f in ./dex_all/classes*.dex; do bash ./d2j-dex2jar.sh "$f" -o "${f%.dex}-dex2jar.jar" --force done # 3) 改完回编译 → 对齐 → 签名 → 验签 → 装 apktool b ./out_full -o ./patched_unsigned.apk zipalign -p -f -v 4 ./patched_unsigned.apk ./patched_aligned.apk apksigner sign --ks ./demo.keystore --ks-pass pass:demo123 \ --ks-key-alias demo --out ./patched_signed.apk ./patched_aligned.apk apksigner verify --print-certs ./patched_signed.apk adb install -r ./patched_signed.apk

这段脚本真正的价值不在命令本身，而在顺序。第 0 步的unzip -l是我后来才加上的，加了之后省掉大量返工——先知道有几个 dex、有没有 so、资源目录多大，再决定用-r还是-s，比上来就完整拆要理性得多。第 3 步里zipalign和apksigner的先后关系也不能反，反了就是前面说的那个“解析包时出现问题”的坑。

最后说一个判断上的习惯。这四个工具里，apktool 是唯一值得你花时间研究参数和版本演进的，因为它同时承担拆和装；dex2jar 和 jd-gui 只需要会用、会批量、会调内存就够，遇到反编译失败不要试图修工具，直接换路线；auto-sign 只当历史包袱处理，新环境一律用apksigner。把这层权重分清之后，选型就不再是“哪个更强”的问题，而是“哪一段该投入精力”。

从那以后我每次拿到一份新 APK，都强制走一遍“先 unzip 看结构、再 apktool 拆、最后才动 smali”的顺序，哪怕再急也不跳步。跳过第 0 步省下的两分钟，通常会在后面以半小时的返工还回来。希望帮到你。

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