如何反编译Android 5.0 framework.docVIP

如何反编译Android 5.0 framework 文/腾讯优测 储俊雄 在Android平台，对于和硬件交互相关的模块来说，比如：和双卡对应的Telephony模块、和拍照对应的Camera模块，以及Bluetooth模块等等，不同厂商会不同程度的修改Android framework层对应的原生模块代码来达到他们自己的目的，这就给应用层的开发人员带来了让他们很头疼的适配问题，严重会导致crash等问题。为了更好的适配，我们不得不对framework层进行反编译，在Android 更新到5.0后，开发人员对framework的反编译也出现了新的变化。 相关背景介绍 在5.0以前，我们可以直接从手机system目录导出的framework文件夹根目录里找到相关的odex文件或者相关dex文件（解压jar文件或apk文件得到），然后通过smali和dex2jar等工具就可以成功反编译得到我们所需要的东西。但到了5.0，出现了两个问题。 以前分散在framework文件夹根目录里的那些odex文件全部集中在了framework文件夹中的arm（或arm64）子文件夹中，而且通过正常的反编译发现这些odex并不是像5.0以前一样是我们所需要的东西。 （arm文件夹里的各种odex文件） 在arm（arm64）子文件中出现了两个我们在5.0以前没有见过的东西:boot.oat文件和boot.art文件，这两个文件引起了我们的兴趣，也是我们接下来分析的重点。 （arm文件夹里重要的boot.oat文件和boot.art文件） 对oat文件的分析 说到这个oat文件和art文件，我们不能不提Google在4.4版本以后新引入的ART运行时，这里简要的说一下：我们都知道在4.4以前，Android 应用程序运行的核心基础是Dalvik虚拟机，这个Dalvik虚拟机原先是apache开源的一个JVM的优化版本，而Google又对Dalvik虚拟机进行了特别的优化来适应Android系统，所以Dalvik虚拟机本质就是JVM，尽管Google花了大力气优化Dalvik虚拟机，但是效果目前来看还不能让Google满意，为了Android系统的流畅度能更上一层楼，在Android进化到4.4版本时，Google决定抛弃Dalvik虚拟机引入全新的ART运行时，其实，ART运行时依然还是Java虚拟机的实现，只是ART运行时更高效更好用。 （左边对应Dalvik虚拟机，右边对应ART运行时【原图出处：罗升阳——Android ART运行时无缝替换Dalvik虚拟机的过程分析】） 和Dalvik虚拟机相比，ART运行时执行的是本地机器码，虽然Dalvik虚拟机也使用JIT（Just-In-Time）将dex字节码翻译成本地机器码，但是是在应用程序的运行过程中进行的，所以在效率方面还无法和ART运行时相比，ART运行时会在应用程序安装的时候就通过dex2oat将dex字节码翻译成本地机器码，而这个由ART翻译出来的本地机器码会对应着一个oat文件。 （函数run_dex2oat通过调用dex2oat来将dex字节码翻译成本地机器码） 其实，oat文件是一种特殊的ELF文件（关于ELF文件的具体内容可以Google相关内容），通过前面的介绍可以知道它包含本地机器码（从dex翻译而来），此外还包含有原来的dex文件内容，本质上它依然是一种预编译文件。这就告诉我们，oat文件就是把过去的很多dex文件一起合并输入然后由ART运行时在安装时翻译成本地的机器码然后再打包转换输出就OK了，同样的道理，我们知道system分区的文件都是在厂商在压制ROM时打包进去的， framework文件夹里面的内容尤其是各种dex文件等会在系统启动后通过arm（或arm64）子文件夹里的boot.art文件来指定启动一个ART运行时实例，然后把这些classes.dex等dex文件合并输入到ART再翻译成本地机器码打包成oat文件，这就是我们需要的核心文件boot.oat的大致生成过程（具体的过程比较复杂，详细情况可以自行Google相关内容）。到此，我们简单的介绍了oat文件的来历，oat文件里有什么，以及oat文件的生成过程。 三． 反编译的核心：“拆开”oat文件 有了以上的了解，我们可以知道，反编译boot.oat文件的核心步骤就是把之前很多dex合并起来生成的oat文件拆开，之前我们在oat是怎么来的时候提到过，ART运行时会通过dex2oat把很多dex文件合并打包然后翻译转换成oat，所以相同的道理，如果要有一个oat2dex工具就好了，可喜的是，真的有oat2dex工具的存在，有了这个工具，我们就可以把我们需要的boot.o