??本文記錄閱讀DIANE論文的內容總結和一些閱讀過程中不理解地方的補充，我是搬運工。

簡介

摘要

??Abstract: Internet of Things (IoT) devices have rooted themselves in the everyday life of billions of people.Thus, researchers have applied automated bug finding techniques to improve their overall security.However, due to the difficulties in extracting and emulating custom firmware, black-box fuzzing is often the only viable analysis option.Unfortunately, this solution mostly produces invalid inputs, which are quickly discarded by the targeted IoT device and do not penetrate its code.Another proposed approach is to leverage the companion app (i.e., the mobile app typically used to control an IoT device) to generate well-structured fuzzing inputs.Unfortunately, the existing solutions produce fuzzing inputs that are constrained by app-side validation code, thus significantly limiting the range of discovered vulnerabilities.
In this paper, we propose a novel approach that overcomes these limitations.Our key observation is that there exist functions inside the companion app that can be used to generate optimal (i.e., valid yet under-constrained) fuzzing inputs.Such functions, which we call fuzzing triggers, are executed before any data-transforming functions (e.g., network serialization), but after the input validation code.Consequently, they generate inputs that are not constrained by app-side sanitization code, and, at the same time, are not discarded by the analyzed IoT device due to their invalid format.We design and develop DIANE, a tool that combines static and dynamic analysis to find fuzzing triggers in Android companion apps, and then uses them to fuzz IoT devices automatically.We use DIANE to analyze 11 popular IoT devices, and identify 11 bugs, 9 of which are zero days.Our results also show that without using fuzzing triggers, it is not possible to generate bug-triggering inputs for many devices.
??摘要：物聯網 (IoT) 設備已扎根于數十億人的日常生活中。因此，研究人員已應用自動錯誤查找技術來提高其整體安全性。然而，由于難以提取和模擬自定義固件，黑盒模糊測試通常是唯一可行的分析選項。不幸的是，該解決方案大多會產生無效輸入，這些輸入會被目標物聯網設備迅速丟棄并且不會滲透其代碼。另一種建議的方法是利用配套應用程序（即通常用于控制物聯網設備的移動應用程序）來生成結構良好的模糊測試輸入。不幸的是，現有的解決方案產生的模糊輸入受到應用端驗證代碼的限制，從而大大限制了已發現漏洞的范圍。
??在本文中，我們提出了一種克服這些限制的新方法。我們的主要觀察結果是配套應用程序中存在可用于生成最佳（即有效但約束不足）模糊輸入的函數。此類函數，我們稱為模糊觸發器，在任何數據轉換函數（例如，網絡序列化）之前執行，但在輸入驗證代碼之后執行。因此，它們生成的輸入不受應用程序端清理代碼的約束，同時也不會由于格式無效而被分析的 IoT 設備丟棄。我們設計和開發了 DIANE，這是一種結合靜態和動態分析的工具，用于在 Android 配套應用中查找模糊測試觸發器，然后使用它們自動對 IoT 設備進行模糊測試。我們使用 DIANE 分析了 11 個流行的物聯網設備，并確定了 11 個錯誤，其中 9 個是零日漏洞。我們的結果還表明，如果不使用模糊觸發器，就不可能為許多設備生成觸發錯誤的輸入。

導言

