本文详细分析了 Linker 对 SO 文件的装载和链接过程，最后对 SO 加壳的关键技术进行了简要的介绍。
本文来自于腾讯bugly开发者社区，非经作者同意，请勿转载，原文地址：http://dev.qq.com/topic/57e3a3bc42eb88da6d4be143
作者：王赛
1. 前言
Android 系统安全愈发重要，像传统pc安全的可执行文件加固一样，应用加固是Android系统安全中非常重要的一环。目前Android 应用加固可以分为dex加固和Native加固，Native 加固的保护对象为 Native 层的 SO 文件，使用加壳、反调试、混淆、VM 等手段增加SO文件的反编译难度。目前最主流的 SO 文件保护方案还是加壳技术， 在SO文件加壳和脱壳的攻防技术领域，最重要的基础的便是对于 Linker 即装载链接机制的理解。对于非安全方向开发者，深刻理解系统的装载与链接机制也是进阶的必要条件。
对于 Linker 的学习，还应该包括 Linker 自举、可执行文件的加载等技术，但是限于本人的技术水平，本文的讨论范围限定在 SO 文件的加载，也就是在调用
dlopen("libxx.SO")
之后，Linker 的处理过程。
本文基于 Android 5.0 AOSP 源码，仅针对 ARM 平台，为了增强可读性，文中列举的源码均经过删减，去除了其他 CPU 架构的相关源码以及错误处理。
P.S. :阅读本文的读者需要对 ELF 文件结构有一定的了解。
2. SO 的装载与链接
2.1 整体流程说明
1. do_dlopen
调用 dl_open 后，中间经过 dlopen_ext, 到达第一个主要函数 do_dlopen:
soinfo* do_dlopen(const char* name, int flags, const Android_dlextinfo* extinfo) {
protect_data(PROT_READ | PROT_WRITE);
soinfo* si = find_library(name, flags, extinfo); // 查找 SO
if (si != NULL) {
si->CallConstructors(); // 调用 SO 的 init 函数
}
protect_data(PROT_READ);
return si;
}
do_dlopen 调用了两个重要的函数，第一个是find_library, 第二个是 soinfo 的成员函数 CallConstructors，find_library 函数是 SO 装载链接的后续函数， 完成 SO 的装载链接后， 通过 CallConstructors 调用 SO 的初始化函数。
2. find_library_internal
find_library 直接调用了 find_library_internal，下面直接看 find_library_internal函数:
static soinfo* find_library_internal(const char* name, int dlflags, const Android_dlextinfo* extinfo) {
if (name == NULL) {
return somain;
}
soinfo* si = find_loaded_library_by_name(name); // 判断 SO 是否已经加载
if (si == NULL) {
TRACE("[ '%s' has not been found by name. Trying harder...]", name);
si = load_library(name, dlflags, extinfo); // 继续 SO 的加载流程
}
if (si != NULL && (si->flags & FLAG_LINKED) == 0) {
DL_ERR("recursive link to \"%s\"", si->name);
return NULL;
}
return si;
}
find_library_internal 首先通过 find_loaded_library_by_name 函数判断目标 SO 是否已经加载，如果已经加载则直接返回对应的soinfo指针，没有加载的话则调用 load_library 继续加载流程，下面看 load_library 函数。
3. load_library
static soinfo* load_library(const char* name, int dlflags, const Android_dlextinfo* extinfo) {
int fd = -1;
...
// Open the file.
fd = open_library(name); // 打开 SO 文件，获得文件描述符 fd
ElfReader elf_reader(name, fd); // 创建 ElfReader 对象
...
// Read the ELF header and load the segments.
if (!elf_reader.Load(extinfo)) { // 使用 ElfReader 的 Load 方法，完成 SO 装载
return NULL;
}
soinfo* si = soinfo_alloc(SEARCH_NAME(name), &file_stat); // 为 SO 分配新的 soinfo 结构
if (si == NULL) {
return NULL;
}
si->base = elf_reader.load_start(); // 根据装载结果，更新 soinfo 的成员变量
si->size = elf_reader.load_size();
si->load_bias = elf_reader.load_bias();
si->phnum = elf_reader.phdr_count();
si->phdr = elf_reader.loaded_phdr();
...
if (!soinfo_link_image(si, extinfo)) { // 调用 soinfo_link_image 完成 SO 的链接过程
soinfo_free(si);
return NULL;
}
return si;
}
load_library 函数呈现了 SO 装载链接的整个流程，主要有3步:
- 装载:创建ElfReader对象，通过 ElfReader 对象的 Load 方法将 SO 文件装载到内存
- 分配soinfo:调用 soinfo_alloc 函数为 SO 分配新的 soinfo 结构，并按照装载结果更新相应的成员变量
- 链接: 调用 soinfo_link_image 完成 SO 的链接
通过前面的分析，可以看到， load_library 函数中包含了 SO 装载链接的主要过程, 后文主要通过分析 ElfReader 类和 soinfo_link_image 函数, 来分别介绍 SO 的装载和链接过程。
2.2 装载
在 load_library 中， 首先初始化 elf_reader 对象, 第一个参数为 SO 的名字， 第二个参数为文件描述符 fd:
ElfReader elf_reader(name, fd)
之后调用 ElfReader 的 load 方法装载 SO。
...
// Read the ELF header and load the segments.
if (!elf_reader.Load(extinfo)) {
return NULL;
}
...
ElfReader::Load 方法如下:
bool ElfReader::Load(const Android_dlextinfo* extinfo) {
return ReadElfHeader() && // 读取 elf header
VerifyElfHeader() && // 验证 elf header
ReadProgramHeader() && // 读取 program header
ReserveAddressSpace(extinfo) &&// 分配空间
LoadSegments() && // 按照 program header 指示装载 segments
FindPhdr(); // 找到装载后的 phdr 地址
}
ElfReader::Load 方法首先读取 SO 的elf header，再对elf header进行验证，之后读取program header，根据program header 计算 SO 需要的内存大小并分配相应的空间，紧接着将 SO 按照以 segment 为单位装载到内存，最后在装载到内存的 SO 中找到program header，方便之后的链接过程使用。
下面深入 ElfReader 的这几个成员函数进行详细介绍。
2.2.1 read&verify elfheader
bool ElfReader::ReadElfHeader() {
ssize_t rc = read(fd_, &header_, sizeof(header_));
if (rc != sizeof(header_)) {
return false;
}
return true;
}
ReadElfHeader 使用 read 直接从 SO 文件中将 elfheader 读取 header 中，header_ 为 ElfReader 的成员变量，类型为 Elf32_Ehdr，通过 header 可以方便的访问 elf header中各个字段，elf header中包含有 program header table、section header table等重要信息。
对 elf header 的验证包括:
- magic字节
- 32/64 bit 与当前平台是否一致
- 大小端
- 类型:可执行文件、SO …
- 版本:一般为 1，表示当前版本
- 平台:ARM、x86、amd64 …
有任何错误都会导致加载失败。
2.2.2 Read ProgramHeader
bool ElfReader::ReadProgramHeader() {
phdr_num_ = header_.e_phnum; // program header 数量
// mmap 要求页对齐
ElfW(Addr) page_min = PAGE_START(header_.e_phoff);
ElfW(Addr) page_max = PAGE_END(header_.e_phoff + (phdr_num_ * sizeof(ElfW(Phdr))));
ElfW(Addr) page_offset = PAGE_OFFSET(header_.e_phoff);
phdr_size_ = page_max - page_min;
// 使用 mmap 将 program header 映射到内存
void* mmap_result = mmap(NULL, phdr_size_, PROT_READ, MAP_PRIVATE, fd_, page_min);
phdr_mmap_ = mmap_result;
// ElfReader 的成员变量 phdr_table_ 指向program header table
phdr_table_ = reinterpret_cast<ElfW(Phdr)*>(reinterpret_cast<char*>(mmap_result) + page_offset);
return true;
}
将 program header 在内存中单独映射一份，用于解析program header 时临时使用，在 SO 装载到内存后，便会释放这块内存，转而使用装载后的 SO 中的program header。
2.2.3 reserve space & 计算 load size
bool ElfReader::ReserveAddressSpace(const Android_dlextinfo* extinfo) {
ElfW(Addr) min_vaddr;
// 计算 加载SO 需要的空间大小
load_size_ = phdr_table_get_load_size(phdr_table_, phdr_num_, &min_vaddr);
// min_vaddr 一般情况为零，如果不是则表明 SO 指定了加载基址
uint8_t* addr = reinterpret_cast<uint8_t*>(min_vaddr);
void* start;
int mmap_flags = MAP_PRIVATE | MAP_ANONYMOUS;
start = mmap(addr, load_size_, PROT_NONE, mmap_flags, -1, 0);
load_start_ = start;
load_bias_ = reinterpret_cast<uint8_t*>(start) - addr;
return true;
}
首先调用 phdr_table_get_load_size 函数获取 SO 在内存中需要的空间load_size，然后使用 mmap 匿名映射，预留出相应的空间。
关于loadbias: SO 可以指定加载基址，但是 SO 指定的加载基址可能不是页对齐的，这种情况会导致实际映射地址和指定的加载地址有一个偏差，这个偏差便是，之后在针对虚拟地址进行计算时需要使用load_bias_
修正。普通的 SO 都不会指定加载基址，这时load_bias_
，则min_vaddr = 0
，即load_bias_ = load_start_
等于加载基址，下文会将load_bias_
直接称为基址。load_bias_
下面深入
phdr_table_get_load_size
分析一下 load_size 的计算:使用成员变量 phdr_table 遍历所有的program header， 找到所有类型为 PT_LOAD 的 segment 的 p_vaddr 的最小值，p_vaddr + p_memsz 的最大值，分别作为 min_vaddr 和 max_vaddr，在将两个值分别对齐到页首和页尾，最终使用对齐后的 max_vaddr - min_vaddr 得到 load_size。
size_t phdr_table_get_load_size(const ElfW(Phdr)* phdr_table, size_t phdr_count,
ElfW(Addr)* out_min_vaddr,
ElfW(Addr)* out_max_vaddr) {
ElfW(Addr) min_vaddr = UINTPTR_MAX;
ElfW(Addr) max_vaddr = 0;
bool found_pt_load = false;
for (size_t i = 0; i < phdr_count; ++i) { // 遍历 program header
const ElfW(Phdr)* phdr = &phdr_table[i];
if (phdr->p_type != PT_LOAD) {
continue;
}
found_pt_load = true;
if (phdr->p_vaddr < min_vaddr) {
min_vaddr = phdr->p_vaddr; // 记录最小的虚拟地址
}
if (phdr->p_vaddr + phdr->p_memsz > max_vaddr) {
max_vaddr = phdr->p_vaddr + phdr->p_memsz; // 记录最大的虚拟地址
}
}
if (!found_pt_load) {
min_vaddr = 0;
}
min_vaddr = PAGE_START(min_vaddr); // 页对齐
max_vaddr = PAGE_END(max_vaddr); // 页对齐
if (out_min_vaddr != NULL) {
*out_min_vaddr = min_vaddr;
}
if (out_max_vaddr != NULL) {
*out_max_vaddr = max_vaddr;
}
return max_vaddr - min_vaddr; // load_size = max_vaddr - min_vaddr
}
2.2.4 Load Segments
遍历 program header table，找到类型为 PT_LOAD 的 segment:
- 计算 segment 在内存空间中的起始地址 segstart 和结束地址 seg_end，seg_start 等于虚拟偏移加上基址load_bias，同时由于 mmap 的要求，都要对齐到页边界得到 seg_page_start 和 seg_page_end。
- 计算 segment 在文件中的页对齐后的起始地址 file_page_start 和长度 file_length。
- 使用 mmap 将 segment 映射到内存，指定映射地址为 seg_page_start，长度为 file_length，文件偏移为 file_page_start。
bool ElfReader::LoadSegments() {
for (size_t i = 0; i < phdr_num_; ++i) {
const ElfW(Phdr)* phdr = &phdr_table_[i];
if (phdr->p_type != PT_LOAD) {
continue;
}
// Segment 在内存中的地址.
ElfW(Addr) seg_start = phdr->p_vaddr + load_bias_;
ElfW(Addr) seg_end = seg_start + phdr->p_memsz;
ElfW(Addr) seg_page_start = PAGE_START(seg_start);
ElfW(Addr) seg_page_end = PAGE_END(seg_end);
ElfW(Addr) seg_file_end = seg_start + phdr->p_filesz;
// 文件偏移
ElfW(Addr) file_start = phdr->p_offset;
ElfW(Addr) file_end = file_start + phdr->p_filesz;
ElfW(Addr) file_page_start = PAGE_START(file_start);
ElfW(Addr) file_length = file_end - file_page_start;
if (file_length != 0) {
// 将文件中的 segment 映射到内存
void* seg_addr = mmap(reinterpret_cast<void*>(seg_page_start),
file_length,
PFLAGS_TO_PROT(phdr->p_flags),
MAP_FIXED|MAP_PRIVATE,
fd_,
file_page_start);
}
// 如果 segment 可写, 并且没有在页边界结束，那么就将 segemnt end 到页边界的内存清零。
if ((phdr->p_flags & PF_W) != 0 && PAGE_OFFSET(seg_file_end) > 0) {
memset(reinterpret_cast<void*>(seg_file_end), 0, PAGE_SIZE - PAGE_OFFSET(seg_file_end));
}
seg_file_end = PAGE_END(seg_file_end);
// 将 (内存长度 - 文件长度) 对应的内存进行匿名映射
if (seg_page_end > seg_file_end) {
void* zeromap = mmap(reinterpret_cast<void*>(seg_file_end),
seg_page_end - seg_file_end,
PFLAGS_TO_PROT(phdr->p_flags),
MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE,
-1,
0);
}
}
return true;
}
2.3 分配 soinfo
load_library 在调用 load_segments 完成装载后，接着调用 soinfo_alloc 函数为目标SO分配soinfo，soinfo_alloc 函数实现如下:
static soinfo* soinfo_alloc(const char* name, struct stat* file_stat) {
soinfo* si = g_soinfo_allocator.alloc(); //分配空间，可以简单理解为 malloc
// Initialize the new element.
memset(si, 0, sizeof(soinfo));
strlcpy(si->name, name, sizeof(si->name));
si->flags = FLAG_NEW_SOINFO;
sonext->next = si; // 加入到存有所有 soinfo 的链表中
sonext = si;
return si;
}
Linker 为 每个 SO 维护了一个soinfo结构，调用 dlopen时，返回的句柄其实就是一个指向该 SO 的 soinfo 指针。soinfo 保存了 SO 加载链接以及运行期间所需的各类信息，简单列举一下:
装载链接期间主要使用的成员:
- 装载信息
- const ElfW(Phdr)* phdr;
- size_t phnum;
- ElfW(Addr) base;
- size_t size;
- 符号信息
- const char* strtab;
- ElfW(Sym)* symtab;
- 重定位信息
- ElfW(Rel)* plt_rel;
- size_t plt_rel_count;
- ElfW(Rel)* rel;
- size_t rel_count;
- init 函数和 finit 函数
- Linker_function_t* init_array;
- size_t init_array_count;
- Linker_function_t* fini_array;
- size_t fini_array_count;
- Linker_function_t init_func;
- Linker_function_t fini_func;
运行期间主要使用的成员:
- 导出符号查找（dlsym）:
- size_t nbucket;
- size_t nchain;
- unsigned* bucket;
- unsigned* chain;
- ElfW(Addr) load_bias;
- 异常处理:
- unsigned* ARM_exidx;
- size_t ARM_exidx_count;
load_library 在为 SO 分配 soinfo 后，会将装载结果更新到 soinfo 中，后面的链接过程就可以直接使用soinfo的相关字段去访问 SO 中的信息。
...
si->base = elf_reader.load_start();
si->size = elf_reader.load_size();
si->load_bias = elf_reader.load_bias();
si->phnum = elf_reader.phdr_count();
si->phdr = elf_reader.loaded_phdr();
...
2.4 链接
链接过程由 soinfo_link_image 函数完成，主要可以分为四个主要步骤:
1. 定位 dynamic section，
由函数 phdr_table_get_dynamic_section 完成，该函数会遍历 program header，找到为类型为 PT_DYNAMIC 的 header, 从中获取的是 dynamic section 的信息，主要就是虚拟地址和项数。
2. 解析 dynamic section
dynamic section本质上是类型为
Elf32_Dyn
的数组，Elf32_Dyn 结构如下
typedef struct {
Elf32_Sword d_tag; /* 类型(e.g. DT_SYMTAB)，决定 d_un 表示的意义*/
union {
Elf32_Word d_val; /* 根据 d_tag的不同，有不同的意义*/
Elf32_Addr d_ptr; /* 虚拟地址 */
} d_un;
} Elf32_Dyn;
Elf32_Dyn
结构的
d_tag
属性表示该项的类型，类型决定了dun中信息的意义，e.g.:当
d_tag = DT_SYMTAB
表示该项存储的是符号表的信息，d_un.d_ptr 表示符号表的虚拟地址的偏移，当
d_tag = DT_RELSZ
时，d_un.d_val 表示重定位表rel的项数。
解析的过程就是遍历数组中的每一项，根据
d_tag
的不同，获取到不同的信息。
dynamic section 中包含的信息主要包括以下 3 类:
- 符号信息
- 重定位信息
- init&finit funcs
3. 加载 needed SO
调用 find_library 获取所有依赖的 SO 的 soinfo 指针，如果 SO 还没有加载，则会将 SO 加载到内存，分配一个soinfo*[]指针数组，用于存放 soinfo 指针。
4. 重定位
重定位SO 链接中最复杂同时也是最关键的一步。重定位做的工作主要是修复导入符号的引用，下面一节将对重定位过程进行详细分析。
soinfo_link_image 的示意代码:
static bool soinfo_link_image(soinfo* si, const Android_dlextinfo* extinfo) {
...
// 1. 获取 dynamic section 的信息，si->dynamic 指向 dynamic section
phdr_table_get_dynamic_section(phdr, phnum, base, &si->dynamic,
&dynamic_count, &dynamic_flags);
...
// 2. 解析dynamic section
uint32_t needed_count = 0;
for (ElfW(Dyn)* d = si->dynamic; d->d_tag != DT_NULL; ++d) {
switch (d->d_tag) {
// 以下为符号信息
case DT_HASH:
si->nbucket = reinterpret_cast<uint32_t*>(base + d->d_un.d_ptr)[0];
si->nchain = reinterpret_cast<uint32_t*>(base + d->d_un.d_ptr)[1];
si->bucket = reinterpret_cast<uint32_t*>(base + d->d_un.d_ptr + 8);
si->chain = reinterpret_cast<uint32_t*>(base + d->d_un.d_ptr + 8 + si->nbucket * 4);
break;
case DT_SYMTAB:
si->symtab = reinterpret_cast<ElfW(Sym)*>(base + d->d_un.d_ptr);
break;
case DT_STRTAB:
si->strtab = reinterpret_cast<const char*>(base + d->d_un.d_ptr);
break;
// 以下为重定位信息
case DT_JMPREL:
si->plt_rel = reinterpret_cast<ElfW(Rel)*>(base + d->d_un.d_ptr);
break;
case DT_PLTRELSZ:
si->plt_rel_count = d->d_un.d_val / sizeof(ElfW(Rel));
break;
case DT_REL:
si->rel = reinterpret_cast<ElfW(Rel)*>(base + d->d_un.d_ptr);
break;
case DT_RELSZ:
si->rel_count = d->d_un.d_val / sizeof(ElfW(Rel));
break;
// 以下为 init&finit funcs
case DT_INIT:
si->init_func = reinterpret_cast<Linker_function_t>(base + d->d_un.d_ptr);
break;
case DT_FINI:
...
case DT_INIT_ARRAY:
si->init_array = reinterpret_cast<Linker_function_t*>(base + d->d_un.d_ptr);
break;
case DT_INIT_ARRAYSZ:
...
case DT_FINI_ARRAY:
...
case DT_FINI_ARRAYSZ:
...
// SO 依赖
case DT_NEEDED:
...
...
}
...
// 3. 加载依赖的SO
for (ElfW(Dyn)* d = si->dynamic; d->d_tag != DT_NULL; ++d) {
if (d->d_tag == DT_NEEDED) {
soinfo* lsi = find_library(library_name, 0, NULL);
si->add_child(lsi);
*pneeded++ = lsi;
}
}
*pneeded = NULL;
...
// 4. 重定位
soinfo_relocate(si, si->plt_rel, si->plt_rel_count, needed);
soinfo_relocate(si, si->rel, si->rel_count, needed);
...
// 设置已链接标志
si->flags |= FLAG_LINKED;
DEBUG("[ finished linking %s ]", si->name);
｝
2.4.1 重定位 relocate
Android ARM 下需要处理两个重定位表，plt_rel 和 rel，plt 指的是延迟绑定，但是 Android 目前并不对延迟绑定做特殊处理，直接与普通的重定位同时处理。两个重定位的表都由 soinfo_relocate 函数处理。
soinfo_relocate 函数需要遍历重定位表，处理每个重定位项，每个重定位项的处理过程可以分为 3 步:
1. 解析重定位项和导入符号的信息
重定位项的结构如下typedef struct { Elf32_Addr r_offset; /* 需要重定位的位置的偏移 */ Elf32_Word r_info; /* 高24位为符号在符号表中的index，低8位为重定位类型 */ } Elf32_Rel;
首先从重定位项获取的信息如下:
- 重定位的类型 type
- 符号在符号表中的索引号 sym，sym 为0表示为本SO内部的重定位，如果不为0，意味着该符号为导入符号
- 重定位的目标地址 reloc，使用r_offset + si_load_bias，相当于 偏移地址+基地址
符号表表项的结构为elf32_sym:
typedef struct elf32_sym { Elf32_Word st_name; /* 名称 - index into string table */ Elf32_Addr st_value; /* 偏移地址 */ Elf32_Word st_size; /* 符号长度（ e.g. 函数的长度） */ unsigned char st_info; /* 类型和绑定类型 */ unsigned char st_other; /* 未定义 */ Elf32_Half st_shndx; /* section header的索引号，表示位于哪个 section 中 */ } Elf32_Sym;2. 如果 sym 不为0，则查找导入符号的信息
如果 sym 不为0，则继续使用 sym 在符号表中获取符号信息，从符号信息中进一步获取符号的名称。随后调用 soinfo_do_lookup 函数在所有依赖的 SO 中根据符号名称查找符号信息，返回值类型为 elf32_sym，同时还会返回含有该符号的 SO 的 soinfo( lsi )，如果查找成功则该导入符号的地址为:
sym_addr = s->st_value + lsi->load_bias;
3. 修正需要重定位的地址
根据重定位类型的不同，修正重定位地址，具体的重定位类型定义和计算方法可以参考 aaelf 文档的 4.6.1.2 节。
对于导入符号，则使用根据第二步得到 sym_addr 去修正，对于 SO 内部的相对偏移修正，则直接将reloc的地址加上 SO 的基址。
static int soinfo_relocate(soinfo* si, ElfW(Rel)* rel, unsigned count, soinfo* needed[]) { ElfW(Sym)* s; soinfo* lsi; // 遍历重定位表 for (size_t idx = 0; idx < count; ++idx, ++rel) { // // 1. 解析重定位项和导入符号的信息 // // 重定位类型 unsigned type = ELFW(R_TYPE)(rel->r_info); // 导入符号在符号表中的 index，可以为0,(修正 SO 内部的相对偏移) unsigned sym = ELFW(R_SYM)(rel->r_info); // 需要重定位的地址 ElfW(Addr) reloc = static_cast<ElfW(Addr)>(rel->r_offset + si->load_bias); ElfW(Addr) sym_addr = 0; const char* sym_name = NULL; if (type == 0) { // R_*_NONE continue; } if (sym != 0) { // // 2. 如果 sym 有效，则查找导入符号 // // 从符号表中获得符号信息，在根据符号信息从字符串表中获取字符串名 sym_name = reinterpret_cast<const char*>(si->strtab + si->symtab[sym].st_name); // 在依赖的 SO 中查找符号，返回值为 Elf32_Sym 类型 s = soinfo_do_lookup(si, sym_name, &lsi, needed); if (s == NULL) {} // 查找失败，不关心 } else { // 查找成功，最终的符号地址 = s->st_value + lsi->load_bias // s->st_value 是符号在依赖 SO 中的偏移，lsi->load_bias 为依赖 SO 的基址 sym_addr = static_cast<ElfW(Addr)>(s->st_value + lsi->load_bias); } } else { s = NULL; } // // 3. 根据重定位类型，修正需要重定位的地址 // switch (type) { // 判断重定位类型，将需要重定位的地址 reloc 修正为目标符号地址 // 修正导入符号 case R_ARM_JUMP_SLOT: *reinterpret_cast<ElfW(Addr)*>(reloc) = sym_addr; break; case R_ARM_GLOB_DAT: *reinterpret_cast<ElfW(Addr)*>(reloc) = sym_addr; break; case R_ARM_ABS32: *reinterpret_cast<ElfW(Addr)*>(reloc) += sym_addr; break; case R_ARM_REL32: *reinterpret_cast<ElfW(Addr)*>(reloc) += sym_addr - rel->r_offset; break; // 不支持 case R_ARM_COPY: /* * ET_EXEC is not supported SO this should not happen. */ DL_ERR("%s R_ARM_COPY relocations are not supported", si->name); return -1; // SO 内部的偏移修正 case R_ARM_RELATIVE: if (sym) { DL_ERR("odd RELATIVE form..."); return -1; } *reinterpret_cast<ElfW(Addr)*>(reloc) += si->base; break; default: DL_ERR("unknown reloc type %d @ %p (%zu)", type, rel, idx); return -1; } } return 0; }
2.5 CallConstructors
在编译 SO 时，可以通过链接选项或是给函数添加属性-init
来指定 SO 的初始化函数，这些初始化函数在 SO 装载链接后便会被调用，再之后才会将 SO 的 soinfo 指针返回给 dl_open 的调用者。SO 层面的保护手段，有两个介入点, 一个是 jni_onload, 另一个就是初始化函数，比如反调试、脱壳等，逆向分析时经常需要动态调试分析这些初始化函数。__attribute__((constructor))
完成 SO 的装载链接后，返回到 do_dlopen 函数, do_open 获得 find_library 返回的刚刚加载的 SO 的 soinfo，在将 soinfo 返回给其他模块使用之前，最后还需要调用 soinfo 的成员函数 CallConstructors。
soinfo* do_dlopen(const char* name, int flags, const Android_dlextinfo* extinfo) {
...
soinfo* si = find_library(name, flags, extinfo);
if (si != NULL) {
si->CallConstructors();
}
return si;
...
}
CallConstructors 函数会调用 SO 的首先调用所有依赖的 SO 的 soinfo 的 CallConstructors 函数，接着调用自己的 soinfo 成员变量 init 和 看 init_array 指定的函数，这两个变量在在解析 dynamic section 时赋值。
void soinfo::CallConstructors() {
//如果已经调用过，则直接返回
if (constructors_called) {
return;
}
// 调用依赖 SO 的 Constructors 函数
get_children().for_each([] (soinfo* si) {
si->CallConstructors();
});
// 调用 init_func
CallFunction("DT_INIT", init_func);
// 调用 init_array 中的函数
CallArray("DT_INIT_ARRAY", init_array, init_array_count, false);
}
有了以上分析基础后，在需要动态跟踪初始化函数时，我们就知道可以将断点设在 do_dlopen 或是 CallConstructors。
3. 加壳技术
在病毒和版权保护领域，“壳”一直扮演着极为重要的角色。通过加壳可以对代码进行压缩和加密，同时再辅以虚拟化、代码混淆和反调试等手段，达到防止静态和动态分析。
在 Android 环境中，Native 层的加壳主要是针对动态链接库 SO，SO 加壳的示意图如下:
加壳工具、loader、被保护SO。
- SO: 即被保护的目标 SO。
- loader: 自身也是一个 SO，系统加载时首先加载 loader，loader 首先还原出经过加密、压缩、变换的 SO，再将 SO 加载到内存，并完成链接过程，使 SO 可以正常被其他模块使用。
- 加壳工具: 将被保护的 SO 加密、压缩、变换，并将结果作为数据与 loader 整合为 packed SO。
下面对 SO 加壳的关键技术进行简单介绍。
3.1 loader 执行时机
Linker 加载完 loader 后，loader 需要将被保护的 SO 加载起来，这就要求 loader 的代码需要被执行，而且要在 被保护 SO 被使用之前，前文介绍了 SO 的初始化函数便可以满足这个要求，同时在 Android 系统下还可以使用 JNI_ONLOAD 函数，因此 loader 的执行时机有两个选择:
- SO 的 init 或 initarray
- jni_onload
3.2 loader 完成 SO 的加载链接
loader 开始执行后，首先需要在内存中还原出 SO，SO 可以是经过加密、压缩、变换等手段，也可已单纯的以完全明文的数据存储，这与 SO 加壳的技术没有必要的关系，在此不进行讨论。
在内存中还原出 SO 后，loader 还需要执行装载和链接，这两个过程可以完全模仿 Linker 来实现，下面主要介绍一下相对 Linker，loader 执行这两个过程有哪些变化。
3.2.1 装载
还原后的 SO 在内存中，所以装载时的主要变化就是从文件装载到从内存装载。
Linker 在装载 PT_LAOD segment时，使用 SO 文件的描述符 fd：
void* seg_addr = mmap(reinterpret_cast<void*>(seg_page_start),
file_length,
PFLAGS_TO_PROT(phdr->p_flags),
MAP_FIXED|MAP_PRIVATE,
fd_,
file_page_start);
按照 Linker 装载，PT_LAOD segment时，需要分为两步：
// 1、改用匿名映射
void* seg_addr = mmap(reinterpret_cast<void*>(seg_page_start),
file_length,
PFLAGS_TO_PROT(phdr->p_flags),
MAP_FIXED|MAP_PRIVATE,
-1,
0);
// 2、将内存中的 segment 复制到映射的内存中
memcpy(seg_addr+seg_page_offset, elf_data_buf + phdr->p_offset, phdr->p_filesz);
注意第2步复制 segment 时，目标地址需要加上 seg_page_offset，seg_page_offset 是 segment 相对与页面起始地址的偏移。
其他的步骤基本按照 Linker 的实现即可，只需要将一些从文件读取修改为从内存读取，比如读 elfheader和program header时。
3.2.2 分配 soinfo
soinfo 保存了 SO 装载链接和运行时需要的所有信息，为了维护相关的信息，loader 可以照搬 Linker 的 soinfo 结构，用于存储中间信息，装载链接结束后，还需要将 soinfo 的信息修复到 Linker 维护的soinfo，3.3节进行详细说明。
3.2.3 链接
链接过程完全是操作内存，不论是从文件装载还是内存装载，链接过程都是一样，完全模仿 Linker 即可。
另外链接后记得顺便调用 SO 初始化函数( init 和 init_array )。
3.3 soinfo 修复
SO 加壳的最关键技术点在于 soinfo 的修复，由于 Linker 加载的是 loader，而实际对外使用的是被保护的 SO，所以 Linker 维护的 soinfo 可以说是错误，loader 需要将自己维护的 soinfo 中的部分信息导出给 Linker 的soinfo。
修复过程如下：
- 获取 Linker 维护的 soinfo，可以通过 dlopen 打开自己来获得：self_soinfo = dlopen(self)。
- 将 loader soinfo 中的信息导出到 self_soinfo，最简单粗暴的方式就是直接赋值，比如：
self_soinfo.base = soinfo.base
- SO地址范围：base、size、load_bias
- 符号信息:sym_tab、str_tab、
- 符号查找信息：nbucket、nchain、bucket、chain
- 异常处理：ARM_exidx、ARM_exidx_count
参考
-
<<Linkers and loaders>>
-
<<ELF for the ARM Architecture>>
更多精彩内容欢迎关注bugly的微信公众账号：
腾讯 Bugly是一款专为移动开发者打造的质量监控工具，帮助开发者快速，便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类，每日日报会列出影响用户数最多的崩溃，精准定位功能帮助开发同学定位到出问题的代码行，实时上报可以在发布后快速的了解应用的质量情况，适配最新的 iOS, Android 官方操作系统，鹅厂的工程师都在使用，快来加入我们吧！
![与专家面对面：Android开发入门问与答[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)