基于Spark的大規模軟件完整性校驗行為識別框架

邱景 李宜卓

摘 要：軟件完整性校驗廣泛應用于反篡改防御，保護軟件知識產權，防止盜版。因此，了解不同完整性校驗方法的強度和弱點很重要。針對傳統檢測方法處理大規模數據時效率較低的問題，描述了一個基于Spark的大規模軟件完整性校驗行為識別框架。對于單個文件檢測，使用后向污點分析識別可執行或者用來計算可執行位置值的內存位置，然后使用前向污點分析識別校驗過程。該方法適用于多種不同完整性校驗防御方案，提供的信息可以用來輔助繞過防御。實驗表明，該方法可以有效識別常見軟件完整性校驗行為。

關鍵詞：軟件安全;軟件反篡改;完整性校驗;污點分析

DOI：10. 11907/rjdk. 191219

中圖分類號：TP306文獻標識碼：A文章編號：1672-7800（2019）004-0046-04

0 引言

軟件完整性校驗廣泛應用于軟件防篡改保護技術中，其基本思想是對程序指令（或其它與指令相關的數據）計算一個哈希值，當且僅當這個哈希值與預期值相同時，程序才會正常執行[1-7]。任何嘗試篡改代碼的行為，如關閉或移除一個許可證檢測，都會被完整性校驗機制檢測到，因而可用來防止盜版。衡量不同完整性校驗機制的強度和弱點也是安全領域研究熱點。

當前已有不少軟件防篡改防御工作。Aucsmith[3]提出一種使用多重自修改和自解密代碼塊檢測運行時代碼完整性的校驗方法;Horne 等[4]、Chang 等[6]討論了一種使用校驗過程網絡的完整性校驗系統，校驗過程之間相互保護，要繞過這種保護，需要同時繞過所有校驗過程，無疑增加了破解難度;Tsang 等[8]提出使用大量隨機篡改響應的校驗過程，通過多個版本函數使得每次程序運行不同代碼;Cappaert等[2]、Wang等[9]則利用校驗值作為密鑰加解密程序，破壞程序完整性會導致解密過程生成錯誤代碼。還有一些方法，如隱式設計篡改響應，使得攻擊者難以從篡改響應回溯到校驗驗證代碼[10]。也有通過隱式哈希方法檢測代碼執行效果是否符合預期，以判斷軟件是否被篡改[11]。文獻[12]使用污點分析指令執行軌跡檢測上述軟件完整性校驗行為。以上方法無法應付大規模軟件分析，且存在誤報率高的問題。

還有一些反篡改防御工作，通過一個可信的遠程服務器完成完整性校驗[1，5]。湯戰勇等[13]提出一種進程級虛擬機軟件防篡改方法，以虛擬指令方式融合校驗、哨兵技術和反調試技術。這些方法超出了本文工作范圍。

傳統單機分析滿足不了日益增長的軟件發展趨勢，亟需多機并行處理提高速度。鑒于此，本文將Spark與完整性檢測算法結合，提出基于Spark的大規模軟件完整性檢驗識別框。Spark作為當前最流行的大數據處理平臺之一，一直受到各研究領域青睞[14]。如蘭云旭等[15]將傳統醫學圖像處理方法與Spark結合起來，提出基于Spark的并行醫學圖像處理方法;文獻[16]和文獻[17]利用Spark的機器學習庫從海量數據中檢測0day惡意軟件。

借助Spark的大數據處理平臺，本文框架可以較高效率地完成大規模軟件的完整性校驗行為檢測。對于單個文件，檢測方法使用動態信息流分析技術，識別軟件中多種完整性校驗行為。污點分析是二進制代碼信息流分析的主要技術，用來追蹤污點源與錨如何關聯[18]。

本文方法將檢測出完整性校驗代碼的一些關鍵信息，如：是否有完整性校驗發生及被校驗代碼位置;發生創建的位置（如果校驗代碼是動態創建的）;計算出的校驗值;比較校驗值的代碼位置;篡改響應機制（通過條件跳轉、間接跳轉，或者將校驗值作為代碼解壓密鑰）等。這些信息包含完整性校驗的大量細節，并給出如何繞過完整性校驗提示，同時可以指出某個完整性校驗機制的弱點以及可能的補救措施。

1 檢測框架

Spark操作對象稱作彈性分布式數據集（Resilient Distributed Dataset，RDD）。本文框架最主要操作是圍繞RDD進行Map/Reduce。

整體檢測框架如圖1所示。流程如下：

