BLE（四）嗅探工具

商业级的Ellisys BEX400侦听工具最为符合对BLE流量捕获及分析的要求，然而售价过于昂贵；

其次，作为开源硬件且配有混杂模式追踪的“超牙”设备——Ubertooth One拥有二次开发和嗅探已建立连接的蓝牙通信数据包的能力；

而淘宝购买的廉价CC2540开发板则作为最佳替补方案。

0x1 低功耗蓝牙SOC

低功耗蓝牙推出以来，众多厂商根据标准规范实现了不同的解决方案，包括TI的CC2540\2541、北欧Nordic的nRF51822、CSR的1000\1001、Quintic的QN9020\9021（现在被NXP收购）、Broadcom的BCM20732等。其中，在开发者当中比较知名的是TI的CC254x系列和Nordic的NRF51822，并且这两款产品当有着自己的开发板和用于嗅探的调试工具。。

0x11 CC2540

德州仪器的CC2540，是一款高性价比、低功耗的片上系统（SOC）解决方案，适合蓝牙低功耗应用。它包含了一个8051内核的RF收发器，可编程闪存，8KB RAM和其他功能强大的配套特征及外设。CC2540有两种版本：CC2540F128 / F256，分别为128和256 KB的闪存，结合TI的低功耗蓝牙协议栈，CC2540F128 / F256形成了市场上最灵活，性价比也最高的单模式蓝牙BLE解决方案。
CC2540 USB Dongle的实物图如下，它可以配合TI的PacketSniffer软件实现对BLE无线抓包：

实际上，任意包含CC2540芯片的开发板都能实现BLE流量嗅探的功能。不过，TI官方并没有将侦听BLE的源代码放出，仅提供了烧写到USB Dongle的固件

在这个基础上，如果想要实现更多的功能，比如监听指定范围内所有的低功耗蓝牙设备的流量，就有必要对其进行逆向或者自己完全重写个程序。。

优点：

• 价格便宜，单个的USB Dongle淘宝价格60元左右，整套价格在200~400左右
• 配合官方的PacketSniffer程序，可以实现BLE流量嗅探

缺点：

• 程序界面比较简陋，无法很好的展示出数据包中的层级关系
• 本身是作为开发环节中的调试过程，作为逆向分析工具不够亲切。必须要事先在3个广播信道中指定一个进行监听，若恰好在该信道下有设备完成配对连接，方可追踪到后续的通信数据包，整个嗅探过程中存在较大的随机性和不确定性

使用：

• CC2540需事先刷入sniffer固件包（淘宝购买时可选）
• 安装PacketSniffer与驱动（只有win版本）
• 选择bluetooth low energy
• 开始抓包（只可选37、38、39广播信道其中之一，但只有三分之一的概率能捕捉到通信数据包，推测应该是选择信号最好的一个，如：主设备在三个信道进行广播，从设备发起响应，最后选择最先收到响应的信道）
  • 绿色为广播包，initA为初始连接包，如果通信信道与设置不对则停在初始连接包
  • 黄色为通信数据包，可多次抓包尝试，如断开手机蓝牙后重新给设备发送控制指令（不用填initA地址）

数据包类型：

M -> S  主机到从机  手机到ble固件

S -> M  从机到主机

广播包：

初始连接包：

连接事件：

请求更新参数包：

接受请求参数：

result 0表示接受，1表示拒绝

重新设置更新参数：

write写：

主机监听：

监听到：（从机返回）

0x12 NRF51822

挪威Nordic Semiconductor（简称Nordic）公司的nRF51822，是一款多协议ARM内核蓝牙4.0低功耗/ 2.4GHz 专用RF的单芯片解决方案。它基于Cortex-M0 内核，配备16kB RAM，可编程闪存，提供128 KB和 256 KB Flash两种版本供用户选择。

nRF51822 USB Dongle及开发板套件如下所示：

刷入以下固件，配合官方的BLE sniffer程序，即可实现蓝牙流量的嗅探功能

不同与cc2540的Packet Sniffer，该程序无需事先在3个广播信道中指定其一进行守候，只要指定要监听的设备，就会自动进行追踪，并能够配合Wireshark解析BLE数据包，可以很直观的显示出内部的层级关系和各字段含义。比较遗憾的是，实际使用发现它并没有CC2540 USB Dongle稳定，经常会抓不到后面数据通信的网络包，不过这一问题应该是可以通过优化算法得到解决的，但需要对官方的固件进行逆向或自己根据Nordic公司提供的BLE协议栈重写代码。。

优点：

