圖 1-1 ? 華為終端 IoT 獎勵計劃列表
小豚 AI 攝像頭就是表格中的壹項，而且在上圖的所有設備中，小豚 AI 攝像頭是分析難度比較小的壹款設備，比較適合與大家壹起分享。
2. 外部分析
照慣例，拿到壹款新設備肯定是正常使用壹下，看看設備都提供什麽功能、猜壹猜其背後的運行邏輯。通過監聽正常使用時的通信數據，可以獲得手機、攝像頭通信內容如下圖所示：
圖 2-1 攝像頭和手機之間的通信內容
上圖中，手機和攝像頭之間存在 COAP 協議通信數據。此部分通信僅在給攝像頭配網的過程中出現，在這之後，手機和攝像頭不再直接通信，而是完全由雲端轉發兩者的通信數據，攝像頭和雲端的通信內容如下圖所示：
圖 2-2 攝像頭和雲端之間的通信內容
可以看到，攝像頭與雲端的絕大部分通信都是 TLS 加密通信。事實上，攝像頭對雲端的 TLS 證書有校驗，我們無法用簡單的中間人攻擊拿到通信內容。
除通信監聽外，我們還對攝像頭開放的 tcp 端口進行了掃描，截圖如下：
圖 2-3 對攝像頭進行 nmap 掃描
結果顯示該設備並沒有監聽任何 tcp 端口，是個麻煩的設備啊。
3. 硬件分析
在此前的文章中，我們已經分析過不少設備固件了，這裏就輕車熟路地開始吧。簡單翻閱設備官網，可以確定固件並沒有在官網提供下載鏈接。那就直接拆開設備看壹看吧，如下圖所示：
圖 3-1 攝像頭電路板
可以看到，該設備使用 hi3518ev300 作為 SoC，還有型號為 winbond 的 16MB Flash 存儲器。
分析過華為設備的小夥伴肯定知道他們官網是沒有公開海思芯片的相關資料，只有經過官方認證的組織才能拿到指定型號的芯片手冊，顯然我們並沒有被認證。不過，萬能的淘寶幫了我們壹把，可以在淘寶上買到了 hi3518ev300 的芯片手冊以及開發 SDK，這些資料在後文中發揮了重要作用。
圖 3-2 淘寶購買全套資料
將 Flash 存儲器用熱風槍從板子上吹下來，放入編程器提取 Flash 內容，並將提取得到的文件交給 binwalk 分析壹下，結果很讓人滿意，該分析的都分析出來了，如下圖：
圖 3-3 binwalk 分析結果
在 IoT 獎勵計劃的列表中，路由器、AI 音箱 2 等設備都是無法直接用 binwalk 分析的，有機會再和大家分享那些設備的分析過程。
通過 binwalk 的分析結果，我們可以確定攝像頭中運行了壹個嵌入式 Linux 操作系統，那麽，接下來的工作就是以某種方式登錄到系統之中，由此觀察系統中程序的運行狀態並調試感興趣的程序代碼。雖然 qemu 也可以用於調試工作，但在原設備上直接分析和調試肯定是更好的選擇。為了登錄系統，我們踩了不少坑，這些踩坑過程我們就不在文章中復述，感興趣的讀者可以找找當時會議分享的 PPT，這裏直接給出我們用到的 3 種登錄方法：串口登錄、telnet 登錄以及反向 ( reverse ) shell 登錄。
4. 串口分析
借助在淘寶買到的芯片手冊以及萬用表，就可以確定電路板上懸空的幾個過孔即為 SoC 的 UART 接口，如下圖：
圖 4-1 電路板 UART 接口
僅僅接通電路板上的 UART 接口是無法正常使用 UART 串口的，開啟攝像頭的串口還需要兩步操作：其壹是調整 uboot 在引導 linux kernel 時使用的啟動參數 ( bootargs ) ；其二是調整 linux 啟動腳本中對串口的各種設置。
用 16 進制編輯器打開固件中的 uboot 部分，觀察這部分固件內容，並與 SDK 文檔中描述的 uboot 固件結構進行對比，如下圖：
圖 4-2 攝像頭固件結構
通過對比圖 4-2 上下兩圖，可以確定起始 4 個字節為 magic word，代表著設備啟動了 secure boot 機制。在該機制的保護下，boot rom 代碼會對 uboot 部分進行 RSA 簽名校驗，以防止 uboot 程序被篡改。緊接著 4 個字節代表 uboot 部分的總長度，在該設備中為 0x036A58 字節。
由於整個 uboot 部分被 RSA 簽名校驗保護，而我們又沒有簽名私鑰以重新計算簽名，所以 uboot 這部分是沒辦法改動的。但是通過深入地逆向分析 uboot 代碼，我們發現 uboot 並沒有對固件其他部分進行簽名校驗，這意味著我們可以隨意調整文件系統。此外，我們又發現了 linux kernel 的引導參數被保存在了 uboot 之外的部分，如下圖所示：
圖 4-3 攝像頭 Linux 啟動參數
上圖中，kernel 的引導參數保存位置為 0x40000，已經超過了 uboot 的範圍。所以我們可以調整引導參數，如下圖：
圖 4-3 調整 Linux 啟動參數
上圖中起始的 4 個字節為 crc32 校驗，我們更改了啟動參數，所以需要重新計算 crc32 值並填回此處。
接著，查看 squashfs 文件系統中的啟動腳本 ( big_run.sh 和 small_run.sh 兩個 ) ，並對比 SDK 文檔中芯片手冊內容，如下圖：
圖 4-4 啟動腳本中隊引腳的設置
可以看到，在啟動腳本中，SoC 的此引腳被設置為 GPIO 功能。我們需要調整啟動腳本，將該引腳重新設置為 UART 功能，如下圖所示：
圖 4-5 調整後的啟動腳本
在完成上述兩個調整之後，需要將固件重新打包並燒錄至 Flash 中。由於 linux 啟動腳本在 binwalk 提取的 squashfs 文件系統中，所以我們需要用 SDK 中的 mksquashfs 工具，重新打包 squashfs 文件系統，具體方法在胖猴專題之前的關於海康螢石設備分析的文章中介紹過，這裏就不再贅述。
完成以上工作後，給設備重新上電，即可使用串口登錄設備，如下圖：
圖 4-6 通過串口順利登錄設備
5. 小結
到此即是我們對小豚 AI 攝像頭的第壹篇，在本文中，我們對此設備進行了簡單的外部分析，並順利的開啟了設備的串口功能。但事實上，我們分析的很多設備是無法啟用串口的，所以在下壹篇文章中，我們會繼續分享其他的系統登錄方法。在登錄系統之後，我們還會分析其中的壹個關鍵程序，就是產生 TLS 加密通信的關鍵程序。