# argXtract: Deriving IoT Security Configurations via Automated Static Analysis of Stripped ARM Cortex-M Binaries

## Abstract

* IoT 設備的漏洞成因主要是配置問題
* 現有的自動化分析主要運作在有 OS 的裝置
* argXtract 是一個對 Cortex-M 的 Binary 檔案做自動化靜態分析的框架

## Introduction

* IoT 設備發展快速，也處理越來越多隱私資料，需要注意資安
* 許多情況下，漏洞的根本原因是配置不佳
* 提出 argXtract，是一個可自動化靜態分析 ARM Cortex-M 二進制檔案的安全分析框架
* 對三個裝置實際進行分析
* [開源](https://github.com/projectbtle/argXtract)

## Motivation

* 分析 IoT 設備常見的攻擊原因(如 Mirai)，發現設備配置常常是弱點，而這些資料通常在 firmware 可以得到
* 要藉由逆向得到密鑰等資訊，通常要
* 目標 function 位址和 caller 位址
* inline data 位址
* 加載的偏移量
* 但是會遇到問題
* ELF 檔案被 strip 掉
* 反編譯分析錯誤
* 原因是大部分免費的逆向工具都不支援 ARM 的 Thumb 指令集

## argXtract

* argXtract 將反組譯過的 Cortex-M 的二進制檔案作為輸入，目標是提取出參數和和安全相關有興趣的 call
* 過程分為
* Application code base identification: 確認位址
* Data identification: 不把 data 當成 code
* Function block identification: 路徑生成和功能匹配(?)
* COI identification (function call or ARM supervisor call): 確認追蹤結束點
* Tracing and argument processing: 提取和處理 COI 參數

### Application Code Base Identification

* 藉由查詢 vector table 來計算出正確的偏移量

### Data Identification

* 辨識出 .data 和 .text 正確的區塊
* 使用 reset handler 和一些 PC 相關的加載來判斷

### Function Boundary Identification

* argXtract 使用 Function Boundary Identification 來確認執行路徑
* 尋找 function 內的 pop, load-to-PC, bx lr 等指令當作 function 退出點
* 無法繞出的退出點標記成最終退出點(不會走任何 branch 到達的退出點)
* 最終退出點的下一個指令當作是下一個 function 的開始
* 最後可以得到 function 的執行路徑

### COI Identification

* 使用者可以輸入感興趣的 svc(supervisor call)，該指令的地址會被存下來
* 使用者也可以給予感興趣的 function 的 input，會將匹配到的 function 標記出來

### Tracing and Argument Processing

* 得到了 COI 之後就可以反向追蹤出 call path
* 根據給予的輸入型別和內容，會對應輸出追蹤到的結果

## Evaluation

* 使用 python 實作
* 用 Capstone 反組譯
* 支援 ARM
* 用於 radare、angr、binwalk 等工具

---

* 生成 28 個 ARM Cortex-M 二進制檔案，根據晶片供應商使用不同的工具編譯
* 分別把有 strip 和沒有的檔案丟到 argXtract、radare2 和 ghidra，比較 function 的辨識率
* 
* TPR = 正確率
* EFPR = 以為自己有辨識出來，其實是錯的
* argXtraxt 的正確率只有 5 個 < 95%
* 其中 0% 的那一個是因為他有兩個 .text 片段

---

* 針對幾個函式庫和 Texas Instruments 平台驗證函數辨識的部分
* 丟入了不同廠商的 SDK 生成的有 strip 的二進制檔案，全部都有正確辨識出 function

---

* 使用生成已知配置的二進制檔案作測試，並用真實世界的二進制檔和設備驗證
* 針對 Nordic 和 STMicroelectronics 晶片組使用 GCC、Keil 和 IAR 編譯，實現 ANT 和 BLE 兩個傳輸協議
* 由 argXtract 抓出來的配置(加密密鑰、設備資訊等等)和實際上的完全一樣才視為成功
* 實驗結果提取的配置完全符合

## Case Study

* BLE 定義了四個 Level 的安全保護
* 無安全性
* 沒身分驗證的加密配對(會被中間人攻擊打)
* 有加密的身分配對
* 128-bit 的密鑰加上有加密的身分配對
* argXtract 提取出的資料顯示，大多數的開發人員使用的是級別 2 的安全保護
* 在健身或醫療設備中，可能儲存和使用者有關的資訊，沒有保護就代表資料容易外洩
* 甚至發現有些設備可以利用中間人攻擊修改設備和主機的資料，導致醫療設備無法運作

---

* 使用固定的密鑰也是一個問題，在 dataset 中有發現一個智能手錶的文件，密碼永遠是 000000

## Limitations and Future Work

* 正如前面提過的 argXtract 遇到 .text 區段被切很多塊時會無法處理
* 如果一個檔案包含大量的 function 時，作 COI 的動作可能會花好幾個小時

## Conclusion

* 提出 argXtract，是一個用於分析 IoT 二進制文件的框架，可從 ARM Cortext-M firmware 中提取出安全相關的資料
* 實驗顯示設備存在數據保護不足、權限控管問題和隱私洩漏等問題

###### tags: `paper`