??大多數物聯網設備都有配套應用程序（即，用于與設備交互的移動應用程序），其中包含為相應設備生成有效輸入的必要機制。基于這一觀察，Chen等人提出了一種工具IoTFuzzer（本文中很多部分與IOTFUZZER進行了對比，建議先去看一下這篇），該工具通過利用IoT設備的配套應用程序來模糊IoT設備。IoFuzzer分析配套應用程序并檢索將應用程序的用戶界面（UI）連接到網絡相關方法或數據編碼方法的所有路徑。然后，IoTFuzzer將處理這些路徑上的用戶輸入的第一個函數的參數模糊化，從而為IoT設備生成有效的模糊化輸入。
??雖然這種方法比通過網絡直接發送到物聯網設備的數據隨機模糊化產生更好的結果，但在實踐中，它在由UI獲取變量后，在應用程序執行任何輸入驗證或數據處理之前，立即對變量進行變異。因此，當應用程序對提供的輸入進行凈化時，IoTFuzzer的有效性受到很大影響。我們的實驗（第IV-E節）表明，51%的IoT應用程序執行應用程序端輸入驗證。事實上，最近的研究表明，移動應用程序經常執行輸入驗證來觸發不同的行為[86]。由于這些原因，IoTFuzzer的方法無法產生約束不足（即，不受應用程序端消毒的影響）但結構良好（即，被IoT設備接受）的模糊輸入，這可以到達更深的代碼位置，發現更多漏洞。
??我們的做法。在本文中，我們提出并實現了一種利用配套應用程序為分析設備生成輸入的方法。為了克服IoTFuzzer的局限性，我們精確地確定（并模糊）配套應用程序中的最佳代碼位置，從而為IoT設備生成有效但受限制的輸入。
??我們的方法將應用程序的執行視為將用戶引入的數據（例如，通過應用程序的 UI）轉換為網絡數據的一系列函數。我們的直覺是，這個序列中的第一個函數通常將用戶輸入轉換為內部數據結構，生成受應用端驗證約束的數據。相比之下，此序列中的最后一個函數對用戶數據進行了充分編碼，并在網絡上對其進行了序列化。
??我們的方法的新穎之處在于通過調用IoT配套應用程序中的特定功能來模糊IoT設備。我們稱這些函數為模糊觸發器。調用時，模糊觸發器生成的輸入不受應用程序端驗證的約束，同時結構良好，因此不會立即被模糊物聯網設備丟棄。
??我們的方法使用了靜態和動態分析的新組合，并執行兩個主要步驟：i）模糊觸發器識別和ii）模糊化。為此，首先，我們自動檢索應用程序中向物聯網設備發送數據的功能。然后，對于這些函數中的每一個，我們構建一個過程間向后切片，我們動態地分析它以最終識別模糊觸發器。最后，我們使用動態工具使用不同的參數重復調用這些模糊觸發器。這會生成網絡數據流，模糊物聯網設備的功能，最終發現漏洞。
??我們在一個名為DIANE的工具中實現了我們的方法，并針對11個不同類型和不同制造商的流行物聯網設備進行了測試。DIANE正確識別了模糊觸發器，并成功識別了11個bug，其中9個是以前未知的漏洞。此外，我們將DIANE與IoTFuzzer進行了比較，結果表明，模糊觸發器的識別對于生成受約束的、導致崩潰的輸入至關重要。
總之，我們作出以下貢獻：
???我們提出了一種識別模糊觸發器的方法，模糊觸發器是應用程序控制流中位于應用程序端驗證邏輯和數據編碼功能之間的功能。執行時，識別的模糊觸發器產生有效但受約束的輸入，從而實現物聯網設備的有效模糊。
???我們利用我們的方法實施DIANE，一種用于物聯網設備的自動黑匣子模糊器。
???我們針對11種流行的真實物聯網設備評估我們的工具。在我們的實驗中，我們表明，通過識別模糊觸發器并使用它們為分析的設備生成輸入，我們可以有效地發現漏洞。具體而言，我們在5個不同的設備中發現了11個漏洞，其中9個以前未知。
???我們表明，對于大多數物聯網設備和配套應用程序，識別和利用模糊觸發器對于生成錯誤觸發輸入至關重要。

動機

??為了激發我們的方法并舉例說明它解決的挑戰，請考慮圖 1 中的代碼片段。該應用程序利用方法 PTZ（第 2 行）將位置命令（即空間坐標）發送到物聯網攝像機。為此，PTZ 調用本機函數 SendMsg（第 7 行），該函數準備要發送的數據（第 15 行），并將其存儲到共享緩沖區中（第 16 行）。同時，另一個線程從同一個緩沖區讀取數據（第 20 行），并向設備發送命令（第 21 行）。請注意，物聯網攝像頭需要密碼來驗證命令，應用程序對密碼字符串（第 5 行和第 6 行）執行完整性檢查。此示例顯示了從配套應用程序生成 IoT 輸入時必須面臨的兩個關鍵挑戰：
??首先，應用程序使用結構化數據與物聯網設備通信，這些數據以已知協議（如HTTP）或供應商定義的自定義協議編碼。不符合預期格式的消息會被設備立即丟棄，因此不會在其代碼中觸發深層錯誤。在本例中，應用程序使用函數prepare_msg（第15行）創建結構正確的消息。
其次，盡管生成正確結構的輸入至關重要，但有效的方法必須避免生成受應用程序端驗證代碼約束的輸入。在本例中，函數PTZ（第2行）禁止密碼包含字符&和"。然而，這些字符的存在可能對生成碰撞觸發模糊輸入至關重要。

??IoTFuzzer作者的見解是利用配套應用程序以設備可以處理的格式生成模糊輸入。這意味著在應用程序“打包”并將其發送到設備之前，需要對輸入值進行變異。雖然這是真的，但我們的關鍵洞察是，變異確實必須在應用程序打包輸入之前發生，也必須在應用程序執行任何輸入驗證之后發生。請注意，在表達式app-side-validation中，我們指的是應用程序對發送到物聯網設備的數據施加的所有類型的約束。這些約束可能由典型的清理檢查（例如，限制字符串的長度）或在生成的請求中硬編碼的參數（例如，JSON對象中硬編碼的屬性）施加。
??我們的工作填補了這一空白：我們確定了產生不受應用程序邏輯施加的約束影響的輸入的戰略執行點。為了實現這一目標，我們分析了IoT設備配套應用程序，重點是確定有效的模糊觸發：當用作模糊化入口點時，這些功能可以最大限度地增加設備固件上執行的唯一代碼量，從而可能觸發與安全相關的bug。舉例來說，將應用程序執行為從UI接收數據并通過網絡發送數據的函數序列。一方面，如果fuzzed函數過于接近UI，則fuzzing是無效的，因為應用程序端驗證可能會在稍后的執行中出現。另一方面，選擇一個太靠近數據被放到網絡上的點的函數可能是無效的。事實上，在執行早期應用的某些特定于協議的數據轉換將被跳過，從而導致IoT設備丟棄生成的輸入。在圖1中，函數sendMsg表示一個模糊觸發器。
??我們的方法依靠動態和靜態分析的組合自動識別這些模糊觸發器，而不需要任何關于所分析物聯網設備所使用的固件或網絡協議的先驗知識。此外，之前的工作[25]依賴于特定的輸入源（例如，應用程序UI中的文本框）來引導其分析，并且不會改變從未指定源生成的數據（例如，通過計時器觸發的配套應用程序進行固件更新）。我們的自下而上方法（在第三節中解釋）沒有對輸入源進行任何假設，因此更為通用。
??我們在本節中討論的示例是在Wansview應用程序中實現的代碼的簡化版本。我們還注意到，應用程序端驗證在現實世界的應用程序中非常普遍，我們描述的挑戰不僅適用于本例。

方法

??我們的方法沒有對應用程序的用戶界面如何影響發送到受控物聯網設備的數據做出任何假設，并且避免了對生成的數據進行應用程序端凈化。我們的分析不是從考慮UI處理功能開始的，相反，我們使用了“自下而上”的方法。具體來說，我們從識別可能產生網絡流量的低級功能開始，然后逐步在應用程序調用圖中“向上”移動（即，從低級網絡功能到高級UI處理功能）。這種方法允許我們識別產生有效但受約束的輸入的函數，跳過數據處理函數執行的所有清理檢查。然后，我們使用這些函數（我們稱之為模糊觸發器）有效地模糊所分析的物聯網設備，同時監控其異常行為，這些異常行為指示何時觸發錯誤。

圖2。使用靜態分析，DIANE 首先確定候選的 sendMessage 函數。然后，它運行配套應用程序，重放記錄的用戶交互，以驗證候選的 sendMessage 函數。接下來，DIANE 使用混合分析來識別數據轉換功能，從而識別模糊觸發器。最后，DIANE 通過監控設備響應對經過驗證的觸發器進行模糊測試并識別崩潰。

模糊觸發器識別

??直觀地說，模糊觸發器是在應用程序的控制流中位于應用程序端驗證邏輯和通過網絡發送數據之前發生的任何數據轉換（例如，消息序列化）功能之間的函數。準確地說，給定從輸入源（例如，從UI接收的數據）到通過網絡發送數據的函數的執行跟蹤，模糊觸發器定義為支配所有數據轉換函數和后支配所有輸入驗證函數的函數（我們參考調用圖理論的支配概念，其中如果從入口節點到 n 的每條路徑都必須經過 d，則節點 d 支配節點 n。此外，如果從 n 到出口節點的每條路徑都經過 p，則我們說節點 p 后支配 n）。我們認為跟蹤中的第一個數據轉換函數是有效的模糊觸發，因為它支配著每個其他數據轉換函數（包括它本身）。
??我們的自底向上模糊觸發識別算法由四個步驟組成：i）發送消息候選識別，ii）發送消息驗證，iii）數據轉換函數識別，以及iv）Top-Chain 函數收集。算法1列出了我們方法的偽代碼。
步驟1：sendmessage候選函數識別
??我們首先在配套應用程序中確定實現向物聯網設備發送消息所需邏輯的功能。我們稱這些函數為sendMessage函數。以自動化和可擴展的方式識別這些功能是困難的。配套應用程序可能依賴于直接調用系統調用的特殊本機函數來實現sendMessage函數。此外，我們發現這些函數可能在多帶帶的線程中執行，這使得任何分析（靜態或動態）都難以精確跟蹤應用程序UI和sendMessage函數之間的數據流。然而，我們的關鍵洞察是，配套應用程序必須包含“邊界”功能，位于應用程序核心功能和外部組件（即Android框架或本機庫）之間，當執行時，最終觸發發送至物聯網設備的消息。在本文的其余部分，我們將這些邊界函數視為我們的 sendMessage 函數。
??在我們的方法中，我們首先通過靜態分析配套應用程序來識別候選sendMessage函數。我們的目標是找到可能實現與所分析物聯網設備的網絡交互的所有邊界方法（算法1中的函數getBorderMethods）。具體來說，我們收集了所有執行（至少）對本機函數的調用或對Android框架中實現網絡I/O功能的方法的調用的方法（更多詳細信息，請參見附錄a）。

