简介面向Android开发与逆向分析学习者的APK反编译工具合集整合apktool、auto-sign、dex2jar与jd-gui四类常用组件覆盖从解包、资源还原、重新签名到DEX转JAR、源码查看的完整链路适合具备一定Android基础、希望研究应用实现或开展安全审计的开发者使用。压缩包为rar格式共58个文件约10.58MB以bat与sh批处理脚本、jar工具包为主辅以exe可执行程序、txt说明文档及签名所需的pem、pk8密钥文件脚本与工具分目录存放便于按流程调用。已有13976人学习下载说明该组合在逆向入门场景中认可度较高。资源将解编译、签名、格式转换与图形化查看等环节的工具集中打包省去逐个搜集配置的麻烦读者可据此搭建本地分析环境理解APK内部结构与资源组织方式并借助jd-gui直观浏览反编译代码为后续的代码研读与安全检测提供便利。1. 拿到一个 APK 之后反编译工具链到底能帮你做什么一个只有安装包的 APK 摆在面前你想知道它用了什么加固、资源里藏了哪些配置、某个按钮点击后走了哪条逻辑光靠解压看classes.dex是看不出东西的。APK 反编译工具链解决的正是这个断层把二进制字节码还原成可读的 smali 或 Java 近似代码把resources.arsc和AndroidManifest.xml解成明文再配合签名工具把改过的包重新装回设备验证。apktool、dex2jar、jd-gui、auto-sign 这几个名字经常一起出现但它们各自负责的环节并不相同混着用很容易在第一步就翻车。这套资源适合做安卓逆向入门、安全自查、老项目排障的从业者也适合需要读懂第三方 SDK 行为再决定要不要接的开发者。下面按「先立住原理、再跑通流程、最后说清坑」的顺序拆开讲每一步都给到能直接抄的命令和参数。2. 工具链分工apktool、dex2jar、jd-gui 各自管哪一段很多人把反编译当成一个动作实际它是三段流水线解包与资源还原、字节码转 Java、代码阅读与修改回编。apktool 管第一段和回编dex2jar 管第二段jd-gui 管第三段的阅读。auto-sign 不属于反编译它负责把改完的包重新签名让设备愿意安装。理解这条链的边界后面排错才有方向。2.1 apktool 的 decode 与 build 双向能力apktool 的核心价值是「可逆」decode把 APK 拆成 smali 目录、res资源目录、AndroidManifest.xml明文和apktool.yml元信息build再把这些目录按原结构压回 APK。它不负责把 smali 变成 Java那是 dex2jar 的活。常见做法是先 decode 看资源和清单确认目标后再决定是改 smali 还是走 dex2jar 读逻辑。# 基础解包-f 覆盖已有输出目录-o 指定输出路径 apktool d target.apk -f -o ./decoded # 只解资源、跳过 dex用于快速看清单和 res速度更快 apktool d target.apk -s -f -o ./decoded_res # 改完后回编-o 指定产物名 apktool b ./decoded -o rebuilt.apk-f是强制覆盖反复调试时必加否则第二次 decode 会因目录存在直接退出。-s表示 skip sources只保留资源不处理 dex适合只想看AndroidManifest.xml里权限、组件、android:exported配置的场景。-o不给会默认输出到以 APK 名命名的目录容易和旧产物混在一起。回编阶段如果 smali 有语法错误b会在对应文件行号报错这时不要急着改代码先确认是不是 decode 时用了不匹配的 apktool 版本导致框架资源对不上。2.2 dex2jar 把 dex 转成 jar 的边界dex2jar 做的是 dex 字节码到 JVM class 文件的翻译产物是 jar不是源码。它不理解安卓框架特有的调用也不还原混淆后的名字所以转出来的 jar 里方法名可能是a、b、c。它的价值在于让 jd-gui 这类 Java 反编译器能读从而快速定位字符串、常量、控制流而不是拿到能直接编译的工程。# 单个 dex 转换输出默认在同目录同名 .jar d2j-dex2jar.sh classes.dex -o classes.jar # 多 dex 场景APK 里常见 classes.dex、classes2.dex逐个转 d2j-dex2jar.sh classes2.dex -o classes2.jar # 直接对 APK 转工具会自动找内部 dex d2j-dex2jar.sh target.apk -o target.jar-o指定输出 jar 名多 dex 时建议按 dex 序号分开命名否则后一个会覆盖前一个。直接对 APK 转看起来省事但遇到加固包或 dex 被抽离的情况会失败这时要先确认 APK 里classes.dex是否真实存在、大小是否异常。转换报Detail: failed to load多半是 dex 版本或工具版本不匹配换一个较新的 dex2jar 版本再试别在旧版本上反复折腾。2.3 jd-gui 阅读与 auto-sign 回装的分界jd-gui 是图形化 Java 反编译器打开 jar 后按包结构展示类适合快速跳转和搜索字符串。它不做修改改代码要回到 smali 层用文本编辑器动或者用 apktool 回编。auto-sign 则是把回编后的 APK 用测试证书签名让设备接受安装。这条分界要记牢jd-gui 里看到的是「近似源码」不能直接改完编译回去真正能回编的是 smali。工具输入输出主要用途能否回编apktoolAPKsmali res 明文清单资源还原、smali 修改、回编能dex2jardex / APKjar供 Java 反编译器读取不能jd-guijar可读 Java 近似代码阅读、搜索、定位逻辑不能auto-sign未签名 APK已签名 APK测试安装不涉及这张表决定了工作流要看逻辑走 dex2jar jd-gui要改行为走 apktool decode 改 smali 再 build最后 auto-sign 签名安装。把 jd-gui 里看到的代码当成「能改的源码」是新手最常见的误判改完发现没有对应的编译入口白忙一场。3. 跑通一条完整链路从解包到重签装的实操步骤原理清楚后落地要按顺序走每一步的产物是下一步的输入跳步就会在中间卡住。下面以「改一个资源字符串并重新装回设备验证」为例把命令、参数和检查点串起来。这套流程在模拟项目上反复跑过步骤稳定但每一步都有需要盯住的细节。3.1 解包并确认清单与资源结构第一步永远是 decode 后先读AndroidManifest.xml和apktool.yml。清单里看package、versionCode、application的android:name是否加固入口、四大组件的exported配置apktool.yml里看minSdkVersion、targetSdkVersion和doNotCompress列表后者影响回编后资源能否被正确读取。apktool d target.apk -f -o ./decoded # 读清单关键字段 grep -E package|versionCode|android:name\.*Application ./decoded/AndroidManifest.xml # 看 apktool 记录的 SDK 与压缩规则 cat ./decoded/apktool.ymlgrep这行只是快速定位完整清单还是建议用编辑器打开看组件声明。apktool.yml里的doNotCompress很关键如果原包某些资源不压缩回编时被压了运行时就可能读不到。decode 阶段一般不用手动改它但如果你替换了资源文件类型要回头确认这个列表是否还匹配。检查点decoded目录下应同时存在smali、res、AndroidManifest.xml、apktool.yml缺smali说明用了-s或原包 dex 异常。3.2 用 dex2jar jd-gui 定位目标逻辑资源改完往往还要确认代码里有没有对某个字符串做校验这时走 dex2jar。先从解包目录里找 dex 文件逐个转换再用 jd-gui 打开 jar 搜索关键字。# 列出解包目录里的 dex find ./decoded -maxdepth 1 -name *.dex # 逐个转换保留序号 for f in ./decoded/classes*.dex; do base$(basename $f .dex) d2j-dex2jar.sh $f -o ./jars/${base}.jar donefind的-maxdepth 1避免误扫子目录。循环里用basename取文件名去掉.dex作为 jar 名保证多 dex 不互相覆盖。转换完成后用 jd-gui 打开./jars下的 jar搜索目标字符串或方法名。注意jd-gui 搜索到的是近似代码变量名可能被混淆成a、b要结合调用栈和字符串常量反推语义不要指望看到原始命名。检查点jar 能正常打开且类数量与 dex 规模匹配若打开后大量// INTERNAL ERROR说明该 dex 用了较新的字节码特性换 jd-gui 版本或改用 smali 直接读。3.3 改 smali 或资源后回编与签名真正要改行为时回到 smali。比如把某个判断分支的if-eqz改成if-nez或者替换res/values/strings.xml里的文案。改完执行 build再用 auto-sign 签名。# 回编产物为未签名 APK apktool b ./decoded -o ./rebuilt.apk # 用测试证书签名auto-sign 脚本通常接受输入和输出两个参数 ./sign.sh ./rebuilt.apk ./rebuilt-signed.apk # 验证签名与对齐 apksigner verify --verbose ./rebuilt-signed.apk zipalign -c -v 4 ./rebuilt-signed.apkapktool b的-o指定产物路径不指定会输出到decoded/dist/下。签名脚本的参数顺序各版本可能不同跑之前先看脚本头部注释或用--help。apksigner verify用来确认签名有效zipalign -c检查 4 字节对齐未对齐的包在部分设备上安装会报INSTALL_PARSE_FAILED。检查点verify 输出Verifies且 zipalign 返回成功再执行adb install -r。如果安装报INSTALL_FAILED_UPDATE_INCOMPATIBLE说明设备上已有同包名不同签名的版本先卸载旧包再装。4. 避坑与排查反编译链路上最容易翻车的五件事这条链路每一步都有「看起来成功、实际不可用」的陷阱下面五条是按出现频率排的每条按现象、原因、解决写照着对能省不少时间。4.1 回编报资源找不到框架版本不匹配现象apktool b在res/values或AndroidManifest.xml处报resource not found或No resource identifier found。原因decode 用的 apktool 版本与目标 APK 的框架资源版本不一致常见于 targetSdk 较高的包用旧版 apktool 解。解决换用较新的 apktool 重新 decode不要在原目录上硬改如果必须用旧版先apktool if安装对应框架资源再 decode。血泪经验是别在报错目录里反复 build越改越乱直接重新解一遍最省事。4.2 dex2jar 转换成功但 jd-gui 打开全是错误现象jar 生成成功jd-gui 打开后大量类显示// INTERNAL ERROR或空白。原因dex 使用了较新的字节码指令或混淆强度高jd-gui 的反编译引擎跟不上。解决优先改用 smali 直接读逻辑smali 是字节码的直译不会因反编译失败而丢信息确需 Java 视图时换 jd-gui 的维护版本或改用其他 Java 反编译前端打开同一个 jar。注意这不是 dex2jar 失败转换本身是成功的问题在阅读端。4.3 签名后安装被拒v2 签名与对齐顺序现象adb install报INSTALL_PARSE_FAILED_NO_CERTIFICATES或INSTALL_FAILED_INVALID_APK。原因先签名后 zipalign 会破坏 v2 签名块正确顺序是先对齐再签名或者只用了 v1 签名而目标设备要求 v2。解决zipalign -f 4 in.apk out.apk之后再apksigner sign不要用旧式jarsigner单独签。auto-sign 脚本若内部顺序反了手动按「对齐→签名→verify」走一遍。4.4 改完 smali 运行崩溃寄存器数不匹配现象回编安装成功启动即崩logcat 报VerifyError或Invalid register。原因在 smali 方法里新增指令时用了超出.registers声明范围的寄存器号或move-result没有紧跟在调用指令后。解决改之前先看方法头的.registers或.locals数值新增逻辑优先复用已有寄存器invoke之后取返回值必须紧跟move-result中间插指令会校验失败。改完用apktool b能过不代表运行能过必须装到设备看 logcat。4.5 加固包 decode 出来 smali 是空壳现象decode 成功但smali目录里类很少classes.dex体积异常小运行逻辑都在 native 层或动态加载。原因目标包做了加固真实 dex 被抽离或加密apktool 只能解出壳代码。解决这类包不适合走「decode 改 smali」路线先确认application的android:name是否指向加固入口再决定是否放弃静态改法。不要在没有确认加固的情况下反复调 apktool 参数那不是参数问题。5. 进阶把工具链固化成可复用的检查脚本单次手工跑一遍不难难的是每次拿到新包都能稳定复现同一套检查。我一般会把 decode、dex 转换、清单关键字段提取写成一个小脚本产物按包名和时间戳分目录避免不同包互相污染。下面这段是常用的骨架参数集中在顶部改包名就能跑。#!/usr/bin/env bash set -euo pipefail APK$1 WORK./work/$(basename $APK .apk)-$(date %Y%m%d%H%M%S) mkdir -p $WORK/jars # 1. 解包保留 smali 与资源 apktool d $APK -f -o $WORK/decoded # 2. 提取清单关键字段输出到报告 { echo manifest grep -E package|versionCode|versionName $WORK/decoded/AndroidManifest.xml || true echo exported components grep -B2 android:exported\true\ $WORK/decoded/AndroidManifest.xml || true } $WORK/report.txt # 3. 多 dex 转 jar shopt -s nullglob for f in $WORK/decoded/classes*.dex; do base$(basename $f .dex) d2j-dex2jar.sh $f -o $WORK/jars/${base}.jar done echo done: $WORKset -euo pipefail让脚本在任一步失败时立即停避免半成品目录被误当成功。WORK目录用包名加时间戳保证多次运行不覆盖。grep -B2取exportedtrue前两行是为了把组件标签一起带出来方便判断是 Activity 还是 Service。shopt -s nullglob防止没有 dex 时循环把字面量classes*.dex当文件名传给 dex2jar。这段脚本只做「解包 报告 转 jar」签名和回编故意不放进来自动化因为改代码这一步需要人判断自动回编容易把错误产物当成功。验证脚本是否可靠看三个点report.txt里package和versionCode是否与安装包信息一致jars目录下 jar 数量是否等于 dex 数量decoded/smali是否非空。三个都过再进入人工阅读环节。从那以后我每次拿到新包都先跑一遍这个骨架确认基线再动手改省掉了很多「改到一半发现解包就不完整」的返工。希望帮到你。本文还有配套的精品资源点击获取
简介面向Android开发与逆向分析学习者的APK反编译工具合集整合apktool、auto-sign、dex2jar与jd-gui四类常用组件覆盖从解包、资源还原、重新签名到DEX转JAR、源码查看的完整链路适合具备一定Android基础、希望研究应用实现或开展安全审计的开发者使用。压缩包为rar格式共58个文件约10.58MB以bat与sh批处理脚本、jar工具包为主辅以exe可执行程序、txt说明文档及签名所需的pem、pk8密钥文件脚本与工具分目录存放便于按流程调用。已有13976人学习下载说明该组合在逆向入门场景中认可度较高。资源将解编译、签名、格式转换与图形化查看等环节的工具集中打包省去逐个搜集配置的麻烦读者可据此搭建本地分析环境理解APK内部结构与资源组织方式并借助jd-gui直观浏览反编译代码为后续的代码研读与安全检测提供便利。1. 拿到一个 APK 之后反编译工具链到底能帮你做什么一个只有安装包的 APK 摆在面前你想知道它用了什么加固、资源里藏了哪些配置、某个按钮点击后走了哪条逻辑光靠解压看classes.dex是看不出东西的。APK 反编译工具链解决的正是这个断层把二进制字节码还原成可读的 smali 或 Java 近似代码把resources.arsc和AndroidManifest.xml解成明文再配合签名工具把改过的包重新装回设备验证。apktool、dex2jar、jd-gui、auto-sign 这几个名字经常一起出现但它们各自负责的环节并不相同混着用很容易在第一步就翻车。这套资源适合做安卓逆向入门、安全自查、老项目排障的从业者也适合需要读懂第三方 SDK 行为再决定要不要接的开发者。下面按「先立住原理、再跑通流程、最后说清坑」的顺序拆开讲每一步都给到能直接抄的命令和参数。2. 工具链分工apktool、dex2jar、jd-gui 各自管哪一段很多人把反编译当成一个动作实际它是三段流水线解包与资源还原、字节码转 Java、代码阅读与修改回编。apktool 管第一段和回编dex2jar 管第二段jd-gui 管第三段的阅读。auto-sign 不属于反编译它负责把改完的包重新签名让设备愿意安装。理解这条链的边界后面排错才有方向。2.1 apktool 的 decode 与 build 双向能力apktool 的核心价值是「可逆」decode把 APK 拆成 smali 目录、res资源目录、AndroidManifest.xml明文和apktool.yml元信息build再把这些目录按原结构压回 APK。它不负责把 smali 变成 Java那是 dex2jar 的活。常见做法是先 decode 看资源和清单确认目标后再决定是改 smali 还是走 dex2jar 读逻辑。# 基础解包-f 覆盖已有输出目录-o 指定输出路径 apktool d target.apk -f -o ./decoded # 只解资源、跳过 dex用于快速看清单和 res速度更快 apktool d target.apk -s -f -o ./decoded_res # 改完后回编-o 指定产物名 apktool b ./decoded -o rebuilt.apk-f是强制覆盖反复调试时必加否则第二次 decode 会因目录存在直接退出。-s表示 skip sources只保留资源不处理 dex适合只想看AndroidManifest.xml里权限、组件、android:exported配置的场景。-o不给会默认输出到以 APK 名命名的目录容易和旧产物混在一起。回编阶段如果 smali 有语法错误b会在对应文件行号报错这时不要急着改代码先确认是不是 decode 时用了不匹配的 apktool 版本导致框架资源对不上。2.2 dex2jar 把 dex 转成 jar 的边界dex2jar 做的是 dex 字节码到 JVM class 文件的翻译产物是 jar不是源码。它不理解安卓框架特有的调用也不还原混淆后的名字所以转出来的 jar 里方法名可能是a、b、c。它的价值在于让 jd-gui 这类 Java 反编译器能读从而快速定位字符串、常量、控制流而不是拿到能直接编译的工程。# 单个 dex 转换输出默认在同目录同名 .jar d2j-dex2jar.sh classes.dex -o classes.jar # 多 dex 场景APK 里常见 classes.dex、classes2.dex逐个转 d2j-dex2jar.sh classes2.dex -o classes2.jar # 直接对 APK 转工具会自动找内部 dex d2j-dex2jar.sh target.apk -o target.jar-o指定输出 jar 名多 dex 时建议按 dex 序号分开命名否则后一个会覆盖前一个。直接对 APK 转看起来省事但遇到加固包或 dex 被抽离的情况会失败这时要先确认 APK 里classes.dex是否真实存在、大小是否异常。转换报Detail: failed to load多半是 dex 版本或工具版本不匹配换一个较新的 dex2jar 版本再试别在旧版本上反复折腾。2.3 jd-gui 阅读与 auto-sign 回装的分界jd-gui 是图形化 Java 反编译器打开 jar 后按包结构展示类适合快速跳转和搜索字符串。它不做修改改代码要回到 smali 层用文本编辑器动或者用 apktool 回编。auto-sign 则是把回编后的 APK 用测试证书签名让设备接受安装。这条分界要记牢jd-gui 里看到的是「近似源码」不能直接改完编译回去真正能回编的是 smali。工具输入输出主要用途能否回编apktoolAPKsmali res 明文清单资源还原、smali 修改、回编能dex2jardex / APKjar供 Java 反编译器读取不能jd-guijar可读 Java 近似代码阅读、搜索、定位逻辑不能auto-sign未签名 APK已签名 APK测试安装不涉及这张表决定了工作流要看逻辑走 dex2jar jd-gui要改行为走 apktool decode 改 smali 再 build最后 auto-sign 签名安装。把 jd-gui 里看到的代码当成「能改的源码」是新手最常见的误判改完发现没有对应的编译入口白忙一场。3. 跑通一条完整链路从解包到重签装的实操步骤原理清楚后落地要按顺序走每一步的产物是下一步的输入跳步就会在中间卡住。下面以「改一个资源字符串并重新装回设备验证」为例把命令、参数和检查点串起来。这套流程在模拟项目上反复跑过步骤稳定但每一步都有需要盯住的细节。3.1 解包并确认清单与资源结构第一步永远是 decode 后先读AndroidManifest.xml和apktool.yml。清单里看package、versionCode、application的android:name是否加固入口、四大组件的exported配置apktool.yml里看minSdkVersion、targetSdkVersion和doNotCompress列表后者影响回编后资源能否被正确读取。apktool d target.apk -f -o ./decoded # 读清单关键字段 grep -E package|versionCode|android:name\.*Application ./decoded/AndroidManifest.xml # 看 apktool 记录的 SDK 与压缩规则 cat ./decoded/apktool.ymlgrep这行只是快速定位完整清单还是建议用编辑器打开看组件声明。apktool.yml里的doNotCompress很关键如果原包某些资源不压缩回编时被压了运行时就可能读不到。decode 阶段一般不用手动改它但如果你替换了资源文件类型要回头确认这个列表是否还匹配。检查点decoded目录下应同时存在smali、res、AndroidManifest.xml、apktool.yml缺smali说明用了-s或原包 dex 异常。3.2 用 dex2jar jd-gui 定位目标逻辑资源改完往往还要确认代码里有没有对某个字符串做校验这时走 dex2jar。先从解包目录里找 dex 文件逐个转换再用 jd-gui 打开 jar 搜索关键字。# 列出解包目录里的 dex find ./decoded -maxdepth 1 -name *.dex # 逐个转换保留序号 for f in ./decoded/classes*.dex; do base$(basename $f .dex) d2j-dex2jar.sh $f -o ./jars/${base}.jar donefind的-maxdepth 1避免误扫子目录。循环里用basename取文件名去掉.dex作为 jar 名保证多 dex 不互相覆盖。转换完成后用 jd-gui 打开./jars下的 jar搜索目标字符串或方法名。注意jd-gui 搜索到的是近似代码变量名可能被混淆成a、b要结合调用栈和字符串常量反推语义不要指望看到原始命名。检查点jar 能正常打开且类数量与 dex 规模匹配若打开后大量// INTERNAL ERROR说明该 dex 用了较新的字节码特性换 jd-gui 版本或改用 smali 直接读。3.3 改 smali 或资源后回编与签名真正要改行为时回到 smali。比如把某个判断分支的if-eqz改成if-nez或者替换res/values/strings.xml里的文案。改完执行 build再用 auto-sign 签名。# 回编产物为未签名 APK apktool b ./decoded -o ./rebuilt.apk # 用测试证书签名auto-sign 脚本通常接受输入和输出两个参数 ./sign.sh ./rebuilt.apk ./rebuilt-signed.apk # 验证签名与对齐 apksigner verify --verbose ./rebuilt-signed.apk zipalign -c -v 4 ./rebuilt-signed.apkapktool b的-o指定产物路径不指定会输出到decoded/dist/下。签名脚本的参数顺序各版本可能不同跑之前先看脚本头部注释或用--help。apksigner verify用来确认签名有效zipalign -c检查 4 字节对齐未对齐的包在部分设备上安装会报INSTALL_PARSE_FAILED。检查点verify 输出Verifies且 zipalign 返回成功再执行adb install -r。如果安装报INSTALL_FAILED_UPDATE_INCOMPATIBLE说明设备上已有同包名不同签名的版本先卸载旧包再装。4. 避坑与排查反编译链路上最容易翻车的五件事这条链路每一步都有「看起来成功、实际不可用」的陷阱下面五条是按出现频率排的每条按现象、原因、解决写照着对能省不少时间。4.1 回编报资源找不到框架版本不匹配现象apktool b在res/values或AndroidManifest.xml处报resource not found或No resource identifier found。原因decode 用的 apktool 版本与目标 APK 的框架资源版本不一致常见于 targetSdk 较高的包用旧版 apktool 解。解决换用较新的 apktool 重新 decode不要在原目录上硬改如果必须用旧版先apktool if安装对应框架资源再 decode。血泪经验是别在报错目录里反复 build越改越乱直接重新解一遍最省事。4.2 dex2jar 转换成功但 jd-gui 打开全是错误现象jar 生成成功jd-gui 打开后大量类显示// INTERNAL ERROR或空白。原因dex 使用了较新的字节码指令或混淆强度高jd-gui 的反编译引擎跟不上。解决优先改用 smali 直接读逻辑smali 是字节码的直译不会因反编译失败而丢信息确需 Java 视图时换 jd-gui 的维护版本或改用其他 Java 反编译前端打开同一个 jar。注意这不是 dex2jar 失败转换本身是成功的问题在阅读端。4.3 签名后安装被拒v2 签名与对齐顺序现象adb install报INSTALL_PARSE_FAILED_NO_CERTIFICATES或INSTALL_FAILED_INVALID_APK。原因先签名后 zipalign 会破坏 v2 签名块正确顺序是先对齐再签名或者只用了 v1 签名而目标设备要求 v2。解决zipalign -f 4 in.apk out.apk之后再apksigner sign不要用旧式jarsigner单独签。auto-sign 脚本若内部顺序反了手动按「对齐→签名→verify」走一遍。4.4 改完 smali 运行崩溃寄存器数不匹配现象回编安装成功启动即崩logcat 报VerifyError或Invalid register。原因在 smali 方法里新增指令时用了超出.registers声明范围的寄存器号或move-result没有紧跟在调用指令后。解决改之前先看方法头的.registers或.locals数值新增逻辑优先复用已有寄存器invoke之后取返回值必须紧跟move-result中间插指令会校验失败。改完用apktool b能过不代表运行能过必须装到设备看 logcat。4.5 加固包 decode 出来 smali 是空壳现象decode 成功但smali目录里类很少classes.dex体积异常小运行逻辑都在 native 层或动态加载。原因目标包做了加固真实 dex 被抽离或加密apktool 只能解出壳代码。解决这类包不适合走「decode 改 smali」路线先确认application的android:name是否指向加固入口再决定是否放弃静态改法。不要在没有确认加固的情况下反复调 apktool 参数那不是参数问题。5. 进阶把工具链固化成可复用的检查脚本单次手工跑一遍不难难的是每次拿到新包都能稳定复现同一套检查。我一般会把 decode、dex 转换、清单关键字段提取写成一个小脚本产物按包名和时间戳分目录避免不同包互相污染。下面这段是常用的骨架参数集中在顶部改包名就能跑。#!/usr/bin/env bash set -euo pipefail APK$1 WORK./work/$(basename $APK .apk)-$(date %Y%m%d%H%M%S) mkdir -p $WORK/jars # 1. 解包保留 smali 与资源 apktool d $APK -f -o $WORK/decoded # 2. 提取清单关键字段输出到报告 { echo manifest grep -E package|versionCode|versionName $WORK/decoded/AndroidManifest.xml || true echo exported components grep -B2 android:exported\true\ $WORK/decoded/AndroidManifest.xml || true } $WORK/report.txt # 3. 多 dex 转 jar shopt -s nullglob for f in $WORK/decoded/classes*.dex; do base$(basename $f .dex) d2j-dex2jar.sh $f -o $WORK/jars/${base}.jar done echo done: $WORKset -euo pipefail让脚本在任一步失败时立即停避免半成品目录被误当成功。WORK目录用包名加时间戳保证多次运行不覆盖。grep -B2取exportedtrue前两行是为了把组件标签一起带出来方便判断是 Activity 还是 Service。shopt -s nullglob防止没有 dex 时循环把字面量classes*.dex当文件名传给 dex2jar。这段脚本只做「解包 报告 转 jar」签名和回编故意不放进来自动化因为改代码这一步需要人判断自动回编容易把错误产物当成功。验证脚本是否可靠看三个点report.txt里package和versionCode是否与安装包信息一致jars目录下 jar 数量是否等于 dex 数量decoded/smali是否非空。三个都过再进入人工阅读环节。从那以后我每次拿到新包都先跑一遍这个骨架确认基线再动手改省掉了很多「改到一半发现解包就不完整」的返工。希望帮到你。本文还有配套的精品资源点击获取
