基于Android平臺的SO加固技術(shù)研究

韓子諾，劉嘉勇

（四川大學電子信息學院，成都　610065）

基于Android平臺的SO加固技術(shù)研究

韓子諾，劉嘉勇

（四川大學電子信息學院，成都610065）

0　引言

目前Android已經(jīng)成為市場占有量最大的移動智能設備平臺。與此同時，Android平臺上的惡意軟件也越來越泛濫。據(jù)360互聯(lián)網(wǎng)安全中心所發(fā)布的《2015年第二季度中國手機安全狀況報告》顯示，2015年第二季度，Android平臺新增惡意程序樣本550萬個，較2015年第一季度增長141萬個，同時，也是去年全年的1.68倍；平均每天惡意程序感染量達到了72.2萬人次；每天新增惡意程序樣本近6.04萬個。360公司發(fā)布的2015年第二季度Android平臺惡意程序新增量與感染量如圖1所示。

圖1　2015年第二季度Android平臺惡意程序新增量與感染量

1　現(xiàn)有技術(shù)的局限性

在 《Android平臺軟件安全加載技術(shù)研究與實現(xiàn)》和《基于Android系統(tǒng)JNI機制的SO庫加固方案涉及》兩篇論文中，作者基于JNI調(diào)用機制，通過加密原SO文件，使用殼程序加載并解密原SO文件，間接調(diào)用原SO文件的函數(shù)，該方案解決了ARM指令集版本不同帶來的兼容問題。然而，由于該方案不可避免地會在硬盤留下解密后的明文SO文件，攻擊者使用Hook系統(tǒng)API、自動化腳本可以輕易地破解此方案。為了解決這種缺陷，本文提出的SO加固方案，脫離了對JNI調(diào)用機制的依賴，并且在內(nèi)存中完成文件的加解密，保證了沒有臨時文件的生成，具有更高的安全性。

2　Android平臺下SO文件加載機制

通過對loadLibrary函數(shù)的源碼跟蹤，加載過程總結(jié)如下：

（1）檢查/system/lib和/data/data/包名/lib路徑下是否存在指定的動態(tài)庫，未找到則拋出異常，找到則返回動態(tài)庫完整路徑；

（2）檢查需要加載的共享庫是否已經(jīng)被加載，如果已經(jīng)被加載則直接返回，否則將控制權(quán)傳遞給動態(tài)連接器Linker；

（3）Linker檢查文件頭部合法性，如魔術(shù)字，段的個數(shù)；

（4）Linker根據(jù)頭部的數(shù)據(jù)分別讀入對應的各種數(shù)據(jù)結(jié)構(gòu)，并將所有PT_LOAD屬性的段加載至合適的地址空間；

（5）Linker為該庫在共享庫鏈表中分配一個soinfo節(jié)點并填充其數(shù)據(jù)結(jié)構(gòu)；

（6）Linker執(zhí)行標記為.init，.init_array的節(jié)的代碼，進行代碼初始化工作；

（7）若存在JNI_OnLoad函數(shù)，執(zhí)行該代碼；至此，完成了整個動態(tài)庫的加載過程；可以看到，在整個動態(tài)庫加載過程中，并沒有用到節(jié)頭表的信息，也就是從裝載的角度上看，節(jié)頭表是可以被忽略的。

3　加固過程實現(xiàn)

為了配合外殼程序正常實現(xiàn)保護功能并且簡化加固處理的工作量，本方案需要在源程序的源代碼的基礎上添加關(guān)鍵代碼。

（1）環(huán)境檢測代碼

通過硬件信息，文件檢測，設備檢測，IMEI號等多種手段，檢查運行環(huán)境是否為模擬器。一旦檢測到模擬器，則立即退出整個應用程序。

（2）反調(diào)試代碼

檢測應用程序是否正在被動態(tài)調(diào)試，一旦發(fā)現(xiàn)IDA、GDB等動態(tài)調(diào)試工具，立即退出整個應用程序。

（3）解密代碼

解析SO文件，編寫對指定函數(shù)代碼的解密函數(shù)。

