簡單粗暴的so加解密實現，so解密

簡單粗暴的so加解密實現，so解密

轉載自http://bbs.pediy.com/showthread.php?t=191649

以前一直對.so檔案載入時解密不懂，不瞭解其工作原理和實現思路。最近翻看各種資料，有了一些思路。看到論壇沒有類似文章，故來一帖，也作為學習筆記。限於水平，本菜沒有找到安卓平台一些具體實現思路，這些方法都是借鑒其他平台的實現思路和本菜的YY，肯定會有不少疏漏和錯誤之處，還請各位大牛指正，感激不盡！

簡單粗暴的so加解密實現
一、  概述
利用動態連結程式庫實現安卓應用的核心部分，能一定程度的對抗逆向。由於ida等神器的存在，還需要對核心部分進行加密。動態連結程式庫的加密，在我看來，有兩種實現方式：1. 有源碼; 2、無源碼。無源碼的加密，類似window平台的加殼和對.dex檔案的加殼，需要對檔案進行分析，在合適的地方插入解密代碼，並修正一些參數。而如果有源碼，則可以構造解密代碼，並讓解密過程在.so被載入時完成。（當然，應用程式載入了.so檔案後，記憶體中.so資料已經被解密，可直接dump分析。同時，也有一些對抗dump的方法，這裡就不展開了）。
下文只針對有源碼這種方式進行討論，分析一些可行的實現方法。主要是包含對ELF header的分析(不是討論各個欄位含義); 基於特定section和特定函數的加解密實現(不討論複雜的密碼編譯演算法)。

二、  針對動態連結程式庫的ELF頭分析
網上有很多資料介紹ELF檔案格式，而且寫得很好很詳細。我這裡就不重複，不太瞭解的朋友，建議先看看。以下內容，我主要從連結視圖和裝載視圖來分析ELF頭的各個欄位，希望能為讀者提供一些ELF檔案頭的修正思路。
這裡，我再羅嗦列出ELF頭的各個欄位：
typedef struct {
  unsigned char  e_ident[EI_NIDENT];  /* File identification. */
  Elf32_Half  e_type;    /* File type. */
  Elf32_Half  e_machine;  /* Machine architecture. */
  Elf32_Word  e_version;  /* ELF format version. */
  Elf32_Addr  e_entry;  /* Entry point. */
  Elf32_Off  e_phoff;  /* Program header file offset. */
  Elf32_Off  e_shoff;  /* Section header file offset. */
  Elf32_Word  e_flags;  /* Architecture-specific flags. */
  Elf32_Half  e_ehsize;  /* Size of ELF header in bytes. */
  Elf32_Half  e_phentsize;  /* Size of program header entry. */
  Elf32_Half  e_phnum;  /* Number of program header entries. */
  Elf32_Half  e_shentsize;  /* Size of section header entry. */
  Elf32_Half  e_shnum;  /* Number of section header entries. */
  Elf32_Half  e_shstrndx;  /* Section name strings section. */
} Elf32_Ehdr;
e_ident、e_type、e_machine、e_version、e_flags和e_ehsize欄位比較固定；e_entry 入口地址與檔案類型有關。e_phoff、e_phentsize和e_phnum與裝載視圖有關；e_shoff、e_shentsize、e_shnum和e_shstrndx與連結視圖有關。目前e_ehsize = 52位元組，e_shentsize = 40位元組，e_phentsize = 32位元組。
下面看看這兩種視圖的排列結構：

直接，可以得到一些資訊：Program header位於ELF header後面，Section Header位於ELF檔案的尾部。那可以推出：
e_phoff = sizeof(e_ehsize);
整個ELF檔案大小 = e_shoff + e_shnum * sizeof(e_shentsize) + 1
e_shstrndx欄位的值跟strip有關。Strip之前：.shstrtab 並不是最後一個section.則 e_shstrndx = e_shnum – 1 – 2;

而經過strip之後，動態連結程式庫末尾的.symtab和.strtab這兩個section會被去掉. 則e_shstrndx = e_shnum – 1。

使用ndk產生在\libs\ armeabi\下的.so檔案是經過strip的，也是被打包到apk中的。可以在\obj\local\armeabi\下找到未經過strip的.so檔案。到這裡，我們就可以把http://bbs.pediy.com/showthread.php?t=188793 文章中提到的.so檔案修正。如果e_shoff和e_shnum都改成任意值，那麼修正起來比較麻煩。
感覺上好像e_shoff、e_shnum等與section相關的資訊任意修改，對.so檔案的使用毫無影響。的確是這樣的，至少給出兩個方面來佐證：
1.  so檔案在記憶體中的映射

