論文名稱	發表時間	發表期刊	期刊等級	研究單位
Understanding the Security Risks Introduced by Third-Party Components in IoT Firmware	2024年	IEEE TDSC	CCF A	佐治亞理工學院

1. 引言

研究背景：物聯網（IoT）已經無處不在，為我們的日常生活提供了極大的便利。 從路由器、打印機等傳統物聯網設備，到智能燈、智能插件等智能家居，物聯網設備在現代生活中的應用日益廣泛。 根據最近的一份報告，Gartner預測，從2020年到2030年，物聯網設備的數量將增加兩倍。物聯網設備的蓬勃發展也不可避免地引發了公眾對其安全風險的擔憂以及幾次現實世界的攻擊進一步加劇了這種恐慌。 例如，Mirai 已經危害了數百萬個物聯網設備，包括 IP 攝像機、DVR 和路由器，形成僵尸網絡，并對各種在線服務發起 DDoS 攻擊。

固件是在物聯網設備中啟動的集成軟件包，發揮著重要作用。 如今，固件廣泛采用 TPC，例如 BusyBox 和 OpenSSL，以加速和簡化開發過程。 然而，TPC 的廣泛使用是一把雙刃劍，因為大量 TPC 存在已知漏洞，這些漏洞將為物聯網固件帶來許多新的攻擊面。 例如，OpenSSL 中的 Heartbleed 漏洞 已經極大地影響了至少數百萬臺物聯網設備。 更糟糕的是，供應商可能會在不同類型的固件中重復使用一組相同的 TPC，這會加速潛在漏洞的傳播。 因此，識別固件中使用的易受攻擊的 TPC 至關重要。 由TPC引起的單一漏洞可能會在物聯網生態系統中造成蝴蝶效應。

現存問題：盡管一系列研究采用了靜態或動態方法在評估固件安全性方面，它們仍然受到限制，因為它們較少關注固件中由 TPC 引起的漏洞，缺乏對非基于 Linux 的固件的考慮，和/或在大規模固件安全分析中無法擴展。 具體來說，首先，他們缺乏對TPC引入的 N-day 漏洞的分析，這可能會導致比現實中未知漏洞更嚴重的問題。 其次，大多數方法僅限于分析基于 Linux 的固件，而缺乏對單片固件的分析，而單片固件廣泛應用于新的無處不在的低功耗嵌入式系統，例如智能家居。 最后但并非最不重要的一點是，在進行大規模固件測試時，它們的可擴展性是一個挑戰。 例如，多種方法需要真正的物聯網設備進行分析或進行大量手動配置工作，這極大地限制了它們的可擴展性。 因此，目前仍然缺乏一種可擴展且實用的方法來全面了解TPC在多種固件中的使用情況及其引入的漏洞。

1.1 研究挑戰

固件數據集構建：為了進行研究，第一個挑戰是構建一個大規模且全面的固件數據集，涵蓋來自不同供應商的不同類型的固件。 從而可以獲得關于當前固件安全問題的令人信服的結果。 然而，沒有可公開訪問的固件數據集用于研究。 此外，越來越多的廠商開始禁止公眾下載固件，并對惡意網絡爬蟲采取反抓取技術，這又大大增加了數據收集的難度。 固件處理。 固件處理存在兩個主要挑戰。 (1) 從基于 Linux 的固件中提取包含的對象，這些對象具有 TPC 檢測的基本信息。 雖然現有的工具（binwalk），可以用于解壓固件，但它們在處理采用最新或定制文件系統的固件時存在局限性。 (2)處理單片固件，該固件廣泛應用于低功耗嵌入式系統，例如智能家居。 單片固件通常缺乏分析所需的傳統操作系統或元數據，例如 RAM/ROM 起始地址。 此外，它的代碼、庫和數據是高度混合的。 然而，面對這些挑戰，現有工具（例如 IDA）無法在沒有額外配置的情況下處理單片固件。