• 价格便宜，USB Dongle淘宝价70元左右，整套开发板售价约200软妹币上下
• 无需事先在3个广播信道中指定其一进行守候，只要指定要监听的设备，就会自动进行追踪
• 官方提供的BLE Sniffer程序可配合Wireshark工具对嗅探到的低功耗蓝牙数据包进行解析，能够很直观的显示出内部的层级关系和各字段含义

缺点：

• 不用指定广播信道，确实操作起来比较方便，但与之相对的是经常无法抓到后面的通信数据包。无论是作为开发用的调试工具，还是分析用的嗅探工具，都不够理想

0x2 商业侦听工具

0x21 Frontline BPA® 600

Frontline Test Equipment——“前线测试设备”（简称“前线”，Frontline），主要是针对各种各样的协议所做的一个“协议分析器”。“前线”系统的销售策略是“卖硬件，送软件”，而软件自然是和硬件相关联的，其侦听范围包括SCADA系统、RS-232串口通信、Ethernet以太网通信、ZigBee网络通信，以及蓝牙网络技术。Frontline旗下的BPA® 600双模蓝牙协议分析仪，能够把从空中获取到的基础速率/ 增强数据速率（BR/EDR）的传统蓝牙无线通信和低功耗蓝牙无线通信数据同时直观的显示出来。

优点：

• 无角色指定链路抓取意味着在初始化设置时不再需要指定哪个设备是主设备（master），哪个设备是从设备（slave）
• 能够同时可视化的监视低功耗蓝牙技术所使用的三个广播信道
• 同时抓取和解密多条蓝牙链路
• 链路密钥可自动从第三方软件或调试工具导入到BPA 600
• 支持蓝牙SIG组织发布的所有的协议和应用层协议，完全支持蓝牙4.1版本

缺点：

• 十分昂贵，官网上虽并未公布具体的价格信息，需要与对方进行联系，但淘宝价格在15万左右
• 需要捕获到蓝牙的“连接建立”过程，对于已经建立好连接的蓝牙网络，无法从一个正在处理的进程中，嗅探到这个“微微网”里面的通信数据包

0x22 Ellisys BEX400

Ellisys公司的BLuetooth Explorer 400（简称“BEX400”），是个独特的蓝牙数据通信捕获系统。它使用了一个wideband的接收器，能够同时侦听蓝牙整个79MHz的所有频谱。通过这种无线接入方法，嗅探蓝牙数据包以及对蓝牙活动的评估变得很容易。在BEX400强大的宽带接收能力支持下，我们能够同时捕获蓝牙的所有活动，且无需指定“蓝牙设备地址”信息。此外，该设备在捕获一个“微微网”中的蓝牙通信数据时，既可以是在连接建立前，也可以在连接建立后

优点：

• 对于BLE的流量捕获没有必须在建立连接前就开始嗅探的限制
• 能够同时侦听蓝牙的所有信道，且无需指定“蓝牙设备地址”信息

缺点：

• 价格极其昂贵
• 除价格外，几乎完全符合需求，暂未发现明显缺点

0x3 开源侦听工具Ubertooth

“超牙项目”（Project Ubertooth）是一个开源的硬件项目，由Great Scott Gadgets团队的Michael Ossmann开发。超牙的硬件系统，目前处于版本为1的阶段，称为“超牙一号”（Ubertooth One）。通过这个工具，可以创建属于自己的“传统蓝牙”和“低功耗蓝牙”底层通信数据包捕获工具。

此外，Ubertooth的固件源代码，可以直接从github：https://github.com/greatscottgadgets/ubertooth下载到最新的发布版。

优点：

• 售价约120美元，比较亲民
• 本身是一个开源的硬件和软件工程，其设计目的就是用来进行蓝牙网络的嗅探，便于研究员和黑客使用
• 针对不同的蓝牙规范，具有不同的应对工具，支持传统蓝牙和低功耗蓝牙两种数据包的捕获
• 能够在混杂模式下进行跟踪，通过ubertooth-btle程序对捕获的数据包进行识别和匹配，进而确定“访问地址”、“循环冗余校验”初始值、“跳转间隔”、“跳转增量”等，并还原出数据包的值

缺点：

• 说是支持“传统蓝牙”，但其实只能捕获“基本速率蓝牙”在网络中的活动，并不支持后来的“增强速率蓝牙”在规范改进后的设备。不过这与我们的工作没有太大联系，主要关注的应是低功耗蓝牙

​

BLE（三）APP开发步骤

 Android系统自4.3版本开始，引入了对BLE的支持，详见Bluetooth Low Energy。通过浏览当中的信息，我们可以得知在app开发环节，需要做到如下几件事情：

