• BLE广播数据的抓包解析


    前言:

    报文由数据字节组成同时是按比特传输的,这就免不了牵涉到字节序的问题。

    对于各个字节的传输,总是从最低位开始传输。如0x80是按00000001发送的,0x01是按10000000发送的。

    同时大多数字节域又是从低字节开始发送的。如0x010203发送序列为110000000100000010000000

    之所以说大多数,是因为并不是所有的数据都会从低字节发送从后面的抓取的广播报文中也能看不来。

    另外由于抓包软件可能并不一定能完全知道哪些数据时从低字节开始发的,抓取的广播数据可能有一些需要按字节倒着读。

    下面进入正题:

    在链路层 BLE的广播报文分为如下几个部分。

    |前导|接入地址|报头|长度|广播数据|校验|

    一般抓包工具抓取到广播数据后显示出来的都会分段显示,所以你很容易看出各个段的数据,本文重要是 解析 广播数据段中的内容。

    前导(1字节):不知道的可以理解为”同步头”,主要是用来配置接收机的自动增益控制。

    接入地址(4字节):对于广播报文来说是固定的0x8e89bed6 (同时接入地址也决定前导的序列,在这里并不是重点,不做过多介绍)

    报头(1字节):  依次为广播报文类型(4bit),保留位(2bit),发送数据地址类型(1bit),接收地址类型(1bit)

    长度(1字节): 指示广播数据的长度(广播地址AdvA+数据AdvData)

    广播数据:       我们需要解析的数据段,后面会详细说明。

    校验(3字节):  CRC校验

    下面 是Packet Sniffer抓到数据



     

    从中可以明显的看出各个段的内容:

    红色字段接入地址就是广播的固定接入地址0x8e89bed6。(抓包软件未转换字节序)

    报头字段中:

        广播类型是通用广播(Type为0),

        地址类型都是public(TxAdd和RxAdd都为0)。

    长度字段指示adv+AdvData长度

    广播设备地址是我自己设定的

    ble_gap_addr_t add={.addr_type=BLE_GAP_ADDR_TYPE_PUBLIC,

                        .addr={0x01,0x02,0x03,0x04,0x05,0x06}};

    因为地址是48-bit address, LSB format.

    所以真实地址为0x060504030201.

    AdvDara中一大堆数据就是我们需要解析的。

     

    下面是详细信息,其中有抓包软件加的帧头数据。







    发现图片太小 就复制了一下内容
    +----------------------------------------------------------+----------------- - - -
    |     Packet sniffer frame header                            |
    +--+-------------+-----------------------------+--------+
    |info| Packet nbr| Time stamp                  | Length| Packet data
    +--+-------------+-----------------------------+--------+----------------- - - -
    | 01 | 04 00 00 00  | EB 01 B9 02 00 00 00 00   | 2D 00 | 2C D6 BE 89 8E 00 21 01 02 03 04 05 06 0B 09 4E 6F 72 64 69 63 5F 48 52 4D 03 19 34 12 02 01 06 07 03 0D 18 0F 18 0A 18 39 FE 57 2A A5

     

    从Packet data开始

     

    2C为packet  data总字节数

    D6 BE 89 8E 为接入地址(字节序问题)

    00为报头字段(通用广播类型,public地址)

    21为长度字段的值,指示adv+AdvData的总字节数

    01 02 03 04 05 06 为广播设备地址

     

    之后便为重点需要解析的 AdvData 部分。首先还是需要知道这一部分的数据格式。

    蓝牙说明书4.1中说明 数据格式为


    |length|AD type|AD data|

     







     

    即Advdata 都是由这种格式的数据段组成。

    Length即为一小段数据的长度

    AD type指示 AD Data数据的含义。

    AD type的定义如下,







     

    下面继续分析 后面的数据

    0B告诉我们这一小段的数据长度为11字节

    即09 4E 6F 72 64 69 63 5F 48 52 4D都属于这以部分

    查上面的表 09指明AD type为完整的本地名称。 我定义的为”Nordic_HRM”十六进制就是4E 6F 72 64 69 63 5F 48 52 4D

     



    接着后面 03代表接着的一小段数据位三个字节 那么后面的19 34 12都属于这一小段

    19表示”外观”  34 12代表外观。 (外观特性是SIG定义的一组值,用来表示设备是普通手机,手环什么的)

     

    再后面是02则 01 06属于这段

    01代表 FLAG ,flag说明了物理连接功能,比如有限发现模式,不支持经典蓝牙等

    ·         bit 0: LE 有限发现模式

    ·         bit 1: LE 普通发现模式

    ·         bit 2: 不支持 BR/EDR

    ·         bit 3: Same Device Capable(Controller) 同时支持 BLE BR/EDR

    ·         bit 4: Same Device Capable(Host) 同时支持 BLE BR/EDR

    ·         bit 5..7: 预留

     

    即 06数据说明了 设备的连接功能为 普通发现模式并且不知道经典蓝牙

     

     

     



    继续是  07 表明03 0D 18 0F 18 0A 18属于这一段

    03查上面的表知道 后面的数据表示完整16bit uuid列表

        ble_uuid_t adv_uuids[] =

        {

            {0x180D,         BLE_UUID_TYPE_BLE},

            {0x180F,         BLE_UUID_TYPE_BLE},

            {0x180A,         BLE_UUID_TYPE_BLE}

        };

    就是我设置的广播UUID

     

     

    最后39 FE 57 表示CRC校验。

    2A A5 应该是 抓包软件做的帧校验吧。

  • 相关阅读:
    Apache-一个IP多个主机域名
    Apache-配置详解
    Apache-配置、测试和调试
    Linux-Memcache和Redis常用命令
    Linux-Linux下安装redis报错"undefined reference to__sync_add_and_fetch_4"解决办法
    C-从源文件到可执行文件的详细编译链接过程
    JavaScript-jQuery报TypeError $(...) is null错误(jQuery失效)解决办法
    MSSQL-SQL SERVER一些使用中的技巧
    unity 在Game视图中显示Gizmos
    unity Transform.TransformPoint
  • 原文地址:https://www.cnblogs.com/Free-Thinker/p/8611416.html
Copyright © 2020-2023  润新知