TPC 檢測和漏洞識別：在 TPC 檢測和漏洞識別方面面臨兩大挑戰， （1）在版本級別檢測 TPC。 為了準確識別固件中使用的 TPC 對應的漏洞，我們需要在版本級別進行檢測，而不僅僅是在 TPC 級別進行檢測，因為不同版本的 TPC 的漏洞可能有所不同。 然而，由于不同版本的代碼差異可能很小，因此很難在版本級別區分相同的 TPC。 此外，在沒有源代碼的情況下，只能從固件中獲取有限的特征來進行 TPC 識別。 以前的固件分析工作無法滿足我們的要求，因為它們不支持在固件的版本級別檢測 TPC。（2）構建TPC數據庫， 研究需要一個全面且易于使用的 TPC 數據庫，以指示固件中可能使用的 TPC 以及每個版本的 TPC 的漏洞。 調研結果表明，之前還沒有為物聯網固件構建這樣的 TPC 數據庫的工作。 收集盡可能多的 TPC 并將漏洞映射到 TPC 版本是一項挑戰。

1.2 研究方法

在論文致力于全面了解 TPC 在固件中的使用以及 TPC 帶來的潛在安全風險。 為此，作者開發了一個可擴展的自動化框架 FIRMSEC 來對物聯網固件進行大規模分析，論文的分析方法如下。

• 步驟 1：為了解決構建固件數據集的挑戰，作者從公共來源和私人來源（例如官方網站和私人固件存儲庫）收集固件映像。
• 步驟 2：作者為現有的工具（例如binwalk和IDA）定制了幾個插件，以解決固件處理中的問題。定制工具支持解壓和反匯編基于 Linux 的固件（使用流行和不常見的文件系統）和單片固件。
• 步驟 3：作者提出了一種新的檢測策略來識別固件中使用的 TPC。論文的主要思想是利用從 TPC 和固件中提取的兩種特征：語法特征和控制流圖特征。然后論文根據版本檢查搜索相應的漏洞，這依賴于論文的TPC數據庫。根據結果??，FIRMSEC 將為每個固件映像生成一份報告，指出其潛在風險。此外，報告還將提供一系列修復漏洞的建議。

為了提供更深入的見解，論文進一步研究從四個方面探討物聯網生態系統的安全現狀。 首先，論文評估不同種類、不同供應商的固件的漏洞。 其次，論文調查了不同時期固件中TPC的使用趨勢以及它們引起的相應漏洞。 接下來，論文探討物聯網設備安全性的地域差異。 然后，論文探討了固件中過時的TPC問題。 然后，論文研究固件更新過程中 TPC 的變化。 最后，論文分析了固件中的 TPC GPL/AGPL 許可證違規情況。

1.3 研究貢獻

論文構建了迄今為止最大的固件數據集，其中包括 11,086 個可公開訪問的固件映像和 23,050 個私有固件映像。 它包含 35 種固件，其中大部分在以前的作品中很少研究。為了方便未來的研究，論文在 https://github.com/BBge/FirmSecDataset 開源了該數據集。

論文提出 FIRMSEC，一個可擴展的自動化框架，用于分析固件中使用的 TPC 并識別相應的漏洞。 FIRMSEC 在識別固件版本級別的 TPC 方面具有 91.03% 的精確度和 92.26% 的召回率，顯著優于學術界和工業界商業系統的最新成果，例如 Gemini、BAT、OSSPolice、binare 、360 FirmwareTotal?和阿里巴巴 FSS。

論文對固件中易受攻擊的 TPC 問題進行了首次大規模分析。 論文在 34,136 個固件映像中識別出 584 個 TPC，并檢測到 429 個 CVE。 根據結果??，論文揭示了物聯網固件中易受攻擊和過時的 TPC 的廣泛使用。 此外，論文注意到，隨著時間的推移，固件中包含越來越多由TPC引起的漏洞，而供應商在固件更新時幾乎不更新易受攻擊的TPC。 此外，論文確認了物聯網設備安全性的地理差異，其中韓國和中國等幾個地區的情況比其他地區更為嚴重。 最后，論文發現 2,478 個固件映像可能違反 GPL/AGPL 許可條款，這可能會導致訴訟。

2. 設計與實施

FIRMSEC 旨在自動識別固件中使用的 TPC 并檢測相應的漏洞。 如下圖所示，FIRMSEC主要包含三個部分：固件采集、固件預處理和固件分析。 固件采集模塊主要用于采集不同來源的固件。 接下來，固件預處理模塊將分三步處理收集到的固件，（1）從原始數據集中過濾掉非固件文件； （2）識別固件必要的信息； （3） 解壓并拆解固件。最后，固件分析模塊將根據從 TPC 和固件中提取的語法特征和控制流圖特征來檢測固件中版本級別的 TPC。 根據論文的TPC數據庫，通過版本檢查來識別相應的漏洞。 以下小節將討論每個組件背后的實現。

2.1 固件收集

固件采集模塊負責采集固件以構建大規模的原始數據集。 為了解決固件資源有限的問題，論文實現了一個網絡爬蟲從三個來源收集固件：官方網站，一些供應商在其官方網站上提供固件下載鏈接。FTP站點，論文發現了一個存儲舊版本固件的 ftp 站點列表，可以免費下載。社區，論文從社區收集了多家廠商的部分固件鏡像，包括相關論壇和GitHub倉庫；私有固件存儲庫，論文獲得了訪問一家主要專注于智能家居的世界領先公司的私有固件存儲庫的權限。 在論文使用 TSmart 來代表這家公司。 TSmart 的固件存儲庫包含數以萬計的由數百家供應商（例如飛利浦）制造的智能家居固件映像，并且從未被研究過。 其次，我們基于 Scrapy 實現了一個網絡爬蟲，它支持從13個供應商的31個站點收集固件，例如TP-Link、DLink、Trendnet等。

2.2 固件預處理

在這一部分中，論文主要通過三個步驟對收集到的固件進行預處理：固件過濾、固件識別、固件提取以及固件反匯編。

固件過濾：第一步是從原始數據集中排除非固件文件。 分析原始數據集中的非固件文件將產生意想不到的結果，從而影響論文最終結果的可信度。 因此，論文需要從收集的固件中排除非固件文件。 首先，論文通過后綴匹配過濾掉明顯的非固件文件，例如.txt文件。 其次，論文采用下一代二進制分析（BANG），它支持識別136種文件，以去除其他非固件文件，例如Android Dex。 論文將其應用于其余收集的文件，并根據返回的文件類型刪除非固件文件。

固件識別：第二步是識別固件的必要信息，例如操作系統、架構和文件系統，這對于進一步分析至關重要。 盡管非固件文件已從數據集中排除，但仍有大量固件映像的類別仍未知。 此外，論文還缺乏有關他們的操作系統、體系結構、文件系統等信息，這對于進一步分析至關重要。 采用兩種方法來識別未知固件的類別。 (1) 論文從固件爬取的元數據文件中提取信息。 元數據文件描述了固件，包括其對應的設備型號、類別等。 元數據文件通常與固件位于同一存檔中。 （2）論文實現一個腳本來查詢互聯網上未知固件的文件名，并爬取返回的前3個站點的內容，其中可能包含相關信息，例如固件的類別。論文最終結合上述兩種方法獲得的信息來識別未知固件的類別。 其次，論文采用binwalk掃描所有固件鏡像，獲取其操作系統、架構和文件系統。

固件提取：固件中包含的對象具有許多語法特征，這對于進一步的 TPC 檢測至關重要。 此外，從固件中提取的鏈接庫是創建TPC數據庫的主要來源。 因此，在進行進一步分析之前，有必要進行固件提取。 然而，現有工具在提取采用最新或定制文件系統的固件時或多或少存在提取不完整等問題。 這里的主要挑戰是徹底提取固件中的文件系統，而不遞歸提取壓縮數據。 為了應對這一挑戰，論文為 binwalk 配備了一系列插件。 首先，論文分析了收集到的固件中使用的文件系統，發現原始的binwalk主要在處理三種流行的系統上存在問題：SquashFS、JFFS2、YAFFS和UBIFS。 然后，論文利用 sasquatch 和 jefferson 來替換 binwalk 中的 unsquashfs 和 jffsdump。 這些插件支持許多特定于供應商的 SquashFS 和 JFFS2 實現。 接下來，論文為 binwalk 實現一個基于 yaffshiv 的新插件來解壓 YAFFS，它支持 YAFFS 構建參數（例如頁面大小）的暴力破解，甚至在文件系統運行多輪后也可以提取包含的對象。 最后，論文基于 UBI Reader?為 binwalk 開發了一個插件來解壓 UBIFS。

