Android ART Oat文件格式简析（下）

最新推荐文章于 2024-08-14 17:34:39 发布
最新推荐文章于 2024-08-14 17:34:39 发布
阅读量6.6k 收藏 3
点赞数 3
分类专栏： Android 文章标签： android art oat 二进制
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Roland_Sun/article/details/25722859
版权

在上篇中，我们分析到了OatFile的begin_和end_变量分别被指定到了符号oatdata和oatlastword指定的位置。那么指定的这一段数据到底是什么呢？本文会接下来分析。

首先来看OatFile::Setup的实现：

bool OatFile::Setup() {
  if (!GetOatHeader().IsValid()) {
    LOG(WARNING) << "Invalid oat magic for " << GetLocation();
    return false;
  }
  ......
GetOatHeader？这是什么东东？接下来看看OatFile::GetOatHeader的实现： 

const OatHeader& OatFile::GetOatHeader() const {
  return *reinterpret_cast<const OatHeader*>(Begin());
}
很简单，就是将前面设置的begin_指向的内存，强制转换成OatHeader。OatHeader又是什么东西？翻出定义看看，只看成员变量定义： 

private:
  uint8_t magic_[4];
  uint8_t version_[4];
  uint32_t adler32_checksum_;

  InstructionSet instruction_set_;
  uint32_t dex_file_count_;
  uint32_t executable_offset_;
  uint32_t interpreter_to_interpreter_bridge_offset_;
  uint32_t interpreter_to_compiled_code_bridge_offset_;
  uint32_t jni_dlsym_lookup_offset_;
  uint32_t portable_resolution_trampoline_offset_;
  uint32_t portable_to_interpreter_bridge_offset_;
  uint32_t quick_resolution_trampoline_offset_;
  uint32_t quick_to_interpreter_bridge_offset_;

  uint32_t image_file_location_oat_checksum_;
  uint32_t image_file_location_oat_data_begin_;
  uint32_t image_file_location_size_;
  uint8_t image_file_location_data_[0];  // note variable width data at end

  DISALLOW_COPY_AND_ASSIGN(OatHeader);
};
我们也对照着把文件中的内容拿出来看看，还是以系统的Boot Oat（system@framework@boot.oat）为例， oatdata值为0x60a9d000，而通过看Program Header，可以知道elf文件起始被指定映射到了0x60a9c000：


所以，可以知道，oatdata指向的位置在文件中的偏移是0x60a9d000-0x60a9c000=0x1000。拿出二进制编辑工具看看那里有什么：


顿时明白了一切，原来所谓oat文件，其实就是影藏在elf文件中的一个子文件，其有特殊的头和数据格式。我们对照着实际的数据一一做个分析：

1）首先是oat文件的magic code：

const uint8_t OatHeader::kOatMagic[] = { 'o', 'a', 't', '\n' };

2）然后是oat文件的版本号： 

const uint8_t OatHeader::kOatVersion[] = { '0', '0', '7', '\0' };

3）接下来是什么checksum，不太重要，暂时忽略；

4）接下来指定oat文件支持的CPU指令集，有以下几种：

enum InstructionSet {
  kNone,
  kArm,
  kThumb2,
  kX86,
  kMips
};

实际文件中的值是2，对应于Thumb2指令集，也是ARM处理器支持的一种指令集啦。

5）接下来是指定Dex文件的数量，看来例子中的oat文件共包含15个Dex文件；

      不明明是oat文件嘛，怎么又来Dex文件啦？其实oat文件是通过Dex文件转换过来的，并且oat文件包含了一个完整的初始的Dex文件，这也就解释了为什么Dex文件转换成oat文件后比原来要大很多。关于这点，先解释到这里，后面碰到的时候还会更具体的分析。

6）可执行部分的偏移，其值是0x18CE000。值得注意的，这里的偏移就不是相对于elf文件头的了，而是相对于oat文件头的。前面说过，oatdata的值为0x60a9d000，所以0x60A9D000+0x18CE000=0x6236B000，正好等于oatexec指向的地址：


而这个虚拟地址0x6236B000，正好是Program Header第三项指定段的起始地址，该段的属性是可读可执行（RE）。真好，全都对应上了。

7）接下来还有一堆偏移，后面碰到再解释；

8）紧接着这些offset的应该是关于Image的一些信息，例子中的文件这些都是0，所以跳过。

