简介面向安卓应用逆向分析与安全评估的工具合集整合了apktool、dex2jar、jd-gui、autosign等社区常用组件覆盖APK资源反编译、DEX字节码转换、Java源码查看和自动重签名等典型场景。压缩包共69个文件以18个jar工具库、17个bat、14个sh脚本及8个exe可执行程序为主附带txt说明与签名证书文件整体仅15.21MB便于快速部署。借助这套工具读者可完整走通“APK反解→dex2jar转码→JD-GUI阅读→autosign重新签名”的流程既能学习他人代码实现、排查问题也能在合规前提下开展安全审计与加固验证。已有144人学习下载适合有一定Java/Android基础、希望深入理解应用内部结构的开发者和安全爱好者。1. android逆向助手别一把梭先把三个工具的主次分清拿到一个 APK 想做点分析很多人第一反应是把 apktool、dex2jar、jd-gui 全装一遍然后对着同一份文件轮流试试不出来就换下一个。这种做法其实是在浪费时间因为这三个工具根本不是平级关系而是同一套流水线上不同环节的机器。apktool 负责拆壳和打包dex2jar 负责把 DEX 字节码转成 Java 可读的 Jarjd-gui 负责让你像看源码一样翻代码。各有各的用途也各有各的边界连起来用才是完整的 android 逆向链路拆开单用往往卡在中间某一步。这篇就把这套链路的搭建顺序、工具选择依据和容易翻车的细节一次讲清楚给两类人看一是刚开始学反编译、想知道从哪入手的二是已经碰过这几个工具、但总在某些环节踩坑的老手。前者能照着步骤走完一遍拿到可用的代码后者能明白失败时该往哪个方向查。2. 搭建反编译链路apktool 拆壳、dex2jar 转换、jd-gui 读码2.1 先拆资源包apktool 的拆解与回编译apktool 在这套链路口干的是最粗的活把一个 APK 当成 zip 解开把二进制 XML 转成明文 XML把资源文件按原始目录结构摆出来。它不负责还原 Java 代码它还原的是应用的骨架和脸面。最常见的用法是解码整个 APK# target.apk 是要分析的样本out_dir 是输出目录 apktool d target.apk -o out_dird代表 decode-o指定输出目录。跑完后 out_dir 里会出现 AndroidManifest.xml明文版、smali 目录DEX 反汇编后的汇编代码、res 资源目录和 apktool.yml。这里要强调一件事apktool 的d模式默认输出的是 smali不是 Java。很多人误以为用了 apktool 就能看到 Java 源码看到一屏的 smali 就懵了。smali 是寄存器和指令级的中间表示能读懂它属于进阶技能新手阶段不需要硬啃直接把它当「DEX 的可读备份」就好。真正要读 Java 逻辑走 dex2jar 那条路。与之相对的是回编译也就是b模式# 修改过 out_dir 里的资源或 smali 后重新打包成 APK apktool b out_dir -o rebuilt.apk回编译最典型的用途是做二次修改比如改应用名、换图标、改某个 smali 里的判断逻辑。但回编译对环境的依赖比拆解大得多它依赖系统里安装的框架资源版本后面避坑章节会专门说这个问题。如果你只是想做阅读分析拆解 转换两条命令就够了不用碰回编译。2.2 DEX 转 Jardex2jar 的两种常见入口dex2jar 做的事一句话概括把 APK 里的 classes.dex可能有多个转成 .jar 文件让 Java 世界里那些现成的反编译器能读进去。它是连接字节码和可读源码的桥梁。常用命令有两种入口。第一种针对单独的 dex 文件# 先解压 APK 取出 classes.dex或者直接用 apktool 输出的文件 unzip target.apk -d apk_unziped # 转换单个 dex d2j-dex2jar.sh apk_unziped/classes.dex -o output.jar第二种更省事直接对整个 APK 操作# dex2jar 自己会处理 APK 里的 dex 文件 d2j-dex2jar.sh target.apk -o output.jar两种方式的区别在于如果你只有一个 dex 文件方式一够用如果 APK 里有多个 dex比如 multidex 分包方式二会自动识别全部并合并输出到一个 jar省去手动多次调用。需要注意-o参数指定输出文件名不写的话 dex2jar 会按输入文件同名生成一个 .jar。从实践看我一般建议每次都用-o显式命名否则输出文件容易和原始文件混在一个目录里后面 jd-gui 打开时容易拿错文件。转换完成后output.jar 里就是 class 文件。到这一步离 Java 源码只差一个反编译器。这个 jar 也可以直接用 jd-gui 打开也可以丢给其他 Java 反编译工具但整条链路里 jd-gui 和 dex2jar 的配合最顺滑因为两者对同一套类文件格式的理解是一致的换别的工具偶尔会遇到类解析不一致导致的空白类。2.3 jd-gui 读码阅读还原后代码的正确姿势jd-gui 是这条链路最后一步的阅读器。它把 class 文件反汇编成接近原始 Java 源码的样子显示在图形界面里。到这步才算真正「看到代码」。打开 jd-gui 之后直接把上一步输出的 output.jar 拖进去即可。左侧是包结构和类列表右侧是源码。我一般会先做三件事第一看 AndroidManifest 里注册的组件理清入口第二搜关键字符串比如接口地址、密钥相关字段第三看 BuildConfig 或者 Application 子类的 onCreate找全局逻辑。jd-gui 也有一些短板代码里用到混淆后的短类名时文件名和类名对不上跳转容易错乱部分复杂泛型或 switch 语句反编译后会变成诡异的写法但逻辑通常能看懂。它不适合做大规模代码搜索因为打开大文件时会有卡顿定位逻辑更推荐用命令行 grep 配合源码文本后面第 6 章会单独给出一套可抄的搜索技巧。这里补充一个常见误区有人拿到 jar 后不看 jd-gui而是直接解压 jar 看 .class 文件再用 javap 看字节码。javap 给的是 JVM 指令级信息和 smali 一个层级适合排查具体方法的字节码行为不适合通读业务逻辑。通读用 jd-gui深挖单点用 javap两者不是替代关系。这条链路默认走 jd-gui只有在 jd-gui 反编译出错、某段代码完全不可读时才降级看 javap 或 smali。整条链路搭起来就这么三步apktool 拆出资源和清单dex2jar 把 DEX 转成 Jarjd-gui 把 Jar 还原成 Java。工具的先后顺序是硬性的不能换但选型时有几个细节会影响最终效果下一章做逐项对比。3. 三个工具逐项对比从还原度、效率、容错看差距3.1 反编译还原度对比谁更能还原真实逻辑还原度是选型时最容易产生错觉的维度。很多接触 android 逆向不久的人以为 apktool 还原的是资源dex2jar 还原的是 Javajd-gui 只是查看器所以还原度应该由 dex2jar 单方面承担。实际不是这样三个工具各自管一段还原度要分三段看谁拖后腿都不行。环节工具输出产物还原目标常见还原失败表现清单/资源apktoolXML res结构完整可读XML 乱码、资源缺失字节码转换dex2jarJar/class类结构完整类缺失、方法体为空类反编译jd-guiJava 源码逻辑可读变量名丢失、泛型错乱apktool 的还原度问题主要出现在资源上。老版本 APK 或用了资源混淆方案的应用资源 ID 会被改得面目全非apktool 拆解后 res 目录里会出现大量 unnamed 文件能看结构但不知道具体用途。这个不算工具失败是对方故意加了混淆后面避坑章节会说怎么处理。dex2jar 的还原度受 DEX 版本和指令集影响。新版 Android 平台对应的 DEX 格式较新老版本 dex2jar 偶尔不识别某些新指令转换后个别类直接丢失。遇到这种情况换更新的 dex2jar 版本或者用--debug参数跑一遍看日志看是哪个类转换失败。jd-gui 的还原度最直观影响阅读体验。同一个 class 文件jd-gui 能还原出 80% 可读代码换用另一款反编译器可能只有 60%但局部逻辑和继承关系反而不如 jd-gui 清晰。从我的使用经验看jd-gui 对变量名保留程度高自动生成的 else/if 结构相对稳定适合通读业务它的弱项是 Lambda 表达式和枚举类还原出来的代码偶尔会让你怀疑是不是原开发者写得太抽象。3.2 操作效率对比上手难度与批量处理效率维度要看两个场景单文件分析和批量分析。单文件分析apktool 是命令行一条命令拆完dex2jar 也是命令行一条命令转完jd-gui 是图形界面打开 jar、点开类就能看。三者里 jd-gui 效率最高因为它把代码浏览、字符串搜索、类跳转都做成了可视化操作。命令行两个工具适合脚本化不适合交互式阅读。批量处理是命令行工具的强项。比如一批样本都要做清单排查写个循环调 apktool 就完事# 对同一目录下所有 APK 执行解码输出到各自目录 for apk in samples/*.apk; do apktool d $apk -o out_$(basename $apk .apk) done这段循环对文件名不带空格、不带特殊字符的情况没问题。如果文件名里有空格$apk加了引号也能正确处理推荐写脚本时统一加引号否则文件路径一有空格就当场报错这种问题排查起来很浪费时间。双手操作习惯上我一般把 apktool 的命令行窗口固定在一个工作目录把 dex2jar 的脚本路径加到 PATH 里这样拆解和转换都不用敲绝对路径。jd-gui 则保持默认配置不做多余设置。整套链路从拿到 APK 到打开 jd-gui 看到代码熟练后一分钟内能完成大部分时间花在等命令跑完上。3.3 对混淆和加固的处理三类工具各自的极限混淆和加固是 android 逆向绕不开的坎也是选型分水岭。先说混淆常见混淆工具会把类名、方法名改成 a、b、c 这种短名字符串也可能被加密。apktool 拆解后smali 里的类名已经是混淆名资源文件名还算正常dex2jar 转换后jd-gui 里看到的类名全部变短跳转逻辑基本靠包结构和调用关系摸索。对纯混淆的应用三个工具都能正常工作只是阅读体验差。真正让工具失效的是加固方案。加固应用的特征是APK 里真实的 classes.dex 被抽空或加密运行时由壳的 loader 加载真正的 dex。流行业务里大多数商业应用都会做这一步。这种情况下apktool 能拆出壳相关的资源和清单但 dex2jar 转出来的 jar 里只有壳的逻辑看不到业务代码jd-gui 打开后是空的或者只有壳的方法。很多人卡在这步以为工具坏了其实是样本加了保护需要先脱壳才能回到正常的反编译流程。脱壳不在本篇选型范围内但要知道判断标准dex2jar 输出的 jar 里类数量远小于正常水平jd-gui 打开后大面积空白基本可以断定是加固了。针对加固和混淆并存的恶劣样本我的建议是不要指望某个工具单打独斗。apktool 先拆出清单看应用有没有壳的特征再用 dex2jar 验证类完整性最后 jd-gui 阅读时配合混淆映射关系做人工还原。三个工具都有极限组合起来覆盖面更大。4. 选型结论学习分析、源码审计分别该用哪套4.1 学习与简单分析选哪套apktool jd-gui 双组合如果你的目的是学习某个应用的实现思路或者只是分析某个功能点怎么写的不需要改动打包那不用完整走三件套。apktool 负责拆资源和看清单dex2jar 转 jarjd-gui 读代码。这套组合是学习分析场景的标准答案。为什么推荐 apktool 而不是直接解压 APK因为 APK 本质是 zip直接解压看到的 AndroidManifest.xml 是二进制格式编辑器打开是乱码资源文件虽然在但目录结构不如 apktool 整理得直观。apktool 把这些都处理成了可读文本还附带了 apktool.yml 记录原包信息方便后续操作。学习分析场景里 smali 也不是完全不用看。遇到 jd-gui 还原不出来的方法或者你想理解某个加密算法在寄存器层面的具体计算过程还是要切到 smali 目录里对着看。所以这条路径的实际学习曲线是先 jd-gui 通读业务再按需回 smali 抠细节。如果只是临时看一下某个 APK 里有没有某个字符串甚至可以不装三件套直接用 grep 扫二进制# 不拆包直接搜索二进制内容里的关键字符串 grep -a http:// target.apk | head -20这个技巧对初学者很有用能快速判断一个应用是否包含某个接口或域名但不是完整方案因为混淆后的字符串往往加密了搜不到不代表没有。它适合做初步情报收集不适合做源码级分析。4.2 源码审计与二次开发怎么选链路完整优先源码审计场景比如分析某个应用的数据采集行为、排查敏感权限调用或者想基于某应用做二次开发要求的是链路完整和可回编译。这时候三件套缺一不可而且要额外注意版本匹配。审计场景里我一般会先完整走一遍三件套apktool 拆包确认清单和权限声明dex2jar 转 jar 确认类齐全jd-gui 通读可疑逻辑。如果发现某个类在 jd-gui 里空白马上回 apktool 的 smali 目录里读对应方法的实现不能跳过去否则审计结论不完整。二次开发场景则更依赖 apktool 的回编译能力。改 smali、改资源后重新打包需要系统里有对应 Android 版本的框架资源。这里有个经验如果目标应用本身是低版本 targetSdk 编译的回编译时用低版本框架成功率更高高版本框架会把新的资源 ID 强行映射进去导致改完的包行为异常。选型时不能只看工具的版本号还要看目标应用的 targetSdk 版本两者对齐才稳定。至于 jar 层面做二次开发的情况比如往反编译出的 jar 里注入类再重新转成 dex 塞回 APK这套操作 dex2jar 和 jd-gui 都不擅长。它们只是转换和查看真正的字节码注入要用其他工具链不在这篇讨论范围。记住一条凡是要改字节码核心工作围绕 apktool 的 smali 做dex2jar 转出的 jar 不参与回编译流程只是给人看的。4.3 临时救急场景只用一个工具时怎么选有时候你只有五分钟就想知道这个 APK 是什么公司做的、包名叫什么、入口 Activity 是哪个三件套全跑一遍反而浪费时间。这种救急场景单个 apktool 就够。# 只拆解但只保留清单文件用于快速查看 apktool d target.apk -o out_dir # 直接读清单 cat out_dir/AndroidManifest.xmlapktool 拆出来的 AndroidManifest.xml 里能找到包名、声明权限、入口 Activity、第三方 SDK 的组件注册等信息。这些内容足够应付「这个应用靠什么起家」「它集成了哪些外部服务」这类初步判断。如果救急目标是确认某个类是否存在、某个字符串在不在代码里那就用 dex2jar 转 jar 后对 jar 做 unzip 再 grep# 先把 jar 解开 unzip output.jar -d jar_classes # 再在 class 文件里搜字符串注意 class 文件是二进制 grep -rl 目标字符串 jar_classes这里输出的结果是一堆 .class 文件的路径说明目标字符串出现在这些类里具体上下文还得靠 jd-gui 打开对应类看。之所以不直接用 jd-gui 全包搜索是因为大 jar 在 jd-gui 里全量搜索一次很慢命令行 grep 秒出结果定位到类之后再用 jd-gui 精读效率高一个量级。单工具选型有个底线调试用 jd-gui改动用 apktool验证用 dex2jar。任何场景都不要指望一把锤子敲完所有钉子。5. 避坑与排查四个高频翻车点及处理5.1 apktool 回编译失败资源 ID 与系统框架版本现象apktool d 拆解一切正常一旦执行 apktool b 回编译立刻报错错误信息里出现 aapt 相关字段提示某个资源属性找不到或者直接抛出「brut.androlib.AndrolibException」。原因APK 的反编译环境缺少目标系统版本的框架资源。apktool 在回编译时要参照框架资源来校验资源 ID本地没有对应版本就挂了。另外部分应用使用了自定义资源 ID 或做了资源混淆拆解后的资源本身就不完整回编译自然过不去。解决先安装对应版本的框架资源命令是apktool if framework.apk其中 framework.apk 是从设备或模拟器里拿到的对应系统版本框架包。如果还失败检查是否改了 res 目录里的文件却没同步更新 public.xml。我自己的习惯是回编译前先备份一份刚拆解出来的原始状态一旦改动出问题直接恢复不从头重拆。还有一种情况是改 smali 时少加了.locals声明这类错误属于编写问题用文本编辑器检查修改区域的寄存器声明数量即可。5.2 dex2jar 转 jar 报错DEX 版本与内存参数现象d2j-dex2jar.sh 执行后控制台输出一堆异常堆栈常见的是java.lang.RuntimeException: IndexOutOfBounds或java.lang.ArrayIndexOutOfBoundsException最终生成的 jar 里类不完整甚至只生成了几 KB 的空壳。原因两个因素叠加。一是 APK 里的 DEX 用了比较新的指令或特性旧版 dex2jar 解析不了二是样本 dex 体积较大转换时 JVM 默认内存不够用中途内存溢出导致类丢失。解决换新版 dex2jar或者手动加大 JVM 堆内存# 显式指定 JVM 内存1g 适用于大多数样本超大 dex 可以调 2g java -Xmx1g -jar dex2jar.jar target.apk -o output.jar如果加了内存还是失败把报错信息里提到的类名记下来单独从 dex 里提取这个类用 javap 看一眼确认是不是指令不兼容。极少数情况下 DEX 被特殊处理过比如加了自定义指令扩展这时 dex2jar 无解只能回到 smali 层面硬读。这条排查路径能覆盖 95% 的转换失败情况剩下 5% 靠换工具版本解决。5.3 jd-gui 打开卡死或乱码混淆类名与中文注释现象jd-gui 打开一个较大的 jar 后UI 卡顿明显点某个类时长时间转圈或者打开后类名是a.class、b.class这种短名使用体验很差还有一类是源码里中文注释变成乱码读起来费劲。原因jar 体积大、类数量多jd-gui 索引全部类要一定时间这属于性能瓶颈。混淆类名是样本本身被混淆过jd-gui 无能为力。乱码则是编码识别问题jd-gui 默认按 UTF-8 读取遇到 GBK 编码的注释文件就糊了。解决大 jar 打开后别急着点类等左下角进度条跑完再做跳转。卡得特别严重时用命令行先按第 6 章的技巧定位到具体类再在 jd-gui 里用类名跳转过去比在树状列表里翻快很多。混淆类名的问题解决不了只能靠搜索关键字符串锁定目标类再顺着调用关系逆推。乱码问题倒是可以改jd-gui 的配置文件里调整默认编码或者把源码文本复制出来用文本编辑器转换编码后再看。5.4 遇到加固应用先脱壳再谈反编译现象apktool 拆解正常但 dex2jar 转换后 jar 里的类数量特别少jd-gui 打开后看不到业务代码只有一些初始化类。同时 AndroidManifest.xml 里能看到可疑的 Application 类类名带有壳特征比如「StubApp」「ProxyApplication」之类。原因应用接入了商业加固方案或自定义加壳。真实 dex 被加密存放在 assets 或其他位置运行时才解密加载。普通反编译链路解析的是壳的代理 dex自然看不到业务逻辑。解决先做加固识别看 Application 类名特征和 assets 目录下的可疑数据文件。确认加固后用对应脱壳工具或动态调试手段把真实 dex dump 出来再对 dump 出的 dex 走 dex2jar jd-gui 链路。脱壳这一步依赖具体加固方案没有通用命令但有个通用的判断标准dump 出的 dex 如果能被 dex2jar 正常转换、类数量恢复到合理水平就说明脱壳成功。如果 dump 后转换还是失败检查是否还需要修复导入表和字符串加密那属于另一个层面。加固应用排查还有一个常见误判有人看到 jd-gui 里全是空类就以为是 jd-gui 坏了换版本、调参数折腾一圈最后发现是样本加固。我自己的流程是apktool 拆解后先看一眼 AndroidManifest发现壳特征就不再浪费时间走常规链路直接进脱壳流程。6. 一个能直接抄的技巧三分钟定位入口与核心逻辑6.1 最快定位入口 Activity拿到干净样本第一步永远是找入口 Activity。apktool 拆解后直接用 grep 在 AndroidManifest.xml 里查# 找到带有 MAIN 和 LAUNCHER 的 activity grep -n MAIN\|LAUNCHER out_dir/AndroidManifest.xml输出里会指向某个 activity 名称。这个类就是应用启动后第一个加载的界面顺着它的 onCreate 方法能摸到应用的初始化逻辑和主流程。入口类在 jd-gui 里打开后优先看 onCreate 里调用了哪些方法一般是初始化 SDK、绑定服务、加载数据整条线就有了。6.2 定位关键逻辑先用搜索入口找到后要看具体业务逻辑先在 jd-gui 里用搜索功能直接搜特征字符串。比如要找网络请求地址搜http要找密钥相关搜api_key、secret要找加密逻辑搜encrypt、Cipher。搜索结果的批量筛选效率不高我会先用命令行把 jar 里的类路径 grep 一遍再在 jd-gui 里精读# 先解压 jar unzip output.jar -d jar_classes # grep 出包含目标字符串的 class 文件路径 grep -rl encrypt jar_classes拿到类路径后手动跳转避免 jd-gui 全包搜索的卡顿。这个方法对新手特别友好不需要理解太多原理就能定位。6.3 把结论记录成可复用笔记分析完一个样本后把入口类名、关键逻辑位置、加密算法入口、可疑接口地址记成笔记。下次再遇到同一厂商或同一加固方案的应用直接按笔记里的路径切入省掉重新摸索的时间。从我开始坚持这个习惯后分析同类样本的速度明显提升以前每次都要从入口摸一遍现在直接跳到可疑类验证。这套三分钟技巧的核心不是工具用的多花哨而是顺序对清单 → 入口 → 搜索 → 精读。从那以后我每次拿到 APK 都强制走一遍这个顺序不跳步不随机点类效率稳定提升。希望帮到你。本文还有配套的精品资源点击获取