1. 背景

在2019年的某個月份，筆者的朋友給筆者送來了一個手環(huán)，讓筆者搞一搞。詳細詢問之后，筆者理清了具體情況：這個手環(huán)會收集佩戴者的步數并上報給公司，公司認為步數不夠的員工顯然是沒有業(yè)績的。一個好奇怪的判斷依據。

這個BLE智能手環(huán)就是本篇中的研究目標，由于當時的原版手環(huán)并不方便透露給大家，而且早已還給了朋友，所以我們選用了另一款手環(huán)。該手環(huán)是我們研究原版手環(huán)之后，根據其功能，專門訂制開發(fā)的一款手環(huán)，可以實現(xiàn)相同的效果，非常合適在這里進行展示。如下圖所示：

圖1-1 定制BLE智能手環(huán)

上圖即為我們定制的BLE智能手環(huán)(沒錯，我們也是DC0086的成員)。在本篇的結尾部分，我們會給一個小小的題目，感興趣的讀者可以嘗試解答并發(fā)到我們的郵箱中，我們會挑選3個愿意動手的讀者，送出上圖中的BLE智能手環(huán)。不要太在意手環(huán)上面的時間，因為長時間放置在貨架中，充電并開機之后，發(fā)現(xiàn)時間戳歸零了。

2. 理論分析

拿到手環(huán)之時，我們以為是手環(huán)可以連接WiFi，通過WiFi實時上傳步數等信息，也可能是通過4G/3G上傳數據。但是我們并沒有發(fā)現(xiàn)任何關于WiFi或者4G相關的設置選項，反而有很多關于BLE通信的設置，所以我們判斷這個智能手環(huán)應該是靠BLE進行數據通信。

既然已經確定了手環(huán)的通信方式，那么下一步就是確定每個佩戴者的步數是如何實時上報給服務器的。這里，我們做了兩種假設：1. 每個手環(huán)不停地廣播自身的數據信息，某個設備只要掃描一下附近的廣播數據就可以獲得所有附近佩戴者的步數；2.某個設備會以輪詢的方式和每個BLE智能手環(huán)建立連接，收集相關信息之后，斷開連接。

上文所述的某個收集信息的設備，與我們所了解的路由器有些類似。我們嘗試著以“藍牙路由器”為關鍵詞進行搜索，發(fā)現(xiàn)確實有一些類似的產品。原本我們打算買一個藍牙路由器回來研究，但仔細思考之后，其實不用買設備回來也能驗證我們上文中提到的兩個假設。如果是第一種上傳方法，我們直接抓一下手環(huán)的廣播包就可以了；如果是第二種上傳方法，用nRF connect連接手環(huán)，觀察所有的characteristic，看看是否有可疑數據即可完成分析。

3. 理論驗證

在本專題的第四篇中，我們提到了一個用于嗅探BLE通信的小設備，在本篇中我們將繼續(xù)使用這個BLE dongle進行分析。根據上一章的分析結論，我們先考察一下“假設一”是否正確。

首先，我們在SmartRF Packet Sniffer工具中，以通信包的類型為判斷依據設置過濾，然后開始抓包10秒鐘，如下圖：

圖2-1 第一次抓包截圖

記錄下這次抓包中出現(xiàn)的藍牙MAC地址，如圖中的右側紅框部分。

然后，我們拿著手環(huán)和電腦，換一個其他較遠的位置，重新抓包。對比兩次不同位置的抓包結果，即可發(fā)現(xiàn)某個設備的MAC地址在兩次抓包中都有出現(xiàn)，那么可以判斷該MAC地址即為BLE智能手環(huán)的MAC地址。

最后，我們以該MAC地址為依據進行過濾，進行第三次抓包，其結果如下圖所示：

圖2-2 第三次抓包截圖

上圖中的右側紅框部分即為廣播的數據。此時，手環(huán)中顯示的實際步數如下圖所示：

圖2-3 手環(huán)的實際步數

