Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> Android開發 >> 關於android開發 >> 【騰訊Bugly干貨分享】Android Linker 與 SO 加殼技術,buglyandroid

【騰訊Bugly干貨分享】Android Linker 與 SO 加殼技術,buglyandroid

編輯:關於android開發

【騰訊Bugly干貨分享】Android Linker 與 SO 加殼技術,buglyandroid


本文來自於騰訊bugly開發者社區,非經作者同意,請勿轉載,原文地址:http://dev.qq.com/topic/57e3a3bc42eb88da6d4be143

作者:王賽

1. 前言

Android 系統安全愈發重要,像傳統pc安全的可執行文件加固一樣,應用加固是Android系統安全中非常重要的一環。目前Android 應用加固可以分為dex加固和Native加固,Native 加固的保護對象為 Native 層的 SO 文件,使用加殼、反調試、混淆、VM 等手段增加SO文件的反編譯難度。目前最主流的 SO 文件保護方案還是加殼技術, 在SO文件加殼和脫殼的攻防技術領域,最重要的基礎的便是對於 Linker 即裝載鏈接機制的理解。對於非安全方向開發者,深刻理解系統的裝載與鏈接機制也是進階的必要條件。

本文詳細分析了 Linker 對 SO 文件的裝載和鏈接過程,最後對 SO 加殼的關鍵技術進行了簡要的介紹。

對於 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步:

通過前面的分析,可以看到, 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_,之後在針對虛擬地址進行計算時需要使用 load_bias_ 修正。普通的 SO 都不會指定加載基址,這時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:

 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):
    • const char* strtab;
    • ElfW(Sym)* symtab;
    • 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或是給函數添加屬性__attribute__((constructor))來指定 SO 的初始化函數,這些初始化函數在 SO 裝載鏈接後便會被調用,再之後才會將 SO 的 soinfo 指針返回給 dl_open 的調用者。SO 層面的保護手段,有兩個介入點, 一個是 jni_onload, 另一個就是初始化函數,比如反調試、脫殼等,逆向分析時經常需要動態調試分析這些初始化函數。

完成 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。

修復過程如下:

參考

  • <<Linkers and loaders>>
  • <<ELF for the ARM Architecture>>

更多精彩內容歡迎關注bugly的微信公眾賬號:

騰訊 Bugly是一款專為移動開發者打造的質量監控工具,幫助開發者快速,便捷的定位線上應用崩潰的情況以及解決方案。智能合並功能幫助開發同學把每天上報的數千條 Crash 根據根因合並分類,每日日報會列出影響用戶數最多的崩潰,精准定位功能幫助開發同學定位到出問題的代碼行,實時上報可以在發布後快速的了解應用的質量情況,適配最新的 iOS, Android 官方操作系統,鵝廠的工程師都在使用,快來加入我們吧!

  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved