隨著物聯網設備的普及，嵌入式安全攻擊也隨之增加。從歷史上看，嵌入式系統工程師忽略了設備層的安全性，盡管嵌入式設備的許多領域都容易受到錯誤的影響。串行端口、無線電接口，甚至編程/調試接口都可能被黑客利用。模糊測試是工程師發現嵌入式設備弱點的重要場所，應考慮用于強化物聯網設備接口。

什么是模糊測試？

模糊測試就像神話中的百萬只猴子隨機打字寫莎士比亞。在實踐中，小說作品需要許多隨機組合來產生一個簡單的短語，但對于嵌入式系統，我們只需要從一個已知的好句子中更改幾個字母。

許多商業和開源工具可用于實施模糊攻擊。這些工具生成隨機字節串，也稱為模糊向量或攻擊向量，并將它們提交到正在測試的接口，跟蹤可能表示錯誤的結果行為。

模糊測試是一個數字游戲，但我們不能嘗試無限數量的可能輸入。相反，我們專注于通過最大化模糊向量提交率、模糊向量的有效性和錯誤檢測算法來優化測試時間。

模糊測試概念

由于許多模糊測試工具都是為測試 PC 應用程序而設計的，因此如果您將嵌入式代碼作為本地編譯的 PC 應用程序運行，則更容易適應它們。在 PC 上運行嵌入式代碼會產生巨大的性能優勢，但也有兩個缺點。首先，PC 微處理器的反應與嵌入式微控制器不同。其次，我們必須重新編寫任何涉及硬件的代碼。然而，在實踐中，在 PC 上運行的優勢大于劣勢。真正的障礙是移植代碼以在 PC 上本地編譯的困難。

我們如何知道模糊向量何時觸發錯誤？崩潰很容易發現，但很難識別導致重置的模糊向量。內存溢出錯誤或雜散指針寫入（對黑客最有價值的錯誤類型）幾乎不可能從系統外部辨別出來，因為它們通常不會導致崩潰或重置。

許多現代編譯器，例如 GCC 和 Clang，都有一個稱為內存清理的功能。這將內存塊標記為干凈或臟，具體取決于它們是否正在使用，并標記任何訪問臟內存的嘗試。但是，內存清理會消耗閃存、RAM 和 CPU 周期，使其難以在嵌入式設備上運行。因此，相反，我們可以測試代碼子集，構建具有更多資源的設備版本，或者使用 PC。

測試的有效性可以通過執行的代碼量來評估。在這里，編譯器也可以通過使用面包屑子例程調用來跟蹤內存使用情況。代碼覆蓋率庫為每個代碼路徑維護一個使用值表，在面包屑執行時遞增它們。

然而，對于嵌入式模糊測試來說，代碼覆蓋率數字很難解釋，因為大部分代碼對于模糊向量來說是不可訪問的；例如，獨立于接口運行的外圍設備的設備驅動程序。因此，很難為嵌入式系統定義“完整的代碼覆蓋率”——也許只有 20% 的嵌入式代碼是可訪問的。代碼覆蓋還消耗大量閃存、RAM 和 CPU 周期，并且需要專門的硬件或 PC 目標才能運行。

錯誤報告

當模糊測試發現導致不良行為的向量時，我們需要詳細信息。錯誤發生在哪里？調用堆棧的狀態是什么？錯誤的具體類型是什么？所有這些信息都有助于分類并最終修復錯誤。

錯誤分類在模糊測試中至關重要。新的 fuzz 項目經常會發現很多 bug，我們需要一種自動的方法來確定它們的嚴重性。此外，模糊錯誤往往會阻止錯誤，因為它們通常會在代碼路徑中進一步掩蓋其他錯誤。我們需要快速解決模糊測試期間出現的問題。

嵌入式客戶端不像 PC 那樣愿意透露他們的信息。通常，崩潰只會導致設備重置并重新啟動。雖然這在現場是需要的，但它會擦除設備的狀態，從而難以了解是否發生了崩潰、發生的地點或原因，或者所采用的代碼路徑。工程師必須找到一致的再現向量，然后使用調試器跟蹤不良行為并找到錯誤。

在模糊測試中，一個測試可能會為幾個錯誤產生數千個崩潰向量，給人一種錯誤系統的錯誤印象。快速確定哪些向量與相同的潛在錯誤相關聯非常重要。對于嵌入式設備，崩潰本身的位置對于錯誤通常是唯一的，通常不需要找到完整的調用堆棧跟蹤。

連續模糊測試

由于模糊測試的隨機性，長時間運行它們會增加他們發現問題的機會。但是，任何項目計劃都不能吸收開發結束時冗長的模糊測試周期造成的延遲。

在實踐中，模糊測試將在發布過程之后在其自己的分支上開始。任何新發現的錯誤都將在本地分支中修復，以便測試可以繼續，而新錯誤不會阻止額外的錯誤發現。作為發布周期的一部分，從模糊測試先前版本中發現的錯誤將被評估以包含在新版本中。最后，應該將發現錯誤的模糊向量添加到正常的質量保證過程中，以驗證修復并確保這些錯誤不會無意中重新引入代碼中。

我們應該在不同場景下對設備進行模糊測試；例如，如果聯網，設備對連接請求的響應會有所不同。在每個可能的場景上運行模糊測試是不切實際的，但我們可以為每個可能狀態的值包括模糊測試。例如，對每種不同的設備類型運行模糊測試，同時保持其他變量相同。然后為一個設備類型的另一個變量（例如網絡連接狀態）運行不同的值。

模糊測試架構

兩種突出的模糊測試架構是定向模糊測試，其中模糊向量由工程師在測試前指定，以及覆蓋引導模糊測試，其中模糊工具從一組初始測試向量開始，并根據數據包的滲透程度自動改變它們編碼。

此外，并非所有代碼都可以在 PC 上運行，并且為嵌入式應用程序開發 PC 模擬器可能是不切實際的，具體取決于所測試的內容。

以下是四種模糊測試架構的總結：

嵌入式硬件上的直接接口測試——在嵌入式設備上運行正常的生產映像，并通過接口注入模糊數據包

數據包（堆棧）注入測試——直接調用傳入的數據包例程，而無需通過無線運行接口

使用模擬器進行定向模糊測試——使用基于 PC 的模擬技術開發和測試嵌入式代碼

使用模擬器進行覆蓋引導的模糊測試（如下所示的 Libfuzz）

多個模糊測試器

在使用調試接口鎖定和安全啟動鎖定嵌入式設備后，我們需要考慮對設備接口進行模糊測試。用于保護 Web 服務器的許多相同工具和概念可以適用于嵌入式設備。

為工作使用正確的工具。Coverage-guided fuzzing 對于連續模糊測試是必要的，但如果您的代碼僅在嵌入式硬件上執行，那么定向模糊器可能是提供一定程度的模糊測試覆蓋率的不錯選擇。

最后，您應該在盡可能多的場景中使用多個模糊測試器，因為每個測試器都會對設備進行略微不同的測試，從而最大限度地提高覆蓋率，從而提高嵌入式設備的安全性。

審核編輯：郭婷