1
背景
在2019年的某个月份，笔者的朋友给笔者送来了一个手环，让笔者搞一搞。详细询问之后，笔者理清了具体情况：这个手环会收集佩戴者的步数并上报给公司，公司认为步数不够的员工显然是没有业绩的。好一个奇怪判断依据。
这个BLE智能手环就是本篇中的研究目标，由于当时的原版手环并不方便透露给大家，而且早已还给了朋友，所以我们选用了另一款手环。该手环是我们研究原版手环之后，根据其功能，专门订制开发的一款手环，可以实现相同的效果，非常合适在这里进行展示。如下图所示：
图1-1 定制BLE智能手环
上图即为我们定制的BLE智能手环（没错，我们也是DC0086的成员）。在本篇的结尾部分，我们会给一个小小的题目，感兴趣的读者可以尝试解答并发到我们的邮箱中，我们会挑选3个愿意动手的读者，送出上图中的BLE智能手环。不要太在意手环上面的时间，因为长时间放置在货架中，充电并开机之后，发现时间戳归零了。
2
理论分析
拿到手环之时，我们以为是手环可以连接WiFi，通过WiFi实时上传步数等信息，也可能是通过4G/3G上传数据。但是我们并没有发现任何关于WiFi或者4G相关的设置选项，反而有很多关于BLE通信的设置，所以我们判断这个智能手环应该是靠BLE进行数据通信。
既然已经确定了手环的通信方式，那么下一步就是确定每个佩戴者的步数是如何上报给服务器的。这里，我们做了两种假设：1. 每个手环不停地广播自身的数据信息，某个设备只要扫描一下附近的广播数据就可以获得所有附近佩戴者的步数；2.某个设备会以轮询的方式和每个BLE智能手环建立连接，收集相关信息之后，断开连接。
上文所述的某个收集信息的设备，与我们所了解的路由器有些类似。我们尝试着以“蓝牙路由器”为关键词进行搜索，发现确实有一些类似的产品。原本我们打算买一个蓝牙路由器回来研究，但仔细思考之后，其实不用买设备回来也能验证我们上文中提到的两个假设。如果是第一种上传方法，我们直接抓一下手环的广播包就可以了；如果是第二种上传方法，用nRF connect连接手环，观察所有的characteristic，看看是否有可疑数据即可完成分析。
3
理论验证
在本专题的第四篇中，我们提到了一个用于嗅探BLE通信的小设备，在本篇中我们将继续使用这个BLE dongle进行分析。根据上一章的分析结论，我们先考察一下“假设一”是否正确。
首先，我们在SmartRF Packet Sniffer工具中，以通信包的类型为判断依据设置过滤，然后开始抓包10秒钟，如下图：
图3-1 第一次抓包截图
记录下这次抓包中出现的蓝牙MAC地址，如图中的右侧红框部分。
然后，我们拿着手环和电脑，换一个其他较远的位置，重新抓包。对比两次不同位置的抓包结果，即可发现某个设备的MAC地址在两次抓包中都有出现，那么可以判断该MAC地址即为BLE智能手环的MAC地址。
最后，我们以该MAC地址为依据进行过滤，进行第三次抓包，其结果如下图所示：
图3-2 第三次抓包截图
上图中的右侧红框部分即为广播的数据。此时，手环中显示的实际步数如下图所示：
图3-3 手环的实际步数
结合两图的情况，可以判断出广播的第9字节应该就是步数，一边抓包，一边走路，即可发现该字节在同步变化。
除了Dongle监听之外，我们在nRF connect中也可以看到该手环的广播数据，某次nRF Connect扫描的结果如下图所示，图中我们可以看到Service UUID列表里有0x86DC，这并不是手环真实的Service，只是我们在定制手环时留下的DC0086的标志。
图3-4 通过nRF connect工具查看
4
伪造广播数据
现在我们知道了手环如何上报自己统计的步数，接下来我们要尝试发送伪造的广播数据。
在本专题之前的篇章中，曾介绍过nRF connect可以发送BLE通信的广播包。但受限于Android系统本身，在nRF connect发送的BLE广播包中，可以设置的各种广播内容并不多，尤其是不能设置广播时使用的MAC地址。这里我们需要一个自由度更高的设备，用于定制我们想要发出的广播内容，并修改发送广播时使用的MAC地址。
截至目前，我们只是使用了USB dongle用作BLE通信的嗅探设备，其实这个USB dongle也是可以刷写固件的。在进行开发之前，先要确定USB dongle使用的芯片，并选择相应的开发工具。在本专题第四篇中，我们介绍过USB dongle的核心是CC2540芯片，该芯片的工作原理图如下：
图4-1 CC2540工作原理图
上图中可以看到CC2540芯片选用了8051系列的CPU内核，所以我们选用了IAR For 8051作为IDE，由于我们不是专业的嵌入式开发工程师，相关知识就不多做介绍了。
在CC2540芯片开发包中，可以找到包含各种样例的工程文件夹，如下图：
图4-2 IAR蓝牙广播工程项目
其中，就有一个满足我们需求的蓝牙广播样例程序。打开此工程，根据第3节的分析结果调整代码，并编译工程，如下图，红框中的内容就是我们需要广播的数据。
图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地址。程序开发者设置的MAC地址保存在Secondary中，当存在Secondary Address时，Dongle优先使用Secondary Address。固件刷写完成之后，会按照广播我们在程序中设置的步数。
最后，还有一个小说明：原本的USB dongle固件在Packet Sniffer \bin \general \firmware文件夹中，所以不用担心固件被刷坏而变砖的情况。
5
小结
本篇中，我们对一款BLE智能手环进行了分析，研究了手环如何实时上传佩戴者步数，还修改了CC2540的样例工程，实现了我们需要的广播内容，由此对蓝牙广播数据有了更深入的认识。
在这里我们留下一个小问题：写一个扫描并收集附近蓝牙广播的安卓小应用，展示MAC地址和广播内容。
期待着各位读者把自己的应用发送到我们的邮箱：pwn@pwnmonkey.org，我们会从中挑选3个读者，为其送出本篇中的BLE智能手环和USB dongle，以示鼓励。
作者：Light & Yimi Hu @ PwnMonkeyLabs
