基于Android平臺的SO加固技術研究

韓子諾，劉嘉勇

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

基于Android平臺的SO加固技術研究

韓子諾，劉嘉勇

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

0　引言

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

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

1　現有技術的局限性

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

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

通過對loadLibrary函數的源碼跟蹤，加載過程總結如下：

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

（2）檢查需要加載的共享庫是否已經被加載，如果已經被加載則直接返回，否則將控制權傳遞給動態連接器Linker；

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

（4）Linker根據頭部的數據分別讀入對應的各種數據結構，并將所有PT_LOAD屬性的段加載至合適的地址空間；

（5）Linker為該庫在共享庫鏈表中分配一個soinfo節點并填充其數據結構；

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

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

3　加固過程實現

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

（1）環境檢測代碼

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

（2）反調試代碼

檢測應用程序是否正在被動態調試，一旦發現IDA、GDB等動態調試工具，立即退出整個應用程序。

（3）解密代碼

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

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

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

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

（2）對待加密函數進行異或加密。

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

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

圖2　加固程序處理流程圖

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

圖3　外殼程序處理流程圖

4　關鍵技術

關鍵細節示例如下。

檢測模擬器：

（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，通常在正常手機中沒有該屬性。

防動態調試：

（1）多進程使用ptrace。

//阻止被調試器附加

ptrace（PTRACE_TRACEME，0，0，0）

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

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

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

（1）修改e_ident字段后9個字節。

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

（4）根據函數名稱，計算hash值。

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

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

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

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

（1）找到so文件在內存中的起始地址。

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

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

5　實驗結果

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

圖4

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

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

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

圖5

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

6　結語

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

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

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

［3］王覃思，秘錫辰，郭燕慧.Android平臺軟件安全加載技術研究與實現［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應用面臨的盜版、篡改、植入病毒等威脅，大量開發者對Dex代碼進行加固保護，然而由于Android的開放性，基于Android源碼底層的通用Dex脫殼工具層出不窮，Dex代碼破解難度大大降低，更多的開發者轉而使用C/C++代碼進行核心功能的開發?；趯LF文件格式以及Android平臺下的Linker機制的研究與分析，提出并實現一種基于特定函數保護的SO加固方案。

SO加固；Android平臺；ELF；防靜態分析

劉嘉勇（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.