相信瞭解elf裝載(執行)視圖的朋友肯定清楚，.so檔案是以segment為單位映射到記憶體的。圖中紅色地區的section是沒有被映射的記憶體，當然也在segment中找不到。
2.  安卓linker源碼
在linker.h源碼中有一個重要的結構體soinfo，下面列出一些欄位：
struct soinfo{
    const char name[SOINFO_NAME_LEN]; //so全名
    Elf32_Phdr *phdr; //Program header的地址
int phnum; //segment 數量
unsigned *dynamic; //指向.dynamic，在section和segment中相同的
//以下4個成員與.hash表有關
unsigned nbucket;
unsigned nchain;
unsigned *bucket;
unsigned *chain;

unsigned *preinit_array;
unsigned preinit_array_count;
//這兩個成員只能會出現在可執行檔中

  //指向初始化代碼，先於main函數之行，即在載入時被linker所調用，在linker.c可以看到：__linker_init -> link_image -> call_constructors -> call_array
unsigned *init_array;
unsigned init_array_count;
void (*init_func)(void);
//與init_array類似，只是在main結束之後執行
unsigned *fini_array;
unsigned fini_array_count;
void (*fini_func)(void);
}
另外，linker.c中也有許多地方可以佐證。其本質還是linker是基於裝載視圖解析的so檔案的。
基於上面的結論，再來分析下ELF頭的欄位。
1) e_ident[EI_NIDENT] 欄位包含魔數、位元組序、字長和版本，後面填充0。對於安卓的linker，通過verify_elf_object函數檢驗魔數，判定是否為.so檔案。那麼，我們可以向位置寫入資料，至少可以向後面的0填充位置寫入資料。遺憾的是，我在fedora 14下測試，是不能向0填充位置寫資料，連結器報非0填充錯誤。
2) 對於安卓的linker，對e_type、e_machine、e_version和e_flags欄位並不關心，是可以修改成其他資料的(僅分析，沒有實測)
3) 對於動態連結程式庫，e_entry 入口地址是無意義的，因為程式被載入時，設定的跳轉地址是動態連接器的地址，這個欄位是可以被作為資料填充的。
4) so裝載時，與連結視圖沒有關係，即e_shoff、e_shentsize、e_shnum和e_shstrndx這些欄位是可以任意修改的。被修改之後，使用readelf和ida等工具開啟，會報各種錯誤，相信讀者已經見識過了。
5) 既然so裝載與裝載視圖緊密相關，自然e_phoff、e_phentsize和e_phnum這些欄位是不能動的。

根據上述結論，做一個面目全非，各種工具開啟報錯的so檔案就很easy了，讀者可以試試，這裡就不舉例，你將在後續內容中看到。

三、  基於特定section的加解密實現
這裡提到基於section的加解密，是指將so檔案的特定section進行加密，so檔案被載入時解密。下面給出執行個體。
假設有一個shelldemo應用，調用一個native方法返回一個字串供UI顯示。在native方法中，又調用getString方法返回一個字串供native方法返回。我需要將getString方法加密。這裡，將getString方法存放在.mytext中(指定__attribute__((section (".mytext")));)，即是需要對.mytext進行加密。
加密流程：
1)  從so檔案頭讀取section位移shoff、shnum和shstrtab
2)  讀取shstrtab中的字串，存放在str空間中
3)  從shoff位置開始讀取section header, 存放在shdr
4)  通過shdr -> sh_name 在str字串中索引，與.mytext進行字串比較，如果不匹配，繼續讀取
5)  通過shdr -> sh_offset 和 shdr -> sh_size欄位，將.mytext內容讀取並儲存在content中。
6)  為了便於理解，不使用複雜的密碼編譯演算法。這裡，只將content的所有內容取反，即 *content = ~(*content);
7)  將content內容寫回so檔案中
8)  為了驗證第二節中關於section 欄位可以任意修改的結論，這裡，將shdr -> addr 寫入ELF頭e_shoff，將shdr -> sh_size 和 addr 所在記憶體塊寫入e_entry中，即ehdr.e_entry = (length << 16) + nsize。當然，這樣同時也簡化瞭解密流程，還有一個好處是：如果將so檔案頭修正放回去，程式是不能啟動並執行。

