物聯(lián)網(wǎng)安全實戰(zhàn)從零開始-低功耗藍牙初探

本環(huán)境是蛇矛實驗室基于"火天網(wǎng)演攻防演訓靶場"進行搭建，通過火天網(wǎng)演中的環(huán)境構建模塊，可以靈活的對目標網(wǎng)絡進行設計和配置，結合虛實結合技術能夠快速將wifi、藍牙等進行接入并保證正常運行邏輯，從而可以快速進行場景搭建和復現(xiàn)驗證工作。

背景

?藍牙技術始于愛立信公司的1994年方案，它是研究在移動電話和其他配件間進行低功耗、低成本無線通信連接的方法。發(fā)明者希望為設備間的通訊創(chuàng)造一組統(tǒng)一規(guī)則(標準化協(xié)議)，以解決用戶間互不兼容的移動電子設備。1997年前愛立信公司此概念接觸了移動設備制造商，討論其項目合作發(fā)展，結果獲得支持。1998年項目正式啟動。1998年5月，愛立信、諾基亞、東芝、IBM和英特爾公司等五家著名廠商，在聯(lián)合開展短程無線通信技術的標準化活動時提出了藍牙技術，其宗旨是提供一種短距離、低成本的無線傳輸應用技術。這五家廠商還成立了藍牙特別興趣組，以使藍牙技術能夠成為未來的無線通信標準。芯片霸主Intel公司負責半導體芯片和傳輸軟件的開發(fā)，愛立信負責無線射頻和移動電話軟件的開發(fā)，IBM和東芝負責筆記本電腦接口規(guī)格的開發(fā)。1999年下半年，著名的業(yè)界巨頭微軟、摩托羅拉、三康、朗訊與藍牙特別小組的五家公司共同發(fā)起成立了藍牙技術推廣組織，從而在全球范圍內掀起了一股“藍牙”熱潮。全球業(yè)界即將開發(fā)一大批藍牙技術的應用產(chǎn)品，使藍牙技術呈現(xiàn)出極其廣闊的市場前景，并預示著21世紀初將迎來波瀾壯闊的全球無線通信浪潮。

如對藍牙基礎有過了解，可以直接看第三章。

1.藍牙基礎

藍牙出現(xiàn)的原因，是為了解決從有線數(shù)據(jù)傳輸?shù)綗o線傳輸數(shù)據(jù)過程的問題。目前藍牙的版本：1.1、1.2、2.0、2.1、3.0、4.0、4.1、4.2、5.0、5.1、5.2、5.3。藍牙版本一直在更新，"<4.0" 的被稱為經(jīng)典藍牙(Classic Bluetooth)，">=4.0" 開始有了低功耗藍牙(Bluetooth Low Energy，一般簡寫為BLE)。其實我們常說的藍牙4.0并不等同于BLE，BLE只是藍牙4.0的子集；藍牙4.0是一個綜合性協(xié)議規(guī)范。藍牙4.0版本以后技術模式上分為低功耗藍牙(BLE)和經(jīng)典藍牙(BR/EDR)兩種、市場藍牙產(chǎn)品大多數(shù)為僅支持BLE的，也有兩者都支持的。藍牙 4.0 的芯片模式分為 Single mode 與 Dual mode。Single mode 只能與藍牙 4.0 互相傳輸無法向下與 3.0/2.1/2.0 版本兼容；Dual mode 可以向下兼容 3.0/2.1/2.0 版本。前者應用于使用紐扣電池的傳感器設備，例如對功耗要求較高的心率檢測器和溫度計；后者應用于傳統(tǒng)藍牙設備，同時兼顧低功耗的需求。

Bluetooth ：經(jīng)典藍牙，特點是耗電量大，傳輸距離近，速度一般，適合數(shù)據(jù)量大的傳輸。（相關設備：藍牙耳機、藍牙音響）

Bluetooth Smart ：Single mode藍牙只支持低功耗藍牙，特點是耗電量小，傳輸距離遠速度快，適合數(shù)據(jù)量小的傳輸。（相關設備：藍牙鎖、藍牙燈泡、藍牙手環(huán)）

Bluetooth Smart Ready：Dual mode藍牙同時支持經(jīng)典藍牙和低功耗藍牙。（相關設備：手機）

藍牙5.0是由藍牙技術聯(lián)盟在2016年提出的藍牙技術標準，藍牙5.0針對低功耗設備速度有相應提升和優(yōu)化，有著更廣的覆蓋范圍和相較四倍的速度提升，同時還提供了基于AoA/AoD 等定位的功能，并且針對物聯(lián)網(wǎng)進行了很多底層優(yōu)化，讓使用藍牙做為標準的物聯(lián)網(wǎng)應用更加強大。

BLE協(xié)議架構

要實現(xiàn)一個BLE應用，需要一個支持BLE射頻的芯片，然后基于一個與芯片配套的協(xié)議棧，開發(fā)藍牙應用。協(xié)議棧的作用就是軟件和硬件之間的橋梁，對應用數(shù)據(jù)進行封包然后生成可以通過射頻發(fā)送的空中數(shù)據(jù)包及其逆向過程。藍牙協(xié)議將藍牙整體分成了兩層架構，底層是核心協(xié)議，描述了藍牙核心技術的基礎和規(guī)范，包括了Host和Controller。應用層協(xié)議則基于具體需求，使用核心協(xié)議提供的機制，實現(xiàn)不同的功能策略。這兩部分在不同的藍牙協(xié)議版本中略有區(qū)別，但大致上是，Controller完成硬件側的規(guī)范制訂，包括信號調制解調，會抽象出用于通信的邏輯鏈路，可能存在一個或多個，如LE Controller、BR/EDR Controller；Host則在邏輯鏈路的基礎上完成更友好的封裝，屏蔽掉技術細節(jié)，方便應用層對數(shù)據(jù)的使用。

BLE協(xié)議架構由下面幾部分組成：

1.物理層(PHY)：PHY層用來指定BLE所用的無線頻段，調制解調方式和方法等。

2.鏈路層(LL)：LL層是整個BLE協(xié)議棧的核心，要做的事情非常多，比如具體選擇哪個射頻通道進行通信，怎么識別空中數(shù)據(jù)包，具體在哪個時間點把數(shù)據(jù)包發(fā)送出去，怎么保證數(shù)據(jù)的完整性，ACK如何接收，如何進行重傳，以及如何對鏈路進行管理和控制等等。LL層只負責把數(shù)據(jù)發(fā)出去或者收回來，對數(shù)據(jù)進行怎樣的解析則交給上面的GAP或者GATT。

3.主機控制接口(HCI)：HCI主要用于2顆芯片實現(xiàn)BLE協(xié)議棧的場合，用來規(guī)范兩者之間的通信協(xié)議和通信命令等。這一層可以是軟件或者硬件接口，如UART、SPI、USB等。

4.通用訪問配置文件(GAP)：GAP是對LL層payload（有效數(shù)據(jù)包）如何進行解析的兩種方式中的一種，而且是最簡單的那一種。GAP簡單的對LL payload進行一些規(guī)范和定義，因此GAP能實現(xiàn)的功能極其有限。GAP目前主要用來進行廣播，掃描和發(fā)起連接等。

5.邏輯鏈路控制級自適應協(xié)議(L2CAP)：L2CAP對LL進行了一次簡單封裝，LL只關心傳輸?shù)臄?shù)據(jù)本身，L2CAP就要區(qū)分是加密通道還是普通通道，同時還要對連接間隔進行管理。

6.安全管理(SMP)：SMP用來管理BLE連接的加密和安全的，如何保證連接的安全性，同時不影響用戶的體驗，這些都是SMP要考慮的工作。

7.屬性協(xié)議(ATT)：簡單來說，ATT層用來定義用戶命令及命令操作的數(shù)據(jù)，比如讀取某個數(shù)據(jù)或者寫某個數(shù)據(jù)。BLE協(xié)議棧中，開發(fā)者接觸最多的就是ATT。BLE引入了attribute概念，用來描述一條一條的數(shù)據(jù)。Attribute除了定義數(shù)據(jù)，同時定義該數(shù)據(jù)可以使用的ATT命令，因此這一層被稱為ATT層。

