智能門鎖與 BLE 設備安全 Part 1：BLE 協議棧與 Android BLE 接口簡介

作者：Yimi Hu & Light @ PwnMonkeyLabs
原文鏈接：https://mp.weixin.qq.com/s/p55KxJcqPSqkwNVEZ2t9UQ

概述

最近受疫情影響，已經在家辦公了很長一段時間，正好借此機會把此前的工作進行了一番整理，并挑選出來了一部分可以公開的題材，最終形成了這個專題的文章。

在我們的計劃中，這個專題有兩個主線，分別是：

a. BLE設備安全研究

b. 智能門鎖的安全研究

其中，智能門鎖是我們的主要研究目標，但由于很多智能門鎖在藍牙BLE這塊的設計或多或少地有些小問題，所以我們就將一些BLE設備也單獨拿出來，作為另一個線索，用以幫助專題內容的展開敘述。

這個系列，我們取名為《胖猴小玩鬧》，因為在整個專題中出現的各種案例或者已經修復，或者危害程度不高，所以我們將這些無傷大雅的小打小鬧統一稱為“小玩鬧”。

作為這個專題的第一篇文章，我們將這篇中簡要敘述一下BLE協議和Android關于BLE相關的接口，這些內容比較傾向于基礎知識，在專題后續的文章中有很多處都會用到這些知識點。當然，這里我們只是淺嘗輒止地介紹，并不做深刻地討論，有需要了解更多內容的讀者可以參考相關的文檔。

BLE協議

我們通常所說的藍牙，即Bluetooth，有兩種形式：傳統藍牙BR（Basic Rate）和低功耗藍牙BLE（Bluetooth Low Energy）。前者的典型使用場景是藍牙耳機、藍牙音箱等，而后者的典型使用場景是各種IoT設備，如藍牙手環等。

藍牙的數據傳輸模型如下圖2-1所示，分為Physical層、Logical層和L2CAP層：

為了幫助理解，可以類比OSI七層網絡協議：數據發送時，高層將數據發送給L2CAP層，并逐層向下流動；數據接收時，設備從Physical層獲得數據，并逐層向上流動。對這三層數據傳輸模型有一些簡單的認知，就可以極大的加快我們分析和研究的速度。

首先，來關注下L2CAP層。在這一層中，我們需要關注的內容比較少，高層應用中出現的需要發送的BLE數據和需要接收的BLE數據都會直接出現在這一層之中，所以，如果我們能夠抓到這一層的通信數據，則意味著我們可以直接抓到高層應用的通信數據，雖然這些數據可能是在應用層中被加密了，但至少這些數據還沒有被BLE協議棧加密。這在某種程度上方便了我們的分析。通過wireshark分析L2CAP層的通信數據如下圖：

上圖中，ATT協議即為運行于L2CAP層之上的通信協議，wireshark可以直接分析出ATT協議中的通信數據。在本專題的后續文章中，我們可以看到抓取未加密的L2CAP層數據用于輔助分析的案例。

然后，我們再來關注下Physical層。Physical層定義了3個廣播信道和37個數據通信信道。兩個BLE設備進行連接時，會隨機挑選一個廣播信道進行廣播，連接建立之后，會在37個通信信道上進行跳頻通信。下圖展示了某一次通信的流程：

上圖中，BLE通信在0x27信道進行廣播，等待BLE雙方成功建立連接之后，會在0x5----0xA----0xF----0x14等信道，按照一定規律進行跳頻通信。

最后，我們再來關注下Logical層。該層中主要完成BLE通信過程中的各種邏輯控制，這么說并不準確，但可以幫助我們理解問題。大多數使用場景中，一次BLE通信過程存在master和slave兩方，其中master是主動掃描并發起連接的一方，而slave是不斷發送廣播并等待連接的一方。在一次通信中，master和slave的狀態變化如下圖所示：

其中，scanner和advertiser分別表示master和slave的掃描狀態和廣播狀態。建立連接之后，開始跳頻通信，并成為最終的master和slave.

Android的BLE接口

絕大部分IoT設備都需要與Android/IOS手機通信，而BLE顯然是一種很常見的通信方式。為此，我們也有必要了解一下Android設備中，關于BLE通信相關的各種API。

我們先回憶一下TCP的socket通信。在socket通信中，服務端程序運行于某一IP地址上，并持續監聽某一端口(port)。客戶端程序選擇服務端的IP和port，發起socket連接，經過三次TCP握手之后完成socket連接的建立，此后使用該socket進行通信。藍牙BLE通信也是如此，首先我們需要掃描周圍的藍牙BLE設備，并選擇某個BLE設備。此時，需要用到的API如下：

掃描并選擇完畢之后，我們就需要與之通信。在TCP通信中，發送數據和接收數據常用的函數為：send和recv。而在BLE通信中，我們使用到的API如下表所示：

上表中，讀者可能對characteristic有些陌生，我們在這里對characteristic有一個簡短的說明。每一個BLE設備，都有一個對應的profile，用于對這個設備進行描述。一個profile中包含多個service，這些service就是該設備提供的各種服務。而在一個service中，會有多個characteristic，設備提供的service就是靠這些characteristic來完成的。用一張圖片來表示上述文字，如下：

上圖中，右側圖片為一個BLE設備的實例，可以看到在圖片中有4個service，前兩個為Unknown service，后兩個分別是Battery Service(電池服務)和Current Time Service(當前時間服務)。而在第二個Unknown service中，有一個Unknown Characteristic。值得一提的是，Service和Characteristic各自擁有一個UUID用于標識，在BluetoothGatt類的相關函數中，就是用這些UUID找到所需的service和characteristic，這就相當于TCP通信中的端口（port）。

小結

這個系列的第一篇到此就要結束了，在本篇中，我們簡要介紹了一下BLE協議棧以及Android BLE的常用API。后續的文章中，就會挑選一些我們遇到的設備，拿過來說一說講一講，這些文章都偏向于實戰，純理論的介紹相對會少一些，如果有條件的話，還期待各位讀者能跟著我們實際操作一下，以幫助加深印象。

最后，希望大家看完本系列文章能有所收獲。

本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1527/