為了不影響源程序的正常功能，需要保證殼代碼首先得到執(zhí)行，因此，編寫的殼代碼需用__attribute （constructor）修飾，使得殼代碼被編譯器放在.init_array節(jié)中，這樣Linker加載SO時就會首先執(zhí)行殼代碼。

加固處理流程的功能是完成對待加密函數(shù)的加密處理以及對ELF文件頭部信息的變形處理。流程如圖2所示，具體步驟為：

（1）讀取待加固的SO庫文件，解析文件信息，得到待加密函數(shù)的偏移地址與大小。

（2）對待加密函數(shù)進行異或加密。

（3）解析文件頭，修改文件頭部部分字段值。

（4）計算文件的MD5值，并將其寫入文件末尾。

圖2　加固程序處理流程圖

外殼程序是添加在.init_array節(jié)的代碼段，在程序執(zhí)行階段，外殼程序首先被執(zhí)行。外殼程序在執(zhí)行過程中首先運行環(huán)境檢測、對抗動態(tài)調(diào)試、MD5完整性校驗，接著對加密代碼進行解密，最后外殼程序交出控制權(quán)，源程序正常運行。具體工作流程如圖3所示。

圖3　外殼程序處理流程圖

4　關(guān)鍵技術(shù)

關(guān)鍵細節(jié)示例如下。

檢測模擬器：

（1）檢測“/dev/socket/qemud”，“/dev/qemu_pipe”這兩個通道。

//判斷兩個通道是否存在，存在則為模擬器 access（“/ dev/socket/qemud”，0）

access（“/dev/qemu_pipe”，0）

（2）檢測props。

①ro.product.model該值在模擬器中為sdk，通常在正常手機中為手機的型號。

②ro.build.tags該值在模擬器中為test-keys，通常在正常手機中為release-keys。

③ro.kernel.qemu該值在模擬器中為1，通常在正常手機中沒有該屬性。

防動態(tài)調(diào)試：

（1）多進程使用ptrace。

//阻止被調(diào)試器附加

ptrace（PTRACE_TRACEME，0，0，0）

（2）對proc/xxx/task和proc/xxx/status進行檢測。默認情況下status中TracerPid值為0，若不為0，則程序正處于被調(diào)試狀態(tài)。

ELF頭部的各個字段如下：｝Elf32_Ehdr；

通過前文對Android平臺下動態(tài)庫的加載過程的分析，發(fā)現(xiàn)許多字段并沒有使用。修改這些字段值也不會影響動態(tài)庫的正常使用。然而，在使用readelf、IDA等靜態(tài)分析工具的時候，若這些字段值錯誤，會導致靜態(tài)分析失敗。本方案利用這一特性，修改部分字段，達到阻止程序被靜態(tài)分析的目的。

（1）修改e_ident字段后9個字節(jié)。

（2）修改e_type，e_machine，e_version，e_flag字段。

（3）修改e_shoff，e_shentsize，e_shnum，e_shstrndx字段。

加密的流程與部分源碼示例如下。

（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的大小。在我的測試環(huán)境下，F(xiàn)edora 14和 Windows 7 Cygwin x64中elf.h定義.hash的d_tag標示是：DT_GNU_HASH；而Android源碼中的是：DT_HASH。

（4）根據(jù)函數(shù)名稱，計算hash值。

（5）根據(jù)hash值，找到下標hash%nbuckets的bucket；根據(jù)bucket中的值，讀取.dynsym中的對應索引的Elf32_Sym符號；從符號的st_name所以找到在.dynstr中對應的字符串與函數(shù)名進行比較。若不等，則根據(jù)chain［hash%nbuckets］找下一個Elf32_Sym符號，直到找到或者chain終止為止，代碼如下：

（6）找到函數(shù)對應的Elf32_Sym符號后，即可根據(jù)st_value和st_size字段找到函數(shù)的位置和大小。

（7）將需要加密的區(qū)域進行加密，即取反操作。*content=～（*content）。

解密流程為加密逆過程，大體相同，只有一些細微的區(qū)別，具體如下：

（1）找到so文件在內(nèi)存中的起始地址。