好的，解释完OatHeaader后，我们回到OatFile::Setup继续往下看：

  const byte* oat = Begin();
  oat += sizeof(OatHeader);
  if (oat > End()) {
    LOG(ERROR) << "In oat file " << GetLocation() << " found truncated OatHeader";
    return false;
  }

  oat += GetOatHeader().GetImageFileLocationSize();
  if (oat > End()) {
    LOG(ERROR) << "In oat file " << GetLocation() << " found truncated image file location: "
               << reinterpret_cast<const void*>(Begin())
               << "+" << sizeof(OatHeader)
               << "+" << GetOatHeader().GetImageFileLocationSize()
               << "<=" << reinterpret_cast<const void*>(End());
    return false;
  }
  ......
这段代码比较容易理解，局部变量oat先获得Oat文件头的位置，然后加上OatHeader结构体的大小，最后还要加上记录Image文件位置的字符串的长度。这时oat变量指向的内存地址刚好就是跳过OatHeader后的位置，应该就是数据区了。好，接着看： 

  for (size_t i = 0; i < GetOatHeader().GetDexFileCount(); i++) {
    size_t dex_file_location_size = *reinterpret_cast<const uint32_t*>(oat);
    if (dex_file_location_size == 0U) {
      LOG(ERROR) << "In oat file " << GetLocation() << " found OatDexFile # " << i
                 << " with empty location name";
      return false;
    }
    oat += sizeof(dex_file_location_size);
    if (oat > End()) {
      LOG(ERROR) << "In oat file " << GetLocation() << " found OatDexFile # " << i
                 << " truncated after dex file location size";
      return false;
    }

    const char* dex_file_location_data = reinterpret_cast<const char*>(oat);
    oat += dex_file_location_size;
    if (oat > End()) {
      LOG(ERROR) << "In oat file " << GetLocation() << " found OatDexFile # " << i
                 << " with truncated dex file location";
      return false;
    }

    std::string dex_file_location(dex_file_location_data, dex_file_location_size);

    uint32_t dex_file_checksum = *reinterpret_cast<const uint32_t*>(oat);
    oat += sizeof(dex_file_checksum);
    if (oat > End()) {
      LOG(ERROR) << "In oat file " << GetLocation() << " found OatDexFile # " << i
                 << " for "<< dex_file_location
                 << " truncated after dex file checksum";
      return false;
    }

    uint32_t dex_file_offset = *reinterpret_cast<const uint32_t*>(oat);
    if (dex_file_offset == 0U) {
      LOG(ERROR) << "In oat file " << GetLocation() << " found OatDexFile # " << i
                 << " for "<< dex_file_location
                 << " with zero dex file offset";
      return false;
    }
    if (dex_file_offset > Size()) {
      LOG(ERROR) << "In oat file " << GetLocation() << " found OatDexFile # " << i
                 << " for "<< dex_file_location
                 << " with dex file offset" << dex_file_offset << " > " << Size();
      return false;
    }
    oat += sizeof(dex_file_offset);
    if (oat > End()) {
      LOG(ERROR) << "In oat file " << GetLocation() << " found OatDexFile # " << i
                 << " for "<< dex_file_location
                 << " truncated after dex file offset";
      return false;
    }
    ......
  }

最开始，根据前面得到的Dex文件数进行遍历。为了方便理解，我们还是结合实际文件中的值来看：


首先得到的是dex文件位置字符串的大小，这里是0x21，就是有33个字符。紧接着的就是具体的dex文件的位置信息，这里是”/system/framework/core-libart.jar“，可以数数，刚好是33个字符。再下面4个字节是对应此dex文件的checksum。再下面记录的是dex文件相对oat头地址的偏移，此例中是0xD1B0，由于这是相对于oat头位置的偏移，加上oat头相对于elf头的0x1000偏移，所以应该在0xE1B0处找，我们看看那有什么：


看到没有，是不是非常熟悉呢？众里寻他千百度，暮然回首，那人却在灯火阑珊处，这里就是转换前的dex文件所在地呀。好了，接着分析剩下的代码：

    const uint8_t* dex_file_pointer = Begin() + dex_file_offset;
    if (!DexFile::IsMagicValid(dex_file_pointer)) {
      LOG(ERROR) << "In oat file " << GetLocation() << " found OatDexFile # " << i
                 << " for "<< dex_file_location
                 << " with invalid dex file magic: " << dex_file_pointer;
      return false;
    }
    if (!DexFile::IsVersionValid(dex_file_pointer)) {
      LOG(ERROR) << "In oat file " << GetLocation() << " found OatDexFile # " << i
                 << " for "<< dex_file_location
                 << " with invalid dex file version: " << dex_file_pointer;
      return false;
    }
    const DexFile::Header* header = reinterpret_cast<const DexFile::Header*>(dex_file_pointer);
    const uint32_t* methods_offsets_pointer = reinterpret_cast<const uint32_t*>(oat);

    oat += (sizeof(*methods_offsets_pointer) * header->class_defs_size_);
    if (oat > End()) {
      LOG(ERROR) << "In oat file " << GetLocation() << " found OatDexFile # " << i
                 << " for "<< dex_file_location
                 << " with truncated method offsets";
      return false;
    }

    oat_dex_files_.Put(dex_file_location, new OatDexFile(this,
                                                         dex_file_location,
                                                         dex_file_checksum,
                                                         dex_file_pointer,
                                                         methods_offsets_pointer));
  }