（1）將待檢測可執行文件復制到共享空間，路徑包裝成RDD。

（2）對于每個可執行文件通過黑盒獲取執行軌跡。執行軌跡記錄程序運行時的指令及地址，執行軌跡可通過二進制插樁工具如Intel Pin Tool，或者基于虛擬機的Ether得到[19，20]，這一步相當于將可執行文件映射成執行軌跡。由于被檢測程序可能不會自動關閉（如GUI程序），因此設置執行時間限制及軌跡文件大小上限。

（3）對于一條執行軌跡，搜集其中的已執行代碼地址，然后均分成子任務，執行后向污點分析，Map得到污點源后，Reduce各個計算節點結果得到不重復的污點源。

（4）均分上一步得到的污點源，使用前向污點分析Map得到子結果，Reduce匯總過濾得到最后報告。

2 完整性校驗檢測

2.1 整體流程

一般來說，一個完整性校驗首先通過包含代碼或者用來創建代碼（即脫殼）的內存計算一個值，然后用其影響后續要執行的代碼。完整性校驗檢測本質就是搜索能夠控制代碼執行的自校驗行為。

本文完整性校驗檢測方法包含如下步驟：

（1）后向污點分析。首先遍歷軌跡，搜集已執行的內存地址，標記為污點。后向傳播污點識別可能用來創建執行代碼的內存地址。

（2）前向污點分析。從后向污點分析得到的污染位置開始，分析前向傳播污點狀態。

（3）識別完整性校驗。這一步識別校驗值驗證指令，檢查執行軌跡中的指令是否滿足如下條件之一：①它是一個有污染操作數的控制轉移指令;②它寫入一個污染值到后續被執行的代碼內存位置;③它傳入一個污染值到系統輸出函數，如printf（）。

然后，進一步分析這些驗證指令，得到校驗代碼的額外細節。

2.2 污點分析

根據問題特點，本文用字節級別的污點分析。污點分析傳播方向有前向（與控制流同向）和后向（與控制流反向）。在前向污點分析中，如果指令的源操作數是污染的，則其目標操作數也標記為污染。在后向污點分析中，如果目標操作數是污染的，則源操作數也標記為污染。

后向污點分析識別執行軌跡中已執行代碼的源位置，也就是執行代碼從這些源位置變化（或者不變化）而來。這個分析是保守的，即若指令目標操作數是污染的，則污染該條指令的所有源操作數，即使實際源操作數中只有一個是污染的。然后，將目標操作數標記為未污染。

2.3 識別完整性校驗

首先，使用后向污點分析得到已執行代碼的源位置，排除沒有被任何指令讀寫的源位置。

其次，污染第一步得到的源位置，識別操作數被污染指令，對于能夠影響程序行為的指令也污染。

第三，每一個能夠影響程序行為的指令對應一些源位置，如果這些源位置數量超過（用戶定義的）閾值θmin，則該指令被識別為完整性校驗驗證指令。

在x86中，函數調用通常被轉換為push指令和call指令組合，這類call不讀寫污染的內存地址。為了處理校驗值流向系統輸出函數，對于call指令，若有其參數是污染的，則此指令也被認為是污染的。

如果被分析文件使用一些壓縮工具，如UPX，代碼是壓縮的，則上述算法會有誤報。閾值θmin用來減少誤報。在解壓縮中（即脫殼），被壓縮字節序列會被復制到可執行位置或不可執行位置。不可執行的內存地址有可能會在前向污點傳播中被檢測到，從而導致誤報，因此使用閾值θmin過濾掉這些誤報。此外，本文還增加全局閾值θmax，如果被忽略的檢測數量超過θmax，則會生成一個警告。

一個軟件可以使用多個脫殼軟件加密，而完整性校驗可能發生在脫殼過程序列的任何一個點。但是，本文算法可以檢測任意點的完整性校驗。分析如下：

在算法第一步，Cn 中的指令地址以及Φi的代碼地址都將被搜集并污染。因為Φn讀取了Cn-1，Cn-1的地址也將會被污染。以此類推，所有Ci以及Φi都會被后向污點傳播標記。假設校驗發生在第k個脫殼步驟之前（1≤k≤n），被校驗地址集合為C'k-1[？]Ck-1。

假設C'k-1=C'0，后向污點分析將污染C'0，因此C'0前向傳播污點、CHECK（Ck-1）讀取的C'k-1以及參與校驗計算本身的值，都將被標記為污染。這使得參與完整性校驗過程的值都將被污染，完整性校驗也就會被識別。