固件反匯編：固件中的控制流圖 (CFG) 包含識別固件中 TPC 的基本信息。 為了獲得CFG，論文需要先反匯編固件。 然而，現有的反匯編工具無法在沒有額外配置的情況下處理單片固件。 例如，原生 IDA 和 GHIDRA 都無法處理許多單片固件映像，因為它們采用不常見的處理器并丟棄一些必要的信息，例如分析所需的 RAM/ROM 起始地址。 這里的主要挑戰是根據單片固件的已知有限信息來恢復丟失的信息。 為了解決這一挑戰，論文首先分析單片固件中使用的處理器以恢復丟失的信息，然后為 IDA 實現一系列定制插件來加載和反匯編單片固件。 更具體地說，首先，論文分析收集的單片固件中使用的處理器類型，例如 ESP8266 。 其次，論文收集每個處理器相應的參考手冊或數據表。 參考手冊和數據表可以為我們提供三種有用的信息：處理器的核心、內存映射和中斷向量表。 論文可以根據核心找出反匯編固件的確切指令集，并從內存映射中檢索用于加載固件的RAM/ROM起始地址。 此外，論文還可以從中斷向量表中獲取固件起始地址。 最后，論文根據恢復的信息為IDA實現了 7 個插件，對應于單片固件中使用的7種處理器。 這些插件使 IDA 能夠自動加載和反匯編單片固件。

2.3 固件分析

通常的做法是使用版本檢查來識別TPC的相應漏洞。 在FIRMSEC中，論文也采用這種策略來分析固件。 固件分析模塊包括三個子模塊：（1）TPC數據集構建，（2）TPC檢測，（3）漏洞識別。

TPC 數據集構建：論文的分析策略需要一個 TPC 數據庫，其中包含固件中可能使用的 TPC 以及每個 TPC 版本的詳細漏洞信息。 然而，與指示 Android 應用程序中使用的 TPC 的 Maven 存儲庫不同，沒有這樣一個可公開訪問的 IoT 固件數據庫。 這里的主要挑戰是從可靠來源收集盡可能多的 TPC 并將漏洞映射到 TPC 版本。 為了克服這一挑戰，論文首先從四個來源收集物聯網固件中可能使用的 TPC：（1）從固件中提取的鏈接庫； （2）開源物聯網項目； （3）來自多個物聯網平臺的SDK，例如AWS IoT； 4）來自 TSmart 的 TPC 候選列表，如下表所示。其次，論文利用專業的CVE搜索工具 cve-search 從CVE數據庫中查詢TPC，并實現一個腳本 查詢 NVD?和 CVE 詳細信息以收集 TPC CVE。 通過這兩種方法，論文可以獲得不同版本 TPC 對應的 CVE。 構建的物聯網固件TPC數據庫具有以下字段：TPC、許可證、版本、CVE、CVSS分數[49]和CVE描述。 我們最終收集到了 1,261 個 TPC。

TPC 檢測：在版本級別精確檢測固件中使用的 TPC 對于我們的分析至關重要，因為論文將使用檢測到的 TPC 的確切版本來確認其漏洞。 然而，由于論文只能從固件中獲取有限的信息，并且不同版本的代碼差異可能很小，因此很難在版本級別區分相同的TPC。 為了應對這一挑戰，論文實現了一種基于兩種特征的新型 TPC 檢測方法：語法特征和 CFG 特征，這些特征在源文件和二進制文件之間幾乎沒有變化。 論文首先從 TPC 和固件中提取上述兩個特征。 接下來，論文利用編輯距離這種廣泛使用的方法來衡量兩個字符串之間的相似度，并使用基于比率的匹配來計算句法特征的相似度，并使用定制的Gemini 來比較 CFG 特征。 根據比較結果，論文最終確認了 TPC 在版本級別的使用。 工作流程如下。