1. BLE相关权限声明

 2. 操作蓝牙之前，判断系统是否支持BLE

3. 获取本机的蓝牙适配器，BluetoothAdapter的获取依赖于bluetoothManager.getAdapter()实现

4. 发intent通知系统打开蓝牙

5. 使用startLeScan()函数获取外围设备，并实现BluetoothAdapter.LeScanCallback方法接受扫描结果

6. 调用connectGatt方法对设备进行连接，里面的BluetoothGattCallback对象用于交付操作结果给客户端。如果连接成功将返回BluetoothGatt实例，该实例是进行蓝牙控制的基础

7. 成功建立连接后，便可对attributes（属性，参考前面的BLE协议栈）进行读写。利用getService、getCharacteristics获取外围设备的service和characteristic，对于其中支持写的characteristic在写入相应的数据，可实现外围设备的控制

了解BLE app的开发步骤后，进行逆向时思路也就清晰了许多。首先，可以通过startLeScan、LeScanCallback等方法定位到扫描BLE外围设备的相关代码段；然后，根据connectGatt、BluetoothGattCallback等api锁定设备连接的相关函数，并找到指令交互部分，最后梳理出整个控制流程。

BLE（二）信道&数据包&协议栈格式

参考低功耗蓝牙（BLE）安全初探

0x1 信道

BLE的物理通道即“频道，分别是‘f=2402+k*2 MHz, k=0, … ,39’，带宽为2MHz”的40个RF Channel。

其中，有3个信道是advertising channel（广播通道），分别是37、38、39，用于发现设备（Scanning devices）、初始化连接（initiating a connection）和广播数据（broadcasting date）；

剩下的37个信道为data channel（数据通道），用于两个连接的设备间的通讯。

0x2 BLE数据包格式

在低功耗蓝牙规范中，分广播报文和数据报文这两种。设备利用广播报文发现、连接其它设备，而在连接建立之后，便开始使用数据报文。无论是广播报文还是数据报文，链路层只使用一种数据包格式，它由“前导码”（preamble）、“访问码”（access code）、”有效载荷“和”循环冗余校验“（Cyclical Redundancy Check，CRC）校验码组成。其中，”访问码“有时又称为”访问地址“（access address）

1. Preamble
   1个字节长度，接受中用于频率同步、数据速率同步、自动增益控制调整，固定为01010101或者10101010序列
2. Access Address
   4个字节长度，广播报文接入地址为：0x8E89BED6，数据报文接入地址为：32bits随机数
3. PDU
   1. 广播报文（见协议BLUETOOTH SPECIFICATION Version 4.0 [Vol 6] Part B 2.3）
      
      1. PDU Type：有效载荷内容的类型，通过这一字段确定该数据包是一个”通告“还是”扫描请求“或”响应“等
         
         
      2. RFU 保留位
      3. TxAdd：发送地址字段
      4. RxAdd：接收地址字段
      5. Payload Length：用来表示”有效载荷数据“（payload data）的长度，不包括头部内容
   2. 数据报文（见协议BLUETOOTH SPECIFICATION Version 4.0 [Vol 6] Part B 2.4）

1. LLID（逻辑链路ID）：0x01表示该数据包是一个帧的延续内容，或者这是一个空的“逻辑链路控制及适配协议”数据包；0x02表示一个“逻辑链路控制及适配协议”数据包的开始；0x03表示这是一个“逻辑链路控制”数据包的内容
2. NESN：下一个期望的序列号，用于对接收到的数据包进行确认
3. MD：更多数据字段，主要是为了说明发送方是否还有要发给接收者的数据
4. RFU 保留位
5. Payload Length：用以表示包含“信息完整性校验码”（Message Integrity Check，MIC）在内的“有效载荷数据”的长
   度

CRC
3个字节长度，“循环冗余校验”（Cyclical Redundancy Check，CRC），可检查数据的正确性

0x3 BLE协议栈

BLE协议栈的结构图如下所示：

各个结构简述：

• PHY： 使蓝牙可以使用2.4GHz频道，并且能自适应的跳频。
• LL层： 控制设备处于 准备、广播、监听、初始化、连接等五个状态。
• HCI层： 向上为主机提供软件应用程序接口，对外为外部硬件提供控制接口。
• L2CAP层： 对传输数据实行封装。
• SM层： 提供主机和客机的配对和密钥分发，实现安全连接和数据交换。
• ATT层： 对数据主机或客机传入的指令进行指令搜索处理，
• GATT层： 接收和处理主机或客机的指令信息，并将指令打包成合适的profile。
• GAP层： 向上提供API，向下合理分配各个层工作。

0x31 Physical Layer

