程序逆向分析在軟件供應鏈污染檢測中的應用研究綜述

武振華，張 超，孫 賀，顏學雄

(1.戰略支援部隊信息工程大學 數學工程與先進計算國家重點實驗室，鄭州 450001；2.清華大學 網絡科學與網絡空間研究院，北京 100084； 3.陸軍工程大學 指揮控制工程學院，南京 210007)

0 引言

近年來，軟件供應鏈(Software Supply Chain, SSC)安全問題頻發，在給用戶的隱私和財產帶來巨大損失的同時，也對軟件供應鏈的安全防護提出了新的考驗和挑戰。有別于傳統的針對軟件自身程序漏洞進行的攻擊，軟件供應鏈攻擊者側重利用軟件供應鏈上的安全漏洞，在合法軟件的開發編譯、分發交付以及安裝使用等環節中進行劫持或篡改，借助用戶和軟件供應商之間的信任關系，在合法軟件的外衣下，突破安全產品的防線，獲得用戶的信任，悄然實施攻擊[1]。這種攻擊的結果導致了軟件供應鏈污染。

目前關于軟件供應鏈安全的研究剛剛起步，文獻[2]列舉了多個宏觀層面的研究，概述了軟件供應鏈定義、安全威脅、防御手段等方面的內容。在具體技術方面，文獻[1]對軟件供應鏈污染技術、軟件供應鏈污染主動防御方法以及針對WordPress的供應鏈安全污染檢測技術進行了研究。目前尚未有工作對軟件供應鏈安全研究的其他問題進行研究和綜述。

文獻[3]指出，自動化程序分析技術是軟件供應鏈安全研究的重點內容，但是當前多數軟件供應鏈污染檢測研究仍處于手工或半自動分析階段。多數工作利用手動分析或自動化分析工具輔助分析的方法進行研究，鮮有工作能夠實現自動化分析并檢測軟件是否被污染。

自動化程序逆向分析技術一直是信息安全領域研究的熱點和重點問題之一，已有大量工作對程序逆向分析和惡意代碼檢測技術進行了研究。在基礎程序分析方法方面，文獻[4]對靜態分析方法進行了深入研究；文獻[5]對動態分析方法進行了綜述；在現今主流的程序分析技術方面，文獻[6]對符號執行和污點分析技術進行了綜述；在程序分析技術的應用方面，文獻[7]對惡意代碼分析技術進行了全面的研究，但是尚未有工作系統性地分析現有程序逆向分析方法及其應用技術(惡意代碼檢測)是否可以滿足軟件供應鏈安全研究的需要。

本文主要關注針對二進制程序的軟件供應鏈的污染檢測技術，在軟件供應鏈下游發現供應鏈中存在的污染問題。本文主要工作及貢獻包括：

1)對軟件供應鏈污染檢測問題進行了深入剖析和闡述；

2)指出了軟件供應鏈污染檢測問題與傳統惡意程序分析和檢測問題的聯系和區別；

3)介紹了目前使用的程序逆向分析方法及其在軟件供應鏈污染檢測中的應用；

4)展望了軟件供應鏈污染檢測中亟待解決的問題及若干可行并值得進一步研究的課題。

針對上述問題，本文詳細分析了22個軟件供應鏈污染事件；對97篇高水平論文進行了分析和介紹，文獻主要來自中文核心期刊以及中國計算機學會(China Computer Federation, CCF)A類會議、期刊；內容涵蓋了程序分析技術以及軟件供應鏈污染研究前沿研究。論文搜索關鍵詞包括(中英文的)程序分析、逆向工程、靜態分析、動態分析、符號執行、污點分析、軟件供應鏈、軟件供應鏈污染等。絕大多數論文下載自谷歌學術、知網、百度學術等知名學術搜索平臺，內容涵蓋了信息學科下主流數據庫，包括國際計算機協會(Association for Computing Machinery, ACM)、電氣和電子工程師協會(Institute of Electrical and Electronics Engineers, IEEE)、愛思唯爾、斯普林格等。

1 軟件供應鏈污染檢測問題

1.1 研究背景

軟件供應鏈是指軟件從軟件供應商到達用戶手中并被用戶使用的整個過程中相關環節的連接，從軟件設計開始，到代碼編寫與軟件生成，再到軟件分發與用戶下載，并最終由用戶使用的一個軟件供應商與軟件用戶之間，緊密圍繞軟件，由開發環節(上游)、交付環節(中游)和使用環節(下游)三大環節所組成的鏈狀結構[1,8]。軟件供應鏈攻擊是指攻擊者利用軟件供應商與最終用戶之間的信任關系，在合法軟件的開發、傳播和升級過程中進行劫持或篡改，從而繞過傳統安全產品檢查并達到非法目的的攻擊類型[1,9]。如圖1所示，軟件供應鏈攻擊可能發生在軟件供應鏈的任意環節。軟件供應鏈攻擊的結果是造成了軟件供應鏈污染，攻擊者在用戶運行了被污染的軟件后開始實施后續攻擊。與傳統的漏洞挖掘利用和終端病毒感染不同，軟件供應鏈污染更加強調由于第三方原因造成的軟件供應鏈上的軟件產品的安全威脅，主要包括攻擊者攻擊造成的軟件篡改或使用第三方代碼庫而引入的惡意代碼及安全漏洞。表1中總結了近幾年軟件供應鏈安全事件中，攻擊者使用的攻擊方式和最終導致污染的位置。

