Android安全交流群：478084054
先贴老罗的一张图：
再摘一段老罗的描述：“作为Android私有的一种ELF文件，OAT文件包含有两个特殊的段oatdata和oatexec，前者包含有用来生成本地机器指令的dex文件内容，后者包含生成的本地机器指令，它们之间的关系通过储存在oatdata段前面的oat头部描述。此外，在OAT文件的dynamic段，导出了三个符号oatdata、oatexec和oatlastword，它们的值就是用来界定oatdata段和oatexec段的起止位置的。”
老罗的这段描述，有些地方稍微有点不太准确。
符号oatdata、oatexec和oatlastword是动态符号表(.dynsym)中导出的，不是dynamic段导出的。
另外，oatdata和oatexec并不是OAT(ELF格式)文件中两个独立的段，而是分别位于第1个和第2个LOAD段中，这一点对比上面的.dynsym和下面的Program Headers Table就可以看出来了。
如何在OAT文件中找到一个类方法的本地机器指令呢？还是贴老罗的一幅图，再结合上图和老罗的一段描述(感谢老罗的博客)就可以大概理解了。
“首先根据类签名信息从包含在OAT文件里面的DEX文件中查找目标Class的编号，然后再根据这个编号在OAT文件中找到对应的OatClass。接下来再根据方法签名从包含在OAT文件里面的DEX文件中查找目标方法的编号，然后再根据这个编号在前面找到的OatClass中找到对应的OatMethod。有了这个OatMethod之后，我们就根据它的成员变量begin_和code_offset_找到目标类方法的本地机器指令了。”
下面以Android 6源码为例，看一下OatFile::Open函数(art/runtime/Oat_file.cc)：
可以看到，有两个函数可以加载OAT文件：OpenDlopen和OpenElfFile。这两个函数有什么区别？继续摘老罗的博客(非原文，简化了一下)：“ART运行时会为类方法生成相应的本地机器指令，这些本地机器指令可能会调用外部函数，这就涉及到模块依赖问题，就好像我们在编写程序时，需要依赖C库提供的接口一样。ART运行时支持两种类型的Backend：Portable和Quick。Portable类型的Backend通过静态链接器生成本地机器指令，通过重定位技术来处理模块依赖问题。这对熟悉linker动态加载过程的程序员来说很容易理解。而Quick类型的Backend生成的本地机器指令用另外一种方式来处理模块之间的依赖关系。简单的说，就是ART运行时会在每一个线程的TLS（线程本地区域）提供一个函数表，本地机器指令通过它来调用其它模块的函数。这使得生成的OAT文件在加载时不需要再处理模块之间的依赖关系，也就省去了重定位，不需要通过系统的动态链接器提供的dlopen来加载。这样OAT文件在加载时就会更快，这也是称其为Quick的缘由。”。
仔细看一下OatFile::Open，会发现参数executable为false时，不会执行OpenDlopen。什么情况下executable为false？如果是dex2oat过程中调用的OatFile::Open，参数executable就为false。
调用OpenDlopen加载非executable的OAT文件可能会失败，具体看函数注释：
主要看OpenElfFile函数：
继续跟OatFile::ElfFileOpen（省去了一些出错处理代码）：
先Open文件，再Load加载，然后调用FindDynamicSymbolAddress找到OAT文件中的oatdata、oatlastword、oatbss、oatbsslastword四个符号的地址。
其中Open和Load的过程类似于linker的dlopen过程的，但没有重定位，仅仅是将OAT文件的LOAD段映射到内存，并解析出字符串表、符号表等重要信息的地址等等。
这里摘录Roland_Sun博客对这个过程的一点总结：
1）如果elf文件中包含了虚拟地址为0的PT_LOAD段，则证明它不是Boot Oat，而是一个普通的应用程序的oat，这时候该elf文件无所谓被映射到内存中的任何地方，其虚拟地址（p_vaddr）中记录的是该段相对于文件头的偏移；
2）如果elf文件中没有包含任何虚拟地址为0的PT_LOAD段，则证明它是一个Boot Oat，必须被加载到一个指定位置（实际是紧接在Image之后），其虚拟地址（p_vaddr）中记录的就是实际要被加载的绝对地址。
Boot OAT的Program Header：
一个普通应用程序的OAT的Program Header：
回到OatFile::ElfFileOpen，继续看Setup函数。下篇笔记继续。
