共 2 篇相关文章
这篇讲的是 Android 系统里 Dex 文件格式的深度解析。作者从一个简单的 Java 程序生成 Dex 文件开始，聚焦分析了文件头这个核心区域的内部构造。 文章详细解读了魔数、校验码和 SHA-1 等关键字段。特别是为了确保文件安全，系统设计了双重校验机制：先用 Adler32 快速筛查文件是否损坏，再用 SHA-1 进行高精度的完整性验证。这种分层的设计思路既高效又可靠。 此外，文章还剖析了文件头中字符串索引的存储方式。作者指出，Dex 文件使用了 uleb128 变长编码来表示字符串长度，这种精巧的编码能在绝大多数情况下节省空间，是针对移动端场景的务实优化。 通过对这些底层细节的拆解，文章揭示了 Dex 文件如何兼顾执行效率与安全性。理解这些格式规范，是深入进行 Android 应用安全分析和性能调优的基础。
这篇讲的是作者对一个加壳Android应用进行手动脱壳、还原出完整dex文件的完整实践。APK的dex文件只有1KB多，显然代码被加密保护了，真正的内容需要在运行时解密和动态加载。 作者的核心思路是“在运行时拦截解密后的代码”。他没有用一键脱壳工具，而是通过经典的调试器组合来亲手捕获。具体流程是：先部署IDA的android_server进行远程调试，通过adb和jdb完成进程附加，然后在关键的动态链接库`libdvm.so`中，找到了负责加载dex文件的`dvmDexFileOpenPartial`函数并下断点。这个函数在程序运行时会被调用，其参数就包含了内存中解密后的dex文件地址。 断点命中后，通过查看寄存器R0的值，就能在内存中看到完整的dex数据结构。最后，利用一个简单的IDC脚本，根据dex文件头部记录的文件大小信息，将这段内存区域完整地dump出来，就得到了一个可用的dex文件。 整个操作像一次精密的追踪：从静态分析发现异常，到动态调试定位关键函数，再到内存取证完成“抓捕”。它演示了一种不依赖特定脱壳工具、而是基于对Android运行时机制理解的通用思路。
