韓子諾，劉嘉勇

（四川大學(xué)電子信息學(xué)院，成都　610065）

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

韓子諾，劉嘉勇

（四川大學(xué)電子信息學(xué)院，成都610065）

0　引言

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

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

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

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

2　Android平臺(tái)下SO文件加載機(jī)制

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

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

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

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

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

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

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

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

3　加固過(guò)程實(shí)現(xiàn)

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

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

通過(guò)硬件信息，文件檢測(cè)，設(shè)備檢測(cè)，IMEI號(hào)等多種手段，檢查運(yùn)行環(huán)境是否為模擬器。一旦檢測(cè)到模擬器，則立即退出整個(gè)應(yīng)用程序。

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

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

（3）解密代碼

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

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

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

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

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

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

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

圖2　加固程序處理流程圖

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

圖3　外殼程序處理流程圖

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

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

檢測(cè)模擬器：

（1）檢測(cè)“/dev/socket/qemud”，“/dev/qemu_pipe”這兩個(gè)通道。

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

access（“/dev/qemu_pipe”，0）

（2）檢測(cè)props。

①ro.product.model該值在模擬器中為sdk，通常在正常手機(jī)中為手機(jī)的型號(hào)。

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

③ro.kernel.qemu該值在模擬器中為1，通常在正常手機(jī)中沒(méi)有該屬性。

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

（1）多進(jìn)程使用ptrace。

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

ptrace（PTRACE_TRACEME，0，0，0）

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

ELF頭部的各個(gè)字段如下：｝Elf32_Ehdr；

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

（1）修改e_ident字段后9個(gè)字節(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）通過(guò)Elf32_Phdr中的p_type字段，找到DYNAMIC。從下圖可以看出，其實(shí)DYNAMIC就是.dynamic section。從p_offset和p_filesz字段得到文件中的起始位置和長(zhǎng)度。

（3）遍歷.dynamic，找到.dynsym、.dynstr、.hash section文件中的偏移和.dynstr的大小。在我的測(cè)試環(huán)境下，F(xiàn)edora 14和 Windows 7 Cygwin x64中elf.h定義.hash的d_tag標(biāo)示是：DT_GNU_HASH；而Android源碼中的是：DT_HASH。

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

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

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

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

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

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

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

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

5　實(shí)驗(yàn)結(jié)果

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

圖4

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

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

最后，在殼運(yùn)行過(guò)程中，使用IDA嘗試對(duì)程序進(jìn)行附加調(diào)試，IDA附加后，原程序退出，達(dá)到了反動(dòng)態(tài)調(diào)試的目的。

圖5

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

6　結(jié)語(yǔ)

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

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

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

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

［4］何先波，唐寧九，呂方等.ELF文件格式及應(yīng)用［J］.計(jì)算機(jī)應(yīng)用研究，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-），男，四川成都人，碩士，研究方向?yàn)锳ndroid安全

2015-11-16

2015-11-30

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

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

劉嘉勇（1962-），男，四川成都人，博士，研究方向?yàn)槊艽a學(xué)

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.