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

簡介

摘要

??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.
??摘要：物聯(lián)網(wǎng) (IoT) 設(shè)備已扎根于數(shù)十億人的日常生活中。因此，研究人員已應(yīng)用自動錯誤查找技術(shù)來提高其整體安全性。然而，由于難以提取和模擬自定義固件，黑盒模糊測試通常是唯一可行的分析選項。不幸的是，該解決方案大多會產(chǎn)生無效輸入，這些輸入會被目標(biāo)物聯(lián)網(wǎng)設(shè)備迅速丟棄并且不會滲透其代碼。另一種建議的方法是利用配套應(yīng)用程序（即通常用于控制物聯(lián)網(wǎng)設(shè)備的移動應(yīng)用程序）來生成結(jié)構(gòu)良好的模糊測試輸入。不幸的是，現(xiàn)有的解決方案產(chǎn)生的模糊輸入受到應(yīng)用端驗證代碼的限制，從而大大限制了已發(fā)現(xiàn)漏洞的范圍。
??在本文中，我們提出了一種克服這些限制的新方法。我們的主要觀察結(jié)果是配套應(yīng)用程序中存在可用于生成最佳（即有效但約束不足）模糊輸入的函數(shù)。此類函數(shù)，我們稱為模糊觸發(fā)器，在任何數(shù)據(jù)轉(zhuǎn)換函數(shù)（例如，網(wǎng)絡(luò)序列化）之前執(zhí)行，但在輸入驗證代碼之后執(zhí)行。因此，它們生成的輸入不受應(yīng)用程序端清理代碼的約束，同時也不會由于格式無效而被分析的 IoT 設(shè)備丟棄。我們設(shè)計和開發(fā)了 DIANE，這是一種結(jié)合靜態(tài)和動態(tài)分析的工具，用于在 Android 配套應(yīng)用中查找模糊測試觸發(fā)器，然后使用它們自動對 IoT 設(shè)備進行模糊測試。我們使用 DIANE 分析了 11 個流行的物聯(lián)網(wǎng)設(shè)備，并確定了 11 個錯誤，其中 9 個是零日漏洞。我們的結(jié)果還表明，如果不使用模糊觸發(fā)器，就不可能為許多設(shè)備生成觸發(fā)錯誤的輸入。

導(dǎo)言

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

動機

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

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

方法

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

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

模糊觸發(fā)器識別

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

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

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

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

fuzzing

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

實驗

??原文中作者使用DIANE對11種不同的物聯(lián)網(wǎng)設(shè)備進行模糊處理，還與現(xiàn)有的網(wǎng)絡(luò)級模糊器進行了比較。在這里只介紹與LOTFUZZER對比部分的實驗。

DIANE vs LOTFUZZER

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

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

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

局限性和未來工作

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

結(jié)論

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