主動防御和被動檢測是保障軟件安全的兩種重要手段。其中，主動防御側重于阻斷攻擊者的攻擊，主要包括針對軟件開發商、開源軟件管理平臺、軟件發布平臺和用戶終端的安全防護，旨在從源頭上遏制惡意代碼的植入和擴散。文獻[10]對軟件供應鏈各個環節的主動防御策略進行了較為詳細的闡述。

圖1 軟件供應鏈攻擊示意圖Fig. 1 Schematic diagram of SSC attack

表1 軟件供應鏈污染事件污染方式總結 Tab. 1 Summary of pollution methods of SSC pollution events

續表

被動檢測是假定可能有攻擊存在，在生成的軟件中檢測是否存在污染。軟件供應鏈污染檢測屬于被動檢測，主要包括對開源代碼、開源軟件包、軟件安裝包和軟件可執行程序的安全性檢測。這其中，安全性檢測又包括惡意代碼檢測和漏洞挖掘，檢測對象包括程序源代碼和程序可執行文件。程序逆向分析技術是安全性檢測的基礎，文獻[11]對其進行了詳細闡述。文獻[5]對惡意程序檢測技術進行了全面的綜述。文獻[12]對軟件安全漏洞檢測技術進行了總結。

1.2 軟件供應鏈下游的污染檢測

軟件供應鏈下游的污染檢測是針對軟件的可執行文件或提供的服務進行的污染檢測。檢測目標是表1中“污染位置”列所示的軟件形態。由于軟件供應鏈污染檢測涵蓋內容過于繁雜，涉及不同編程語言、編譯環境、運行環境等，后文主要針對傳統的C/C++語言編寫、編譯得到的程序進行闡述。

1.2.1 研究意義

軟件供應鏈上游的軟件廠商和中游的分發平臺可能受到成本、效率和利潤等因素的制約，不可避免地遺留一些安全漏洞。這些漏洞可能被攻擊者利用，導致軟件供應鏈的污染，因此軟件供應鏈的污染源很難被完全消除，仍需要在軟件發布之后，即在軟件供應鏈下游對發行的軟件進行污染檢測。

同時，在軟件供應鏈下游的污染檢測能夠發現上游、中游的所有污染。從表1中很容易看出，軟件供應鏈污染的代碼最終必須要在下游用戶端執行才能發揮其效用，因此，軟件供應鏈下游的污染檢測能夠極大彌補主動防御的不足，對軟件進行更加全面的掃描。

再者，軟件供應鏈下游的軟件樣本比較容易獲取。研究人員可以更加容易地獲取軟件樣本進行研究。

1.2.2 問題分析

軟件供應鏈下游的軟件供應鏈污染檢測問題與惡意代碼檢測問題沒有本質區別，都是對程序是否惡意的判定。檢測流程是，首先搜集軟件特征，之后對特征進行結果判定。目前主流的人工智能(Artificial Intelligence, AI)技術完全可以實現高精度的結果判定，但是，其前提條件是要能夠搜集到完整的或者關鍵的軟件特征。如果無法搜集到污染代碼或污染行為，即使是最先進的AI技術也無法作出準確的判斷。然而，在搜集軟件特征方面，軟件供應鏈污染檢測比傳統的惡意代碼檢測更加復雜，表現在如下幾方面。

首先，軟件供應鏈下游的污染檢測比傳統的惡意代碼更為隱蔽，被植入的代碼常與正常程序代碼混淆在一起，當軟件供應鏈上游被污染時，惡意代碼還可能帶有合法的軟件廠商的簽名。由于多數安全防護軟件使用白名單機制過濾掉可信任廠商發布的軟件，因此其中的污染代碼比傳統惡意代碼更難被發現。

其次，很多被污染的軟件會提示用戶在使用過程中關閉安全防護軟件從而實施攻擊，導致程序難以被安全防護軟件集成的云查殺系統發現，導致被污染軟件可以長期在網絡上傳播。

再次，軟件供應鏈上的安全檢測目標不僅包括軟件的可執行程序，還包括軟件的安裝程序，然而軟件的安裝過程往往需要借助用戶交互來完成；同時，很多軟件廠商使用自定義的打包工具發布軟件安裝包，且不支持靜默安裝，對于大量存在的此類安裝包，現有方法很難實現自動化的用戶交互并完成軟件安裝過程，因此導致其中的污染代碼難以被發現。

最后，攻擊者還可能在軟件中植入惡意代碼，這些代碼可能隱藏在軟件程序的任何角落中，只有當用戶通過用戶界面(User Interface, UI)使用軟件的特定功能，這些代碼才能被觸發。此時，這些惡意代碼極難被分析人員發現。

1.2.3 程序逆向分析與軟件供應鏈污染檢測

