简介这是一份面向 Android 开发者、测试人员及逆向爱好者的 APK 反编译工具资源包用于解析应用内部结构、查看 Java 源代码与资源文件帮助理解他人应用实现原理或辅助二次调试。压缩包共 488 个文件大小约 8.84MB主要包含 435 个 pgt 界面布局文件、22 个 ogg 音频资源、13 个 jar 库、6 个 xml 配置、2 个 dex、2 个 exe 主程序、2 个 apk 示例并附 readme 说明文档与日志文件夹结构清晰便于直接上手。包内自带示例 APK 和反编译产生的输出文件可对照学习完整流程同时提供 32 位与 64 位两个版本适配常见 Windows 环境。目前已有 621 人学习下载适合刚接触逆向分析、希望快速掌握 APK 拆解与资源查看的初学者及中级开发者作为入门工具使用。1. 反编译工具Androidfby把APK拆成可读代码的完整流水线反编译工具一直是Android逆向的基础设施Androidfby就是其中一套直接可用的完整流水线。无论是排查线上崩溃时的混淆堆栈还是要借鉴某个成熟模块的实现思路或者做一次竞品功能对标你都得先把APK拆开。用单点工具的人都有体会解包、转格式、看代码、找资源是四件独立的事窗口切换比看代码还累。Androidfby把这四步串成一个流程APK进去可读Java代码和明文资源出来适合想把时间花在业务逻辑分析上的人而不是耗在工具链调度上。2. 认识APK结构与反编译原理为什么选Androidfby2.1 APK的四个核心部件与各自的还原目标在动手之前先搞清楚你手里的APK到底是什么。它本质上是ZIP压缩包里面几个核心部件决定了反编译的走向。第一个是classes.dex。这是Dalvik字节码文件你写的Java或Kotlin代码先编译成class文件再由构建工具合并转成dex。反编译代码部分就是在处理这个文件。大型应用通常不止一个dexclasses2.dex、classes3.dex按序排列做多DEX合并时很容易漏掉后几个文件漏一个就少一截业务逻辑。第二个是AndroidManifest.xml。清单文件经过AAPT2编译后变成二进制XML直接打开是乱码必须经过工具还原成可读XML。入口Activity、权限声明、Service与Receiver都从这里读它是你定位代码入口的第一张地图。第三个是resources.arsc。这是资源索引表把所有资源ID与文件路径的对应关系记在这里全局字符串池也保存在其中。资源混淆过的APK里R类字段与文件名对不上就是因为这张表被改写还原工具必须把它重建出来后面的资源访问才能对上号。第四个是res/与assets/目录。前者放布局、图片、颜色等编译资源后者放未被编译的原始文件比如内置词典、加密模型、HTML模板。反编译工具能还原res下的二进制资源而assets里的文件一般原样取出就能用。理解这些部件的还原目标比死记命令参数更重要。Androidfby实际做的就是按这四个部件分阶段处理先解资源和明文XML再把dex转成jar最后转成Java源码并重建资源索引。我在分析模拟项目X的时候就是按这个顺序逐层拆每个阶段确认产出目录和预期一致再进下一步。这里有一个经常被忽略的点ZIP压缩包内除了上述四个部件还有META-INF签名目录。反编译阶段签名信息不影响解包但如果你在做完修改后要回编译打包签名就得重新处理否则安装时会直接报应用未签名。2.2 为什么用Androidfby单点工具组合的中间断层如果你单独用apktool资源与XML能解得很干净代码部分它却不擅长。单独用jadxJava代码读起来很舒服但遇到资源混淆的APK时反编译结果里全是数值ID没有真实文件名对着看很难受。两套工具的输出不互通资源ID和代码里的引用经常对不上这是单点工具组合最大的断层。Androidfby解决的是中间衔接的问题。它把apktool解出的资源、jadx还原的代码放到同一个映射体系下资源ID可以反查对应名称。实际使用中我最看重的是它按包名归档的目录结构。一次批量导入多个APK后每个APK的代码、资源、日志分开存放后面做对比和追溯都方便很多。选型判断我一般这样定只看一个布局或颜色值直接解包看XML就行单点工具确实够用。但要梳理完整业务功能、分析数据流或者做多版本对比这种多步骤任务一个固定流程的工具能少踩很多人工操作的坑。工具链越固定出错的变量越少这是被反复折腾出来的经验。还有一点值得说单点工具的参数很灵活灵活意味着每次执行前你都要做一轮参数决策。比如jadx有--no-res、--show-bad-code这些开关选错了输出就缺东西。Androidfby把参数预置成适合完整分析的默认值不需要每次手动调整对新手尤其友好。2.3 工具链对比边界与取舍我整理了一份对比表写清楚Androidfby与常用单点工具的边界避免误用。对比项Androidfbyapktooljadx资源反编译支持自动处理二进制XML支持仅查看代码还原dex转jar再转Java不支持支持批量处理支持列表导入需自行写脚本需自行写脚本回编译修正后可回编译支持不支持输出报告索引文件加阶段日志无标准报告控制台输出适用任务完整分析、批量对比资源还原、改包重打包单文件快速阅读这张表不意味着你要完全放弃单点工具。Androidfby负责整体流程遇到冷门类或特殊文件格式时再拿jadx单独追查仍然有效。边界清楚以后分析节奏会快很多遇到问题也知道该去哪一层排查。2.4 拿到反编译结果后先看什么工具跑完以后第一步不是急着翻代码而是看三个产出的完整性。资源目录里应该有完整的res与明文AndroidManifest.xml代码目录里应该有以包路径组织的.java文件日志里不应出现大段异常堆栈。只有这三项都满足后边的定位工作才有基础。这个习惯来自一次翻车。当时我反编译完一个渠道包跳过了产出检查直接进代码搜索找了半天才发现DEX只解了一个另外一个dex里的核心逻辑完全没进来。从那以后每次跑完流程我都先花两分钟确认产出确认完整再开始分析。这一步看起来很笨实际上能省下后面几个小时的无效搜索。3. 完整反编译实操从APK到可读代码的五个步骤3.1 环境准备JDK版本与目录规划Androidfby依赖Java工具链JDK版本直接影响整个流程的稳定性。我这边长期用的是JDK 11解包和转码都没有遇到版本相关异常。如果你还在JDK 8上跑碰到新版DEX格式常会报Unsupported class file version这就是版本不匹配的信号先换JDK再继续。# 检查当前 JDK 版本 java -version # 期望输出示例 # openjdk version 11.0.21 2023-10-17如果输出里出现1.8开头的版本建议装一个11或17的JDK。Androidfby内部调用的转换组件对JDK 8的兼容性越来越差尤其处理targetSdk 30以上的APK时老JDK容易在资源解析阶段抛异常。除了版本目录规划也值得提前做。反编译会产生大量中间文件不约定目录的话磁盘会散落一堆jar和smali目录回头找东西很痛苦。我一般固定三层结构mkdir -p input output workinginput放APK原始文件output放最终分析结果working是临时解包目录跑完就清理。这样每次分析的路径都一样批量跑脚本的时候也少出错。有些开发者随意放在桌面临时目录跑完一周后再想找当时的分析产出只能重新来一遍时间成本很高。3.2 第一步解包与资源还原资源还原这一步的目标是拿到明文的XML和可浏览的res目录。命令参数上-o指定输出目录-f强制覆盖已有目录避免上一次执行残留的文件干扰新结果。apktool d input/app-release.apk -o working/apktool_out -f # 执行后 working/apktool_out 下会出现 # AndroidManifest.xml 明文形式可直接阅读 # res/ 还原后的资源目录按类型分文件夹 # smali/ Dalvik 汇编形式的代码属于中间产物这一步的关键是确认AndroidManifest.xml已经是文本形式。如果打开还是乱码说明反编译没有成功需要排查工具版本或系统框架是否缺失。apktool首次处理高版本targetSdk的应用时有时会提示需要安装framework-res.apk按提示用工具自带的框架安装命令补上然后重新执行解包。s mali目录在这一阶段默认也会生成但大部分场景下你不会直接读s mali汇编它更适合做代码修改和回编译。如果你只关注资源结构可以忽略这个目录重点看res和AndroidManifest.xml。3.3 第二步把DEX转成Jar再转成Java资源还原后代码部分还在dex里。先解出classes*.dex再用dex2jar类工具转成jar包。需要留意的是大型应用有多个dex解压时用通配符一次全部解出遗漏任何一个后边分析结果就会缺一整块逻辑。# 解出所有 dex 文件 unzip -o input/app-release.apk -d working/apk_files classes*.dex # 将主 dex 转成 jar d2j-dex2jar.sh working/apk_files/classes.dex -o working/classes.jar # 将classes2等后续dex逐个转jar for dex in working/apk_files/classes2.dex; do d2j-dex2jar.sh $dex -o working/$(basename ${dex%.dex}).jar doned2j-dex2jar.sh在Windows环境下是d2j-dex2jar.bat参数没区别。转换完成后你会得到与dex数量对应的jar文件每个jar代表一段DEX的字节码。转完的jar已经是标准Java字节码接着用jadx类工具还原成可读的.java源码。# 方案一从jar转Java源码 jadx -d working/jadx_out working/classes.jar # 方案二直接把APK丢给jadx它内部会处理dex jadx -d working/jadx_out_all input/app-release.apk方案一的优势是你控制了dex来源每个jar对应一个dex多DEX情况下一目了然。方案二是jadx自己解析整个APK适合快速看全貌但在多DEX合并时偶尔会漏掉部分类。我一般先跑方案二拿全局再用方案一逐dex补细节。3.4 第三步从明文资源与代码里定位关键逻辑到了这一步你已经拥有明文资源和Java代码。定位关键逻辑时我遵循一个固定顺序先看AndroidManifest.xml里的入口Activity和权限声明再看代码包里与入口同级的类最后用字符串反查。# 搜索可疑的接口地址或密钥字符串 grep -r api working/jadx_out/ | head -20 # 搜索某个业务关键词比如 login、pay、token grep -rn login working/jadx_out/ | grep \.java | head -20搜字符串是定位效率很高的手段。大部分应用在代码里保留了日志Tag或URL前缀一个关键词就能命中一个核心类。拿到之后用jadx的搜索跳转到对应源码再往上翻调用它的地方顺着调用链就能把整个功能模块的骨架还原出来。定位入口时优先看清单文件里的MAIN intent action# 在明文 AndroidManifest.xml 中找入口 grep -n android.intent.action.MAIN working/apktool_out/AndroidManifest.xml从入口Activity出发读onCreate方法看setContentView对应的布局ID再去res/layout下找对应布局文件一个页面的完整逻辑就从代码和资源两个维度拼出来了。3.5 第四步核对输出报告与索引流程化工具的一个重要价值是日志汇总。Androidfby跑完以后会在输出根目录生成索引文件记录APK的包名、版本、入口Activity、签名摘要以及每个阶段是否成功的状态标记。# 查看索引文件的关键行 grep -E package|entry|signature|status output/index.txt如果状态列显示某个阶段failed不要带着残缺产出继续深挖回退到对应阶段修原因。反编译产物一旦缺了资源映射或漏了dex后面所有基于它的结论都可能站不住脚。宁可多花二十分钟重跑一个不完整的APK也不要对着缺数据的目录猜测业务逻辑。这里说一个血泪经验我分析某跨平台系统的APK时第一次跑完没核对索引直接开始读代码。读了两小时才发现jadx_out里面只有MainActivity一个类迟疑半天回看索引显示代码转换阶段failed重跑一次才拿到完整类树。从那以后索引文件成了我必须检查的第一项。4. 避坑与常见问题反编译翻车的五个典型场景4.1 资源文件解出来全是乱码现象apktool解包完成后AndroidManifest.xml用编辑器打开是一堆二进制符号看不清任何可读标签。原因解包所用工具版本与APK的AAPT2编译版本不匹配二进制XML没有被正确反转。常见于targetSdk版本高于工具内置的框架资源版本。解决先确认工具是否最新版。然后检查系统框架是否初始化必要时执行框架更新命令再重新反编译。如果乱码只出现在单个XML文件尝试手动指定框架目录重新解包。4.2 Multi-DEX缺漏方法体大面积消失现象代码目录里类文件都在方法体却是空的或者某个业务模块的类完全找不到。原因APK有多个dex只转换了classes.dex。大型应用业务逻辑分散在classes2.dex、classes3.dex里漏一个就少一截。解决解压时用通配符classes*.dex一次取出全部文件每个dex单独转换。验证方法是随便搜一个确定存在的方法名看能否命中。我习惯在转换完成后统计jar文件数量和APK里的dex数量对照对不上就说明漏了。4.3 加固壳导致什么都解不出来现象APK解包后只有一个入口类代码目录里找不到真实业务类Java目录里全是壳加载器相关代码。原因应用做了加固classes.dex里只包含壳的加载逻辑真实代码在加密的.so或本地文件里运行时才解密加载。解决这种情况需要先脱壳。常见做法是在受控的模拟器环境里运行应用让壳完成自解密再从内存中dump出真实的dex文件之后用Androidfby对dump出的dex做常规反编译。没有动态分析条件时也可以静态分析壳的加载器逻辑但工作量和难度会大得多。注意脱壳和动态dump涉及应用运行时行为务必在获得授权的测试环境中进行不要针对未经许可的目标做动态分析。4.4 回编译失败资源ID对不上现象反编译后不做任何改动直接回编译也报错提示某个资源ID找不到或者资源目录下的文件引用失效。原因resources.arsc的索引与res目录里的实际文件不一致常见于资源混淆过的APK。反编译还原时部分ID映射丢失或错位回编译时就暴露了。解决先排查反编译工具版本是否过旧新版本对资源ID的还原完整度更高。回编译前不要手动改动res目录里的文件结构每改一个文件的位置或ID都可能导致整体错位。如果必须改动尽量用工具层面的资源重映射功能而不是直接改文件名。4.5 超大APK内存溢出现象处理体积大或dex数量多的APK时转码阶段直接OOM退出终端日志里出现OutOfMemoryError转换进程被干掉了。原因jadx或dex2jar默认的JVM堆内存不够多DEX同时加载时内存消耗陡增默认的512MB或1GB堆空间撑不住。解决调大JVM堆内存参数。执行转换脚本前设置JVM选项比如-Xmx4g64位系统上稳定很多。另外超大APK可以先剔除无用资源比如只保留目标ABI的.so文件减少镜像体积后再做反编译内存压力小不少。5. 进阶用法验证反编译结果与二次开发5.1 用签名信息反向验证APK身份反编译结果里最容易忽略的是签名信息。从APK的META-INF目录里提取签名文件能算出签名摘要拿这个摘要和官方渠道公布的指纹比对就能确认APK是否被篡改过。Androidfby索引文件里的signature字段就是这个用途分析第三方来源的APK之前先做这一步避免拿到一个被二次打包的恶意版本。5.2 批量对比渠道包差异批量导入同一应用的不同渠道包或版本序列按包名归档后做文件级对比。用diff命令对比两个版本的源码目录和资源目录新增的类、改动的资源一目了然。这个做法在做版本功能迭代分析时非常实用能快速圈出变化范围不用逐行读完整代码。# 对比两个渠道包反编译产出的差异 diff -rq output/version_101/jadx_out output/version_102/jadx_out | head -30输出里会列出仅在某个版本出现或者内容有改动的文件顺着这些文件去读就能锁定功能变化点。5.3 把反编译代码用于学习的最小实践反编译代码最合适的用法不是直接抄而是读结构、学思路。我会挑一个目标类先看它的方法划分再看资源引用方式最后看它怎么处理生命周期。动手实践时把核心算法提取出来做本地Demo验证比如某个图像处理Demo里的滤镜实现提取后跑一遍比只看不练的理解深得多。关于二次开发一个底线要求是反编译不是造轮子的替代品。第三方库有开源版本时优先参考开源代码只有纯闭源且需要兼容的场景才适合用反编译产物做行为层面的分析。最后说一个真实教训。早前我在某个分析任务里跳过了签名验证和索引核对直接拿反编译出的代码定位问题折腾一整天才发现那个APK是被人重新打包过的代码已经被植入了一段额外逻辑。从那以后我每次分析任何来源不明的APK都强制走完签名验证、索引核对、产出完整性确认这三步再开始业务分析。工具跑得快不等于你拿到的东西值得信。希望这篇实操笔记帮到你少走这些弯路。本文还有配套的精品资源点击获取
简介这是一份面向 Android 开发者、测试人员及逆向爱好者的 APK 反编译工具资源包用于解析应用内部结构、查看 Java 源代码与资源文件帮助理解他人应用实现原理或辅助二次调试。压缩包共 488 个文件大小约 8.84MB主要包含 435 个 pgt 界面布局文件、22 个 ogg 音频资源、13 个 jar 库、6 个 xml 配置、2 个 dex、2 个 exe 主程序、2 个 apk 示例并附 readme 说明文档与日志文件夹结构清晰便于直接上手。包内自带示例 APK 和反编译产生的输出文件可对照学习完整流程同时提供 32 位与 64 位两个版本适配常见 Windows 环境。目前已有 621 人学习下载适合刚接触逆向分析、希望快速掌握 APK 拆解与资源查看的初学者及中级开发者作为入门工具使用。1. 反编译工具Androidfby把APK拆成可读代码的完整流水线反编译工具一直是Android逆向的基础设施Androidfby就是其中一套直接可用的完整流水线。无论是排查线上崩溃时的混淆堆栈还是要借鉴某个成熟模块的实现思路或者做一次竞品功能对标你都得先把APK拆开。用单点工具的人都有体会解包、转格式、看代码、找资源是四件独立的事窗口切换比看代码还累。Androidfby把这四步串成一个流程APK进去可读Java代码和明文资源出来适合想把时间花在业务逻辑分析上的人而不是耗在工具链调度上。2. 认识APK结构与反编译原理为什么选Androidfby2.1 APK的四个核心部件与各自的还原目标在动手之前先搞清楚你手里的APK到底是什么。它本质上是ZIP压缩包里面几个核心部件决定了反编译的走向。第一个是classes.dex。这是Dalvik字节码文件你写的Java或Kotlin代码先编译成class文件再由构建工具合并转成dex。反编译代码部分就是在处理这个文件。大型应用通常不止一个dexclasses2.dex、classes3.dex按序排列做多DEX合并时很容易漏掉后几个文件漏一个就少一截业务逻辑。第二个是AndroidManifest.xml。清单文件经过AAPT2编译后变成二进制XML直接打开是乱码必须经过工具还原成可读XML。入口Activity、权限声明、Service与Receiver都从这里读它是你定位代码入口的第一张地图。第三个是resources.arsc。这是资源索引表把所有资源ID与文件路径的对应关系记在这里全局字符串池也保存在其中。资源混淆过的APK里R类字段与文件名对不上就是因为这张表被改写还原工具必须把它重建出来后面的资源访问才能对上号。第四个是res/与assets/目录。前者放布局、图片、颜色等编译资源后者放未被编译的原始文件比如内置词典、加密模型、HTML模板。反编译工具能还原res下的二进制资源而assets里的文件一般原样取出就能用。理解这些部件的还原目标比死记命令参数更重要。Androidfby实际做的就是按这四个部件分阶段处理先解资源和明文XML再把dex转成jar最后转成Java源码并重建资源索引。我在分析模拟项目X的时候就是按这个顺序逐层拆每个阶段确认产出目录和预期一致再进下一步。这里有一个经常被忽略的点ZIP压缩包内除了上述四个部件还有META-INF签名目录。反编译阶段签名信息不影响解包但如果你在做完修改后要回编译打包签名就得重新处理否则安装时会直接报应用未签名。2.2 为什么用Androidfby单点工具组合的中间断层如果你单独用apktool资源与XML能解得很干净代码部分它却不擅长。单独用jadxJava代码读起来很舒服但遇到资源混淆的APK时反编译结果里全是数值ID没有真实文件名对着看很难受。两套工具的输出不互通资源ID和代码里的引用经常对不上这是单点工具组合最大的断层。Androidfby解决的是中间衔接的问题。它把apktool解出的资源、jadx还原的代码放到同一个映射体系下资源ID可以反查对应名称。实际使用中我最看重的是它按包名归档的目录结构。一次批量导入多个APK后每个APK的代码、资源、日志分开存放后面做对比和追溯都方便很多。选型判断我一般这样定只看一个布局或颜色值直接解包看XML就行单点工具确实够用。但要梳理完整业务功能、分析数据流或者做多版本对比这种多步骤任务一个固定流程的工具能少踩很多人工操作的坑。工具链越固定出错的变量越少这是被反复折腾出来的经验。还有一点值得说单点工具的参数很灵活灵活意味着每次执行前你都要做一轮参数决策。比如jadx有--no-res、--show-bad-code这些开关选错了输出就缺东西。Androidfby把参数预置成适合完整分析的默认值不需要每次手动调整对新手尤其友好。2.3 工具链对比边界与取舍我整理了一份对比表写清楚Androidfby与常用单点工具的边界避免误用。对比项Androidfbyapktooljadx资源反编译支持自动处理二进制XML支持仅查看代码还原dex转jar再转Java不支持支持批量处理支持列表导入需自行写脚本需自行写脚本回编译修正后可回编译支持不支持输出报告索引文件加阶段日志无标准报告控制台输出适用任务完整分析、批量对比资源还原、改包重打包单文件快速阅读这张表不意味着你要完全放弃单点工具。Androidfby负责整体流程遇到冷门类或特殊文件格式时再拿jadx单独追查仍然有效。边界清楚以后分析节奏会快很多遇到问题也知道该去哪一层排查。2.4 拿到反编译结果后先看什么工具跑完以后第一步不是急着翻代码而是看三个产出的完整性。资源目录里应该有完整的res与明文AndroidManifest.xml代码目录里应该有以包路径组织的.java文件日志里不应出现大段异常堆栈。只有这三项都满足后边的定位工作才有基础。这个习惯来自一次翻车。当时我反编译完一个渠道包跳过了产出检查直接进代码搜索找了半天才发现DEX只解了一个另外一个dex里的核心逻辑完全没进来。从那以后每次跑完流程我都先花两分钟确认产出确认完整再开始分析。这一步看起来很笨实际上能省下后面几个小时的无效搜索。3. 完整反编译实操从APK到可读代码的五个步骤3.1 环境准备JDK版本与目录规划Androidfby依赖Java工具链JDK版本直接影响整个流程的稳定性。我这边长期用的是JDK 11解包和转码都没有遇到版本相关异常。如果你还在JDK 8上跑碰到新版DEX格式常会报Unsupported class file version这就是版本不匹配的信号先换JDK再继续。# 检查当前 JDK 版本 java -version # 期望输出示例 # openjdk version 11.0.21 2023-10-17如果输出里出现1.8开头的版本建议装一个11或17的JDK。Androidfby内部调用的转换组件对JDK 8的兼容性越来越差尤其处理targetSdk 30以上的APK时老JDK容易在资源解析阶段抛异常。除了版本目录规划也值得提前做。反编译会产生大量中间文件不约定目录的话磁盘会散落一堆jar和smali目录回头找东西很痛苦。我一般固定三层结构mkdir -p input output workinginput放APK原始文件output放最终分析结果working是临时解包目录跑完就清理。这样每次分析的路径都一样批量跑脚本的时候也少出错。有些开发者随意放在桌面临时目录跑完一周后再想找当时的分析产出只能重新来一遍时间成本很高。3.2 第一步解包与资源还原资源还原这一步的目标是拿到明文的XML和可浏览的res目录。命令参数上-o指定输出目录-f强制覆盖已有目录避免上一次执行残留的文件干扰新结果。apktool d input/app-release.apk -o working/apktool_out -f # 执行后 working/apktool_out 下会出现 # AndroidManifest.xml 明文形式可直接阅读 # res/ 还原后的资源目录按类型分文件夹 # smali/ Dalvik 汇编形式的代码属于中间产物这一步的关键是确认AndroidManifest.xml已经是文本形式。如果打开还是乱码说明反编译没有成功需要排查工具版本或系统框架是否缺失。apktool首次处理高版本targetSdk的应用时有时会提示需要安装framework-res.apk按提示用工具自带的框架安装命令补上然后重新执行解包。s mali目录在这一阶段默认也会生成但大部分场景下你不会直接读s mali汇编它更适合做代码修改和回编译。如果你只关注资源结构可以忽略这个目录重点看res和AndroidManifest.xml。3.3 第二步把DEX转成Jar再转成Java资源还原后代码部分还在dex里。先解出classes*.dex再用dex2jar类工具转成jar包。需要留意的是大型应用有多个dex解压时用通配符一次全部解出遗漏任何一个后边分析结果就会缺一整块逻辑。# 解出所有 dex 文件 unzip -o input/app-release.apk -d working/apk_files classes*.dex # 将主 dex 转成 jar d2j-dex2jar.sh working/apk_files/classes.dex -o working/classes.jar # 将classes2等后续dex逐个转jar for dex in working/apk_files/classes2.dex; do d2j-dex2jar.sh $dex -o working/$(basename ${dex%.dex}).jar doned2j-dex2jar.sh在Windows环境下是d2j-dex2jar.bat参数没区别。转换完成后你会得到与dex数量对应的jar文件每个jar代表一段DEX的字节码。转完的jar已经是标准Java字节码接着用jadx类工具还原成可读的.java源码。# 方案一从jar转Java源码 jadx -d working/jadx_out working/classes.jar # 方案二直接把APK丢给jadx它内部会处理dex jadx -d working/jadx_out_all input/app-release.apk方案一的优势是你控制了dex来源每个jar对应一个dex多DEX情况下一目了然。方案二是jadx自己解析整个APK适合快速看全貌但在多DEX合并时偶尔会漏掉部分类。我一般先跑方案二拿全局再用方案一逐dex补细节。3.4 第三步从明文资源与代码里定位关键逻辑到了这一步你已经拥有明文资源和Java代码。定位关键逻辑时我遵循一个固定顺序先看AndroidManifest.xml里的入口Activity和权限声明再看代码包里与入口同级的类最后用字符串反查。# 搜索可疑的接口地址或密钥字符串 grep -r api working/jadx_out/ | head -20 # 搜索某个业务关键词比如 login、pay、token grep -rn login working/jadx_out/ | grep \.java | head -20搜字符串是定位效率很高的手段。大部分应用在代码里保留了日志Tag或URL前缀一个关键词就能命中一个核心类。拿到之后用jadx的搜索跳转到对应源码再往上翻调用它的地方顺着调用链就能把整个功能模块的骨架还原出来。定位入口时优先看清单文件里的MAIN intent action# 在明文 AndroidManifest.xml 中找入口 grep -n android.intent.action.MAIN working/apktool_out/AndroidManifest.xml从入口Activity出发读onCreate方法看setContentView对应的布局ID再去res/layout下找对应布局文件一个页面的完整逻辑就从代码和资源两个维度拼出来了。3.5 第四步核对输出报告与索引流程化工具的一个重要价值是日志汇总。Androidfby跑完以后会在输出根目录生成索引文件记录APK的包名、版本、入口Activity、签名摘要以及每个阶段是否成功的状态标记。# 查看索引文件的关键行 grep -E package|entry|signature|status output/index.txt如果状态列显示某个阶段failed不要带着残缺产出继续深挖回退到对应阶段修原因。反编译产物一旦缺了资源映射或漏了dex后面所有基于它的结论都可能站不住脚。宁可多花二十分钟重跑一个不完整的APK也不要对着缺数据的目录猜测业务逻辑。这里说一个血泪经验我分析某跨平台系统的APK时第一次跑完没核对索引直接开始读代码。读了两小时才发现jadx_out里面只有MainActivity一个类迟疑半天回看索引显示代码转换阶段failed重跑一次才拿到完整类树。从那以后索引文件成了我必须检查的第一项。4. 避坑与常见问题反编译翻车的五个典型场景4.1 资源文件解出来全是乱码现象apktool解包完成后AndroidManifest.xml用编辑器打开是一堆二进制符号看不清任何可读标签。原因解包所用工具版本与APK的AAPT2编译版本不匹配二进制XML没有被正确反转。常见于targetSdk版本高于工具内置的框架资源版本。解决先确认工具是否最新版。然后检查系统框架是否初始化必要时执行框架更新命令再重新反编译。如果乱码只出现在单个XML文件尝试手动指定框架目录重新解包。4.2 Multi-DEX缺漏方法体大面积消失现象代码目录里类文件都在方法体却是空的或者某个业务模块的类完全找不到。原因APK有多个dex只转换了classes.dex。大型应用业务逻辑分散在classes2.dex、classes3.dex里漏一个就少一截。解决解压时用通配符classes*.dex一次取出全部文件每个dex单独转换。验证方法是随便搜一个确定存在的方法名看能否命中。我习惯在转换完成后统计jar文件数量和APK里的dex数量对照对不上就说明漏了。4.3 加固壳导致什么都解不出来现象APK解包后只有一个入口类代码目录里找不到真实业务类Java目录里全是壳加载器相关代码。原因应用做了加固classes.dex里只包含壳的加载逻辑真实代码在加密的.so或本地文件里运行时才解密加载。解决这种情况需要先脱壳。常见做法是在受控的模拟器环境里运行应用让壳完成自解密再从内存中dump出真实的dex文件之后用Androidfby对dump出的dex做常规反编译。没有动态分析条件时也可以静态分析壳的加载器逻辑但工作量和难度会大得多。注意脱壳和动态dump涉及应用运行时行为务必在获得授权的测试环境中进行不要针对未经许可的目标做动态分析。4.4 回编译失败资源ID对不上现象反编译后不做任何改动直接回编译也报错提示某个资源ID找不到或者资源目录下的文件引用失效。原因resources.arsc的索引与res目录里的实际文件不一致常见于资源混淆过的APK。反编译还原时部分ID映射丢失或错位回编译时就暴露了。解决先排查反编译工具版本是否过旧新版本对资源ID的还原完整度更高。回编译前不要手动改动res目录里的文件结构每改一个文件的位置或ID都可能导致整体错位。如果必须改动尽量用工具层面的资源重映射功能而不是直接改文件名。4.5 超大APK内存溢出现象处理体积大或dex数量多的APK时转码阶段直接OOM退出终端日志里出现OutOfMemoryError转换进程被干掉了。原因jadx或dex2jar默认的JVM堆内存不够多DEX同时加载时内存消耗陡增默认的512MB或1GB堆空间撑不住。解决调大JVM堆内存参数。执行转换脚本前设置JVM选项比如-Xmx4g64位系统上稳定很多。另外超大APK可以先剔除无用资源比如只保留目标ABI的.so文件减少镜像体积后再做反编译内存压力小不少。5. 进阶用法验证反编译结果与二次开发5.1 用签名信息反向验证APK身份反编译结果里最容易忽略的是签名信息。从APK的META-INF目录里提取签名文件能算出签名摘要拿这个摘要和官方渠道公布的指纹比对就能确认APK是否被篡改过。Androidfby索引文件里的signature字段就是这个用途分析第三方来源的APK之前先做这一步避免拿到一个被二次打包的恶意版本。5.2 批量对比渠道包差异批量导入同一应用的不同渠道包或版本序列按包名归档后做文件级对比。用diff命令对比两个版本的源码目录和资源目录新增的类、改动的资源一目了然。这个做法在做版本功能迭代分析时非常实用能快速圈出变化范围不用逐行读完整代码。# 对比两个渠道包反编译产出的差异 diff -rq output/version_101/jadx_out output/version_102/jadx_out | head -30输出里会列出仅在某个版本出现或者内容有改动的文件顺着这些文件去读就能锁定功能变化点。5.3 把反编译代码用于学习的最小实践反编译代码最合适的用法不是直接抄而是读结构、学思路。我会挑一个目标类先看它的方法划分再看资源引用方式最后看它怎么处理生命周期。动手实践时把核心算法提取出来做本地Demo验证比如某个图像处理Demo里的滤镜实现提取后跑一遍比只看不练的理解深得多。关于二次开发一个底线要求是反编译不是造轮子的替代品。第三方库有开源版本时优先参考开源代码只有纯闭源且需要兼容的场景才适合用反编译产物做行为层面的分析。最后说一个真实教训。早前我在某个分析任务里跳过了签名验证和索引核对直接拿反编译出的代码定位问题折腾一整天才发现那个APK是被人重新打包过的代码已经被植入了一段额外逻辑。从那以后我每次分析任何来源不明的APK都强制走完签名验证、索引核对、产出完整性确认这三步再开始业务分析。工具跑得快不等于你拿到的东西值得信。希望这篇实操笔记帮到你少走这些弯路。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
