文档介绍：Android 应用程序的补丁方法图/文非虫能完成这篇文章, 打心底里十分高兴, 一直在研究 Android 程序的逆向与解密方法, 每次都使用传统的反编译与回编 APK ,这样需要花费大量时间去测试,而且很多时候反编译出的程序无法回编回去,这着实让我郁闷了好些日子。当时就在想, Android 程序如果能像 Windows 程序一样可以打补丁的话该多好啊, 这样测试程序就不用反复的反编译程序了。为了完成设想,我开始对 DEX 文件进行研究,在经过一个多月的慢推慢磨后终于将 APK 程序的两种补丁方法研究出来了,特此拿来与大家分享。 Dex 文件结构研究 Windows 的程序,首先要掌握 PE 文件格式,到了 Linux/Unix 环境,又必须掌握 ELF 文件格式。因为它们都是分析自身所在系统程序的基础。不了解它, 就像中国人不了解汉字, 美国人不了解英语, 太阳不了解月亮,丈夫不了解妻子...... 也正因为如此,在分析 Android 软件之前,了解 Dalvik DEX 文件格式是很有必要的。在以往的文章中,我跟大家曾多次提到过 DEX 文件,今天,我就带领大家一起来揭开它的神秘面纱。随着 Android 系统版本的增加,一些结构也有了微妙的变化,本文所描述的 DEX 文件格式源于 Android 源代码中的“ dalvik\libdex\ ”文件所提供的信息。另外,由于本人知识也极有限的,所以,在理解与表述方面出现错误也再所难免,如果大家发现文中有任何不对的地方,也请批评指出。 DEX 文件作为 APK 程序的“可执行体”,里面存放着 APK 所有的包、类以及方法信息。 DEX 文件的完整定义格式如下: struct DexFile { /* directly-mapped "opt" header */ const DexOptHeader* pOptHeader; /* pointers to directly-mapped structs and arrays in base DEX */ const DexHeader* pHeader; const DexStringId* pStringIds; const DexTypeId* pTypeIds; const DexFieldId* pFieldIds; const DexMethodId* pMethodIds; const DexProtoId* pProtoIds; const DexClassDef* pClassDefs; const DexLink* pLinkData; /* ???* These are mapped out of the "auxillary" section, and may not be * included in the file. ???*/ const DexClassLookup* pClassLookup; const void* pRegisterMapPool; // RegisterMapClassPool /* points to start of DEX file data */ const u1* baseAddr; /* track memory overhead for auxillary structures */ int overhead; /* additional app-specific data structures associated with the DEX */ //void* auxData; }; DexOptHeader 这里我们先不讨论, 如结构中注释所说, DexLink 下面的四个字段也不属于原始的 DEX 文件。原始的 DEX 文件只包含下面几个字段: const DexHeader* pHeader; const DexStringId* pStringIds; const DexTypeId* pTypeIds; const DexFieldId* pFieldIds; const DexMethodId* pMethodIds; const DexProtoId* pProtoIds; const DexClassDef* pClassDefs; const DexLink* pLinkData; 整个 DEX 文件分成了头和体两个部分, DexHeader 存放着 DEX 文件的校验以及各数据类型起始地址、偏移量等信息,其它的字段即为 DexBody 部分。在“ ”文件中 DexHeader 的定义如下: struct DexHeader { u1 magic[8]; /* includes versi