傳統的惡意代碼分析技術使用的特征主要分為語法特征和語義特征兩大類。程序的語法特征需要通過解析程序的二進制執行，并轉換為高級語言(反匯編、反編譯)。程序的語義特征主要包括應用程序接口(Application Programming Interface, API)調用和執行過程中的系統狀態改變情況。

然而由于代碼混淆技術的廣泛使用，惡意代碼經常主動識別當前的運行環境，或者設置觸發條件來執行惡意行為。

傳統的單純依靠被動監控程序執行的方法很難搜集到惡意代碼的真實語義，所以，對于帶有反分析技術的惡意代碼，無論搜集其語法特征還是語義特征，都需要用到程序逆向分析技術。又由于軟件供應鏈下游的污染檢測目標主要為可執行程序，因此，需要用到程序逆向分析技術對其進行分析。

后文將首先介紹當前程序逆向分析技術在軟件供應鏈下游的污染檢測中的應用，并分析當前技術在解決軟件供應鏈污染檢測問題時仍存在的具體問題，最后提出了若干可行的解決思路。

2 程序逆向分析技術的應用

現有的程序分析方法主要包括靜態分析、動態分析、符號執行和污點分析。靜態分析和動態分析是檢測代碼安全的基本方法，兩者的區別在于獲取信息的方式不同：靜態分析方法的數據源是可執行文件中的數據，動態分析的數據源是動態執行過程中獲取的運行時數據。符號執行和污點分析技術是應用最廣泛的二進制程序分析技術，靜態分析方法和動態分析方法均可以實現這兩種技術。

本文總結了近十年來國內外發生的百余起軟件供應鏈安全事件，標注了安全人員在分析事件樣本時使用的程序分析方法，部分結果如表2所示。

傳統的靜態分析方法在目前軟件供應鏈污染檢測中起到了非常重要的作用，分析人員在事件的分析過程中無一例外地使用了交互式反匯編器專業版(Interactive Disassembler Professional, IDA Pro)[35]工具查看反匯編、反編譯代碼以及程序中各個函數的控制流圖。大多數事件的分析過程也用到了動態分析方法，表2標注了事件分析中使用的具體的動態分析方法。同時，符號執行和污點分析兩欄標注了自動化分析該事件的樣本時否需要該項技術，例如對不存在對抗的樣本可以直接用動態跟蹤技術跟蹤程序行為，而對存在對抗的樣本，如“隱魂”木馬，在自動化分析時則要借助符號執行和污點分析技術實現。目前供應鏈污染問題的檢測尚處于人工分析階段，在現有軟件供應鏈污染事件報告中很少提及自動化分析技術的應用。

表2 軟件供應鏈安全事件中使用的程序逆向分析方法 Tab. 2 Program reverse analysis method used in SSC security events

2.1 靜態分析

靜態分析以靜態反匯編[36]技術為核心。靜態反匯編技術是指將程序可執行文件中保存的二進制機器碼(machine code)解碼為匯編代碼的過程。主流的靜態分析算法包括線性掃描和遞歸沉降算法[37]。區別是遞歸沉降算法解析控制流轉移指令的目標地址，下一條要解析的指令地址是上一條指令的控制流后繼指令的地址，而不是該指令的結束地址。IDA Pro[35]、Capstone[38]、Binary ninja[39]和Ghidra[40]等是使用比較廣泛的反匯編及逆向分析工具。

靜態分析的最大優勢是能夠對整個程序的指令進行全面的分析。表2中所示幾乎所有軟件供應鏈安全分析工作都使用了靜態反匯編或靜態分析工具。這些靜態分析工具均除提供反匯編功能外，還提供了基于反匯編指令的進一步分析結果，包括可執行文件結構解析、控制流分析[41]、數據流分析[42]、庫函數識別[43]、反編譯等。

可執行文件結構包含了大量有利于逆向分析的信息，不同平臺的可執行文件結構的不同，以Windows PE結構為例，其中的段屬性信息指示了數據的類型，反匯編方案只需要針對可執行屬性的數據進行分析；導入表信息指示了程序使用的動態鏈接庫及動態鏈接函數。

控制流分析主要是識別函數中的基本塊以及基本塊間的流轉關系。數據流分析主要識別指令操作數間的依賴關系，一般基于控制流分析實現。數據依賴分析是現在應用最廣泛的數據流分析方法，程序切片[44]、污點分析[45]、約束求解[46](符號執行[47])等技術都直接或間接地應用了數據依賴分析技術。同時，主流的靜態分析工具在靜態反匯編過程中都會默認實現控制流和數據流分析，用于獲取控制流圖和代碼間的引用關系。

庫函數識別是靜態分析方法優勢的重要體現。靜態鏈接庫函數體嵌入在程序代碼中，由于二進制程序中沒有符號表信息，靜態鏈接庫函數需要用特定的方式進行識別。目前通用的方法是通過對已知靜態鏈接庫函數建模得到唯一的特征，并在程序分析時分析各個庫函數，查看其特征是否與已知靜態鏈接庫函數的特征一致。例如在CCleaner事件[27]中，奇安信安全團隊通過分析異常庫函數發現惡意代碼被植入在C語言動態運行庫(C Run-Time library, CRT)中[48]，進而推斷出實施攻擊的方法。