步驟2：發送消息驗證
??我們動態執行應用程序并利用API掛鉤來驗證候選sendMessage函數。為了確定邊界函數是否為有效的sendMessage函數，理論上，我們可以i）多次動態執行該函數并檢查每次是否生成網絡流量，ii）阻止應用程序執行該函數并檢查是否仍生成網絡流量。不幸的是，我們發現阻止一個函數執行，以及強迫應用程序多次執行同一個函數，通常會導致應用程序本身崩潰。為了解決這些問題，我們采用了一種基于時間戳和機器學習的不同方法。
??首先，我們動態地鉤住所有候選函數并運行應用程序。當我們觀察網絡活動時，我們登記最后執行的候選sendMessage函數。特別是，每次執行候選sendMessage函數時，我們都會收集其執行和觀察到的網絡活動之間經過的時間。然后，我們利用K-均值算法對觀察到的經過時間度量進行聚類。
??具體來說，我們將候選者分為兩個集群（即 k = 2）。為此，我們將每個特征向量計算為每個候選的經過時間的均值、標準差和眾數。基本原理是導致網絡活動的函數具有較小的均值和標準差，因為它們受噪聲的影響較小。最后，在 sendMessage 候選中，我們選擇那些屬于具有最小經過時間平均值的集群。在我們分析的后續步驟中，將只考慮該集群中的 sendMessage 函數。這種方法由算法1中的函數 dynamicFilter 表示。
步驟3：數據轉換函數識別
??雖然sendMessage函數直觀上是執行模糊化的好觸發器，但應用程序可以在sendMessage函數之前執行的函數中應用數據轉換。數據轉換函數的典型示例由編碼方法表示，該方法將整數列表作為輸入，并將其序列化為字節序列。
??如前所述，模糊觸發器是應用程序控制流中位于任何數據轉換函數之前的函數。模糊化位于數據轉換功能和sendMessage功能之間的功能可能會產生無效輸入，這些輸入被物聯網設備丟棄。因此，為了找到模糊觸發器，我們首先需要確定應用于所發送數據的數據轉換函數。
??這項任務提出了不同的挑戰。首先，正在發送的數據可能包含在類字段中，該字段由 sendMessage 函數引用。這個字段理論上可以設置在應用程序代碼的任何地方，包括在其他線程中。此外，對于每個字段，我們需要考慮其父類，因為保存要發送的消息的變量可能會被不同的類繼承。
在我們的方法中，我們考慮了這些問題。我們首先靜態地確定保存由sendMessage函數發送的數據的可能變量，以及在應用程序中設置這些變量的代碼位置（算法1中的函數getArgAndObjLocs）。為了實現這一點，我們創建了一個包含元組（v，cl）的集合Sv，其中v是sendMessage使用的變量（即sendMessage主體中引用的sendMessage參數或對象），cl是設置的代碼位置。
??然后，我們識別數據轉換函數。對于每個元組（v、cl）∈在Sv中，我們執行一個靜態過程間反向切片（算法1中的第6行），從任意函數到任意UI對象檢索值。然后，我們將計算出的程序切片劃分為函數范圍（第7行的getFunctionScopes）。給定一個程序片，函數作用域定義為片中屬于同一函數的順序指令的子序列。
??對于每個收集的函數范圍，我們執行活度分析：我們考慮函數范圍內引用的變量（即，局部變量和類字段），并且計算在范圍的開始處生存的變量集和在范圍的末尾（第8行）生存的變量集。例如，如果一個函數被切片遍歷，則位于函數作用域開頭的變量是的參數和在寫入之前讀取的類字段。位于的作用域末尾的變量是返回的變量和創建或修改的類字段。
??為了確定數據轉換函數，我們利用了相關工作所探討的觀察結果，即這些函數增加了它們所消耗數據的熵。因此，我們將在切片中識別的函數掛鉤，動態運行應用程序，并計算在運行時分配給包含在$L{i}_f$和$L{o}_f$中的每個變量v的數據的香農熵。（關于如何計算熵的更多詳細信息，請參見附錄C）。如果是一個基本變量（例如int）或一個已知類型（例如String、Integer、Float和Double），我們將轉換它包含在字節表示中的數據，并計算這個字節列表的香農熵。相反，如果是類字段，則檢索其類定義，并考慮其類型為原始或已知類型的每個字段變量。然后，我們計算這些變量中每一個的熵，并將它們添加到集合或集合中，具體取決于活動集合所屬。
??最后，我們檢查每個收集的函數范圍，并計算中所有變量的最大熵與中所有變量的最小熵之間的商（第11行）。如果大于某一閾值（在我們的實驗中設置為2，如先前的工作建議，我們認為函數是數據轉換函數（第12行）。
補充熵相關知識：