8.通用屬性配置文件(GATT)：GATT 是在 ATT 上面的一層結構，定義了使用 ATT的服務框架，GATT用來規(guī)范attribute中的數(shù)據(jù)內容，并運用group（分組）的概念對attribute進行分類管理，GATT規(guī)定配置文件（profile）的結構。沒有GATT，BLE協(xié)議棧也能跑，但互聯(lián)互通就會出問題，也正是因為有了GATT和各種各樣的應用profile，BLE擺脫了ZigBee等無線協(xié)議的兼容性困境，成了出貨量最大的2.4G無線通信產(chǎn)品。GATT定義了使用ATT的服務框架。在BLE中，所有被profile或者服務用到的數(shù)據(jù)塊稱為“特性”，兩個建立連接的設備之間的所有數(shù)據(jù)通信都是通過GATT子程序處理。GATT層用于已連接的藍牙設備之間的數(shù)據(jù)通信，應用程序和profile直接使用GATT層。當兩個設備建立連接之后，它們就處于下面兩種角色之一：GATT服務器：為GATT客戶端提供數(shù)據(jù)服務的設備。GATT客戶端：從GATT服務器讀寫應用數(shù)據(jù)的設備。

2.低功耗藍牙工作流程

在BLE中存在兩個角色，一個是中心角色（Central），一個是外圍角色（Peripheral）,藍牙設備或手機都可以單獨作為Central或Peripheral角色。外設角色的作用是為中心角色提供各種數(shù)據(jù)，中心角色可以掃描并接收多個外設角色數(shù)據(jù)（外圍角色中的設備進行廣播，中心角色的設備掃描尋找廣播），數(shù)據(jù)以服務（Service）和特性（Characteristic）的形式呈現(xiàn)。

藍牙工作流程：藍牙廣播->掃描設備->設備配對->數(shù)據(jù)傳輸。

這里以智能手環(huán)為例，我們簡單理解藍牙的工作流程為：智能手環(huán)(外圍設備)開啟藍牙后會進行廣播，這時智能手環(huán)會在3個廣播信道(37,38,39)上發(fā)送相同的廣播報文，此時手機(中心設備)打開藍牙后，手機中藍牙適配器自帶掃描器開始工作(掃描也在三個特定的廣播信道進行)，掃描器接收廣播信道的報文后，發(fā)出掃描請求報文，智能手環(huán)發(fā)送掃描響應報文，這時手機就知道了發(fā)現(xiàn)了周邊有一個智能手環(huán)設備。手機在點擊連接智能手環(huán)時，發(fā)起連接請求報文，智能手環(huán)收到并處理后返回連接回應報文，此時倆者一旦連接建立之后，則開始使用數(shù)據(jù)報文(這里不理解也沒關系，后面會講解)。連接成功后，倆者開始通信，通信過程中手機發(fā)現(xiàn)藍牙耳機存在某種服務，服務中存在一些特性如獲取人體心率，這些特性允許手機通過特定的信道發(fā)出讀、寫等請求進行數(shù)據(jù)傳輸，上面過程中所有的數(shù)據(jù)傳輸均以無線的形式在空中傳播。

如何通過無線發(fā)送藍牙數(shù)據(jù)包

