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

韓子諾，劉嘉勇

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

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

韓子諾，劉嘉勇

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

0　引言

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

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

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

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

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

通過對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ù)分別讀入對應(yīng)的各種數(shù)據(jù)結(jié)構(gòu)，并將所有PT_LOAD屬性的段加載至合適的地址空間；

（5）Linker為該庫在共享庫鏈表中分配一個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í)行該代碼；至此，完成了整個動態(tài)庫的加載過程；可以看到，在整個動態(tài)庫加載過程中，并沒有用到節(jié)頭表的信息，也就是從裝載的角度上看，節(jié)頭表是可以被忽略的。

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

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

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

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

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

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

（3）解密代碼

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

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

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

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

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

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

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

圖2　加固程序處理流程圖

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

圖3　外殼程序處理流程圖

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

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

檢測模擬器：

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

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

access（“/dev/qemu_pipe”，0）

（2）檢測props。

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

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

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

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

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

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

ptrace（PTRACE_TRACEME，0，0，0）

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

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

通過前文對Android平臺下動態(tài)庫的加載過程的分析，發(fā)現(xiàn)許多字段并沒有使用。修改這些字段值也不會影響動態(tài)庫的正常使用。然而，在使用readelf、IDA等靜態(tài)分析工具的時候，若這些字段值錯誤，會導(dǎo)致靜態(tài)分析失敗。本方案利用這一特性，修改部分字段，達(dá)到阻止程序被靜態(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。從下圖可以看出，其實(shí)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標(biāo)示是：DT_GNU_HASH；而Android源碼中的是：DT_HASH。

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

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

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

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

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

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

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

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

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

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

圖4

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

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

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

圖5

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

6　結(jié)語

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

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

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

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

［4］何先波，唐寧九，呂方等.ELF文件格式及應(yīng)用［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

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

SO加固；Android平臺；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.