• TPC 特征提取：首先，論文實現一個解析器來從 TPC 的 C/C++ 源文件中提取語法特征。 語法特征包括字符串文字（例如，唯一字符串）、函數信息（例如，函數名稱和函數參數類型）。 對于每種TPC，論文總結了其所有版本中共同的句法特征，將其視為共享句法特征。 然后，論文識別每個版本的 TPC 中的特定語法特征，這些特征被視為獨特的語法特征。 其次，我們從每個版本的 TPC 中提取屬性控制流圖（ACFG）。 ACFG 中的每個頂點都是一個標有一組屬性的基本塊。 除了Gemini 中使用的塊級屬性外，論文還使用了三個函數級屬性，如表2所示。函數級屬性提供了有關CFG結構的更詳細信息，而Gemini忽略了這些信息。
• 固件特征提取：首先，論文從固件中提取與上一步相同類型的語法特征。 雖然論文成功反匯編了基于 Linux 的固件和單片固件，但許多函數名稱是 IDA 無法識別的，特別是在單片固件中。 為了解決這個問題，我們為 IDA 配備了大量 TPC 的簽名文件，以識別反匯編文件中的函數名稱。 簽名文件主要是從互聯網上收集的，例如 GitHub 項目，論文也手動生成了一部分簽名文件。 其次，論文從反匯編的固件中提取 ACFG，其屬性與從 TPC 中提取的屬性相同。 然而，Gemini 使用的原始提取工具無法從單片固件中提取 ACFG，因為它無法反匯編單片固件。 因此，論文通過集成論文的固件反匯編模塊來定制提取工具。
• 語法特征匹配：在此步驟中，論文進行句法特征匹配來識別 TPC。 不幸的是，直接的特征匹配，例如正則表達式，會導致精度和召回率較低。 設計一種新的高精度和召回率匹配方法是這一步的主要挑戰。 為了應對這一挑戰，論文利用編輯距離和基于比率的匹配來測量 TPC 和固件之間的相似性。
• CFG 特征匹配：論文利用定制的 Gemini 來進行 CFG 特征匹配。 最初的 Gemini 旨在檢測固件中的特定漏洞，例如 OpenSSL Heartbleed 漏洞。 它首先分別從漏洞和固件中提取CFG。 然后，Gemini 將所有 CFG 轉換為 ACFG，記為 VulACFG 和 FirmACFG。ACFG 表示為七維向量，由七個塊級屬性組成。接下來，它使用嵌入基于 struct2vec?的網絡來計算這些 ACFG 之間的余弦相似度，記為 Cosine(VulACFG, FirmACFG)。 最后根據Cosine(V ulACF G, F irmACF G)列出了固件中前K個相似函數。盡管如此，最初的 Gemini 并不能直接應用于TPC檢測。 論文想要確認 TPC 和固件之間的相似性，而不是單個功能的相似性。 由于每個TPC 有許多 ACFG，單個 ACFG 的相似性不能確定TPC和固件之間的相似性。 這里的主要挑戰是設計一種方法來聚合 TPC 中每個 ACFG 的相似度，以表示TPC和固件之間的最終相似度。

漏洞識別：在此步驟中，論文利用版本檢查來根據論文的 TPC 數據庫識別固件中檢測到的 TPC 的漏洞。 該數據庫包含與不同版本的 TPC 對應的 CVE。 因此，論文實現一個腳本來自動查詢數據庫中的TPC和相應的版本（例如OpenSSL 0.9.8），并記錄返回的漏洞信息。 論文需要澄清的是，某些漏洞可能無法被利用，因為由于其他補救措施（例如禁用某些配置選項或執行某些檢查以防止其使用），可能無法訪問某些易受攻擊的代碼。 因此，論文將已識別的漏洞視為潛在漏洞。 論文最終為測試的固件生成一份報告，該報告指出了其潛在的風險，并提供了一系列修復漏洞的建議。

3. 系統評估

在本節中，論文首先介紹數據集的組成。 接下來，論文評估 FIRMSEC 的性能，并將其與來自學術界和工業界商業系統的三個最先進的作品進行比較：Gemini、BAT、OSSPolice、binare、360 FirmwareTotal 和阿里巴巴 FSS。

3.1 數據集組成