反編譯是將匯編代碼翻譯成高級語言的過程，目前主流反編譯工作需識別不同的處理器架構，僅支持一部分架構的匯編語言。高級語言能夠幫助分析人員更好地理解程序邏輯，極大地提高了人工分析樣本的效率；但是，惡意程序常在運行過程中動態解密、釋放指令或數據[49-50]，靜態分析方法很難檢測該問題。Oh等[51]為提高靜態分析的準確度，提出了基于貝葉斯優化的自適應學習方案,并以此建立面向數據流和上下文的部分靜態分析工具。Jeong等[52]通過非線性的上下文選擇,建立識別上下文敏感函數的學習方法，并設計了數據驅動的上下文敏感的指針分析方案。但這兩種方案并不能從根本上解決問題，動態分析方法更適合對其進行分析。

2.2 動態分析

動態分析以動態跟蹤技術為核心。在動態跟蹤過程中獲取原始數據，之后再利用這些數據進行后續分析。動態跟蹤可以獲得不同語法語義級別的數據，跟蹤過程中可以按照指令、基本塊、函數等不同粒度搜集程序本身的語法信息，也可以在程序運行過程中搜集系統信息，根據系統狀態的變化來表征程序行為；或在運行時搜集系統調用信息，用來刻畫程序行為；或者監控內存權限變化，例如先寫后執行(execute-after-write)[53-54]或先重構導入表信息再執行(execute-after-rebuild)[55]等特征來表征程序的自脫殼行為。

目前主流的動態分析平臺主要采用三種方式構建運行環境。第一種是基于QEMU[56]的全系統模擬方案。混合符號執行(concolic execution)方案S2E(Selective Symbolic Execution)[57]、TEMU(BitBlaze[58]的動態跟蹤模塊)均基于QEMU實現。全系統模擬的好處是能夠獲得整個系統的信息。例如表2中列舉的“隱魂”“異鬼”木馬病毒事件，惡意代碼與正常程序安裝包捆綁發布，并注冊系統服務或安裝程序驅動，借助服務或驅動實現惡意代碼持久化以及其他部分功能。此時，基于全系統模擬的分析平臺能夠在動態分析過程中發現這些行為。

第二種方式是使用代碼插樁的方式進行動態跟蹤，包括動態插樁和靜態插樁兩種方式。動態代碼插樁是在程序運行過程中插入分析代碼。Intel Pin[59]是使用最廣泛的動態插樁方式，例如DynamoRIO[60]、Mayhem[61]等均基于Pin實現。此外DynInst[62]和Valgind[63]也是比較著名的動態插樁工具。靜態插樁方法主要以二進制重寫(Binary Rewrite)為核心，代表性的工作包括MIL[64]和Pebil[65]等。由于動態插樁需要在程序執行時執行額外操作，以調用執行跟蹤的回調函數，因此靜態插樁方法的開銷普遍低于動態插樁方法；但是由于靜態插樁方式在程序執行之前完成插樁，當惡意程序引用惡意的第三方庫，或存在自修改代碼，或靜態分析被干擾時，該方法將造成漏報。

第三種方式是使用硬件特性記錄程序的執行序列。典型工作是Intel Processor Tracing (PT)[66]，信息搜集工作位于硬件CPU上，需要主機提供硬件支持。由于該技術采用硬件機制實現，因此跟蹤速度最快，特別適用于構建基于Fuzzing技術的漏洞挖掘方案；但是PT獲取的信息不完整，跟蹤得到的信息需要額外計算時間進行解碼。

絕大多數軟件供應鏈安全威脅檢測都需要借助動態分析方法來完成，表2中標注了各個事件的分析過程中具體涉及的動態分析方法，包括了在動態執行過程中對程序本身以及各種系統資源，如系統資源、服務、驅動、流量信息等的監控。此外，表2中標注的“動態字符串提取”和“監控代碼動態釋放”是指污染代碼會在動態執行過程中從數據段解密出敏感API名稱字符串和敏感操作指令，從而對抗靜態分析；“溯源分析”和“系統日志分析”是指利用攻擊者在系統或軟件中留下的痕跡定位污點源的過程，常用于軟件供應鏈污染源頭定位工作。

動態分析方法的瓶頸在于分析覆蓋率有限，很容易受到惡意程序作者的惡意干擾。例如“隱魂”木馬使用多種反分析技術，防止分析系統搜集到程序惡意行為。對此，研究者們提出了路徑探索[67]和透明分析[68]技術。其中路徑探索技術是應用最廣泛的提高動態分析覆蓋率的方法。該技術通過求解不同路徑約束的程序輸入，引導程序控制流向更高覆蓋率方向轉移。透明分析著力于構建被分析樣本無法感知的分析系統，防止被分析程序因為檢測到分析環境而不再執行惡意行為。當程序設定只有在滿足特定條件時才會觸發惡意代碼時，例如分布式拒絕服務(Distributed Denial of Service, DDoS)[69]攻擊程序，透明分析平臺依然無法搜集到惡意行為，因此，路徑探索技術更適用于惡意程序分析工作，該技術已經成為符號執行引擎的內置模塊，能夠顯著減少人工分析的工作量。