步驟4：Top-Chain函數集合
??數據轉換功能通常以精確的順序執行，以充分準備要發送到物聯網設備的數據。例如，一個配套應用程序可能會在base64中編碼一些用戶數據，然后將其封裝在HTTP請求x中。
??我們將數據轉換函數序列稱為轉換數據鏈，并使用術語“頂鏈函數top-chain”指代序列中的第一個函數。如果修改 f 變量的內容最終會影響 v 的值，我們就說頂鏈函數 f 會影響變量 v。
我們特別感興趣的是影響sendMessage變量的頂鏈函數。事實上，如果我們控制這些頂級鏈的變量，我們就可以控制發送到被分析物聯網設備的數據。特別是，這些數據既有效（即被物聯網設備接受），又不受不必要的應用端輸入驗證的影響。因此，影響 sendMessage 變量的頂級鏈函數代表了刺激物聯網設備功能的最佳模糊測試觸發器。
??為了識別頂鏈函數，我們構建在上一步（第13行）檢測到的每個數據轉換函數的支配樹（一個圖，其中每個節點的子節點是它直接支配的那些節點），并選擇那些不受任何其他數據轉換函數支配的數據轉換函數（第16行）。最后，我們認為fuzzing觸發了收集的頂鏈函數。
??注意，如果沒有數據轉換函數支配SM消息函數，我們將SM視為模糊觸發（第14, 15行和第16行）。例如，當配套應用程序不包含數據轉換功能時，可能會發生這種情況。
??最后請注意，原則上，應用程序端清理代碼可能存在于轉換數據鏈中的函數中。我們將在第五節中對此進行討論。
??作為一個簡單的例子，考慮圖3，它代表了我們在8月智能鎖設備上發現的數據鏈之一。假設我們之前將sendToDevice標識為sendMessage函數，我們將{c}設置為可能包含要發送的數據的初始變量集，并確定設置c的代碼位置。由于c是一個函數參數，我們檢索sendMessage調用站點（第15行），并從調用站點向后引導程序切片，直到函數unlock（第1行）。這是通過向后跟蹤變量e的數據流實現的：sendToDevice使用變量e，它是調用函數encrypt的結果。然后，我們繼續從函數encrypt的末尾向后切片，直到其入口點，然后返回sendCommand函數。最后，我們到達了該函數的入口點，并考慮其調用者（即函數unlock）繼續切片。

??按照上述函數作用域的定義，此向后切片包含以下函數作用域：i）sendCommand：第15行；ii）encrypt：6到9行；iii）sendCommand：第12行和第13行；iv）unlock：第3行；v）Command constructor（本例中未報告代碼）；和vi）unlock：第1行和第2行。為了簡潔起見，在下面，我們只考慮相關的功能范圍：ii）encrypt，iii）sendCommand，和vi）unlock。它們的活動變量集是：encrypt:$L{i}_f$={b}，$L{o}_f$={enc}；sendCommand:$L{i}_f$={cmd}，$L{o}_f$={cmd}；和unlock:$L{i}_f$={}，$L{o}_f$={cmd}。
??一旦我們確定了切片中的函數范圍，我們運行應用程序并計算分配給每個活動變量的數據的熵。然后，我們計算每個函數作用域引入的熵量，并檢查其值是否超過閾值。
??函數unlock不會引入任何熵，因為集合為空。在集合為空的情況下，我們不考慮函數作為候選數據轉換函數，因為它不接受任何輸入。
??對于函數encrypt，存儲在b中的數據的熵為5.94，而在enc中返回的數據的熵為53.16。由于熵δ大于我們的閾值（$d_e$＝53.16／5.94＞2），所以我們考慮加密作為數據變換函數。此外，函數sendCommand引入了較低的熵（$d_e$=1.03），因此，它不被視為數據轉換函數。最后，由于函數encrypt控制函數sendToDevice，因此encrypt是唯一的頂鏈函數，并用作唯一的模糊觸發器。
UI刺激
??我們的方法多次執行同一個應用程序，在不同的運行中保持一致。因此，理想情況下，我們希望應用程序始終遵循相同的執行路徑。為了實現這個目標，我們要求分析員運行應用程序一次，而DIANE記錄生成的UI輸入。然后，通過利用RERAN在后續運行中自動重放相同的輸入。我們沒有明確處理具有不確定性的其他來源，因為我們發現它們不會顯著影響我們的方法。
??模糊化中間數據轉換函數。原則上，轉換數據鏈可能是任意長的。由于DIANE的目標是刺激物聯網設備的核心功能，我們的方法忽略了中間數據轉換功能（即，由頂鏈功能主導的數據轉換功能），因為它們生成的消息可能會被物聯網設備丟棄。然而，由于物聯網設備在用于解碼接收到的消息的過程中可能也包含bug，我們為DIANE提供了模糊所有中間數據轉換功能的選項。類似地，DIANE提供了一個選項，可以直接模糊sendMessage函數，即使它由頂鏈函數控制。在第IV-C節中，我們根據經驗證明，模糊sendMessage函數不會導致發現新的bug，但會減慢工具的執行速度。

