简介：这套工具面向Android开发、安全测试和逆向学习人员，将apktool、dex2jar、jd-gui、autosign等常用组件整合为一体化逆向助手，能够完成APK反编译、DEX转JAR、Java代码查看、重签名等核心操作，帮助使用者快速分析应用结构、定位关键逻辑并开展安全评估。压缩包共69个文件，大小15.21MB，包含18个jar库文件、8个exe工具、17个bat脚本、14个sh脚本以及签名密钥和原生库等，jar是逆向分析的核心组件，exe提供Windows下的可视化执行，bat/sh则方便在Windows和Linux环境中自动调用，整体覆盖从解包、转换到签名加固的典型流程。目前已有144人学习下载，适合希望免去手动装配环境的开发者直接入门。借由这套整合包，读者可省去逐一下载和配置工具的麻烦，直接对目标APK进行反编译阅读Java逻辑，也可修改资源后一键重签名并安装调试；同时包内的说明文档和脚本注释还能辅助理解每一步的原理，适合逆向入门和日常分析使用。
1. android逆向助手能拆到什么程度：先跑通apktool、dex2jar、jd-gui这条链路
拿到一个没有源码的APK，想改个包名发到自己渠道，或者想搞清楚某个接口的参数怎么拼，android逆向助手这类整合包的价值就出来了。它把apktool、dex2jar、jd-gui搭成一条可执行的链路：apktool负责解包和回编译，dex2jar负责把dex字节码转成jar，jd-gui负责把jar读成近似Java的伪代码。这三段串起来是日常反编译最常用的组合，适合没有源码但要定位逻辑、修改资源、重签名安装的从业者。
要注意边界：这套链路是静态分析，能看到的是资源、smali、伪代码，不是原始源码；遇到加固或so混淆，刚才说的三个环节会变得不可用或明显失真。接下来的内容按“解包→转jar→读码→回编译→签名→安装验证”展开，把每段的参数、坑和验证方式写清楚。新手可以按章节顺序走，熟手直接跳去第5章看避坑，也能省下不少时间。
2. 三件套的分工与边界：为什么中间要转一道dex2jar
2.1 apktool负责“解包与回编译”，保住资源和smali
先说apktool。APK本质上是一个zip压缩包，但是里面的AndroidManifest.xml和资源文件都用二进制格式编码过，直接用普通解压工具打开之后是一堆不可读的乱码。apktool干的事情就是把这种二进制布局还原成人能看懂的明文：它会把AndroidManifest.xml解码成标准XML，把res目录下的资源还原成可编辑的文件，同时把dex文件反汇编成smali目录。
smali是什么？它是Dalvik字节码的助记符形式，每一条指令对应一个human-readable的文本行。解包完的工程目录里常见结构是：res/放资源，smali/放dex反汇编出来的smali代码（多dex会分成smali_classes2/等目录），根目录则是解出来的AndroidManifest.xml、apktool.yml这类元数据文件。
这里要理解一个关键点：Android应用跑的不是class字节码，而是dex字节码，所以apktool第一步只负责把apk“摊开”，并不负责把dex还原成Java语法。它给出的smali已经是能修改的代码级产物，只不过很多人在smali里改逻辑觉得吃力，才需要后面两个工具做进一步还原。
我一般会先用apktool解包，确认资源、Manifest、smali都正常，再做下一步。解包这一步如果连报错都没有，说明这个包没有做严重加固，后面dextojar才有戏；如果解包时就提示无法解析dex，那基本可以判断这包有壳，后面两件套大概率拿不到有效产出。
2.2 dex2jar负责“翻译dex字节码”，JDK版本很敏感
dex2jar的定位是一个翻译器：把Dalvik字节码翻译成JVM class字节码，然后打包成jar文件。为什么要中转这一道？因为jd-gui这类工具只能读class/jar格式，它不理解dex字节码。所以apk里的classes.dex必须先变成jar，jd-gui才能打开并把每个class进一步还原成近似Java的伪代码。
这套工具的整合包里，dex2jar通常提供的是shell脚本或者bat脚本，对应Linux/macOS和Windows两种环境。脚本名常见为d2j-dex2jar.sh和d2j-dex2jar.bat，直接执行时需要注意可执行权限。Windows下最容易踩的坑是路径中的空格和中文，脚本内部对路径处理得比较脆弱，遇到这类路径经常直接报错、或者生成一个空的jar文件。
还有一个非常容易卡住人的点：dex2jar对JDK版本极度敏感。老版本dex2jar是在JDK 8时代发布的，放在JDK 11、JDK 17环境下经常会报Unsupported class file version，花几分钟去查错误代码，结果发现只是JAVA_HOME指错了环境。遇到这个问题时，最省事的方案不是去换新版的dex2jar，而是把JDK临时切到8。多版本JDK共存时，我会在脚本执行前单独设置JAVA_HOME，不污染全局变量。
另外要注意，现在的应用大多是多dex结构，有classes.dex、classes2.dex、classes3.dex。d2j-dex2jar脚本直接喂apk，或者把多个dex分别喂进去，都能得到jar，但产出物的命名和数量会不同。喂单个dex时输出是单jar，喂整个apk时有些版本会整理成一个jar，有些版本会按dex顺序生成多个jar，这个差异在后面的阅读阶段要心里有数。
2.3 jd-gui负责“把jar变成人读的Java伪代码”，以及链路边界
jd-gui的定位是可视化阅读器。它打开jar之后会按包结构展示类，每个类里的方法会以近似Java的语法呈现。但必须有一个预期管理：它展示的是“反编译后的伪代码”，不是源码。变量名、方法名如果是混淆过的，这里只会看到a、b、c这种短名；字符串常量还在，但注释和原始结构基本全丢。
因此真正常见的定位方式是：先在jd-gui里确认类名、方法名、关键字符串，再到smali里去改具体逻辑。不要指望jd-gui像读IDE源码一样把所有调用关系和类型都还原出来。它最适合干的事情是快速找到“这个App在登录请求里拼接了什么参数”“这个点击事件绑定了哪个方法”，定位之后，真正动手的位置大概率在apktool解出来的smali里。
这套三件套的边界也比较清楚：不处理加固后的壳，包里有壳时，apktool解出来的dex往往只是一层壳的加载代码，真正的业务逻辑被加密存放在了so或某份加密资源里，这时候dextojar转出来的东西毫无业务价值。不处理so层逻辑，底层算法在so里面时，需要另开反汇编工具而不是这三件套。很多android逆向助手整合包里还会额外带上jadx和签名工具，jadx可以直接从apk一步还原成伪代码，省掉dextojar的中转，这在第6章会展开讲，先不抢戏。
3. 反编译实操：从拿到APK到在jd-gui里定位目标逻辑
3.1 解包：apktool d 和几个值得改的参数
实战第一步永远是解包。假设拿到一个app.apk，我习惯的完整命令是：
apktool d app.apk -o app_src -f这条命令的意思是：把app.apk解包到app_src目录，-f表示如果目录已存在就强制覆盖。不加-f时，遇到同名输出目录apktool会停下来问你是否覆盖；在脚本化操作里很容易因为没人回答而卡住，所以自动化处理时一定要带-f。
解包完成后，目录里最值得关注的有三个位置：AndroidManifest.xml、res/、smali/。AndroidManifest.xml是明文XML，能直接看到权限、Activity、Service、Application类名；res/里是资源文件，strings、layout、图片都在这里；smali/是后续改逻辑的主要战场。如果只是临时想看某个资源长什么样，而不是改逻辑，其实不必用apktool，直接把apk后缀改成zip解压，再单独处理二进制XML的编码问题即可。
这里有个小经验：解包时报错如果出现在“Could not decode arsc file”这类资源相关的提示，多半是apktool版本和APK的编译版本不兼容。常见做法是优先用新版本apktool，如果必须用旧版本，那就先去安装framework资源。安装命令是：
apktool if framework-res.apkframework-res.apk可以从设备/system/framework路径拉出来，也可以从系统ROM包里拿。这个步骤在深度定制的ROM上尤其重要，因为厂商改过系统资源ID，apktool不认识时回编译必然失败。
3.2 转jar：dex文件、jar文件与class文件的关系
解包完成之后，业务dex已经在app_src/目录下等着了。现在把它交给dex2jar：
d2j-dex2jar.sh app.apk -o app.jar直接喂apk文件也支持，脚本会自动定位apk内的dex文件。但我个人更推荐先解包再针对dex目录逐个转，命令是这样：
d2j-dex2jar.sh app_src/classes.dex -o classes.jar两种写法产出的jar行为不完全一样。喂apk时，它一次处理包里所有dex，多dex场景下输出粒度取决于版本，有的把多个dex合并到一个jar，有的输出多个jar；喂单个dex则更可控，你明确知道自己转的是哪段代码，排查问题也方便。
这个阶段经常拿到的产出物是classes-dex2jar.jar这类名字。名字不重要，关键是确认jar里有东西。我会用jar命令快速看一眼里面包结构：
jar tf classes.jar | head -50如果输出是空，或者解出来的class寥寥几个，先别急着让jd-gui背锅，回过去检查dex2jar的JDK环境。另外，有些加固应用会在dex里加入特殊指令，dex2jar转换时偶尔会中断，提示某些opcode无法处理。遇到这种情况可以尝试用jadx直接读apk，jadx的容错性要更好。
Windows环境记得用bat版本，并且尽量把路径放到纯英文目录。之前有一次我把apk放在“下载/测试包/”这种目录里，d2j-dex2jar.bat直接连报三次路径不存在，改到D:\work\以后一次通过。这不是工具脆弱，是它内部拼接路径时对非ASCII字符处理确实激进。
3.3 读代码：从AndroidManifest入口往下追，别在smali里硬读
jar到手，jd-gui开起来：
jd-gui classes.jar打开后看到的是反编译后的Java伪代码。很多新手第一屏就懵了，类名全是a/b/c，不知道该看哪里。正确顺序是先回到apktool解出来的明文AndroidManifest.xml，找到入口Activity。入口Activity在Manifest标签里是这样的：
<activity android:name="com.demo.app.MainActivity"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity>拿到入口类名之后，再去jd-gui里按这个名字找到类，从onCreate方法一路往下读。这样读代码的效率远高于在smali里一行行看汇编。jd-gui里还有个实用功能是“Save All Sources”，可以把所有反编译出来的java文件打包导出：
# 导出后用命令行检索关键字，比在GUI里一屏一屏翻快得多 grep -rl "password" /path/to/saved_src | head -20grep命中的文件列表会给你一张“哪些类跟目标逻辑相关”的地图，之后回到jd-gui里针对性地精读。这步在大型项目里极其好用，盲目乱点会浪费很多时间。
4. 回编译与重签名：改完之后怎么让APK重新跑起来
4.1 apktool b 回编译：--use-aapt2 与 framework 对齐
在apktool解包后的目录里做的所有修改，最后都要通过回编译重新打包成APK。回编译命令非常短：
apktool b app_src -o new.apk --use-aapt2输出new.apk，app_src是解包目录，这点不要搞反。参数--use-aapt2是让apktool使用新版资源编译器aapt2，如果解包时的resources.arsc比较新、或者目标App使用了较新的资源编译特性，加上这个参数能减少很多资源相关的回编译失败。老版本apktool默认走的是aapt1，两者对资源的处理逻辑有差异，遇到资源报错时可以先把--use-aapt2去掉再试一次，两边的报错信息往往不同，哪个给的信息更明确就顺着哪个查。
回编译常见的失败现场有两种。第一种是编码问题，报错信息里如果出现乱码符号或提示字符集错误，基本是编辑器保存时用了GBK，而apktool按UTF-8读文件导致的。解决办法是把所有改动文件统一转成UTF-8无BOM格式，Windows下的CMD窗口可以先执行chcp 65001切到UTF-8代码页再操作。第二种是framework资源缺失，报错会指向某个resource ID无法解析，常见做法是先执行apktool if framework-res.apk把系统框架装进本地静态资源库，再重新回编译。
4.2 keytool、zipalign、apksigner：重签名的完整命令链
回编译出来的new.apk是一个“脱过签名”的包，里面原始的签名信息已经被apktool清掉了，必须重新签名才能安装到设备上。
先生成一个自己的签名密钥：
keytool -genkey -v -keystore my.keystore -alias myalias -keyalg RSA -keysize 2048 -validity 3650-keyalg RSA指定算法，-keysize 2048是RSA的推荐长度，-validity 3650表示有效期10年。签名这件事最忌讳临时起意生成一个只有30天有效期的密钥，后面你会反复用它给多个重新打包的APK签名，过期之后所有已安装的包全都得重新签一遍。
生成密钥之后，正式的签名链是先对齐再签名：
zipalign -f 4 new.apk aligned.apk apksigner sign --ks my.keystore --ks-key-alias myalias --out signed.apk aligned.apk apksigner verify --verbose signed.apkzipalign的4表示4字节对齐，目的是让APK内的资源文件在运行时可以直接映射到内存，减少读取时的内存拷贝。顺序很关键：先zipalign、后apksigner。如果先签名再对齐，签名校验是能过，但APK包内的数据对齐信息会被破坏，运行时资源读取性能下降，部分设备甚至会在解析阶段出问题。
apksigner默认会根据minSdkVersion自动决定启用哪些签名方案，但为了兼容Android 6.0及以下的设备，需要手动把v1签名打开，这是apksigner命令行比较容易忽略的点：
apksigner sign --ks my.keystore --ks-key-alias myalias --v1-signing-enabled true --out signed.apk aligned.apkv2和v3签名方案是Android 7.0和9.0以后引入的，老旧设备只认v1。apksigner与传统的jarsigner相比，最大的优势是同时支持v1/v2/v3三种签名方案的生成和验证，不需要为不同系统版本分别处理。最后一步apksigner verify用于确认签名结果，输出里会列出当前包使用的所有签名方案和证书信息，这是安装失败时排查问题的第一道证据。
4.3 adb安装验证与logcat抓崩溃
签名后的signed.apk拿到真机上验证，最标准的命令是一组：
adb install -r signed.apk adb logcat -s AndroidRuntime:E-r表示覆盖安装，如果之前已经装过同包名但不同签名的包，adb install会直接报出INSTALL_FAILED_UPDATE_INCOMPATIBLE，提示你签名不匹配。这时候先卸载旧包再安装：
adb uninstall com.demo.app adb install signed.apk覆盖安装成功但应用启动后立刻闪退的情况，观察logcat时优先过滤AndroidRuntime标签。崩溃堆栈如果停在某个类加载位置，通常是改动后的代码里引用了不存在的字段或方法；如果堆栈本身是正常的业务代码，但退出前出现SecurityException或者PackageManager相关错误，那多半是应用自身做了签名校验，这在第5章会专门说。
正常跑起来的验证流程是：安装完成后手动打开App，先看首页是否正常，再点开你改过逻辑的那个功能，最后用logcat的包名进程过滤确认有没有非预期异常：
adb logcat --pid=$(adb shell pidof com.demo.app)这比全量logcat清爽很多，一眼能看到当前进程自己的输出。
5. 常见问题与避坑排查：五个高频翻车点
5.1 dex2jar在JDK新版上报Unsupported class file version
现象：d2j-dex2jar.sh执行后很快就退出，终端打印出一长串异常，开头是Unsupported class file version，或者提示无法读取某个class文件的major version。
原因：dex2jar的编译目标停留在JDK 8时代，JDK 11及以上的class文件版本号它不认。如果你系统里的java命令指向的是新版本JDK，工具一启动就会在读class阶段挂掉。
解决：临时切换到JDK 8再跑dex2jar。我是这样做的：
export JAVA_HOME=/path/to/jdk8 export PATH=$JAVA_HOME/bin:$PATH切换后再执行一遍d2j-dex2jar.sh，就能顺畅跑完。如果机器上没装JDK 8，装一个专门给这类工具用，不要动系统默认的JDK。这个坑最大的迷惑性在于错误信息没有直接提dex2jar，而是以Java异常的形式出现，不熟悉的人容易去查“如何升级dex2jar版本”，走很多弯路。
5.2 apktool回编译失败：编码问题与framework缺失
现象：apktool b回编译时，报错信息里出现invalid resource name或一串疑似乱码的资源名，又或者提示某个resource ID对应不上。Windows环境下尤其频繁。
原因：这里聚集了两个常见根因。第一个是终端编码，Windows的CMD默认GBK代码页，而apktool强依赖UTF-8，解包出来的资源文件大部分是UTF-8编码，命令行输出和文件解析互相干扰；第二个是framework缺失，深度定制的ROM或者较新的Android版本会修改系统资源ID定义，apktool本地没有对应的framework-res.apk缓存，回编译时无法解析系统引用。
解决：先切代码页再执行回编译：
chcp 65001 apktool b app_src -o new.apk --use-aapt2如果切完编码还是报资源ID问题，就把framework装上：
apktool if framework-res.apk装完后再回编译。注意framework-res.apk要从目标Android版本对应的设备或ROM里拉，版本不匹配时装了也白装。
5.3 安装成功但启动崩溃：签名校验与完整性校验
现象：adb install成功，点开App后瞬间退出，logcat在崩溃前打印出签名相关异常，有时会看到SecurityException: Invalid signature。有的App更隐蔽，App本身能启动但关键页面打不开，退出不崩溃但功能压制。
原因：目标App在代码或so层做了签名校验，运行期读取当前APK的签名信息，和自己内置的合法签名做比对，发现不一致就直接拒绝运行。这是很多商业App的自我保护手段。不是签名步骤没做对，而是你用了自己的证书，App不认识。
解决：先确认自己重签名后的证书信息：
apksigner verify --print-certs signed.apk再把原始APK的证书也打印出来对比：
apksigner verify --print-certs original.apk两个证书的SHA-256完全不同，说明App确实在对比签名。想要让测试跑通，常见的本地测试做法是找到App内置的合法签名hash，把自己新签名的hash替换进去；或者用Hook方案绕过校验。但这里要说清楚：绕过别人的签名校验涉及突破应用保护，只建议在自己有权测试的范围内做本地验证。更稳妥的思路是重新评估这次改动的目标——如果只是想看某个界面的交互逻辑，静态分析配合动态调试也能完成，不一定非要在原包上重签名。
5.4 手改AndroidManifest导致解析失败
现象：安装时直接提示“解析包出现问题”，或者adb install返回INSTALL_PARSE_FAILED。
原因：最常见的操作是直接编辑解包后的AndroidManifest.xml改包名、改权限，但改坏了XML结构，比如标签不闭合、属性值没有转义、把一个activity节点删掉了一半。还有一种情况是把包名改了之后，没有同步改Application类、Provider的authority等需要保持一致的属性。
解决：改完Manifest后先做一次静态校验，用aapt2自带的能力：
aapt2 dump badging new.apk | head -30如果aapt2能正常输出包名、版本、启动Activity，说明Manifest结构没问题。如果这里就报错，回到XML里逐行检查改动位置。另外提醒一个老生常谈的点：Provider的authority往往是全局唯一的，很多App内部用ContentProvider跨进程通信，只改主包名不改authority，装上之后照样能解析成功，但运行时provider找不到，功能明显异常。
5.5 回编译后中文乱码或资源丢失
现象：回编译安装后，界面上的中文变成乱码，或者原本应该显示的图标、文案直接消失。重新解包检查res目录，发现某些字符串文件内容还在，但显示不对。
原因：编辑资源时保存的编码不是UTF-8。最常见的场景是在Windows上用记事本编辑strings.xml，默认保存为ANSI/GBK，apktool回编译按UTF-8读取，字符就错乱。资源丢失则不一样，它多半是你解包时用了自定义参数，比如在解包命令里加了-r或-s这类限制参数，导致部分资源没有被完整还原，回编译时自然缺料。
解决：所有编辑器统一设置UTF-8无BOM格式，避免在资源文件里夹带中文之外的编码字符。修改前先确认解包时用的参数，看apktool.yml里有没有特殊配置；如果你不确定当初怎么解的包，重新用完整模式解一遍再改：
apktool d app.apk -o app_src_clean -f解包参数这种东西，很容易在调试时顺手加一个然后忘掉，后面回编译出了问题完全没有任何头绪。遇到过几次这种疑似玄学的资源丢失之后，我现在每次解包前都会把完整命令贴到终端显眼处，强制自己全程盯着参数跑。
6. 进阶验证技巧：用jadx对照和smali插桩交叉验证
反编译器本质上是个概率工具，它输出的“Java代码”是基于字节码反推的近似结果。变量名丢了、控制流被改写、部分调用被内联，这些都是常态。如果只凭jd-gui的输出就动手改smali，很容易把逻辑改反。更稳妥的做法是引入第二个反编译结果做对照。
在android逆向助手的整合包里，通常会放着jadx的命令行工具。jadx可以直接从APK一步还原出伪代码，而且容错率比“apktool+dex2jar+jd-gui”的串联链路更高。我一般会在jd-gui定位到目标类之后，再用jadx把同一个APK完整导出一份做对照：
jadx -d jadx_out app.apk对比一下两个工具对同一个类的还原结果。如果jd-gui说某个分支条件是等于0，jadx里却显示不等于0，那说明这段逻辑还原不可信，需要结合smali手工确认。双击一份smali代码从头看到尾，比争执哪个工具对更快：
const/4 v0, 0x0 if-eqz v0, :cond_a在smali层面，if-eqz就是“等于零跳转”，对应Java里的if (x == 0)。两个反编译器如果在这里打架，smali会给你最终答案。多一个工具不是端架子，是真能拦住冲动改错。
确认逻辑之后，动态验证一样有价值。经典做法是在smali的目标方法入口插入一条日志调用：
const-string v0, "TraceTag" invoke-static {v0, v1}, Landroid/util/Log;->i(Ljava/lang/String;Ljava/lang/String;)I假定v1寄存器里是你要观察的参数值，插入后重新回编译、签名、安装，然后在logcat里只过滤自己的Tag：
adb logcat -s TraceTag:D这样做一次，你就能确认静态分析得出的结论和运行时真实数据是否一致。我见过太多人改完代码只看界面效果，不看日志，结果界面是正常的，但数据流完全不是他想的那样。
那次我在一个登录逻辑里只凭jd-gui的结果改了一个跳转条件，回编译、签名、安装都没问题，App也能正常启动，但登录成功后页面跳去错误的地方。后来插桩打日志一看，那个条件判断的寄存器值跟我理解的完全是两个来源。从那以后我每次改完smali都会强制把反编译、回编译、安装验证、日志观察全流程走一遍，确认每个阶段的输出是稳定的，而不是侥幸通过。希望帮到你。
本文还有配套的精品资源，点击获取
