深入解析BLE空口报文抓取：从GAP广播到LESC安全通信全流程
1. BLE空口报文抓取基础
想要分析BLE设备间的通信过程，抓取空口报文是最直接有效的方法。这就像在两个人对话时，用录音设备记录下他们的每一句话。不过BLE通信使用的是2.4GHz无线频段，我们无法直接用耳朵听到这些"对话"，需要借助专门的工具。
传统有线网络抓包常用的Wireshark和tcpdump工具，在BLE场景下需要配合专用硬件才能使用。原因在于：
- 有线网络依赖交换机/路由器转发数据包
- BLE设备直接通过无线电波通信，没有中间转发设备
广播报文相对容易抓取，因为BLE设备会主动向周围所有设备发送广播数据。这就像一个人在广场上公开演讲，任何人都能听到他的声音。而连接状态下的报文则像两个人在私密通话，只有通信双方能听懂内容，其他设备会自动忽略这些数据。
2. 抓包工具与硬件准备
2.1 常用抓包方案对比
目前主流的BLE抓包方案主要有两种：
| 方案类型 | 代表工具 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 低成本方案 | Wireshark + Nordic nRF Sniffer | 成本低(约$20)、易获取 | 功能相对基础 | 日常开发调试 |
| 专业方案 | Ellisys蓝牙分析仪 | 功能强大、支持高级分析 | 价格昂贵(约$20万) | 专业协议分析 |
2.2 Nordic nRF Sniffer使用指南
对于大多数开发者，我推荐使用Nordic的nRF Sniffer方案。具体配置步骤如下：
硬件准备：
- nRF52840 Dongle或nRF52 DK开发板
- 一台安装好驱动程序的电脑
烧录Sniffer固件：
# 使用nrfjprog烧录固件示例 nrfjprog --program sniffer_nrf52840dongle_nrf52840_7cc811f.hex --sectorerase nrfjprog --reset软件配置：
- 安装Wireshark(3.4.4或更高版本)
- 安装nRF Sniffer插件
- 选择正确的COM端口开始抓包
基本过滤命令：
btle.advertising_address # 只显示广播包 btatt.opcode == 0x12 # 过滤特定ATT操作码 btle.length > 0 # 排除空数据包3. BLE通信全流程解析
3.1 GAP广播与连接建立
当BLE设备上电后，首先会进入广播状态。通过Wireshark抓取的ADV_IND广播包通常包含这些关键信息：
- 广播地址：设备的MAC地址
- Flags：发现模式(如LE General Discoverable)
- Service UUIDs：设备支持的服务类型
- 厂商自定义数据：如iBeacon信息
连接建立过程由Central设备发起，发送CONNECT_IND报文。这个报文中最重要的部分是连接参数：
- connInterval(7.5ms-4s)：决定通信频率
- connSlaveLatency(0-499)：允许从设备跳过的连接事件
- connSupervisionTimeout(100ms-32s)：连接超时时间
3.2 链路层控制协议
连接建立后，设备会交换能力信息并协商通信参数。关键的控制过程包括：
功能交换(Feature Exchange)：
- 协商支持的PHY(1M/2M/Coded)
- 确定是否支持数据长度扩展
数据长度更新：
// 典型的数据长度更新请求 LL_LENGTH_REQ { MaxRxOctets = 251, MaxRxTime = 2120, MaxTxOctets = 251, MaxTxTime = 2120 }- PHY更新：
- 1M PHY：兼容性好，速率低(1Mbps)
- 2M PHY：速率高(2Mbps)，兼容性稍差
3.3 GATT服务发现与数据交互
GATT通信是BLE应用开发的核心，主要流程包括：
- MTU交换：协商最大传输单元(默认23字节，最大可达247字节)
- 服务发现：
- 通过Primary Service Discovery查找服务
- 使用Include Discovery查找包含的服务
- 特征值操作：
- 读取(Read)：获取当前值
- 写入(Write)：修改值
- 通知(Notify)：服务端主动推送数据
典型的心率服务交互示例：
# 伪代码示例 hrm_service = discover_service(0x180D) # 心率服务UUID hrm_char = discover_characteristic(hrm_service, 0x2A37) # 心率测量特征 enable_notification(hrm_char) # 启用通知 def callback(value): print(f"当前心率: {parse_heart_rate(value)}") set_notification_callback(hrm_char, callback)4. LESC安全通信解析
4.1 配对流程与安全机制
BLE 4.2引入的LE Secure Connections(LESC)采用ECDH密钥交换算法，安全性显著提升。配对过程分为三个阶段：
配对特性交换：
- 协商IO能力(如是否支持输入PIN码)
- 确定认证要求
认证与加密：
- 交换公钥
- 进行MITM保护(如Numeric Comparison)
- 生成LTK(长期密钥)
密钥分发：
- 分发IRK(身份解析密钥)
- 分发CSRK(连接签名密钥)
4.2 解密加密报文的方法
由于LESC的安全特性，常规抓包工具无法直接解密通信内容。需要通过以下方式之一实现解密：
- Debug模式： 修改设备固件使用预置的调试密钥对
// Nordic SDK中的调试密钥设置 #define LESC_DEBUG_MODE 1 const uint8_t LESC_DEBUG_KEY[32] = {0x3f,0x49,...,0xbd};私钥导入： 专业分析仪支持导入设备私钥
Passkey捕获： 对于LE Legacy Pairing，可以在Wireshark中输入配对码
4.3 典型配对过程分析
以Just Works配对为例的报文交互流程：
Pairing Request/Response：
- 协商配对方法(AuthReq)
- 确定密钥分发需求
Public Key Exchange：
- 交换P-256椭圆曲线公钥
DHKey计算：
- 双方各自计算共享密钥
加密启动：
Central->Peripheral: LL_ENC_REQ (Rand, EDIV, SKD, IV) Peripheral->Central: LL_ENC_RSP (Rand, EDIV, SKD, IV) Central->Peripheral: LL_START_ENC_REQ Peripheral->Central: LL_START_ENC_RSP5. 实战案例分析
5.1 心率监测器通信解析
通过nRF Sniffer抓取的心率服务完整交互过程：
广播阶段：
- 设备广播包含HRM服务UUID(0x180D)
- 可能包含电池服务(0x180F)等附加服务
连接建立后：
- 交换MTU(通常协商为默认23字节)
- 发现所有Primary Service
- 订阅心率测量特征通知(CCCD写入0x0001)
数据传输：
- 心率数据格式(8位或16位)
- RR-Interval(用于计算心率变异性)
5.2 安全配对问题排查
当遇到配对失败时，可以通过以下步骤分析：
- 检查Pairing Failed报文中的错误码
- 确认双方支持的配对方法
- 验证公钥交换是否成功
- 检查加密参数(SKD, IV)是否正确同步
常见错误码：
- 0x01: PASSKEY_ENTRY_FAILED - 0x02: OOB_NOT_AVAILABLE - 0x03: AUTH_REQ_CANNOT_BE_MET - 0x04: CONFIRM_VALUE_FAILED6. 高级技巧与注意事项
6.1 优化抓包效果
- 信道选择：BLE使用37/38/39三个广播信道，连接后会在37个数据信道间跳频
- 时间同步：对于时序敏感的分析，需要校准嗅探器的时钟
- 多设备协同：使用多个嗅探器覆盖不同信道
6.2 常见问题解决
问题1：抓不到连接建立后的报文
- 检查是否在连接前就开始抓包
- 确认嗅探器与目标设备距离足够近
问题2：无法解密加密报文
- 确认设备是否使用LESC配对
- 检查是否启用了Debug模式
- 尝试捕获配对过程中的密钥交换信息
问题3：抓包数据不完整
- 调整嗅探器位置减少干扰
- 尝试降低PHY速率(从2M切换到1M)