任何一个通信系统，首先要确定的就是通信介质（物理通道，Physical Channel），BLE也不例外。在BLE协议中，“通信介质”的定义是由Physical Layer（其它通信协议也类似）负责。

Physical Layer是这样描述BLE的通信介质的：

由于BLE属于无线通信，则其通信介质是一定频率范围下的频带资源（Frequency Band）；
BLE的市场定位是个体和民用，因此使用免费的ISM频段（频率范围是2.400-2.4835 GHz）；
为了同时支持多个设备，将整个频带分为40份，每份的带宽为2MHz，称作RF Channel。

所以经过上面的定义之后，可以推测出BLE的物理通道，即“频道分别是‘f=2402+k*2 MHz, k=0, … ,39’，带宽为2MHz”的40个RF Channel。其中，有3个信道是advertising channel（广播通道），分别是37、38、39，用于发现设备（Scanning devices）、初始化连接（initiating a connection）和广播数据（broadcasting date）；剩下的37个信道为data channel（数据通道），用于两个连接的设备间的通讯。

0x32 Link Layer

Link Layer用于控制设备的射频状态，设备将处于Standby（待机）、Advertising（通告）、Scanning（扫描）、Initiating（初始化）、Connection（连接）这五种状态中的一种。

• 待机状态（Standby State）：此时即不发送数据，也不接收数据，对设备来所也是最节能的状态；
• 通告状态（Advertising State）：通告状态下的设备一般也被称为“通告者”（Advertiser），它会通过advertising channel（广播通道）周期性发送数据，广播的数据可以由处于Scanning state或Initiating state的实体接收；
• 扫描状态（Scanning State）：可以通过advertising channel（广播通道）接收数据的状态，该状态下的设备又被称为“扫描者”（Scanner）。此外，根据advertiser所广播的数据类型，有些Scanner还可以主动向Advertiser请求一些额外数据；
• 初始化状态（Initiating State）：和Scanning State类似，不过是一种特殊的状态。Scanner会侦听所有的advertising channel，而Initator（初始化者）则只侦听某个特定设备的的广播，并在接收到数据后，发送连接请求，以便和Advertiser建立连接；
• 连接状态（Connection State）：由Initiating State或Advertising State自动切换而来，处于Connection State的双方，分别有两种角色。其中，Initiater方被称为Mater（主设备），Advertiser方则称作Slave（从设备）。

0x33 HCI

主机控制接口层（Host Controller Interface，简写 HCI）：定义Host（主机）和Controller（控制器）之间的通信协议，这一层可以是软件或者硬件接口，如UART、SPI、USB等。

0x34 Generic Access Profile（GAP）

前面Link Layer虽然对连接建立的过程做了定义，但它并没有体现到Application（或者Profile）层面，而GAP则是直接与应用程序或配置文件通信的接口，它实现了如下功能：

• 定义GAP层的蓝牙设备角色（role）
  • Broadcaster（广播者）：设备正在发送advertising events
  • Observer（观察者）：设备正在接收advertising events
  • Peripheral（外设）：设备接受Link Layer连接（对应Link Layer的slave角色）
  • Central（主机）：设备发起Link Layer连接（对应Link Layer的master角色）
• 定义GAP层的用于实现各种通信的操作模式（Operational Mode）和过程（Procedures）
  • Broadcast mode and observation procedure，实现单向的、无连接的通信方式
  • Discovery modes and procedures，实现蓝牙设备的发现操作
  • Connection modes and procedures，实现蓝牙设备的连接操作
  • Bonding modes and procedures，实现蓝牙设备的配对操作
• 定义User Interface有关的蓝牙参数，包括蓝牙地址、蓝牙名称、蓝牙的PIN码等
• Security相关的定义。

0x35 Logical Link Control and Adaptation Protocol（L2CAP Protocol）

逻辑链路控制及自适应协议层（Logical Link Control and Adaptation Protocol）：为上层提供数据封装服务，允许逻辑上的点对点数据通信。

0x36 Security Manager（SM）

Security Manager负责BLE通信中有关安全的内容，包括配对（pairing,）、认证（authentication）和加密（encryption）等过程。

0x37 Attribute protocol（ATT）

在BLE协议栈中，Physical Layer负责提供一系列的Physical Channel；基于这些Physical Channel，Link Layer可在两个设备之间建立用于点对点通信的Logical Channel；而L2CAP则将这个Logical Channel换分为一个个的L2CAP Channel，以便提供应用程序级别的通道复用。到此之后，基本协议栈已经构建完毕，应用程序已经可以基于L2CAP欢快的run起来了。

