1。 簡介
上一篇文章中我們透過SWD介面提取出了門鎖韌體，並使用IDA順利載入了韌體，本篇將繼續對韌體進行分析，研究門鎖如何處理手機透過BLE下發BleKey的通訊資料。
書接上文，我們仿照果加門鎖韌體的處理方式，對鹿客門鎖的韌體進行解析之後，IDA 的導航條如下圖所示
圖1-1 IDA直接解析韌體後的導航條
上圖中可以看到，目前韌體只有開始的一小部分被解析成程式碼了，其他絕大部分韌體資料都是unexplored狀態。瀏覽韌體中的字串，可以發現如下圖所示的內容：
圖1-2 韌體中的部分字串
結合被順利解析的程式碼片段，我們可以推測目前此部分程式碼僅僅是bootloader，後續的主程式可能使用了FreeRTOS系統（一種開源的實時作業系統，https：//www。freertos。org/）。
針對當前的情況，我們可以選擇直接“莽”，即由bootloader開始分析，一直分析到BLE的處理流程，但是由於門鎖韌體使用了FreeRTOS作業系統，這個分析思路實現起來會更麻煩一點。這裡可以選擇一種更直接的研究方法：既然門鎖電路板上已經提供了SWD引腳，這裡我們就看看能不能“投機取巧”一下，直接透過SWD除錯，快速定位到韌體的關鍵位置。關於bootloader和FreeRTOS，後續會以一篇番外的形式來分享其分析方法。
2。 SEGGER JLink的除錯功能
在進行除錯之前，先簡單介紹一下如何使用SEGGER JLink（下文以JLink代稱）的除錯功能。上一篇文章中，我們在提取韌體時使用了JLink的命令列工具，這個命令列工具也包含了諸如設定斷點、暫停CPU核心、讀取/寫入暫存器或指定位置的記憶體、單步除錯等動態除錯所需要的指令，具體可以查閱SEGGER的Wiki（https：//wiki。segger。com/J-Link_Commander）。可以選擇openOCD配合JLink進行除錯，但我們在本篇中暫不介紹openOCD，而是選擇另一款除錯工具。
在實際除錯過程中，命令列工具通常需要搭配IDA使用，用起來非常繁瑣，且資訊展示不夠直觀。SEGGER提供了一個圖形介面工具——Ozone，可以在一定程度上解決以上問題， 關於Ozone的介紹可以參考SEGGER的官方網站（https：//www。segger。com/products/development-tools/ozone-j-link-debugger/），軟體以及使用手冊的下載頁面也可以在這裡找到。下載後的安裝一路next就可以了，想必大家都很熟練（滑稽）。
安裝完成後，可以透過“File->New->New Project Wizard”選項來建立新的專案，建立時需要選擇待除錯晶片的型號、除錯介面型別、通訊速率等資訊。繼續，點選“Debug->Start Debug Session->Attach to Running Program”連線到待除錯裝置，注意整個除錯過程中需要保持電腦、偵錯程式和裝置的接通狀態，如下圖所示。
圖2-1 連線到裝置
連線到待除錯裝置後，Ozone可以像IDA一樣展示多個subview，這樣就可以同步觀察很多資訊了，下圖是筆者某次除錯的介面。
圖2-2 Ozone除錯介面
如上圖所示，我們在除錯時可以一次性看到暫存器的資料、多個記憶體區域的資料以及反彙編後的程式碼，下方的控制檯區域可以執行一些指令或預先編寫好的指令碼，除此之外，左上角的斷點設定區域，可以看到斷點除了Location以外，還有Type和Extra兩個屬性， 透過閱讀使用者手冊可以確定這兩個屬性是用於設定斷點型別的，如執行斷點，讀寫斷點、TRACE斷點等，如下圖所示：
圖2-3 Ozone中斷點的屬性
Ozone還提供了很多強大的功能，在後文中，我們用到的時候就會逐一介紹這些功能。
3。 透過SWD介面對門鎖進行除錯
學習了Ozone的基本使用方法，我們就來除錯一下門鎖韌體。回顧第一篇鹿客門鎖的分析文章，我們分析了鹿客門鎖與手機app之間的通訊資料，知道BLE通訊有AES加密保護，聯想到果加門鎖的分析文章中，我們透過TEA加密使用的常量來定位門鎖的通訊處理程式碼，那麼這裡我們是不是也可以從AES加密入手呢？
3.1 韌體中的AES加解密
翻閱門鎖MCU的晶片手冊可以看到，晶片提供了AES處理模組，該模組的記憶體對映如下圖所示。
圖3-1 EFM32中的記憶體對映
顯然，我們假設鹿客門鎖使用晶片的AES模組進行加解密操作，而不是自寫AES演算法，那麼必然需要訪問0x400E0000~0x400E0400這片區域中的記憶體地址，那麼我們只要在設定適當的讀寫斷點，然後等待手機與門鎖進行通訊時觸發斷點就可以了。
在斷點設定區域右鍵，選擇Set Data Breakpoint，會彈出如下圖所示的視窗，
圖3-2 設定資料端點
上圖中的設定，表示當CPU向0x400E00XX地址寫入資料時觸發斷點。
斷點設定完成之後，在手機上點選開鎖，由於我們設定的資料斷點是監控一片記憶體區域，所以開鎖過程中會多次被觸發，後可以看到如下圖左側的一小段程式碼，右側是執行到0xED0C地址時的暫存器資料。
圖3-3 寫入待解密資料的斷點
上圖中，0x400E001C地址（R0 + 28）是AES_DATA暫存器，這一小段程式碼所處的函式向AES_DATA暫存器寫資料，應該就是AES的處理函式（下文以AESFunc代稱）。回溯呼叫棧，可以找到呼叫AESFunc的外層函式，以及AESFunc函式的起始地址，進而使用IDA的F5功能對AESFunc函式進行分析，如下圖：
圖3-4 AESFunc函式的虛擬碼
結合晶片手冊，由虛擬碼很容易能判斷出AESFunc各個引數的作用，在本系列第一篇文章中，我們已經知道了開鎖時的解密金鑰就是BleKey，而門鎖BleKey的獲取過程，是由伺服器下發一組資料totalData至手機app，app沒有進行任何處理，直接透過BLE通訊轉發給了門鎖。那麼，接下來看一看門鎖是如何處理totalData的。
3.2 門鎖獲取BleKey的過程
首先我們需要看一下，totalData的內容是什麼，如下圖所示：
圖3-5 totalData欄位及其base64解碼資料
可以看到totalData是一串二進位制資料經過base64編碼後的結果，紅框之前的部分可以視作資料的header，包含訊息頭、資料包序號、校驗等內容， header之後的body部分，即紅、藍、黑框中的資料，這三組資料的結構是相同的，如下圖所示：
圖3-6 totalData中payload用到的資料結構
紅框中data_type為0x03的資料，其data_content=0x5FFFECAE，該部分與AES根金鑰密文有關。totalData的body部分還有兩組資料，其具體作用不再詳細說明，說太多有些不妥。
接著，我們在AESFunc的入口下一個斷點，可以看到BleKey的值如下圖所示：
圖3-7 記憶體中的BleKey
從圖3-5和圖3-7中看不到BleKey和totalData之間的聯絡，想必二者之間還是經過了某些解密或解碼轉換，我們需要繼續尋找門鎖對totalData的處理過程。保持AESFunc函式的斷點，在除錯過程中可以發現totalData也是經過 AESFunc函式進行解密的。此時，回溯呼叫棧即可找到如下圖所示的關鍵程式碼。
圖3-8 totalData資料的處理
上圖中的AESEntry函式為AESFunc的封裝，這部分就是由totalData生成BleKey的核心程式碼，該流程可以整理為下圖。
圖3-10 BleKey獲取流程圖
在這個流程中，如果沒有根金鑰就無法解密得到BleKey，透過除錯可以找到根金鑰在Flash中的儲存地址是0x7E09C。
4。 總結
鹿客門鎖的系列文章就先到這裡，其他的功能邏輯分析就不再做過多討論，感興趣的讀者可以自行探索。在關於鹿客的第一篇文章中，我們透過逆向手機app知道了門鎖藍芽功能的通訊資料有AES加密保護；第二篇文章分享瞭如何使用SWD介面提取韌體；本篇文章進一步透過對門鎖韌體的除錯，來分析門鎖獲取BleKey的過程。在下一篇番外中，我們會介紹關於鹿客門鎖的其他分析技巧，但不會再更多的討論鹿客門鎖的執行邏輯了，感興趣的同學請多多關注我們的後續文章。最後，希望大家都能有所收穫。
Light & Yimi Hu @ PwnMonkeyLabs