2.3 符號執行

動態符號執行又稱混合符號執行(concolic execution)。其核心思想是在程序執行過程中搜集路徑約束[47]，之后根據路徑探索策略[70]選擇一個需要繼續探索的路徑，并且求解[71]滿足該路徑的約束的程序輸入，使得控制流向目標路徑轉移。絕大多數符號執行引擎會將指令轉換為中間語言(Intermediate Language, IL)，在中間語言上實施符號執行。IR能夠消除復雜指令集中存在的指令二義性問題[58]。目前使用最廣泛的IR包括Vex[63]、底層虛擬機(Low-Level Virtual Machine, LLVM)[72]等，但文獻[73]指出將指令lift為IR會影響分析的效率，進而提出了直接針對特定指令的快速混合符號執行和模糊測試方法。

程序執行路徑的路徑約束可以在程序執行過程中獲取，如S2E[57]，被稱作在線分析；也可以在程序執行結束后對得到的指令trace進行分析后獲取，如Sage[74]，被稱作離線分析。離線分析模式需要每次從程序入口點開始執行程序進行分析，好處是分析系統不需要維護程序狀態，減少了由于保存程序狀態而造成的內存開銷；在線分析模式不需要重復執行不同路徑間的重復指令，但是會隨著正在分析的路徑數目增大逐漸耗盡系統資源。對此，Mayhem[61]提出了混合模式的符號執行方法。

符號執行技術依靠路徑探索策略選擇下一個需要分析的路徑及需要求解的路徑約束。根據不同應用，符號執行引擎會選擇不同的路徑探索策略，例如：在惡意程序分析和模糊測試應用中，廣度優先和深度優先策略應用最為廣泛；而在漏洞挖掘應用中，敏感操作優先策略應用更多。具體應用可以定義自己的敏感操作規則，從而使能夠引導控制流至敏感操作的路徑被優先分析。例如S2E提出了一種面向符號化數據(data-based selection)的路徑探索策略，優先執行對污點進行操作的路徑。

由于符號執行會造成較大的時間開銷，文獻[75]中提出了選擇符號執行的概念，并實現了能夠在動態執行過程中選擇部分代碼進行符號執行，而剩余代碼具體執行(concrete execution)。Chipounov等[57]根據這一思想實現了著名的符號執行引擎S2E，并從一致性角度提出了針對不同應用的六種分析模型[76]。此外，一些符號執行引擎通過靜態方法獲取元數據，但是也實現混合符號執行的功能。例如二進制程序分析框架Angr[77]首先將程序可執行文件中所有二進制碼轉換為vex語言，并實施一系列靜態分析方法，包括控制流圖分析和程序依賴圖分析，之后再實施符號執行。通過解釋執行的方法彌補靜態分析產生的誤差。

符號執行的兩大難題是路徑空間爆炸和約束求解，程序切片[78-79]、程序抽象[80]和等價路徑約減[81]等方式可以通過控制約束輸入范圍來減小程序路徑空間，有效緩解路徑空間爆炸問題；文獻[82-83]利用查詢緩存和重用的方式，在調用求解器前優化查詢路徑條件，以此來減少求解器的調用次數，降低求解時間，然而卻對非線性算數運算的約束無能為力；文獻[84]將約束轉換為滿足函數，并以此獲取滿足相應約束的值。

符號執行是實現路徑探索、提高動態分析覆蓋率的主要技術。表2中標注了符號執行的事件均需要借助路徑探索技術才能搜集到表達程序真實意圖的執行路徑。在現有軟件供應鏈污染分析報告中，絕大多數還依靠人工分析實現對程序執行路徑的探索。Sun等[85]提出了面向深度學習的動態符號執行方法,該符號執行方法將測試需求表示為量化線性運算(quantified linear arithmetic),以神經元覆蓋為目標測試深度神經網絡的魯棒性。符號執行策略的更加智能化[86]、與其他技術在不同層面的密切結合[73,87-88]以及面向大規模軟件的高效的符號執行方法是下一步研究的重點和難點，也是符號執行的研究趨勢。

2.4 污點分析

動態污點分析的主要流程是選擇程序的某些輸入標記為污點，在程序運行過程中根據污點傳播規則標記數據依賴于污點的內存或寄存器。如果從程序中的敏感操作涉及到的數據被標記為污點，則需要對該操作進行進一步分析。

污點分析的一般步驟如下：首先，污點分析系統需要根據實際需求確定污染源。一般以程序外部輸入作為污點源，包括程序命令行輸入、網絡輸入、I/O、API返回值、系統狀態(如注冊表、進程控制塊、線程控制塊)等。文獻[89]主張在惡意程序分析過程中考慮盡可能多的程序輸入作為污點源；其次，污點傳播規則定義了在何種情況進行污點傳播。一般來說滿足數據依賴于污點數據的指令的目的操作數會被標記為污點；最后，污點分析系統還需要指定需要執行進一步的敏感操作。一般來說，間接控制流轉移(包括間接跳轉和間接函數調用指令)、網絡傳出操作、I/O寫操作等都會被標記為敏感操作。在漏洞挖掘應用中，可能產生漏洞的API調用也會被標記為敏感操作。

