??本文記錄閱讀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 Li_{f} Lif?和 L o f Lo_{f} Lof?中的每個變數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 Li_{f} Lif?={b}， L o f Lo_{f} Lof?={enc}；sendCommand: L i f Li_{f} Lif?={cmd}， L o f Lo_{f} Lof?={cmd}；和unlock: L i f Li_{f} Lif?={}， L o f Lo_{f} Lof?={cmd}，
??一旦我們確定了切片中的函式范圍，我們運行應用程式并計算分配給每個活動變數的資料的熵，然后，我們計算每個函式作用域引入的熵量，并檢查其值是否超過閾值，
??函式unlock不會引入任何熵，因為集合為空，在集合為空的情況下，我們不考慮函式作為候選資料轉換函式，因為它不接受任何輸入，
??對于函式encrypt，存盤在b中的資料的熵為5.94，而在enc中回傳的資料的熵為53.16，由于熵δ大于我們的閾值（ d e d_{e} de?＝53.16／5.94＞2），所以我們考慮加密作為資料變換函式，此外，函式sendCommand引入了較低的熵（ d e d_{e} de?=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），