谈起应用程序，就不得不说BLE的初衷——物联网。物联网中传输的数据和传统的互联网有什么区别呢？抛开其它不谈，物联网中最重要、最广泛的一类应用是：信息的采集。

这些信息往往都很简单，如温度、湿度、速度、位置信息、电量、水压、等等。
采集的过程也很简单，节点设备定时的向中心设备汇报信息数据，或者，中心设备在需要的时候主动查询。

基于信息采集的需求，BLE抽象出一个协议：Attribute protocol，该协议将这些“信息”以“Attribute（属性）”的形式抽象出来，并提供一些方法，供远端设备（remote device）读取、修改这些属性的值（Attribute value）。

Attribute Protocol的主要思路包括：

1. 基于L2CAP，使用固定的Channel ID
2. 采用client-server的形式。提供信息（以后都将其称为Attribute）的一方称作ATT server（一般是那些传感器节点），访问信息的一方称作ATT client。
3. 一个Attribute由Attribute Type、Attribute Handle和Attribute Value组成。
   1. Attribute Type用以标示Attribute的类型，类似于我们常说的“温度”、“湿度”等人类可识别的术语，通过UUID进行区分。
   2. Attribute Handle是一个16-bit的数值，用作唯一识别Attribute server上的所有Attribute。Attribute Handle的存在有如下意义：
      1. 一个server上可能存在多个相同type的Attribute，显然，client有区分这些Attribute的需要。
      2. 同一类型的多个Attribute，可以组成一个Group，client可以通过这个Group中的起、始handle访问所有的Attributes。
   3. Attribute Value代表Attribute的值，可以是任何固定长度或者可变长度的octet array。
4. Attribute能够定义一些权限（Permissions），以便server控制client的访问行为，包括：
   1. 访问有关的权限（access permissions），Readable、Writeable以及Readable and writable；
   2. 加密有关的权限（encryption permissions），Encryption required和No encryption required；
   3. 认证有关的权限（authentication permissions），Authentication Required和No Authentication Required；
   4. 授权有关的权限（authorization permissions），Authorization Required和No Authorization Required。
5. 根据所定义的Attribute PDU的不同，client可以对server有多种访问方式，包括：
   1. Find Information，获取Attribute type和Attribute Handle的对应关系；
   2. Reading Attributes，有Read by type、Read by handle、Read by blob（只读取部分信息）、Read Multiple（读取多个handle的value）等方式；
   3. Writing Attributes，包括需要应答的writing、不需要应答的writing等。

0x38 Generic Attribute profile（ GATT）

ATT之所以称作“protocol”，是因为它还比较抽象，仅仅定义了一套机制，允许client和server通过Attribute的形式共享信息。至于具体共享哪些信息，ATT并不关心，这是GATT（Generic Attribute Profile）的主场。GATT相对ATT只多了一个‘G‘，然含义却大不同，因为GATT是一个profile（更准确的说是profile framework）。

由上图可知，GATT中的三个要素Profile、Service、Characteristic以及他们的层级关系。值得注意的是，“Profile”是基于GATT所派生出的真正的Profile，乃SIG蓝牙技术联盟对一些同范畴内的Service打包后的集合，如电池、心率、血压等，可参照官方Profiles Overview，对分析并无大用。

Service和Characteristic则是比较重要的，Service可以理解为PHP中的“类”、功能对象的集合。Characteristic可以理解为PHP的“函数”，是GATT中具体的功能对象，每个Service都可以包含一个或多个Characteristic（特征）。Characteristic是GATT profile中最基本的数据单位，由一个Properties、一个Value、一个或者多个Descriptor组成。

以上除“Profile”外的每一个定义，Service、Characteristic、Characteristic Properties、Characteristic Value、Characteristic Descriptor等等，都是作为一个Attribute存在的，具备前面所描述的Attribute的所有特征：Attribute Handle、Attribute Types、Attribute Value和Attribute Permissions。

在理解了GATT后，就已经能够分析或是“黑掉”一些BLE设备了。这里拿小米手环做例子，当LightBlue连上小米手环后，可以看到一个名为FEE7的UUID，如下所示：

其中，FEE7是一个私有Service的UUID，里面的0xFE**则是私有Characteristic的UUID。下面的Immediate Alert 显示出了名称，代表其不是小米私有的Service，而是官方公开定义的Service。点击进入这个Characteristic，看到它的UUID为2A06。然后我们到蓝牙官网定义的列表Characteristics搜索2A06，进入Characteristic的详情页面。

于是，该Characteristic操作定义非常明确了。点击“Write new value”，可以写入新的值。若写入1或2，则可以引起手环的震动。

​