動態污點分析系統需要克服污點傳播過程中可能發生的欠污染和過污染問題，文獻[45,97]對此進行了比較詳細的探討，但是目前尚未有完全精確的解決方案。Yadegari等[98]提出了比特級污點分析方案，并將其應用于提高針對混淆代碼的符號執行工作中[94]，通過污點分析方法搜集能夠引發控制流轉移的路徑約束。該方案還被用于進行控制流圖化簡[89]和分析由程序異常引發的控制流轉移的程序路徑[99]。文獻[100]中提出了基于逆向計算的細粒度污點分析方法，通過規定逆向計算規則，考慮語句的語義邏輯，推算污點傳播策略，有效減少了代碼冗余和污點的過度傳播。

隨著技術的發展，污點分析和符號執行工作的界限越來越模糊，因為符號執行中對路徑約束的搜集和求解在本質上也是數據依賴分析，并且例如上述Yadegari的幾個工作，利用污點分析幫助符號執行技術完成路徑約束的搜集。此外，符號執行和污點分析都可以通過前向或后向的方式實現。文獻[95]實現了反向符號執行方法，如果在后向回溯一定步數內，沒有發現能夠引導新控制流的程序輸入，則判定目標約束為無透明謂詞。其后向回溯的過程既可以被看作逆向符號執行過程，也可以看作是逆向污點傳播過程，因此可以認為，污點分析工作可以用作或者輔助符號執行的約束搜集方法獲得更準確的路徑約束。

污點分析的思想在軟件供應鏈污染檢測中使用非常廣泛，特別是在存在信息泄露的事件中。將敏感數據標注為污點源，如果污點數據被網絡發送，則說明發生了信息泄露。表2中標注了污點分析的事件多數發生了信息泄露。同樣的，目前類似問題仍多數由人工檢測完成。

2.5 現有工作的綜合對比

現有二進制程序逆向分析工作或在上述某一方面進行了深入研究，或設計實現統一的分析平臺，提供各種技術的調用接口。表3中列舉了10余個經典的或近年來發表在高水平期刊、會議的二進制程序分析工具，總結了這些工作的適用場景、測試數據集以及對比方法。研究人員可以有針對性地在這些平臺上進行軟件供應鏈污染檢測工作研究。

表3 二進制程序分析工具的適用場景 Tab. 3 Suitable scenarios for binary program analysis tools

續表

3 仍存在的問題

1.2.2節對軟件供應鏈下游的污染檢測問題進行了分析，本章聚焦于程序逆向分析方法，分析現有技術在解決軟件供應鏈下游的污染檢測問題中仍存在的問題及挑戰。

3.1 程序逆向分析方法自身的局限性

在對程序的逆向分析時，準確識別程序中所有代碼或行為至關重要，只有在獲取程序中所有代碼的基礎上，才能進一步實現惡意代碼檢測工作；然而現有技術在這方面仍存在一些局限性。

3.1.1 傳統逆向分析技術的局限

首先，文獻[101-103]總結了靜態分析方法分析對抗樣本時的不足。例如，加殼[104]或代碼自修改(self-modification)技術[49-50]的使用，可以將執行惡意行為的代碼變成數據存儲在二進制文件中，只有程序執行后原始代碼才會被執行，靜態分析方法很難準確通過指令解釋執行的方法分析出原始程序代碼；代碼混淆技術[105]，例如控制流扁平化、不透明謂詞、花指令、API混淆等也會干擾靜態分析的分析結果，導致誤報或漏報；別名分析(Alias Analysis)、值域分析(Value Set Analysis)[106]等分析方法在反向數據流分析、間接控制流轉移的目標預測等任務中均無法達到較高的實用性，準確率也偏低，進而導致靜態分析方法無法有效準確地判定控制流可達性和發現控制流轉移目標，最終導致靜態分析方法出現漏報或誤報。

此外，文獻[107]對多種反匯編工作在x86/x64架構下的反匯編能力進行了全面深入的分析，總結了反匯編工作仍存在的問題。由于反匯編是所有靜態分析方法的基礎，反匯編能力有限在惡意程序分析領域影響更大。

其次，雖然符號執行、路徑探索技術能夠提高動態分析的覆蓋率，惡意程序依然可以通過隱藏路徑約束[94]、利用復雜數學變換攻擊約束求解器[108]、使用單向函數阻礙約束求解[109]等技術干擾分析，使得動態分析方法很難搜集到程序的惡意行為。此外，符號執行技術還存在路徑爆炸的問題，當程序中存在循環，或者圈復雜度非常大時，程序的所有可執行路徑條數將過于龐大，無法逐一分析。此外，動態分析過程中缺乏全局信息，很難在動態執行過程中準確識別靜態鏈接庫函數。

3.1.2 緩解技術及其局限