再理解藍牙工作流程的細節(jié)前，我們先來看藍牙無線通信是如何進行的。下面部分內容來自于該文章(https://www.cnblogs.com/schips/p/12293062.html)，原理講解比較通透，所以我拷貝了一部分。假設有設備A和設備B，設備A要把自己目前的電量狀態(tài)83%（十六進制表示為0x53）發(fā)給設備B，該怎么做呢？作為一個開發(fā)者，他希望越簡單越好，對他而言，他希望調用一個簡單的API就能完成這件事，比如send(0x53)，實際上我們的BLE協(xié)議棧就是這樣設計的，開發(fā)者只需調用send(0x53)就可以把數(shù)據(jù)發(fā)送出去了，其余的事情BLE協(xié)議棧幫你搞定。很多人會想，BLE協(xié)議棧是不是直接在物理層就把0x53發(fā)出去，就如下圖所示：

這種方式初看起來挺美的，但由于很多細節(jié)沒有考慮到，實際是不可行的。首先，它沒有考慮用哪一個射頻信道來進行傳輸，在不更改API的情況下，我們只能對協(xié)議棧進行分層，為此引入LL層，開發(fā)者還是調用send(0x53)，send(0x53)再調用send_LL(0x53,2402M)（注：2402M為信道頻率）。這里還有一個問題，設備B怎么知道這個數(shù)據(jù)包是發(fā)給自己的還是其他人的，為此BLE引入access address概念，用來指明接收者身份，其中，0x8E89BED6這個access address比較特殊，它表示要發(fā)給周邊所有設備，即廣播。如果你要一對一的進行通信（BLE協(xié)議將其稱為連接），即設備A的數(shù)據(jù)包只能設備B接收，同樣設備B的數(shù)據(jù)包只能設備A接收，那么就必須生成一個獨特的隨機access address以標識設備A和設備B兩者之間的連接。

廣播方式

我們先來看一下簡單的廣播情況，這種情況下，我們把設備A叫advertiser（廣播者），設備B叫scanner或者observer（掃描者）。廣播狀態(tài)下設備A的LL層API將變成send_LL(0x53,2402M, 0x8E89BED6)。由于設備B可以同時接收到很多設備的廣播，因此數(shù)據(jù)包還必須包含設備A的device address（0xE1022AAB753B）以確認該廣播包來自設備A，為此send_LL參數(shù)需要變成(0x53,2402M, 0x8E89BED6, 0xE1022AAB753B)。LL層還要檢查數(shù)據(jù)的完整性，即數(shù)據(jù)在傳輸過程中有沒有發(fā)生竄改，為此引入CRC24對數(shù)據(jù)包進行檢驗 (假設為0xB2C78E) 。同時為了調制解調電路工作更高效，每一個數(shù)據(jù)包的最前面會加上1個字節(jié)的preamble（前導幀），preamble一般為0x55或者0xAA。這樣，整個空中包就變成（注：空中包用小端模式表示?。?/p>

上面這個數(shù)據(jù)包還有如下問題：

沒有對數(shù)據(jù)包進行分類組織，設備B無法找到自己想要的數(shù)據(jù)0x53。為此我們需要在access address之后加入兩個字段：LL header和長度字節(jié)。LL header用來表示數(shù)據(jù)包的LL類型，長度字節(jié)用來指明payload的長度

設備B什么時候開啟射頻窗口以接收空中數(shù)據(jù)包？如上圖case1所示，當設備A的數(shù)據(jù)包在空中傳輸?shù)臅r候，設備B把接收窗口關閉，此時通信將失??；同樣對case2來說，當設備A沒有在空中發(fā)送數(shù)據(jù)包時，設備B把接收窗口打開，此時通信也將失敗。只有case3的情況，通信才能成功，即設備A的數(shù)據(jù)包在空中傳輸時，設備B正好打開射頻接收窗口，此時通信才能成功，換句話說，LL層還必須定義通信時序。

當設備B拿到數(shù)據(jù)0x53后，該如何解析這個數(shù)據(jù)呢？它到底表示濕度還是電量，還是別的意思？這個就是GAP層要做的工作，GAP層引入了LTV（Length-Type-Value）結構來定義數(shù)據(jù)，比如020105，02-長度，01-類型（強制字段，表示廣播flag，廣播包必須包含該字段），05-值。由于廣播包最大只能為31個字節(jié)，它能定義的數(shù)據(jù)類型極其有限，像這里說的電量，GAP就沒有定義，因此要通過廣播方式把電量數(shù)據(jù)發(fā)出去，只能使用供應商自定義數(shù)據(jù)類型0xFF，即04FF590053，其中04表示長度，F(xiàn)F表示數(shù)據(jù)類型（自定義數(shù)據(jù)），0x0059是供應商ID（自定義數(shù)據(jù)中的強制字段），0x53就是我們的數(shù)據(jù)(設備雙方約定0x53就是表示電量，而不是其他意思)。

最終空中傳輸?shù)臄?shù)據(jù)包將變成：“AA D6BE898E 60 0E 3B75AB2A02E1 02010504FF5900 53 8EC7B2”

AA – 前導幀(preamble)

D6BE898E – 訪問地址(access address)

60 – LL幀頭字段(LL header)

0E – 有效數(shù)據(jù)包長度(payload length)

3B75AB2A02E1 – 廣播者設備地址(advertiser address)

02010504FF590053 – 廣播數(shù)據(jù)

8EC7B2 – CRC24值