fuzzing

??在我們的方法的第一階段之后，我們獲得了一組模糊觸發器，它們是模糊器的輸入。
??測試用例生成
??對于每個模糊觸發器，我們通過改變已識別模糊觸發器的參數來生成一組測試用例，最終修改sendMessage函數發送的數據。我們以循環方式一次模糊一個不同的模糊觸發器。為了改變其參數值，我們使用以下策略：
???字符串長度：我們更改字符串的長度，以觸發緩沖區溢出和越界訪問。我們生成不同長度的隨機字符串。
???數值：我們更改整型、雙精度或浮點值的值，以導致整數溢出或越界訪問。我們生成非常大的值、負值和零值。
???空值：我們提供空值，試圖導致誤解、未初始化變量漏洞和空指針取消引用。
???數組長度：我們通過刪除或添加元素來修改數組的內容。
??重要的是，我們不僅要模糊基本變量（例如int、float），還要通過模糊對象的成員變量來模糊對象識別crash。正如最近的一項研究所示，識別物聯網設備的基于網絡的服務的所有崩潰，而不進行侵入性物理訪問是一項挑戰。同時，獲得對物聯網設備的侵入性物理訪問需要大量的工程工作，因為供應商通常會阻止這種類型的訪問。
??出于這些原因，在對設備進行模糊處理時，DIANE會自動分析其響應以識別崩潰。具體來說，DIANE首先執行應用程序的正常運行，并監控設備在正常活動期間的響應。然后，在模糊化過程中，DIANE再次監控應用程序和設備之間的網絡流量，如果滿足以下任一條件，則認為輸入可能會導致崩潰。
???連接斷開。如果設備突然結束正在進行的連接，我們認為它是設備出現了錯誤的指示。具體來說，對于TCP連接，我們查找應用程序發送FIN數據包但未收到響應（FIN+ACK），然后發送兩個或更多SYN數據包序列的情況。
???HTTPInternalServerError（500）。應用程序和設備通過HTTP進行通信，設備返回內部服務器錯誤（狀態代碼500）的實例被視為設備進入故障狀態的信號。
???網絡流量大小不規則。如果應用程序和設備之間交換的數據量超過閾值，我們將保存當前導致崩潰的輸入。我們的直覺是，當設備進入故障狀態（例如，由于崩潰）時，它通常會暫時不可用于應用程序，從而大大減少了交換的數據量。在我們的實驗中，我們經驗性地驗證了當交換的數據量小于50%（與常規運行相比）時，設備會發生異常情況。因此，我們設定閾值為50%。
???心跳監測。在模糊給定設備的同時，我們不斷對其進行ping并監控其響應時間。我們報告導致響應時間高于某個閾值的任何crash誘導輸入。在我們的實驗中，我們將時間設置為10秒，因為我們根據經驗驗證，在正常條件下，物聯網設備的平均響應時間在1秒之內。
??最后，我們使用另一款Android智能手機，我們稱之為看門狗設備，從中立的角度監控物聯網設備的狀態（即，我們不在此設備上檢測配套應用程序）。我們在看門狗設備上運行配套應用程序，并自動重放先前記錄的UI輸入，以定期運行不同的物聯網設備功能。然后，人類分析員可以觀察看門狗設備執行的功能（例如，按下燈光開關UI按鈕）是否對物聯網設備產生預期效果（例如，打開燈光）。如果檢測到不期望的效果，則意味著Diane能夠使所分析的設備進入無效狀態。

實驗

??原文中作者使用DIANE對11種不同的物聯網設備進行模糊處理，還與現有的網絡級模糊器進行了比較。在這里只介紹與LOTFUZZER對比部分的實驗。

DIANE vs LOTFUZZER

