简介面向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、资源、smaliAPK 本质是个 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 主流工具能力和边界工具负责层典型产物强项弱项jadxDEX → Java 源码可阅读的 .java 文件直接看业务逻辑支持按类跳转混淆代码可读性差需要配合 --deobfapktoolAPK → smali 资源smali 目录、可回编译的资源唯一能稳定回编译资源的工具产出的是 smali不是 Java改起来门槛高AndroidKiller集成 GUI源码、smali、重打包 APK新手友好界面操作简单编码问题多乱码频发对新系统兼容差dex2jar jd-guiDEX → jar → Java.jar .java老方案对付老 APK 稳定对新 DEX 特性支持差维护基本停滞Android Studio APK Analyzer只读分析DEX、资源、清单的可视化视图官方自带分析签名和 DEX 结构方便不能反编译回源码不能重打包这个表说白了就是给你划边界想快速读懂一个包的逻辑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.apkkeytool生成一个新的签名证书-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 打开同一个 APKjadx 对编码处理更规范不会有这个问题。我的习惯是只要涉及中文资源或者中文注释一律用 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 拆资源。反编译工具从来不是越新越全能而是组合越顺手越可靠。改完的产物验证完就删掉尤其是有版权风险的样本留在磁盘上没有任何好处。希望帮到你。本文还有配套的精品资源点击获取