有了PHY，LL和GAP，就可以發(fā)送廣播包了，但廣播包攜帶的信息極其有限，而且還有如下幾大限制：

無法進行一對一雙向通信（廣播是一對多通信，而且是單方向的通信）

由于不支持組包和拆包，因此無法傳輸大數(shù)據(jù)

通信不可靠及效率低下。廣播信道不能太多，否則將導致掃描端效率低下。為此，BLE只使用37(2402MHz) /38(2426MHz) /39(2480MHz)三個信道進行廣播和掃描，因此廣播不支持跳頻。由于廣播是一對多的，所以廣播也無法支持ACK。這些都使廣播通信變得不可靠。

掃描端功耗高。由于掃描端不知道設備端何時廣播，也不知道設備端選用哪個頻道進行廣播，掃描端只能拉長掃描窗口時間，并同時對37/38/39三個通道進行掃描，這樣功耗就會比較高。

而連接則可以很好解決上述問題，下面我們就來看看連接是如何將0x53發(fā)送出去的。

連接方式

到底什么叫連接(connection)？像有線UART，很容易理解，就是用線（Rx和Tx等）把設備A和設備B相連，即為連接。用“線”把兩個設備相連，實際是讓2個設備有共同的通信媒介，并讓兩者時鐘同步起來。藍牙連接有何嘗不是這個道理，所謂設備A和設備B建立藍牙連接，就是指設備A和設備B兩者一對一“同步”成功，其具體包含以下幾方面：

設備A和設備B對接下來要使用的物理信道達成一致

設備A和設備B雙方建立一個共同的時間錨點，也就是說，把雙方的時間原點變成同一個點

設備A和設備B兩者時鐘同步成功，即雙方都知道對方什么時候發(fā)送數(shù)據(jù)包什么時候接收數(shù)據(jù)包

連接成功后，設備A和設備B通信流程如下所示：

如上圖所示，一旦設備A和設備B連接成功（此種情況下，我們把設備A稱為Master或者Central，把設備B稱為Slave或者Peripheral），設備A將周期性以CI（connection interval）為間隔向設備B發(fā)送數(shù)據(jù)包，而設備B也周期性地以CI為間隔打開射頻接收窗口以接收設備A的數(shù)據(jù)包。同時按照藍牙spec要求，設備B收到設備A數(shù)據(jù)包150us后，設備B切換到發(fā)送狀態(tài)，把自己的數(shù)據(jù)發(fā)給設備A；設備A則切換到接收狀態(tài)，接收設備B發(fā)過來的數(shù)據(jù)。由此可見，連接狀態(tài)下，設備A和設備B的射頻發(fā)送和接收窗口都是周期性地有計劃地開和關，而且開的時間非常短，從而大大降低系統(tǒng)功耗并大大提高系統(tǒng)效率。

現(xiàn)在我們看看連接狀態(tài)下是如何把數(shù)據(jù)0x53發(fā)送出去的，從中大家可以體會到藍牙協(xié)議棧分層的妙處。

對開發(fā)者來說，很簡單，他只需要調用send(0x53)

GATT層定義數(shù)據(jù)的類型和分組，方便起見，我們用0x0013表示電量這種數(shù)據(jù)類型，這樣GATT層把數(shù)據(jù)打包成130053（小端模式?。?/p>

ATT層用來選擇具體的通信命令，比如讀/寫/notify/indicate等，這里選擇notify命令0x1B，這樣數(shù)據(jù)包變成了：1B130053

L2CAP用來指定connection interval（連接間隔），比如每10ms同步一次（CI不體現(xiàn)在數(shù)據(jù)包中），同時指定邏輯通道編號0004（表示ATT命令），最后把ATT數(shù)據(jù)長度0x0004加在包頭，這樣數(shù)據(jù)就變?yōu)椋?40004001B130053

LL層要做的工作很多，首先LL層需要指定用哪個物理信道進行傳輸（物理信道不體現(xiàn)在數(shù)據(jù)包中），然后再給此連接分配一個Access address（0x50655DAB）以標識此連接只為設備A和設備B直連服務，然后加上LL header和payload length字段，LL header標識此packet為數(shù)據(jù)packet，而不是control packet等，payload length為整個L2CAP字段的長度，最后加上CRC24字段，以保證整個packet的數(shù)據(jù)完整性，所以數(shù)據(jù)包最后變成：