基于固件采集模塊，論文初步采集了來自 13 家廠商的共計 35 個、978 個固件鏡像，涉及 35 種設備。具體來說，從互聯網爬取 12,913 個固件鏡像，從 TSmart 獲取 23,065 個固件鏡像。論文的數據集實際上涉及數百家供應商，因為 TSmart 的私有固件映像是由數百家供應商制造的。?TSmart提供了一個平臺，可以使不同廠商的設備成為智能產品。為了方便起見，論文使用 TSmart 作為私有固件的供應商。論文列出了數據集的詳細組成。經過數據過濾，論文去除了 1,842 個非固件文件，最終獲得了 13 個供應商的 34,136 個有效固件映像，其中包括 11,086 個可公開訪問的固件映像和 23,050 個來自 TSmart 的私有固件鏡像。論文的數據集包括 35 種已知的物聯網設備和部分未知的物聯網設備。?2,694 (7.9%) 個固件映像用于相機，7,293 (21.3%) 個固件映像屬于路由器，1,191 (3.5%) 個固件映像部署在交換機上，23,050 (67.5%) 個固件映像 TSmart 已裝備智能家居，未知的有 255 個（0.7%）。除了上面提到的供應商和設備之外，論文的數據集還涵蓋了多種指令集，其中 ARM（23.9%）占據多數，MIPS 緊隨其后（4.9%）。SquashFS、CramFS 和 JFFS2 是數據集中包含的三種流行文件系統。根據論文的進一步分析，大多數未知文件系統實際上都屬于上述三個文件系統。 供應商在固件中定制了上述文件系統，這也改變了用于識別的原始文件系統的幻數。 此外，12,342 個 (36.2%) 固件映像是基于 Linux 的，21,794 個 (63.8%) 固件映像是非基于 Linux 的。

3.2 評估

數據集構建：論文首先構建四個數據集，數據集 I 用于訓練定制的 Gemini 并評估模型的準確性； 數據集 II 用于選擇 FIRMSEC 的閾值；數據集 III 用于評估 FIRMSEC 檢測固件中 TPC 級和版本級 TPC 的準確性；數據集 IV 用于比較 FIRMSEC 與業界三個商業系統的性能；數據集 V 用于評估FIRMSEC識別固件中TPC引起的漏洞的精度。

數據集 I 包括論文從 TPC 數據庫中的 1,192 個 TPC 中提取的 ACFG。 數據集 II 和數據集 III 具有固件到 TPC 使用情況的標記映射，以獲取真實數據。 根據前期調研，以前的作品中沒有這樣的數據集。 鑒于很難知道商業固件中使用的具體 TPC，我們最終使用 Tomato-shibby 和 OpenWrt 固件映像來構建論文的數據集，因為它們有源代碼，并且在配置文件中清楚地表明了所采用的 TPC 的確切版本。 對于數據集 II，我們從數據集中隨機收集 200 個 Tomato-shibby 固件映像，其中包括 17, 918 個 TPC 版本對（73 個不同的 TPC，211 個不同版本）。 對于數據集 III，我們從數據集中隨機選擇 300 個 OpenWrt 固件映像，其中包括 19,645 個 TPC 版本對（92 個不同的 TPC，194 個不同版本）。 論文使用兩個數據集分別進行閾值選擇和評估以避免偏差。 對于數據集 IV，論文隨機選擇 24 個固件映像，其中包括 19 個基于 Linux 的固件映像和 5 個單片固件映像。 對于數據集 V，我們隨機選擇 35 個固件映像，其中有 FIRMSEC 識別的 382 個漏洞。

模型精確度：論文按照 6:2:2 的比例將數據集 I 分為三個子集，分別用于訓練、驗證和測試。 論文根據原始 Gemini 的訓練流程對定制的 Gemini 進行 100 個 epoch 的訓練。 保存在 100 個 epoch 期間驗證集上實現最佳 AUC（曲線下面積）的模型。 論文最終在測試集上測試了模型，AUC 為 0.953。 論文也用同樣的過程重新訓練原始的 Gemini，AUC 只有 0.912。

閾值選擇：論文的最終結果是句法特征和CFG特征匹配的結果的并集。當各自的方法達到最佳性能時，論文不直接使用閾值，因為此時并集結果可能無法達到最佳。論文將三個閾值作為一個整體，并利用版本級別的真陽性率（TPR）作為衡量標準來選擇合適的閾值。論文將三個閾值及其對應的 TPR 組合為一個四維向量：[α, β, γ, TPR]。每個閾值的范圍是 0.01 到 1.00。我們選擇 TPR 達到最高時的閾值。

評估結果：論文使用兩個評估指標來評估 FIRMSEC 在數據集 III 上 TPC 級別和版本級別的檢測準確性，精度和召回率。 誤報代表論文錯誤識別的 TPC 和版本，漏報代表論文沒有找到的 TPC 和版本。FIRMSEC 在 TPC 級別上實現了 92.09% 的準確率、95.24% 的召回率，在版本級別上實現了 91.03% 的準確率、92.26% 的召回率。