為緩解上述問題，研究人員提出了大量緩解技術，以提高程序逆向分析技術的能力；但是這些技術仍然不能完全解決傳統程序逆向分析技術在分析混淆代碼時的問題。

首先，動靜結合的分析方法能夠從很大程度上克服動態分析覆蓋率不足的缺點。傳統的基于特征碼的惡意代碼檢測、基于熵的分析方法以及靜態間接控制流轉移識別能夠輔助惡意代碼檢測或指導動態分析朝著目標區域進行動態執行和分析。其中，基于特征碼的方法能夠從程序代碼中找出包含惡意行為特征的字節序列，從而快速完成已知惡意代碼的掃描；基于熵的方法能夠幫助分析系統標注可能存在加殼行為的代碼片段，動態分析應該盡量朝著能夠加載或者執行這些數據或代碼的方向運行；間接控制流轉移指令指示了靜態分析的分析盲區，動態分析方法需要對這些指令的位置作定向分析，以確定控制流轉移目標，彌補靜態分析的不足。文獻[110]中提出了一種深度的動靜結合分析框架，并實現了針對惡意程序的路徑探索策略；但是該工作效率較低，不適用于大型軟件的分析。目前尚未有工作實現了針對大型軟件的深度的動靜結合分析方法。文獻[111]中提出了超集反匯編(Superset Disassembly)的方法，從任意一個可能成為合法指令的地址開始反匯編，從一定程度上緩解了靜態反匯編方法無法獲取間接控制流轉移地址的問題，也能為提高動態分析覆蓋率提供導向依據。

在API識別方面，文獻[112]中提出了基于模式匹配的API識別方案，該方案雖然受到人工先驗知識的制約，漏報率較高，但具備很強的可擴展性；不同于傳統的靜態分析方法需要比對完整的函數代碼的簽名來實現庫函數識別，文獻[113]中提出了一種基于函數參數識別的針對混淆程序的API識別方法，能夠識別被混淆的API調用，該方案的準確性受制于函數參數識別的準確率，但其識別準確率較高，能夠極大提高分析效率。

在控制流圖恢復方面，文獻[114]中提出了一種基于靜態符號執行的，針對控制圖扁平化的控制流圖還原方案，針對LLVM混淆器(Obfuscator-LLVM, OLLVM)[102]的控制流扁平化結果較好，但是受制于靜態符號執行中存在復雜約束無法求解問題。文獻[115]中提出了基于強制執行的路徑探索、異常恢復以及控制流圖還原方案。文獻[94]中提出了符號執行技術的增強方案，用于發現符號執行過程中被隱藏的路徑約束，從而發現更多的隱藏的控制流轉移。文獻[99]中提出了一種針對異常處理機制的符號執行方法，能夠發現被程序作者故意隱藏的基于異常的控制流轉移。文獻[95]中提出了不透明謂詞檢測手段，以判定路徑可達性，從而去除控制流圖中的不可達部分。

然而這些工作也都各自存在一些局限，只有惡意代碼滿足其提出的模型時才能取得較高的準確性。例如文獻[94]需要flags寄存器參與計算才能準確識別路徑約束并實現符號執行；文獻[99]需要在動態觸發異常的條件下才能實現異常控制流轉移的準確識別；文獻[95]的方法受制于反向回溯的步長限制，超過預設步長，該方法將出現漏報。其次，沒有工作顯示上述方法能夠集成在同一個平臺中執行，其檢測目標均為單個可執行文件程序，沒有工作顯示這些方法能夠在大型商用軟件中高效執行。

綜上所述，現有的程序逆向分析技術在對混淆代碼的檢測中仍存在諸多局限，惡意程序作者可以利用這些局限對抗分析，造成分析系統的漏報。特別是在軟件供應鏈污染場景下，被測樣本規模遠大于惡意程序，給程序逆向分析技術帶來了更多挑戰。

3.2 程序逆向分析技術在SSC應用中存在的挑戰

傳統的惡意代碼檢測方案多僅針對單一可執行文件進行分析，導致使用程序分析方法進行軟件供應鏈下游的污染檢測時存在諸多挑戰。

首先，從表1可知，軟件供應鏈污染的目標包括軟件安裝包和軟件可執行程序，但是大型軟件的發布形式十分多樣。為了檢測可能存在的捆綁安裝、內置后門等問題，分析系統需要能夠處理任何一種軟件發布形式，并從中提取相應的程序進行分析。

例如，大多數官方的Windows軟件發布為一個獨立的安裝程序，需先運行安裝程序，將軟件運行所需要的所有文件釋放到指定目錄，并在系統中注冊相關軟件信息，才能使用該軟件。同時一些軟件也會以綠色壓縮版的形式發布，即將所有程序運行所需文件打包在一個壓縮包中，用戶只需解壓這些文件即可使用軟件。這種綠色免安裝的方式極易被攻擊，但是由于使用方便無需安裝，仍有大量用戶使用。

分析系統需要能夠自動執行或解壓縮安裝包，成功釋放程序可執行文件，并監控整個安裝和程序執行過程。目前尚未有工作能夠實現自動、穩定的大規模軟件安裝方法來獲取程序分析的二進制文件。