此时，局部变量dex_file_pointer已经指向了dex文件的位置。代码会先验证一下该dex文件的magic code和版本号。接着局部变量header被强制类型转换成DexFile::Header类型，表示dex的文件头位置。而另一个局部变量methods_offsets_pointer指向了前面dex文件偏移的后4个字节，局部变量名的意思是指向一个什么方法偏移指针数组，而且这个数组成员的个数，似乎还跟dex文件头中的class_defs_size_有联系。很奇怪是吧，这是什么东西呢？那么 class_defs_size_代表什么意思？熟悉dex文件格式的人应该都知道，这里稍微提一下，它其实就表示dex文件中共包含了几个类。再结合变量名联想一下，猜测这个指针指向的是一个数组，元素个数就是dex文件中定义的类的个数，数组内的元素都是一些偏移，指向的是一组方法，这些方法我猜测就对应的是各个类内部定义的方法。空口无凭，我们来简单验证一下，首先看看对应的dex文件中有几个类：


为什么在这，我不解释。好，一共有0x853个类。而methos_offsets_pointer_指向的值是0x106D。好，我们在简单计算一下0x106D+4*0x853=0x31B9，这个位置有什么呢，我们再看看：


看见了没有，刚好是表示下一个dex文件信息的开头。那数组中具体每个偏移指到的是什么呢？先别忙，我们再接下来分析。OatFile::Setup还剩下最后一部分：

    oat_dex_files_.Put(dex_file_location, new OatDexFile(this,
                                                         dex_file_location,
                                                         dex_file_checksum,
                                                         dex_file_pointer,
                                                         methods_offsets_pointer));
  }
  return true;
}
往自己的内部变量oat_dex_files_中插入一项，插入的是什么呢？创建了一个OatDexFile的对象，这又是什么？从中能不能知道前面问题的答案呢，让我们来看看OatFile::OatDexFile::GetOatClass函数： 

  const OatFile::OatClass* OatFile::OatDexFile::GetOatClass(uint16_t class_def_index) const {
  uint32_t oat_class_offset = oat_class_offsets_pointer_[class_def_index];

  const byte* oat_class_pointer = oat_file_->Begin() + oat_class_offset;
  CHECK_LT(oat_class_pointer, oat_file_->End()) << oat_file_->GetLocation();
  mirror::Class::Status status = *reinterpret_cast<const mirror::Class::Status*>(oat_class_pointer);

  const byte* methods_pointer = oat_class_pointer + sizeof(status);
  CHECK_LT(methods_pointer, oat_file_->End()) << oat_file_->GetLocation();

  return new OatClass(oat_file_,
                      status,
                      reinterpret_cast<const OatMethodOffsets*>(methods_pointer));
}
这个函数是用来在Oat文件中找所谓OatClass的。其中oat_class_offsets_pointer_是前面提到的那个偏移数组，从中我们大致可以了解到底这些偏移指向的东西是什么。首先，根据传入的类定义序号找到相应的偏移，然后加上oat文件头地址，得到绝对地址，付给变量oat_class_pointer，从字面来看是所谓的oat类指针，这又是什么呢？接着强制转换成mirror::Class::Status，这是一个枚举值： 

  enum Status {
    kStatusError = -1,
    kStatusNotReady = 0,
    kStatusIdx = 1,  // Loaded, DEX idx in super_class_type_idx_ and interfaces_type_idx_.
    kStatusLoaded = 2,  // DEX idx values resolved.
    kStatusResolved = 3,  // Part of linking.
    kStatusVerifying = 4,  // In the process of being verified.
    kStatusRetryVerificationAtRuntime = 5,  // Compile time verification failed, retry at runtime.
    kStatusVerifyingAtRuntime = 6,  // Retrying verification at runtime.
    kStatusVerified = 7,  // Logically part of linking; done pre-init.
    kStatusInitializing = 8,  // Class init in progress.
    kStatusInitialized = 9,  // Ready to go.
  };
这些应该表明该类的当前状态。除去 mirror::Class::Status枚举的长度后，接下来指向的是OatMethodOffsets结构体数组，定义如下： 