AA – 前導幀(preamble)

0x50655DAB – 訪問地址(access address)

1E – LL幀頭字段(LL header)

08 – 有效數(shù)據(jù)包長度(payload length)

04000400 – ATT數(shù)據(jù)長度，以及L2CAP通道編號

1B – notify command

0x0013 – 電量數(shù)據(jù)handle

0x53 – 真正要發(fā)送的電量數(shù)據(jù)

0xF650D5 – CRC24值

雖然開發(fā)者只調用了 send(0x53)，但由于低功耗藍牙協(xié)議棧層層打包，最后空中實際傳輸?shù)臄?shù)據(jù)將變成下圖所示的模樣，這就既滿足了低功耗藍牙通信的需求，又讓用戶API變得簡單，可謂一箭雙雕！

AAAB5D65501E08040004001B130053D550F6

在理解了上面的知識后，我們可以進行下面的內容了。

藍牙廣播

低功耗藍牙一共有40個信道，頻段范圍從2402兆赫茲到2480兆赫茲，每兩兆赫茲一個信道，其中37、38、39是廣播信道，剩余的是數(shù)據(jù)信道。

藍牙廣播就是在這37,38,39三個信道上廣播數(shù)據(jù)，一個廣播數(shù)據(jù)包最長37個字節(jié)，其中有六個字節(jié)用作藍牙設備的mac地址，剩余的31個字節(jié)又被分為若干個廣播數(shù)據(jù)結構體,藍牙規(guī)范里面稱為ad structure。每一個廣播數(shù)據(jù)結構體有三部分組成，分別是結構體長度類型和內容。其中長度占用1字節(jié)，類型1字節(jié)，和若干個字節(jié)內容。這里面長度等于一加N(內容字節(jié)數(shù))。

下圖中共有兩個廣播數(shù)據(jù)結構體，第一個廣播數(shù)據(jù)結構體的長度為0x4，表示后面有四個字節(jié)屬于這個結構體。緊接著是第二個廣播數(shù)據(jù)結構體，長度為0x03，表示后面有三個字節(jié)屬于這個結構體。上面提到了一個廣播數(shù)據(jù)結構體最大可用的字節(jié)數(shù)為31個，如果沒有用完的話，系統(tǒng)會在后面自動補零，湊夠31個字節(jié)。

注意：藍牙廣播最多只能廣播31個字節(jié)的數(shù)據(jù)，如果要廣播的數(shù)據(jù)超過了31個字節(jié)，可以把一部分數(shù)據(jù)放到掃描響應里面。

上面提到了廣播數(shù)據(jù)結構體組成方式，如果我們要想知道這些廣播數(shù)據(jù)的具體含義，就必須知道每一個廣播數(shù)據(jù)結構體的廣播類型，廣播類型藍牙官網(wǎng)已經(jīng)制定了詳細的標準，我們可以在官網(wǎng)下載完整的AD type 進行查看。下圖是幾個比較常用的類型，比如009表示藍牙設備的名稱，0xa表示藍牙設備的發(fā)射功率，0xff為廠商自定義類型。我們知道了廣播數(shù)據(jù)結構體的類型，后面的數(shù)據(jù)內容是我們比較關注的，這些內容采用的是utf-8編碼，所以可以傳輸中文。下圖中的數(shù)據(jù)內容0x31 0x32 0x33 0x34 表示的字符串是"1234"。那么第一個廣播結構體所表示的含義就是指定了藍牙設備名稱為1234，第二個廣播數(shù)據(jù)結構體發(fā)射功率為8dbm。第三個廣告數(shù)據(jù)結構體是廠商自定義數(shù)據(jù)，其數(shù)據(jù)內容的含義由廠商決定。

掃描與響應

藍牙廣播大致可以分為如下四類：

可連接非定向可連接
定向不可連接
非定向可掃描
非定向可連接

非定向是大部分普通的藍牙設備采用的廣播方式

可連接定向呢主要用于已配對設備中的快速連接

不可連接非定向是藍牙信標或藍牙傳感器常用的廣播方式

可掃描非對象是在不可連接非對象的基礎上加入了掃描響應的功能，能夠通過掃描響應來承載更多的數(shù)據(jù)