解密時，需要保證解密函數在so載入時被調用，那函式宣告為：init_getString __attribute__((constructor))。(也可以使用c++構造器實現， 其本質也是用attribute實現)
解密流程：
1)  動態連結器通過call_array調用init_getString
2)  Init_getString首先調用getLibAddr方法，得到so檔案在記憶體中的起始地址
3)  讀取前52位元組，即ELF頭。通過e_shoff獲得.mytext記憶體載入地址，ehdr.e_entry擷取.mytext大小和所在記憶體塊
4)  修改.mytext所在記憶體塊的讀寫權限
5)  將[e_shoff, e_shoff + size]記憶體地區資料解密，即取反操作：*content = ~(*content);
6)  修改回記憶體地區的讀寫權限
(這裡是對程式碼片段的資料進行解密，需要寫入權限。如果對資料區段的資料解密，是不需要更改許可權直接操作的)

利用readelf查看加密後的so檔案：

運行結果很簡單，源碼見附件

注意：並不是所有的section都能全加，有些資料是不能加密的。比如直接對.text直接加密，會把與crt有關代碼也加密，只能選擇性的加密。下面將介紹如何?

四、  基於特定函數的加解密實現
上面的加解密方式可謂簡單粗暴。採用這種方式實現，如果ELF頭section被恢複，則很容易被發現so多了一個section。那麼，對ELF中已存在的section中的資料部分加密，可以達到一定的隱藏效果。
與上節例子類似，命名為shelldemo2，只是native直接返回字串給UI。需要做的是對Java_com_example_shelldemo2_MainActivity_getString函數進行加密。加密和解密都是基於裝載視圖實現。需要注意的是，被加密函數如果用static聲明，那麼函數是不會出現在.dynsym中，是無法在裝載視圖中通過函數名找到進行解密的。當然，也可以採用取巧方式，類似上節，把地址和長度資訊寫入so頭中實現。Java_com_example_shelldemo2_MainActivity_getString需要被調用，那麼一定是能在.dynsym找到的。
加密流程：
1)  讀取檔案頭，擷取e_phoff、e_phentsize和e_phnum資訊
2)  通過Elf32_Phdr中的p_type欄位，找到DYNAMIC。從可以看出，其實DYNAMIC就是.dynamic section。從p_offset和p_filesz欄位得到檔案中的起始位置和長度

3)  遍曆.dynamic，找到.dynsym、.dynstr、.hash section檔案中的位移和.dynstr的大小。在我的測試環境下，fedora 14和windows7 Cygwin x64中elf.h定義.hash的d_tag標示是：DT_GNU_HASH;而安卓源碼中的是：DT_HASH。
4)  根據函數名稱，計算hash值
5)  根據hash值，找到下標hash % nbuckets的bucket；根據bucket中的值，讀取.dynsym中的對應索引的Elf32_Sym符號；從符號的st_name所以找到在.dynstr中對應的字串與函數名進行比較。若不等，則根據chain[hash % nbuckets]找下一個Elf32_Sym符號，直到找到或者chain終止為止。這裡敘述得有些複雜，直接上代碼。
for(i = bucket[funHash % nbucket]; i != 0; i = chain[i]){
  if(strcmp(dynstr + (funSym + i)->st_name, funcName) == 0){
    flag = 0;
    break;
  }
}
6)  找到函數對應的Elf32_Sym符號後，即可根據st_value和st_size欄位找到函數的位置和大小
7)  後面的步驟就和上節相同了，這裡就不贅述

解密流程為加密逆過程，大體相同，只有一些細微的區別，具體如下：
1)  找到so檔案在記憶體中的起始地址
2)  也是通過so檔案頭找到Phdr；從Phdr找到PT_DYNAMIC後，需取p_vaddr和p_filesz欄位，並非p_offset，這裡需要注意。
3)  後續操作就加密類似，就不贅述。對記憶體地區資料的解密，也需要注意讀寫權限問題。

加密後效果：

運行結果與上節相同，就不貼了。

五、  參考資料
http://blog.csdn.net/forlong401/article/details/12060605
《ELF檔案格式》
Android linker源碼：bionic\linker
Android libc源碼：bionic\libc\bionic
Google：ELF連結視圖與裝載視圖相關資料
------------------------------------------------------------------------
基於上面的方法，我寫了一個CrackMe.apk的註冊機程式供大家玩耍。輸入3~10位的username和regcodes，8位的校正碼，字元範圍：A~Z、a~z、0~9。若校正通過，則提示：congratulation! You crack it!. 
附件：
shelldemo.zip.
shelldemo2.zip.
CrackMe.apk.

上個pdf，這個太亂了。
簡單粗暴的so加解密實現.pdf*轉載請註明來自看雪論壇@PEdiy.com