★ FEATURED ARTICLE 1. 这个报错到底在说什么从一次真实的踩坑说起第一次看到Exception in thread main com.android.tools.smali.dexlib2.dexbacked.DexBackedDexFile$NotAD...这串东西的时候我正拿着一份别人给的安装包准备做二次分析命令行敲下去满屏红字连个像样的堆栈都没给全。后来把异常信息补全才看清完整类名是DexBackedDexFile$NotADexFile翻译成人话就是你喂给我的这个文件我认定它不是一个合法的 dex 文件。这个报错几乎全部出现在用baksmali、smali、apktool这类基于 dexlib2 的工具链做反编译的时候。dexlib2 是 Android 官方 smali 工具集里负责读写 dex 格式的核心库DexBackedDexFile是它“从字节流里解析 dex”的实现类而NotADexFile是它在解析入口处抛出的守卫异常——只要文件头部的魔数、版本号、校验和、偏移表任何一项对不上它就直接拒绝继续往下走。所以这个报错本质上不是“反编译逻辑出错”而是输入文件在格式层面就没通过第一道门禁。它解决的是“为什么工具连解析都不肯解析”的问题适合所有做 Android 逆向、安全审计、老旧应用兼容性排查、以及单纯想改个资源或逻辑的开发者参考。哪怕你只是刚学会用 apktool 拆包遇到这个报错也别慌它九成九不是工具坏了而是你手里的文件有问题或者你调用工具的方式有问题。我见过太多人一上来就怀疑 JDK 版本、怀疑工具版本、怀疑系统环境折腾半天重装了三遍工具链结果问题出在“文件其实是 zip 而不是 dex”这种低级错误上。这篇就把我这些年踩过的坑、排查的顺序、以及每个判断背后的原理一次性讲透。2. 先搞清楚 dexlib2 是怎么判断“你是不是 dex”的2.1 dex 文件头的结构决定了第一道门禁要理解这个报错得先知道 dex 文件长什么样。dex 格式的文件头固定 0x70 字节开头 8 个字节是魔数加版本格式是dex\n035\0这种样子035 是版本号还有 037、038、039 等。紧接着是 4 字节的 Adler-32 校验和、20 字节的 SHA-1 签名再往后是文件大小、头大小、字节序标记以及各种表的大小和偏移。dexlib2 在DexBackedDexFile的构造流程里第一步就是读这 8 个字节的魔数。它期望看到的是dex\n开头、\0结尾中间是三位版本号。只要这 8 个字节不匹配NotADexFile立刻抛出后面的校验和、签名、偏移表根本不会去碰。这就是为什么报错信息里只有NotADexFile而没有更细的原因——它连门都没进。我实测过把任意一个文本文件改名成.dex丢给 baksmali报的就是这个错把一个正常的 APK 直接当 dex 传进去报的也是这个错因为 APK 是 zip 容器开头是PK\x03\x04不是dex\n。这个细节非常关键后面排查会反复用到。2.2 为什么工具不做得“聪明一点”自动识别有人会问工具为什么不干脆自动判断文件类型、自动解压、自动找 dex这其实是设计哲学问题。dexlib2 是一个底层格式库它的职责边界很清晰你给我 dex 字节流我解析你不是 dex我报错。自动识别容器、自动解压属于上层工具比如 apktool的职责。这种分层设计的好处是库本身足够纯粹、可预测坏处就是错误信息对新手不够友好。理解了这一点你就明白排查方向应该放在“我传给工具的到底是什么”上而不是去改工具源码或者换工具版本。我个人的习惯是遇到这个报错第一件事不是看堆栈而是先确认输入文件的真实类型这一步能解决八成问题。2.3 版本号不匹配也会触发同类异常还有一种情况容易被忽略魔数对了但版本号超出 dexlib2 支持范围。比如某些新版本编译产物用了更高的 dex 版本而你手里的 dexlib2 是老版本它读到dex\n040\0这种它不认识的版本同样会在入口处拒绝。虽然严格来说这时抛的可能是版本相关的异常但在不少工具封装里会被统一归到“不是合法 dex”这一类。所以排查时除了看魔数也要留意版本号那三位数字。3. 按这个顺序排查基本不会走弯路3.1 第一步确认文件真实类型别信扩展名这是最高频的坑。很多人拿到一个.dex文件直接baksmali d xxx.dex结果报NotADexFile。实际上那个文件可能是个 zip、可能是个 apk 改的名、甚至可能是个下载失败的 HTML 错误页。扩展名是可以随便改的工具只看内容。判断方法很简单Linux/macOS 下用file命令Windows 下用十六进制编辑器看头几个字节。正常 dex 开头应该是64 65 78 0A即dex\n。如果是50 4B 03 04那是 zip说明你拿到的是压缩包如果是3C 21 44 4F!DO那是 HTML说明下载链接返回了错误页。这一步花十秒钟能省掉后面半小时的瞎折腾。我建议养成习惯任何二进制文件进分析流程前先file一下。这个动作在逆向工作里属于肌肉记忆级别的操作。3.2 第二步APK 要先解压别直接喂给 baksmali这是第二高频的坑而且和第一个坑经常连环出现。APK 本质是 zip里面才装着classes.dex、classes2.dex等。baksmali 只认 dex你把整个 APK 传给它它读到的是PK开头自然报NotADexFile。正确做法是先解压 APK取出里面的 dex 文件再处理。命令行下unzip app.apk -d out就行然后去out目录里找classes*.dex。如果你用的是 apktool它内部会自动做这一步所以用 apktool 一般不会遇到这个错——除非 apktool 自己解压失败或者 dex 文件本身损坏。这里有个细节有些 APK 用了特殊的分包或者加固方案classes.dex可能不是标准 dex而是加密后的壳。这种情况下即使你正确解压取出喂给 baksmali 依然会报NotADexFile因为壳把真正的 dex 加密了文件头被改掉了。遇到这种就不是格式排查能解决的了需要先脱壳那是另一个话题。3.3 第三步检查文件是否完整传输损坏很常见文件头对了、也确实是 dex但还是报错那就要怀疑文件完整性。dex 文件头里有文件大小字段和校验和字段dexlib2 在通过魔数检查后会继续校验这些。如果文件在传输、拷贝、下载过程中被截断大小对不上或者校验和不匹配同样会解析失败。判断方法看文件大小是否和文件头里记录的一致。用十六进制编辑器打开偏移 0x20 处是 4 字节的文件大小小端序和你实际看到的文件字节数对比。不一致基本就是文件损坏。另外可以算一下 Adler-32 校验和和偏移 0x08 处的值比对。这些手工算比较麻烦实际排查中更实用的办法是重新从原始来源获取一次文件对比大小。如果两次大小不同说明传输环节有问题。提示从聊天工具、网盘、邮件附件传二进制文件时偶尔会被二次压缩或截断尤其是大文件。做逆向分析尽量用原始下载链接或者校验过哈希的副本。3.4 第四步多 dex 场景别只盯着 classes.dex现代应用普遍是多 dexclasses.dex、classes2.dex、classes3.dex一路排下去。有时候classes.dex是好的但classes2.dex损坏或者被特殊处理过你批量处理时就会在第二个文件上报错。报错信息里如果带了文件名一定要看清楚是哪个文件出的问题别默认是第一个。我遇到过一种情况某个包的主 dex 正常但分包里有一个是空的占位文件0 字节或者只有文件头baksmali 处理到它就炸了。这种时候要么跳过那个文件要么单独分析它为什么是空的。3.5 第五步工具版本和 dex 版本要对得上前面说过版本号的问题。如果你确认文件是合法 dex、完整、魔数正确但工具还是报错就要看 dex 版本和工具版本是否匹配。老版本的 baksmali 可能不认识较新的 dex 版本。解决办法是升级工具链到较新版本或者用对应版本的 smali/baksmali 组合。这里有个实操经验smali 和 baksmali 的版本最好成对使用不要一个很新一个很老。它们共享 dexlib2版本错配时行为可能很诡异。我一般会固定一套经过验证的版本组合放在一个独立目录里避免和其他项目的工具混用。4. 完整实操从拿到文件到成功反编译4.1 环境准备与工具获取我习惯用命令行版的 baksmali/smali轻量、可控。需要 Java 运行环境建议 JDK 8 或以上。工具从官方发布渠道获取 jar 包命名类似baksmali-x.x.x.jar。为了命令好写我会把 jar 包重命名成短名字比如baksmali.jar放在一个固定目录然后把这个目录加进 PATH 或者用绝对路径调用。下面是我常用的目录结构供参考work/ tools/ baksmali.jar smali.jar input/ app.apk out/ dex/ smali/这种结构的好处是输入输出分离出问题容易定位也不会把工作目录搞乱。4.2 从 APK 到 dex 的提取过程假设手里是app.apk第一步解压mkdir -p out/dex unzip -o input/app.apk classes*.dex -d out/dex这里用通配符只提取 dex 文件避免把资源、so 库全解出来占地方。提取完ls -l out/dex看一下有哪些 dex以及大小是否合理。正常classes.dex至少几十 KB如果看到 0 字节或者几字节的文件基本可以判定有问题。然后对每个 dex 做一次类型确认file out/dex/classes.dex期望输出里包含Dalvik dex file字样。如果显示Zip archive data说明你提取错了或者 APK 结构特殊如果显示ASCII text或HTML document说明文件内容根本不是二进制 dex。4.3 用 baksmali 反编译并验证输出确认 dex 合法后执行反编译java -jar tools/baksmali.jar d out/dex/classes.dex -o out/smali参数说明d是 disassemble 子命令-o指定输出目录。执行成功的话out/smali下会出现按包名组织的目录树每个类一个.smali文件。如果这一步报NotADexFile回到第 3 节的排查顺序从文件类型开始重新确认。反编译成功后我习惯先统计一下生成的 smali 文件数量和预期做个粗略对比find out/smali -name *.smali | wc -l数量明显偏少比如只有几个往往意味着 dex 里类很少可能是壳或者占位 dex数量正常几百到几千说明解析是完整的。4.4 修改后回编译的注意事项反编译只是第一步改完 smali 要回编译成 dexjava -jar tools/smali.jar a out/smali -o out/dex/patched.dex回编译时常见的坑是 smali 语法错误报错信息通常比较明确会指出文件和行号。另一个坑是寄存器数量、方法引用等约束改代码时如果新增了局部变量但没调整.registers回编译会失败。这些和NotADexFile不是一类问题但同属反编译工作流顺带提一句。回编译出的 dex 要重新打包进 APK 才能安装。打包时注意保持原 APK 的目录结构和压缩方式尤其是META-INF签名相关文件要重新处理否则安装会失败。这部分涉及签名流程不在本文展开但要知道它不是“把 dex 塞回去”这么简单。5. 常见问题速查与独家避坑心得5.1 报错排查速查表现象最可能原因快速验证方法处理方式报 NotADexFile文件是 .dex 扩展名实际是 zip/apk 改名file看头部是否PK解压取内部 dex报 NotADexFile文件是 APK直接把容器当 dex 传看是否PK\x03\x04开头先解压再处理报 NotADexFile文件头是dex\n文件截断或校验和不符对比文件头记录大小与实际大小重新获取完整文件多 dex 处理中途报错某个分包 dex 损坏或为空逐个file检查跳过或单独分析问题 dex魔数版本号不认识工具版本过旧看魔数中间三位版本升级工具链解压出的 dex 头被改加固/壳加密头部非标准dex\n需先脱壳处理这张表我基本是背下来的实际排查时按行往下对命中率很高。建议你也存一份遇到报错先对表比盲目搜索快得多。5.2 几个容易忽略的细节第一个细节大小写和路径问题。有些工具对路径里的空格、中文、特殊字符处理不好虽然一般不会报NotADexFile但会导致文件读取异常表现出的错误可能很迷惑。我习惯把工作路径控制在纯英文、无空格减少变量。第二个细节符号链接和挂载点。如果你在容器或者网络挂载目录里操作文件读取可能不完整尤其是大文件。曾经有一次在共享目录里处理一个几十 MB 的 dex反复报格式错误换到本地磁盘就好了。这种问题很难从报错本身看出来只能靠经验排除。第三个细节不要用文本编辑器“另存为”二进制文件。有人为了改文件头用文本编辑器打开 dex 改几个字节再保存结果编码转换把整个文件破坏了。改二进制必须用十六进制编辑器而且要确保保存时不做任何编码转换。5.3 我的实操心得做了这么多年逆向我最大的体会是报错信息的第一行往往就是答案但答案用的是工具的语言不是人的语言。NotADexFile翻译过来就是“这不是 dex”那就老老实实去验证“它到底是什么”。很多人跳过验证直接猜原因结果在错误的方向上越走越远。另一个心得是建立自己的最小复现集。我会准备几个样本一个正常 dex、一个 zip 改名的假 dex、一个截断的 dex、一个空文件。遇到新环境或者新工具先用这几个样本跑一遍确认工具行为符合预期再去处理真实文件。这样能把“工具问题”和“文件问题”快速分开排查效率提升非常明显。还有一点别迷信图形化工具的错误提示。有些图形界面的反编译工具会把底层异常吞掉只显示一句“反编译失败”这时候换命令行工具跑一遍往往能看到完整的NotADexFile堆栈定位快得多。命令行虽然看起来原始但信息透明度是图形工具比不了的。最后说个扩展方向如果你经常需要批量处理大量 APK可以把“类型确认、解压、dex 校验、反编译”这几步写成脚本遇到异常文件自动记录并跳过而不是让整个批处理中断。这个脚本不复杂但能省下大量重复劳动也避免因为一个坏文件卡住整批任务。我自己维护的脚本里每个文件处理前都会先做一次头部字节检查不通过的直接进异常清单主流程继续跑效率高很多。
阅读完成 · 觉得有帮助？