class PACKED(4) OatMethodOffsets {
 public:
  ......
  uint32_t code_offset_;
  uint32_t frame_size_in_bytes_;
  uint32_t core_spill_mask_;
  uint32_t fp_spill_mask_;
  uint32_t mapping_table_offset_;
  uint32_t vmap_table_offset_;
  uint32_t gc_map_offset_;
};

共由7个变量组成，第一个从字面上看是代码偏移。

我们还是顺着刚才的例子，找第一个偏移看看那到底有什么：


哦，看来该类应该已经初始化完成了（状态值为9），第一个方法的代码段偏移是0x18CE045，第二个方法的代码段偏移是0x18CE0D4。
好了，分析到这里应该已经差不多了，下面简单总结一下什么是oat文件，以及它的一些特性：

1）oat文件其实是包含在一个elf文件中的，符号oatdata和oatlastword分别指定了oat文件在elf文件中的头和尾的位置，符号oatexec指向可执行段的位置；

2）对于包含oat的elf文件来说，如果是Boot Oat，则其是要被加载到一个固定的地址上的，具体来说是紧接着Image文件之后。而对于普通应用程序的oat文件来说，可以被加载到内存中的任何位置；

3）oat文件有自己的头和格式，并且其内部包含了一个完整的dex文件。

Roland_Sun
关注
专栏目录
ART世界探险(11) - OAT文件格式分析
lusing的专栏
08-03 2564
既然是要探险，咱们就保持一定的深度，起码将来可以做个基于ART的黑客之类的。 所以我们针对细节多下一些工夫，先仔细分析一下OAT文件的格式。
ART世界探险(12) - OAT文件分析(2) - ELF文件头分析(中)
weixin_33850890的博客
08-04 216
ART世界探险(12) - OAT文件分析(2) - ELF文件头分析(中) 段(section)的概念 一块内存分配给应用程序之后，从代码的组织上，我们就有将它们分段的需求。比如，可以分为代码段，数据段，只读数据段，堆栈段，未初始化的数据段等等。 在GAS汇编器中，我们通过.section伪指令来指定段名。ARM编译器我买不起，我就忽略它了。 标准se...
主存容量、CPU主频、时钟周期、时钟周期数、CPI、IPS、MIPS、CPU执行时间的相关计算
心碎烤肠的博客
06-26 1177
在描述存储容量、文件大小等时，K、M、G、T通常用2的幂次表示，如 1Kb = 2¹⁰b； 在描述速率、频率等时，k、M、G、T通常用 10 的幂次表示，如 1kb/s = 10³b/s。 通常前者用大写的K，后者用小写的k，但其他前缀均为大写，表示的含义取决于所用的场景；
Android DEX相关，ART加载OAT文件
greatwgb的博客
09-12 383
Android DEX相关，ART加载OAT文件
oat文件结构与内存映射
weixin_34319111的博客
05-13 445
转载于:https://www.cnblogs.com/YYPapa/p/6850963.html
Android动态加载oat文件总结一
cssufo的专栏
12-17 1061
Andriod的Dalvik时代已经过去，Art时代的到来，引发了一些列的变化，或许在开发者的眼里，没有任何的改变，概念上的一些解释也只是入耳即过，但是作为学习安全的一名菜鸟级人物，虽说没有大牛们的高瞻远瞩，但是也略有自己的一点看法与总结。     早在Dalvik上就有动态加载这么回事，当然到了Art时代，动态加载依旧存在，好了，现在开始开门见山地来说说吧！     Dalvik上地动态加载
Android运行时ART加载OAT文件的过程分析
02-20
OAT文件是一种Android私有ELF文件格式，它不仅包含有从DEX文件翻译而来的本地机器指令，还包含有原来的DEX文件内容。这使得我们无需重新编译原有的APK就可以让它正常地在ART里面运行，也就是我们不需要改变原来的APK...
oat2dexes:从 Android ART .oat.odex 文件中提取 .dex 文件
07-10
从 Android ART .oat/.odex 文件中提取 .dex 文件 这个怎么运作？ DEX 文件嵌入在 Android ART .oat/.odex 文件中。 oat2dexes寻找 DEX 魔法“dex\n035\0”。 如何使用？ $ file file.odex file.odex: ELF 32-bit...
android oat如何提取dex文件字节码,ART、OAT格式介绍与dex文件提取
weixin_32926649的博客
05-25 1090
dex文件经过dex2oat编译，会生成.art、.oat两个文件，oat是一个android定制的elf文件，原始dex也保存在其中。8.0后，dex单独保存到.vdex文件中。art文件类似于一个内存映像，缓存常用的ArtField、ArtMethod、DexCache等内容，加载后可直接使用，避免解析耗时。art文件格式介绍以boot.art为例，它分为Image Section和Bitma...
第四章 常见的 Android 文件格式（七）（OAT）
zlmm741的博客
03-10 4116
文章目录@[toc]OATART 虚拟机生成 OAT 文件OAT 文件格式将 OAT 文件转换成 DEX 文件 OAT OAT 文件是在 Android 4.4 中引入的。OAT 是优化过的、用于 ART 虚拟机执行的 DEX 文件，类似 Dalvik 的 ODEX 对新版本的 Android 程序进行安全研究，无论是对 OAT 文件的 Hook 还是加密保护，都要了解 OAT 文件格式 A...
Android ART dex2oat 浅析
最新发布
新程序圆
08-14 456
Dex2oat（Dalvik Executable to Optimized Art File）是用于将DEX文件进行编译优化的工具。在Android设备中，该程序位于。
【Android 逆向】ART 脱壳 ( DexClassLoader 脱壳 | oat_file_assistant.cc 中涉及的 oat 文件生成流程 )
让 学习 成为一种 习惯 ( 韩曙亮 の 技术博客 )
12-15 1780
前言、 一、dalvik_system_DexFile.cc#DexFile_openDexFileNative 函数分析、 二、oat_file_manager.cc#OpenDexFilesFromOat 函数分析、 三、oat_file_assistant.cc#MakeUpToDate 函数分析、 四、oat_file_assistant.cc#GenerateOatFileNoChecks 函数分析、 五、oat_file_assistant.cc#Dex2Oat 函数分析
【个人笔记二】ART系统OAT文件的加载解析
朱小南的博客
08-14 2595
在ART上用YAHFA、Legend以及一个java层实现的Andix:http://weishu.me/2017/03/20/dive-into-art-hello-world/，发现除了framework层的类（如telephonymanager）和应用中的类有效外，对于java核心库的类（如IOBridge和Class等）的hook都无效，所以我就以telephonymanager和IOBridge这两个类为例
为什么“15。，android面试宝典铁道出版社
m0_60607245的博客
03-28 365
面试题集可以帮助你查漏补缺，有方向有针对性的学习，为之后进大厂做准备。但是如果你仅仅是看一遍，而不去学习和深究。那么这份面试题对你的帮助会很有限。最终还是要靠资深技术水平说话。网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。建议先制定学习计划，根据学习计划把知识点关联起来，形成一个系统化的知识体系。学习方向很容易规划，但是如果只通过碎片化的学习，对自己的提升是很慢的。
[C++][转载]一个轻量级高性能的 C++ Web 框架oat++
FL1623863129的博客
08-17 1983
要深入了解 Oat++，
稳定性问题总结
xiaolli的专栏
01-30 6975
稳定性问题比较杂，且很多是概率性问题，没有统一处理方式，需要针对具体的问题，具体分析， 必现的问题较易解决，针对当前代码添加各种调试log，一步步debug去定位，过程虽然可能慢点，但一般都会解决。 但针对偶发性的概率问题，则较为麻烦，依赖于大量的测试复现，然后统计 分析当前抓取到的 events、system 等log中，找到复现的步骤，然后去定位。 且针对与这种概
关于android art模式提取的OAT转dex
zhangmiaoping23的专栏
04-20 3613
三星 android 6.0 系统上提取出的三星软件安装包是.odex后缀的 但是文件头为elf，而不是dey.036 查了相关资料后发现是art模式会将dex转成oat模式,那如何逆向呢 方案： 1.ExtractDexFromOat + jeb/jax https://github.com/ManyFace/ExtractDexFromOat 2.DEX/AP...
Android 虚拟机 (Dalvik & ART)
Elson的博客
10-22 4579
我们知道Android的程序虽然也是使用Java/Kotlin语言编码，并生成.class字节码，但并不能运行在JVM上，而是运行在自己的VM上。而Android程序之所以不能在JVM上运行的根本原因是.class字节码文件并不是Android的最终可执行文件，而是一个过渡产物，最终会生成dex文件在Android VM上执行。Dalvik 虚拟机和 ART 虚拟机。
ART加载OAT文件的过程分析
Invoker123的博客
03-30 1895
  OAT文件是一种Android引入ART虚拟机后的一种私有ELF文件格式,它不仅包含有从DEX文件翻译而来的本地机器指令，还包含有原来的DEX文件内容。Android使用/system/bin/dex2oat（我们也可以编译出debug版本的dex2oatd）来将DEX文件编译成OAT文件，dex2oat的主入口为main函数： /art/dex2oat/dex2oat.cc int ...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值