第二，商用軟件往往包含多個模塊、多個組件以及多種語言編寫的代碼，需要提出高效和統一的分析框架用于深入程序分析。此外，市場上的防病毒軟件多使用白名單機制，如果程序的簽名在白名單中則不再對其進行分析，而在軟件供應鏈開發環節中植入的惡意代碼，在下游程序簽名發布之后往往會逃避防病毒軟件的檢測。由于無法保證軟件供應鏈上游代碼的安全性，傳統的基于黑白名單的啟發式分析策略在軟件供應鏈安全研究中并不適用，需要對整個程序中所有的代碼深入分析。

第三，商用軟件多包含多種程序輸入，例如配置文件、UI交互、網絡通信、與操作系統交互等。這將導致動態分析方法將很難自動發現并提供有效的程序輸入，從而引起與程序輸入相關的代碼無法正常執行，最終造成動態分析方法的分析覆蓋率很難提升，進而導致惡意代碼檢測或漏洞挖掘方法出現漏報。同時，異步處理機制是常用的編程技術，而尚未有靜態分析方法工作能夠做到自動理解各種異步編程模型，并準確還原程序邏輯或控制流轉移關系。

第四，現有工作多處于語法分析層面，鮮有工作能夠自動準確理解程序語義，而程序語義理解在惡意代碼檢測和軟件邏輯漏洞檢測方面非常重要。基于機器學習和AI技術的惡意代碼分析和檢測工作能夠部分緩解語義理解補充的問題，但是該方法依賴大量樣本，而除C/C++語言外，其他編程語言的惡意代碼樣本量均達不到模型訓練要求。在漏洞挖掘領域，針對邏輯漏洞的挖掘大多依靠人工完成，尚未有可靠的自動化方法完成該任務。在具有多模塊的大型軟件中，邏輯漏洞的挖掘變得更加困難，目前沒有較為理想的解決方案。

4 總結與展望

對于發生在軟件供應鏈上的安全事件，安全分析人員往往采取綜合利用傳統的程序逆向分析方法來分析還原事件真相，然而此方法大多依賴于手工的調查取證，很難實現對軟件供應鏈上的軟件進行快速、安全、自動的檢測。針對軟件供應鏈安全問題的特殊性以及現有的程序逆向分析方法的局限，可采取以下可行方案來彌補程序逆向分析方法在軟件供應鏈安全研究中存在的缺陷和不足：

首先，在軟件供應鏈下游進行研究的數據源為軟件安裝包或綠色版軟件壓縮包，因此，要進行該項研究，必須解決軟件自動安裝獲取其可執行文件的問題。目前對軟件自動安裝的研究很少。可行的方案包括：1)基于規則的自動安裝；2)借助文字識別的基于規則的自動安裝；3)借助機器學習方法的自動安裝；4)基于生成對抗網絡的自動安裝。

第二，在軟件自動安裝之后，結合Lehman軟件進化法則[116]進行軟件的家族分類和血統分析[117]，此外，也可結合機器學習方法，可以利用已知版本號的軟件及其元數據特征，訓練血統預測模型，實現對未知軟件的血統分析。將血統分析后的待測軟件與同一家族中上一版本軟件進行對比，獲取待測軟件中的差異代碼；然而傳統的惡意程序家族分類方法僅針對單個可執行文件進行分析，而商用軟件大多包括多個可執行文件和配置信息，目前尚未有工作實現針對大型軟件的家族分類和血統分析工作。尤其是針對綠色版軟件，可執行文件釋放到磁盤后并不會在系統配置信息中留下痕跡，例如版本號信息等，對于這類軟件的血統分析工作需要進一步研究。

第三，獲取待測軟件的差異性代碼后，只需利用程序逆向分析方法對這些差異代碼進行檢測分析，以此來過濾掉軟件中大量的安全代碼，極大減少分析的代碼量，提高檢測效率。在軟件代碼深入分析方面，可以利用動靜結合的分析框架、基于非一致執行的分析方法可以幫助分析系統部分解決深層次路徑無法覆蓋的問題。

第四，對于基于異步模型的代碼觸發問題，分別針對UI、網絡連接等常見場景進行各個擊破是可行的解決辦法。基于反饋的UI自動觸發技術可以避開代碼層面的異步觸發模型，通過監控模擬鼠標點擊的程序狀態改變以及代碼片段間的數據依賴關系，可以提高帶UI界面程序的代碼覆蓋率。通過劫持系統調用，可以控制程序的網絡連接狀態，自動填充模擬數據報文，并結合基于二進制代碼分析的協議逆向技術[118]，可以推斷報文格式，進而更好地實現模糊測試、生成程序輸入報文。

第五，針對程序的語義理解問題，可以通過API調用來表征程序語義，并自動查詢API手冊得到API的具體解釋，通過拼接API解釋的方法，將程序表征為自然語言文字。一方面可以利用自然語言表示輔助程序語義理解；另一方面，由于在不同編程語言中具有相同功能的API的自然語言解釋十分相近，可以通過該方式實現跨編程語言的程序分析。