這個表格總結出了這幾種廣播類型的功能。藍牙廣播是藍牙設備主動發(fā)射的一些數(shù)據(jù)，而掃描響應的是藍牙從機收到藍牙主機的掃描請求之后，回復給藍牙主機的數(shù)據(jù)，掃描響應的數(shù)據(jù)格式和藍牙廣播的數(shù)據(jù)格式完全一樣，不同的是廣播數(shù)據(jù)是主動發(fā)射的，而掃描響應的數(shù)據(jù)呢是在收到其他設備的掃描請求之后才會觸發(fā)的。

掃描響應數(shù)據(jù)和廣播數(shù)據(jù)格式是一樣的，掃描響應數(shù)據(jù)是非必需的，掃描響應數(shù)據(jù)可以作為廣播數(shù)據(jù)的補充，掃描響應需要一定的觸發(fā)條件。

服務與特性

以藍牙鼠標為例，我們來看一下它的服務和特性是如何實現(xiàn)的，在手機上打開名叫谷雨藍牙的微信小程序，搜索藍牙鼠標后點擊連接。連接成功后，展示的就是該設備的服務列表，一共有五個服務，每個服務上面的英文單詞是服務的名稱。

下面還有一行uuid，隨便點開一個服務，展開是該服務里面的特性，每一個特性由特性名稱，特性uuid和特性的訪問權限組成。一個藍牙設備里面可以包含若干個服務，一個服務里面包含若干個特性，每個特性里面又可以有讀寫通知等權限，每一個服務和特性都要有一個uuid。

uuid是藍牙組織定義的用于區(qū)分各個服務和特性的標識符，用戶可以自定義16 bit uuid，也可使用官方定義好的16bit uuid。uuid總長度是128bit，比如下面就是兩個標準的uuid。但是藍牙設計者考慮到128bit的uuid太長，使用起來不太方便。為了方便使用，藍牙組織定義了一些16位的uuid的基地址，可以與16位uuid進行拼接，形成128bit的uid。

數(shù)據(jù)傳輸

上面我們學習了藍牙服務和特性，我們知道了服務與特性。那么數(shù)據(jù)之間是怎么傳輸?shù)哪?，這里我們學習一下數(shù)據(jù)的傳輸，低功耗藍牙通信是基于一個個特性實現(xiàn)的，每一個特性可以被看作一個數(shù)據(jù)點，數(shù)據(jù)的收發(fā)都要依托于這些數(shù)據(jù)點。對數(shù)據(jù)點的操作方法有如下常用的五種類型：

read

write

write with no response，

notify

indicate

這幾種通信方式的區(qū)別，設備作為從機，手機作為主機

read操作，就是手機讀取設備中某個特性的值。

write操作就是手機修改設備中某個特性的值。

write with no response，與write操作類似，只不過寫完之后不需要設備回應，write操作則需要設備回應。

notify，操作是設備里面的數(shù)據(jù)發(fā)生變化之后，通知手機來取數(shù)據(jù)，需要在手機端訂閱相應的通知才有效。

indicate與notify操作類似，不同之處在于，indicate需要手機回應，notify則不需要。