本文方法需要處理大軌跡文件，在時空消耗上都會存在挑戰。一方面，可以使用軌跡壓縮技術減輕存儲和I/O消耗[21]。另一方面，可以使用兩個優化技術加速污點分析：消除非相關指令、使用并行處理技術。

可以通過預污點分析，減少前向污點分析中指令的數量，得到一個子軌跡，包含前向污點分析所有相關指令。這個子執行軌跡與原始執行軌跡進行前向污點分析效果是等價的。子軌跡通常遠小于原始軌跡，因此可以顯著提高性能。前向污點分析中，只讀取指令軌跡文件，因此可以并行前向污點分析，可以通過均分污染源完成。

3 實驗

3.1 實驗配置

使用Intel Pin Tool記錄執行軌跡[19]。實驗使用5臺機器搭建Spark集群，機器配置為：3.70 GHz Intel Core i7-8700K 處理器，32 GB 主存，Ubuntu 18.04;Spark版本為2.0.2;算法θmin、θmax分別設置為16和512。

測試集使用自行編寫的各種完整性校驗方案程序。在每一個程序中，修改MD5計算程序包含完整性校驗。測試包含4種完整性校驗。

（1）Horne等[4]、Chang等[6]所描述的多個完整性校驗過程校驗方案。其用于檢測本文方法是否能夠正確識別多個重疊的完整性校驗過程。本組測試程序中分別有1個（1-guards）、4個（4-guards）、10個（10-guards）、50個（50-guards）完整性校驗過程。

（2）Cappaert等[2]、Wang等[9]所描述的校驗值作為代碼解密密鑰校驗方案。其用于測試是否能夠檢測校驗值驗證和篡改響應使用動態代碼修改影響程序執行，而不是使用一個顯式的控制流轉換到篡改響應。該程序稱為decrypt-key。

（3）運行時在代碼解壓縮過程中進行完整性校驗。測試能否檢測被校驗地址自身是不執行的，而是用來創建執行代碼。測試程序中有100層解壓縮，在偶數解壓層有完整性校驗。該程序稱為100-layers。

（4）使用完整性校驗值生成MD5初始化常數。計算出的MD5值通過函數printf（）輸出到屏幕，MD5代碼參見http：//people.csail.mit.edu/rivest/Md5.c，程序輸入為中華人民共和國國歌歌詞。該程序稱為chksum-md5。

對于各組實驗、插樁程序，在運行時報告被校驗的內存地址范圍與檢測結果進行比較。為了測試集群性能，將上述測試分為若干份輸入集群與單機器進行比較。

3.2 實驗結果

測試集單份實驗結果如表1所示，沒有發現任何誤報。圖2 給出了集群性能測試結果，報告結果與單份相同。從圖2可以看出，處理時間大致與份數成線性關系，符合預期。

3.3 精度分析

有重疊完整性校驗程序，成功識別了所有完整性校驗。不過，檢測出的完整性校驗代碼范圍小于實際。原因有兩點：首先，本文分析的是指令執行軌跡，屬于動態分析方法，而動態分析代碼覆蓋率低，不是所有被校驗代碼都會在運行時執行。其次，從已執行的內存地址開始分析，本身就會漏掉一些沒有執行的內存地址（其可能會被完整性校驗）。

在100-layers中，所有校驗過程被識別出，檢測出的完整性校驗都有相同校驗范圍。原因是在源代碼中，被校驗數據在某一層被變形和校驗，然后立即傳遞到下一層脫殼。

對于decrypt-key，也是同樣結果，完整性校驗的關鍵指令和被校驗范圍被準確識別。

4 結語

本文描述了一種基于Spark的軟件完整性校驗檢測框架。對于單文件檢測，基于動態分析，使用后向污點分析識別可執行或者用來計算可執行位置值的內存位置，然后使用前向污點分析識別校驗過程。實驗表明，本文框架可以有效識別多種完整性校驗行為。

本文方法的輸入是指令執行軌跡，是一種動態分析方法。動態分析方法優勢在于能夠透明地處理反分析防御，如運行時代碼自修改，但存在代碼覆蓋率低的問題，可以通過多路徑探索技術解決[21]。第二個問題來自離線動態分析，大軌跡文件會帶來顯著的存儲和處理消耗，可通過使用軌跡壓縮技術解決[22]。本文方法雖然可以識別完整性校驗，但不能自動轉化為一個直接屏蔽完整性校驗的方法。在對原型工具的測試中，手工驗證了檢測結果的正確性。但是，若校驗代碼是在不可預料的內存位置動態創建的，則驗證識別會比較棘手。