??為了將我們的方法與IoTFuzzer進行比較，我們聯系了作者并獲得了他們的工具。我們還試圖購買用于評估IoTFuzzer的相同設備，但我們只能獲得設備3和6，因為其余設備僅在中國可用。
??IoTFuzzer 需要手動干預以適應不同的設備和配套應用程序。特別是，我們必須 i) 將分析范圍（即掛鉤函數的數量）限制為 Android 應用程序中存在的 Java 包的子集——以保持分析易于處理并避免崩潰——以及 ii) 手動指定任何加密應用程序中存在的功能。在此手動配置步驟之后，我們能夠為我們能夠獲得的設備（設備 3 和設備 6）復制原始論文中顯示的結果。此外，IoTFuzzer 基于 TaintDroid，其最新版本最高支持 Android 4.3 (2012)。出于這個原因，我們無法分析設備 10 和設備 11，因為它們的配套應用程序需要更新的 Android SDK 版本
??我們的結果如表三所示。IoTFuzzer破壞了設備3和6（原始文件中使用的兩個設備）以及設備2，但沒有發現其他8個設備的任何缺陷。
對于設備2，IoTFuzzer確定了5個要進行模糊測試的函數。我們手動分析了這些函數，發現其中三個是誤報，因為它們被用于在Android手機上保存用戶信息。為了證實我們的發現，我們對這些函數進行了模糊化處理，并觀察到它們都沒有產生網絡流量。
??然后，我們繼續模糊剩下的兩個函數，即HouseExtProperty和changeCameraUsernamePassword。在對HouseExtProperty函數進行一小時的模糊化處理時，我們發現生成的消息被定向到供應商的云，而不是實際設備，因此沒有為物聯網設備生成任何有意義的模糊化輸入。
changeCameraUsernamePassword功能用于更改IoT設備上的憑據。我們對這個函數進行了24小時的模糊處理，IoTFuzzer重新發現了DIANE在這個設備上發現的7個bug中的2個。
??為了更好地理解 IoTFuzzer 為什么會遺漏我們發現的一些錯誤，我們檢查了 changeCameraUsernamePassword（如圖 4 所示）。該函數調用函數cam.changeUsername 和cam.changePassword 分別生成更改用戶名和密碼的請求（這些函數的第一個參數代表當前攝像機的用戶名）。此外，變量 cam 是應用程序用來存儲相機詳細信息（例如，相機型號）的內部結構，其內容不受從應用程序 UI 接收到的數據的直接影響。另一方面，newUsr 和 newPwd 都包含通過應用程序 UI 傳遞的用戶數據。由于 IoTFuzzer 僅對包含用戶數據的函數參數進行模糊測試（當函數被調用時），它對第二個和第三個函數參數進行模糊測試，但不會對第一個進行模糊測試。不幸的是，正如我們在第 IV-G 節中詳細解釋的那樣，如果配套應用程序生成的請求包含長度大于特定緩沖區大小的用戶名，則該相機包含一個可以被利用的錯誤。但是，通過模糊測試 changeCameraUsernamePassword 的后兩個參數，IoTFuzzer 只會改變 cam.changeUsername 和 cam.changePassword 的第二個參數——分別是 newUsr 和 newPwd——并且不會改變它們的第一個參數（cam.user），這會導致發現一個額外的錯誤。這個案例凸顯了 IoTFuzzer 方法的局限性，因為它表明，假設發送到設備的所有數據都直接來自應用程序的 UI，對于發現 IoT 設備中的錯誤是無效的。另一方面，我們的自下而上的方法從 sendMessage 函數中引導其分析（參見第 III 節），與輸入源無關，因此更通用。
??此外，changeCameraUsernamePassword僅允許修改特定相機型號的憑據（第2行，cam.checkCameraModel）。這意味著IoTFuzzer無法有效地模糊其他相機模型。通過識別控制流中更深層次的模糊觸發器，DIANE繞過了該檢查，并且獨立于設備版本有效。
??對于設備ID 7和8，IoTFuzzer導致應用程序立即崩潰，原因是掛接的函數數量太多。我們將分析范圍縮小到只包含與設備交互的代碼的包，但無論如何應用程序都會崩潰。因此，我們無法在這些設備上運行IoTFuzzer。

圖4 IoTFuzzer為Insteon攝像頭（設備ID 2）找到模糊功能