上面部分內容來自于課程(https://www.bilibili.com/video/BV1ad4y1d7AM/)，如果大家感興趣，可以前去學習。

3.藍牙抓包分析

?電腦抓包

這里以windows為例，我們作為初學者，一般使用CC2540/nrf52840 usb dongle來抓取藍牙數(shù)據(jù)包，買板子后并且按照手冊安裝好環(huán)境后，更新驅動。利用平臺USB設備接入模塊接入藍牙模塊，并可連接對實物藍牙手環(huán)進行測試

打開wireshark就可以看到nrf sniffer的接口后，我們直接雙擊就可以抓包了。

開啟抓包后，使外圍設備開啟廣播模式。等待外圍設備廣播包穩(wěn)定后，點擊wireshark 中 Device列表外圍設備的mac地址，開啟中心設備進行掃描和連接，就可以抓取倆個設備之間的通信包。

注意：下圖中devcies下拉列表中沒有鼠標的mac地址，說明并不能抓取設備連接后通信過程，但是這里還是可以分析一下廣播和連接的過程。

廣播包中PDU的類型如下：

? 0000 ADV_IND：可連接通用連接廣播
??0001 ADV_DIRECT_IND：可連接定向連接（指定設備）廣播
??0010 ADV_NONCONN_IND：不可連接通用廣播
??0011 SCAN_REQ：掃描請求
??0100 SCAN_RSP：掃描響應
??0101 CONNECT_REQ：連接請求
??0110 ADV_SCAN_IND：可掃描通用廣播
??0111-1111 Reserved
??位[4:5]：保留
??位[6]：RxAdd
??位[7]：TxAdd
??位[8:13]：廣播數(shù)據(jù)長度 （最大為37 字節(jié)）
??位[14:15]：保留

BLE 連接過程中有三個重要的數(shù)據(jù)包：SCAN_REQ, SCAN_RSP 和 CONNECT_REQ(CONN_REQ又稱為CONNECT_IND)。SCAN_REQ：掃描請求，由主設備向從設備發(fā)出，目的是為了獲得從設備的響應以得到更多的從設備廣播數(shù)據(jù)信息（包括設備名字，或者服務UUID，及其它如廠家特定格式的信息（如硬件版本，軟件版本號，設備系列號等等）。

SCAN_RSP: 從設備對就主設備發(fā)起的SCAN_REQ的響應，作為廣播包的補充，從設備可以給主設備更多的廣播數(shù)據(jù)，比如說，有些設備在廣播包里面沒有設備名字，這個時候就可以把設備名字放在這個包里面發(fā)給主設備。

CONNECT_REQ(CONN_REQ又稱為CONNECT_IND)：主設備向從設備發(fā)出連接請求。至此連接建立完成（從設備不會響應這個請求），如果從設備沒有連接上面的問題的話，以后主從雙方會開始相互交換有效數(shù)據(jù)（基于GAP,GATT及SMP協(xié)議）或者交換空包。

BLE抽象出一個協(xié)議：Attribute protocol，該協(xié)議將這些“信息”以“Attribute（屬性）”的形式抽象出來，并提供一些方法，供遠端設備（remote device）讀取、修改這些屬性的值（Attribute value）。一般情況下，ATT 層用來定義用戶命令及命令操作的數(shù)據(jù)，當我們想要給設備發(fā)送惡意報文，這些操作需要在ATT協(xié)議層完成，這里我們需要重點關注一下ATT報文。

下圖中，實線包含的部分為ATT層。ATT報文由Attribute Opcode和Attribute Parameters組成。

ATT層是固定的CID，當L2CAP層的CID為0x4時，為ATT層。

ATT報文中的Opcode決定了后面的Parameters，例如后文中0x1b為Notify，那么后面的Parameters就為Attribute Handle和Attribute Value組成，我們在分析時需要重點關注Attribute Value的值。

上面在數(shù)據(jù)傳輸小節(jié)中已經(jīng)講解了Notify，Notify是當中心設備訂閱從設備相應服務時，從設備里面的數(shù)據(jù)發(fā)生變化后，從設備通知中心設備來取數(shù)據(jù)。下圖為opcode為Notification的ATT報文。

除了上述方法外，我們還可以使用藍牙適配器(電腦自帶也行)與藍牙調試工具進行抓包分析，使用方法位正常連接藍牙設備后，藍牙啟動調試工具就可以看到服務與特性，并且可以看到通信日志以及發(fā)送報文到設備。藍牙調試工具比較多，這里不進行推薦，百度搜索下載就行。

Linux系統(tǒng)抓包與上面相同，大多采用適配器與調試工具組合進行抓包分析，bluetoothd、hcitool和gatttool都是比較好用的工具。

手機抓包

當我們想要抓取手機app與藍牙設備的通信時，有時ble sniffer板子無法抓到通信包，那么就我們需要安裝adb環(huán)境進行藍牙調試，整個過程比較方便。

下面我以某智能手環(huán)為例，進行藍牙抓包分析。windows安裝好adb并配置環(huán)境后，下載adb驅動安裝包，打開ADB Driver Installer程序，通過數(shù)據(jù)線將手機與電腦連接。手機開發(fā)者選項中打開usb調試，此時出現(xiàn)密鑰并保存后，ADB Driver installer點擊refresh就會出現(xiàn)手機設備。