本文關注動態完整性校驗，卻沒有考慮靜態完整性校驗。原則上調整本文方法處理靜態完整性校驗并不困難，需跟蹤庫或系統函數調用，識別任何程序訪問的文件，然后解析文件結構，識別讀取文件操作。整合上述邏輯到原型工具將是下一步工作。

參考文獻：

[1] AHMADVAND M，PRETSCHNER A，KELBERT F. A taxonomy of software integrity protection techniques[J]. Advances in Computers， 2019， 112： 413-486.

[2] CAPPAERT J，PRENEEL B，ANCKAERT B，et al. Towards tamper resistant code encryption： practice and experience[C]. Information Security Practice and Experience， 2008： 86-100.

[3] AUCSMITH D. Tamper resistant software： an implementation[C].? Information Hiding， 1996： 317-333.

[4] HORNE B，MATHESON L，SHEEHAN C，et al. Dynamic self-checking techniques for improved tamper resistance[C]. Security and Privacy in Digital Rights Management， 2002： 141-159.

[5] MARTIGNONI L，PALEARI R，BRUSCHI D. Conqueror：tamper- proof code execution on legacy systems[C]. Detection of Intrusions and Malware， and Vulnerability Assessment， 2010： 21-40.

[6] CHANG H，ATALLAH M J. Protecting software code by guards[C]. Security and Privacy in Digital Rights Management，2002：160-175.

[7] GIFFIN J T，CHRISTODORESCU M，KRUGER L. Strengthening software self-checksumming via self-modifying code[C]. Computer Security Applications Conference， 21st Annual， 2005：10-32.

[8] TSANG H C，LEE M C，PUN C M. A robust anti-tamper protection scheme[C]. Availability，Reliability and Security（ARES），2011 Sixth International Conference， 2011： 109-118.

[9] WANG P，KANG S，KIM K. Tamper resistant software through dynamic integrity checking[C]. Proceedings of the 2005 Symposium on Cryptography and Information Security，2005： 25-28.

[10] TAN G，CHEN Y，JAKUBOWSKI M H. Delayed and controlled failures in tamper-resistant software[C]. Information Hiding，2007： 216-231.

[11] AHMADVAND M，HAYRAPETYAN A，BANESCU S，et al. Practical integrity protection with oblivious hashing[C]. Proceedings of the 34th Annual Computer Security Applications Conference，2018： 40-52.

[12] QIU J，YADEGARI B，JOHANNESMEYER B，et al. Identifying and understanding self-checksumming defenses in software[C]. Proceedings of the 5th ACM Conference on Data and Application Security and Privacy，2015： 207-218.

[13] 湯戰勇，郝朝輝，房鼎益，等. 基于進程級虛擬機的軟件防篡改方法[J]. 華中科技大學學報：自然科學版，2016 （3）： 13.

[14] 張恬恬，孫紹華. 基于Spark的云計算平臺在實驗室的應用與實現[J]. 軟件導刊，2018，17（4）：191-193.

[15] 蘭云旭，王俊峰，唐鵬. 基于Spark的并行醫學圖像處理研究[J].? 四川大學學報：自然科學版，2017，54（1）：65-70.

[16] GUPTA D，RANI R. Big data framework for zero-day malware detection[J].? Cybernetics and Systems， 2018， 49（2）： 103-121.

[17] CHUPRAT S，ARIFFIN A，SAHIBUDDIN S，et al. Malware forensic analytics framework using big data platform[C]. Proceedings of the Future Technologies Conference， 2018： 261-274.

[18] 王蕾，李豐，李煉，等. 污點分析技術的原理和實踐應用[J]. 軟件學報，2017，28（4）：860-882.

[19] LUK C K，COHN R， MUTH R， et al. Pin： building customized program analysis tools with dynamic instrumentation[J]. ACM Sigplan Notices， 2005， 40（6）： 190-200.

[20] DINABURG A， ROYAL P， SHARIF M， et al. Ether： malware analysis via hardware virtualization extensions[C]. Proceedings of the 15th ACM Conference on Computer and Communications Security， 2008： 51-62.

[21] MOSER A，KRUEGEL C，KIRDA E. Exploring multiple execution paths for malware analysis[C]. Security and Privacy，2007： 231-245.

[22] BHANSALI S，CHEN W K，DE JONG S， et al. Framework for instruction-level tracing and analysis of program executions[C]. Proceedings of the 2nd International Conference on Virtual Execution Environments， 2006： 154-163.

（責任編輯：何 麗）