論文發現并集結果的精度與各自方法非常接近，但召回率要高得多。 論文探討了聯合結果比單獨方法具有更好性能的原因。 首先，兩種方法的真陽性部分不重疊，從而減少了并集結果的假陰性。 例如，基于語法的方法很難檢測到具有有限語法特征（例如，沒有唯一字符串文字）的TPC，但可以通過CFG特征來識別它們。 其次，它們的誤報有重疊部分，不會大幅增加并集結果的誤報。 論文進一步分析誤報和漏報。 首先，誤報主要由兩個原因造成：（1）一些 TPC 會重復使用其他 TPC 的代碼，并進行微小的更改。 在這種情況下，FIRMSEC 將報告所有匹配的 TPC。（2）不同版本之間相似度高， 同一TPC的某些版本其代碼差異不大甚至沒有差異。漏報主要由兩個原因造成：（1）固件中使用的 TPC 不常見， FIRMSEC 無法檢測到未包含在我們數據庫中的 TPC。 （2）特征不足，某些固件僅使用部分構建的 TPC，其可用于識別的功能有限。

與學術著作的比較分析：論文將 FIRMSEC 與三種最先進的技術進行比較：Gemini、BAT 以及 OSSSPolice。 最初的 Gemini 使用 8 個塊級屬性來進行代碼相似度比較。 論文使用基于 CFG 權重的方法來增強它來檢測固件中的 TPC。 BAT 利用字符串文字來識別二進制文件中的 TPC，但無法檢測確切的版本。 OSSPolice 最初旨在檢測 Android 應用程序中版本級別的開源軟件使用情況。 鑒于它支持在 C/C++ 本機庫中查找 TPC，我們成功地將其應用到 IoT 固件上，并將其與 FIRMSEC 進行比較。 在進行對比之前，論文根據 BAT 和 OSSPolice 的指令分別生成對應的TPC數據庫。論文不報告版本級別的 BAT 結果，因為它不支持版本級別識別。 對于TPC級別的識別，FIRMSEC 遠遠優于其他工具。 FIRMSEC 以更高的精確度和召回率報告更多的 TPC。 對于版本級別識別，FIRMSEC 在兩個指標上都優于 Gemini 和 OSSPolice。 論文進一步探討 FIRMSEC 優于其他工具的原因。 首先，Gemini 忽略了函數級屬性，這些屬性提供了有關 CFG 結構的許多有用信息。 其次，BAT主要利用字符串文字來識別TPC。 它使用直接特征匹配來比較從TPC和固件中提取的字符串文字，這導致精度和召回率較低。 最后，OSSPolice采用分層匹配策略，依賴于TPC的包結構來識別TPC。 然而，同一TPC在不同版本中的封裝結構可以很容易地改變。 此外，其特征提取工具在物聯網固件上表現不佳，因為它沒有針對固件進行優化。

與行業系統對比分析：我們將 FIRMSEC 與三個行業系統進行比較，binare、360 FirmwareTotal? 以及阿里巴巴 FSS。 binare 實際上是根據最先進的工作開發的，該工作中提出的原型系統不支持查找 TPC 和固件中相應的漏洞，而其工業版本支持此功能。 360 和阿里巴巴是全球兩家知名公司，在物聯網安全方面都有豐富的經驗。 他們是少數提供可公開訪問的系統來檢測固件中 TPC 引起的漏洞的公司。 binare 和 FirmwareTotal 提供免費試用，FSS 每次使用費用為 300 美元。

由于兩個原因，論文不對數據集 III 進行與行業系統的比較分析。 首先，兩個行業制度限制了免費試用的數量。 論文不允許在數百個固件映像上執行它們。 其次，在論文的分析過程中，我們發現有兩個行業系統直接分析 OpenWrt 固件中的配置文件來識別 TPC，阻礙了實驗的公平性。 因此，我們最終對數據集 IV 進行了對比分析，包括 24 個閉源固件鏡像。