結合兩圖的情況，可以判斷出廣播的第9字節(jié)應該就是步數，一邊抓包，一邊走路，即可發(fā)現(xiàn)該字節(jié)在同步變化。

除了Dongle監(jiān)聽之外，我們在nRF connect中也可以看到該手環(huán)的廣播數據，某次nRF Connect掃描的結果如下圖所示，圖中我們可以看到Service UUID列表里有0x86DC，這并不是手環(huán)真實的Service，只是我們在定制手環(huán)時留下的DC0086的標志。

圖2-4 通過nRF connect工具查看

4. 偽造廣播數據

現(xiàn)在我們知道了手環(huán)如何上報自己統(tǒng)計的步數，接下來我們要嘗試發(fā)送偽造的廣播數據。

截至目前，我們只是使用了USB dongle用作BLE通信的嗅探設備，其實這個USB dongle也是可以刷寫固件的。在進行開發(fā)之前，先要確定USB dongle使用的芯片，并選擇相應的開發(fā)工具。在本專題第四篇中，我們介紹過USB dongle的核心是CC2540芯片，該芯片的工作原理圖如下：

圖4-1 CC2540工作原理圖

上圖中可以看到CC2540芯片選用了8051系列的CPU內核，所以我們選用了IAR For 8051作為IDE，由于我們不是專業(yè)的嵌入式開發(fā)工程師，相關知識就不多做介紹了。

在CC2540芯片開發(fā)包中，可以找到包含各種樣例的工程文件夾，如下圖：

圖4-2 IAR藍牙廣播工程項目

其中，就有一個滿足我們需求的藍牙廣播樣例程序。打開此工程，根據第3節(jié)的分析結果調整代碼，并編譯工程，如下圖，紅框中的內容就是我們需要廣播的數據。

圖4-3 IAR編譯工程

待編譯結束之后，我們需要將其刷寫覆蓋原本USB dongle的固件。在刷寫時，需要用cc debugger連接USB dongle和計算機，如下圖：

圖4-3 USB dongle通過cc debugger連接計算機

接下來使用SmartRF Flash Programmer刷寫固件(該軟件與上文中的抓包軟件是同一系列的)，并在刷寫時設置MAC地址，如下圖所示：

圖4-4 刷寫USB dongle固件

注意Location選擇Secondary，如上圖中紅框位置。芯片在生產時設置的MAC地址是保存在Primary中，我們無法更改此MAC地址。程序開發(fā)者設置的MAC地址保存在Secondary中，當存在Secondary Address時，Dongle優(yōu)先使用Secondary Address。固件刷寫完成之后，會按照廣播我們在程序中設置的步數。

最后，還有一個小說明：原本的USB dongle固件在Packet Sniffer \bin \general \firmware文件夾中，所以不用擔心固件被刷壞而變磚的情況。

5. 小結

本篇中，我們對一款BLE智能手環(huán)進行了分析，研究了手環(huán)如何實時上傳佩戴者步數，還修改了CC2540的樣例工程，實現(xiàn)了我們需要的廣播內容，由此對藍牙廣播數據有了更深入的認識。

在這里我們留下一個小問題：寫一個掃描并收集附近藍牙廣播的安卓小應用，展示MAC地址和廣播內容。?

期待著各位讀者把自己的應用發(fā)送到我們的郵箱：pwn@pwnmonkey.org，我們會從中挑選3個讀者，為其送出本篇中的BLE智能手環(huán)和USB dongle，以示鼓勵。

作者：Yimi Hu & Light @ PwnMonkeyLabs

【未來安全胖猴實驗室】專注于物聯(lián)網及其相關領域的安全研究，在三星、海康威視等廠商的設備中發(fā)現(xiàn)多個漏洞。團隊成員有多年移動安全及硬件安全從業(yè)經驗，積極從事于安全技術的分享和知識的科普，希望為安全行業(yè)的發(fā)展貢獻自己的力量。

總結

以上是生活随笔為你收集整理的8.0ble设备 android_【胖猴小玩闹】智能门锁与BLE设备安全Part 4：一次BLE智能手环的小玩闹...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。