（2）通過so文件頭找到Phdr；從Phdr找到PT_ DYNAMIC后，需取p_vaddr和p_filesz字段。

（3）后續(xù)步驟與加密相同，不再贅述。

5　實驗結(jié)果

根據(jù)上述方法，對采取本加固方案的SO文件進行逆向測試。首先，對對抗靜態(tài)分析效果進行測試，將加固后的SO文件拖入IDA后，IDA發(fā)生解析錯誤，如圖4所示。

圖4

并且加密過后的函數(shù)，匯編指令顯示錯誤，如圖5所示。

第二，對整個運行流程進行監(jiān)控，發(fā)現(xiàn)在本地并沒有生成明文的SO文件，增大了攻擊者破解的難度。

最后，在殼運行過程中，使用IDA嘗試對程序進行附加調(diào)試，IDA附加后，原程序退出，達到了反動態(tài)調(diào)試的目的。

圖5

從上面的實驗結(jié)果可以得出，本加固方案在對抗靜態(tài)分析以及反動態(tài)調(diào)試均有良好的效果，并且和之前已有的加固方案比較，本方案摒棄了本地加解密的方式，采用內(nèi)存中完成加解密功能，防止被攻擊者從本地直接得到明文SO文件。本方案大大提高了SO的保護強度，解決了本地存在臨時解密文件導致安全性降低的問題。

6　結(jié)語

本文設計并實現(xiàn)的SO加固技術(shù)方案，可對整個SO文件以及特定函數(shù)塊進行加固保護，并且在整個流程中，沒有臨時解密文件的生成，增加了非法逆向的難度。本方法是基于Android平臺下ELF文件加載與執(zhí)行特性來實現(xiàn)其保護的，依賴于Android Linker機制，該方案的適用性將受限于未來Android系統(tǒng)動態(tài)庫加載與執(zhí)行機制的改變。

［1］張譯恬，王純.基于安卓系統(tǒng)JNI機制的SO庫加固方案設計［J］.電信技術(shù)，2014（10）:90-93.

［2］秘錫辰.Android應用軟件安全加固技術(shù)研究［D］.北京交通大學，2013.

［3］王覃思，秘錫辰，郭燕慧.Android平臺軟件安全加載技術(shù)研究與實現(xiàn)［D］.中國科技論文在線，2012.?

［4］何先波，唐寧九，呂方等.ELF文件格式及應用［J］.計算機應用研究，2001，18（11）:144-145，150.DOI:10.3969/j.issn.1001-3695.2001.11.048.

SO Reinforcement；Android Platform；ELF；Anti-Static Analysis

Research on SO Reinforcement Technology Based on Android Platform

HAN Zi-nuo，LIU Jia-yong
（Department of Electronic Information，Sichuan University，Chengdu 610065）

1007-1423（2015）36-0049-05

10.3969/j.issn.1007-1423.2015.36.012

韓子諾（1991-），男，四川成都人，碩士，研究方向為Android安全

2015-11-16

2015-11-30

近年來，為了對抗Android應用面臨的盜版、篡改、植入病毒等威脅，大量開發(fā)者對Dex代碼進行加固保護，然而由于Android的開放性，基于Android源碼底層的通用Dex脫殼工具層出不窮，Dex代碼破解難度大大降低，更多的開發(fā)者轉(zhuǎn)而使用C/C++代碼進行核心功能的開發(fā)。基于對ELF文件格式以及Android平臺下的Linker機制的研究與分析，提出并實現(xiàn)一種基于特定函數(shù)保護的SO加固方案。

SO加固；Android平臺；ELF；防靜態(tài)分析

劉嘉勇（1962-），男，四川成都人，博士，研究方向為密碼學

In recent years，in order to combat piracy，tampering，implant viruses of Android application，a lot of developers reinforce Dex codes，but because the Android platform is open，With Dex unpack tools based on Android source code emerging endlessly，cracking Dex codes becomes far easier，more developers turn to use C/C++code development the core functions.Based on Executable and Linking Format and the research on Linker on the Android platform，gives a SO reinforcement scheme based on specific function protection.