首先，FIRMSEC 可以分析所有測試固件鏡像，并且是唯一支持分析單片固件的。 對于 19 個基于 Linux 的固件映像，binare 無法處理 1 個固件映像，FirmwareTotal 無法處理 2 個固件映像，FSS 無法分析 7 個固件映像。 其次，FIRMSEC 在每個測試用例中檢測到最多的 TPC。 FIRMSEC發現的TPC已經覆蓋了binare、FirmwareTotal、FSS的全部結果。論文發現，binare、FirmwareTotal 以及 FSS 的結果主要包含幾種流行的 TPC，例如 BusyBox 和 OpenSSL，而 FIRMSEC 可以檢測到一些不常見的 TPC，例如 libogg。 第三，與其他三個系統相比，FIRMSEC 在 19 個基于 Linux 的固件映像中的 12 個中發現了更多的 N 天漏洞。 論文總結了 FIRMSEC 在其他 7 個測試用例中檢測到的漏洞少于其他系統的兩個原因。 (1) binare、FirmwareTotal、FSS錯誤報告不屬于對應固件的 N-day 漏洞。 (2) 對于一些案例，他們報告了相同 TPC 的多個版本。 例如，FSS在tl-ipc423(p).bin 中報告了兩個不同版本的 OpenSSL，并根據這兩個版本計算了漏洞。 論文在這 7 個測試案例中進一步去除了上述其他系統的誤報，發現 FIRMSEC 在所有情況下都能比它們檢測到更多的 N 天漏洞。 最后，FIRMSEC 在分析固件時花費的時間更少。 我們在配備 i7-9700K CPU、RTX 2080 GPU 和 32 GB 內存的 Ubuntu 服務器上實現 FIRMSEC。 FIRMSEC 在不到 10 秒的時間內分析每個固件映像，這在所有測試用例中都比其他系統快得多。

總的來說，我們的結果表明 FIRMSEC 的性能比學術界最先進的工具和工業界的商業工具要好得多。 FIRMSEC 在 TPC 級別和版本級別上均比 Gemini、BAT、OSSPolice 具有更高的精度和召回率。 與 binar ? e、FirmwareTotal 和 FSS 相比，FIRMSEC 在分析固件時的成功率更高，花費的時間更少，并且可以檢測更多的 TPC，以及識別更多的漏洞。

3.3?漏洞識別精度評估

實驗設置：在論文的評估中，論文采用三種方法來驗證漏洞，源代碼審計、靜態分析、基于仿真的動態分析。 我們選擇這些方法有三個原因。 首先，OpenWrt 的部分固件有源代碼。 因此，論文可以檢查其源代碼來驗證漏洞。 其次，由于大量固件鏡像沒有源代碼，因此靜態分析是驗證這種情況下漏洞的可接受方法。 第三，靜態分析可能無法檢查一些未公開相應不安全代碼的漏洞。 在這種情況下，可以采用動態分析來彌補靜態分析的缺點。 論文這里使用 FIRMADYNE 對固件進行動態分析。 FIRMADYNE 支持在桌面上模擬基于 Linux 的固件。 它克服了模擬固件的一般挑戰，例如特定于硬件的外設的存在。 論文的評估方法可以確認結果的真陽性和假陽性，但很難區分假陰性，因為我們沒有固件中所有與 TPC 相關的漏洞的基本事實。

考慮到我們的大規模數據集，評估 FIRMSEC 在所有固件映像上的精度是不現實的。 因此，論文根據兩個標準來選擇一些有代表性的固件：（1）每個識別出的固件漏洞都有實用的驗證方法，無論是通過源代碼審計、靜態分析還是動態分析； （2）包括盡可能多的供應商和類別。 論文最終對數據集V進行評估，包括 35 個隨機選擇的固件映像，其中 FIRMSEC 識別出總共 382 個漏洞。

漏洞驗證：首先，由于 OpenWrt 的5個固件鏡像都有源代碼，論文采用源代碼審計來驗證漏洞。 其次，論文結合靜態分析和動態分析來評估剩余的 30 個固件映像。 論文手動審核其中 335 個漏洞的披露報告，以確定每個漏洞合適的驗證方法。 然后，論文根據相應的驗證方法將這335個漏洞分為兩部分。 第一部分中的192個漏洞可以通過靜態分析來驗證，第二部分中的143個漏洞可以通過動態分析來驗證。

綜上所述，論文最終確認了 382 個漏洞中的 368 個確實存在。 論文未能驗證四個固件映像中的 14 個漏洞，其中一個來自 TP-Link，另外三個來自 TSmart。 總體而言，FIRMSEC 在識別固件中由 TPC 引起的漏洞方面平均達到 96.3% 的準確率。