圖5 IoTFuzzer為Foscam攝像頭配套應用程序（設備ID 4和5）找到模糊功能
??對于設備ID 9，IoTFuzzer確定了3個要fuzz的函數。然而，我們發現這些函數是誤報的，因為它們被用來在智能手機上記錄用戶數據。
??對于ID為1、4和5的設備（表III中標記為?），IoTFuzzer無法識別任何要模糊的功能。原因是為了找到一個fuzz函數，IoTFuzzer必須首先找到應用程序的UI元素和Android的socket發送函數之間的數據流。然而，在這些設備中，“發送”功能是以本機代碼實現的（即，這些設備不依賴Android的發送功能）。由于IoTFuzzer無法識別本機代碼中的發送函數，它無法識別最終將生成網絡流量的UI事件，因此，它沒有生成任何有效的模糊輸入。DIANE通過使用動態分析克服了這一限制，并找到了產生網絡流量的邊界函數，如第III-A節所述。
??為了幫助IoTFuzzer并與我們的工具進行直接比較，我們對DIANE在IoTFuzzer中找到的發送函數進行了硬編碼，并重新對這些設備進行了分析。對于設備ID 4和5，IoTFuzzer為fuzz確定了一個候選函數，與設備ID 2類似，應用程序使用該函數更改設備的憑據。該函數如圖5所示，它實現了一個檢查（通過confirm_憑證），要求用戶提供憑證以便繼續。因此，模糊化并沒有給攝像機產生任何有意義的輸入，因為檢查會不斷失敗。相反，DIANE被識別為模糊觸發函數changeUserAndPwd，它不受任何檢查的影響（因為它在檢查完下憑證信息之后才模糊），并在模糊時有效地向攝像機發送命令。這些案例突出了IoTFuzzer方法的另一個局限性，因為它們表明，模糊化應用程序控制流中處理用戶提供數據的第一個函數是無效的。
??對于設備ID 1，IoTFuzzer識別了一個名為setUser的函數，該函數將用戶的登錄信息發送到設備。在這種情況下，此函數由一個禁止用戶密碼包含某些特殊字符（例如“&”）的檢查來保護。我們對這個函數進行了24小時的模糊處理，沒有在設備中記錄到任何異常。同樣在本例中，DIANE在進行任何客戶端檢查后，選擇了應用程序控制流中更深的一個函數。這是成功發現（零天）bug所必需的。
??總體而言，DIANE僅在兩種情況下（設備ID 3和6）的表現與IoFuzzer一樣出色，并且在所有其他情況下都優于IoFuzzer，這是因為IoFuzzer無法識別任何有意義的發送功能，或者因為它沒有產生任何導致崩潰的輸入。
該評估強調了在配套應用程序中仔細選擇正確的模糊功能的重要性，并且appside消毒檢查會阻礙模糊活動的效果。伴隨應用程序中存在應用程序端消毒的頻率加劇了這一問題。例如（如表II所示），在我們的數據集中，我們發現11個應用程序中至少有7個包含健全性檢查。我們在第IV-E節中進一步衡量了這一方面。

局限性和未來工作

??雖然我們解決了執行物聯網設備黑盒模糊化的主要挑戰，但我們的總體方法和DIANE的實施仍然存在一些局限性。
??當應用程序端健全性檢查在本機代碼、數據轉換函數或直接在sendMessage函數中實現時，我們目前無法繞過這些檢查。盡管我們承認此類檢查可能存在于這些代碼類中的任何一類中，但我們手動驗證數據集中的任何應用程序都不包含這些類別中的健全性檢查。事實上，正如前面的工作[16]所示，本機代碼通常不用于實現主應用程序的邏輯，而是用于庫助手函數中。請注意，與前面的工作不同，這并不意味著DIANE根本無法處理本機代碼。事實上，即使sendMessage函數是本機實現的，DIANE也可以識別它并模糊其模糊觸發器。但是，如果上述任何一類代碼中都存在健全性檢查，則模糊化的效果就較差。
??與任何基于動態分析的方法一樣，DIANE的代碼覆蓋范圍有限，即無法識別應用程序未執行的模糊觸發器。為了緩解這一限制，我們手動刺激應用程序以觸發大部分可用功能，并在真正的智能手機上進行分析。
DIANE的當前實現無法模糊嵌套Java對象。我們計劃在今后的工作中解決這一問題。
??DIANE可以被增強以自動發現語義漏洞（例如，智能鎖打開門而不是鎖上門）。目前，該功能是半自動的，因為它需要分析員檢查看門狗設備并與之交互。

結論

??在本文中，我們研究了物聯網設備模糊器的有效性。一方面，隨機模糊發送到設備的網絡數據包需要了解設備接受的數據格式，而當設備使用自定義固件時，這種數據格式很少可用。另一方面，由于應用程序端代碼施加的限制，利用配套移動應用程序的UI生成語法正確的消息的方法是無效的。
??相反，我們提出了一種介于網絡級模糊和用戶界面級模糊之間的新方法。我們的方法旨在識別模糊觸發器，它是物聯網配套應用程序中的代碼部分，在輸入驗證之后和任何數據轉換功能之前執行，并最大化模糊結果。我們在一個名為DIANE的工具中實現了我們的方法，并在11個不同品牌的真實物聯網設備上對其進行了評估。DIANE的性能優于當前最先進的方法，它可以成功地檢測到現有模糊程序無法觸發的關鍵錯誤（9個0day）。