BLE协议分析

一,Bluetooth Low Energy协议基本组成

蓝牙系统核心架构可分为三个方面:

BLE Application和BLE Host 属于应用层API

HCI(Host Controller Interface)为中间层

BLE Controller为底层蓝牙芯片

BLE协议分析_第1张图片

 

其中在HOST层有的两个比较核心的协议:ATT、GATT

1,ATT(Attribute Protocol)

该协议将数据以属性(Attribute)的方式抽象出来,用UUID定义不同的属性,并提供一下方法以供远端设备读取、修改这些属性的值。

每个属性又由三个元素组成:

  • 一个16bits的Handle
  • 一个16bits/32bits/64bits的UUID
  • 确定长度的属性值

需要注意的是,Handle是用于识别唯一属性的数字,而非UUID,因为一个BLE设备中可能有多个属性拥有同一个UUID,UUID由更上层的GATT定义。

UUID用于确定属性中存放的值所对应的服务,其中主要包括一下几种:

  • Service UUID
  • Characteristic UUID
  • Profile UUID
  • Vendor-Specified UUID

和属性相关的读写权限保存于属性值中,但它也由更上层的GATT定义,ATT本身并不关心。

ATT本身有两个角色,即C/S架构,其中Server存储属性,Client什么也不存,Client主动发起请求读写Server端数据,Server端被动相应。但当Server端的属性发生变化时,也可以主动通知Client。

2,GATT(Generic Attribute Profile)

GATT将ATT中的不同属性组合在一起,形成有意义的服务。

纵向来看,GATT Profile包含一个或多个GATT Services,每个GATT Service又包含一个或多个GATT Characteristics。

BLE协议分析_第2张图片

BLE协议分析_第3张图片

  (1)GATT Profile

  Profile实际上并不存在于BLE外设上,而是由Bluetooth SIG或者外设设计者预先定义的Service的集合。比如说Heart Rate Profile就定义了Heart Rate Service和Device Information Service。 

  (2)GATT Service

  GATT Service的基础是UUID值为0x2800的属性,所有紧接着跟在其后边的UUID定义的属性都同属于一个服务,直到另一个0x2800出现。

  比如说,一个设备中有三个服务,其布局如下:

  BLE协议分析_第4张图片

  UUID为0x2800的属性定义了Primary服务,0x2801定义了Secondary服务,0x2802定义了Include,0x2803定义了属性(Characteristic)。每个属性不需要知道自己属于哪个服务,GATT根据0x2800作为标记区分不同的属性属于哪个服务。可以通过服务来确定Handle值的范围,比如说Service B的Handle就确定在0x0150~0x02ff之间。这样一来Client就可以找到所有服务而不需要知道服务的具体意义。

  BLE协议分析_第5张图片

  (3)GATT Service Characteristics

  每个服务有几个特征,每个特征其中存储了有用的值以及相关权限。特征中至少有两种属性:

  • Characteristic Declaration Attribute:定义了此特征的数据位置
  • Characteristic Data Attribute:存放了特征本身的数据

  比如说一个温度计,它的特征可以包括只读的温度值和可读写的时间戳:

  BLE协议分析_第6张图片

  其中主特征的UUID为0x2803,在它的Value值中又定义了不同特征的UUID。如图所示,通过UUID为0x2803的主特征的Value值中的UUID,可以找到UUID为0x2A2B的temperature的特征值,也可以找到UUID为0x2A08的date/time的特征值。

  特征值的真正格式是由UUID决定的,因此如果客户端知道如何解释UUID为0x0A28的特征值,就能从包含这个特征的任何服务中读取它的日期和时间值。

  • Characteristic Descriptors(可选)

  这些属性用来扩展在Characteristic Declaration Attribute中的数据。一般的Descriptor属性包括如下几种:

  • Extended Properties
    • Contains additional declaration property bits
  • Characteristic User Description
    • Contains a user-readable description for the characteristic in which it is placed (i.e. "Temperature in the Living Room").
  • Client Characteristic Configuration Descriptor (CCCD)
    • A switch, enabling/disabling server-initiated updates.

其它协议

BLE协议分析_第7张图片

3,GAP(Generic Access Profile)

它负责控制蓝牙设备的广播和连接行为,可通过Advertising Data Payload或者Scan Response Payload来进行广播,它们长度都为31bytes。不同之处在于前者为Peripheral设备自己定时发出,后者为接受到Central设备的请求后的响应内容。

4,SM(Security Manager)

通过使用一种密钥分发的方式来实现蓝牙设备之间通讯的加密与解密。当连接建立之后,双方通过某种方式协商出共同使用的密钥,后续传播的数据就要通过这个密钥使用加密算法来加密。

5,L2CAP(Logic Link Control and Adaptation Protocol)

L2CAP中文名为逻辑链路控制和适配协议,它将上层协议(ATT/SM)与下层的协议连接起来,因为ATT与SM层的协议实现和数据格式完全不同,所以说L2CAP的功能是实现了协议复用。L2CAP中定义了一种抽象概念,名为信道,表示两个设备的某个协议层之间的通道。每个信道分配一个2字节的CID(Channel ID),对于BLE协议而言共有三种信道ID:

  • 0x0004 – 属性协议
  • 0x0005 – 低功耗信令信道
  • 0x0006 – 安全管理协议

其中ATT都是通过CID为0x0004的Attribute Protocol来传递数据的。我们关心的上层协议的内容也主要体现于此。

 6,Link Layer

直接与Physical Layer进行交互,其中内容包括Channel,Packets,设备之间Discovery和Connection。

(1)Channel分为Advertising Channel和Data Channel两种,BLE一共使用40个Channel。

(2)在Link Layer种设备有不同的状态,以及不同的角色。在Link Layer所称的Master对应于GAP的Central、GATT的Client,而Slave对应于GAP的Peripheral、GATT的Server。下图是Unicast Connection中的设备连接过程:

 BLE协议分析_第8张图片

 (3)Packet Types

BLE协议分析_第9张图片

BLE包种的Protocal Data Unit(PDU)共分为两种:

Advertising Channel PDU:

  它的Header共定义了7种不同类型的PDU,每种数据包都有不同的格式和功能:

  • Advertising PDUs
    • ADV_IND, ADV_DIRECT_IND, ADV_NONCONN_IND, ADV_SCAN_IND
  • Scanning PDUs
    • SCAN_REQ, SCAN_RSP
  • Initiating PDUs
    • CONNECT_REQ

Data Channel PDU:

  BLE协议分析_第10张图片

 二,wireshark抓取数据包分析

 使用View Tool Hollong BLE Sniffer嗅探手机和蓝牙显示屏之间的通信,并在wireshark上查看数据包具体内容。

我们连接的设备在最下边一行,名字为PRSN-306083,MAC为AC:9A:22:30:60:83。

BLE协议分析_第11张图片

 BLE协议分析_第12张图片

抓到的数据包主要有一下几种:

1,ADV_IND 广播

 属于Link Layer层,长度为37 bytes。

  • Access Adress:0-3 bytes,用于确定通信频道

  BLE协议分析_第13张图片

  • Packet Header:4-5 bytes,定义了PDU Type为ADV_IND

  BLE协议分析_第14张图片

  • Advertising Adress:6-11 bytes,是发送广播的设备的MAC地址

  

  • Advertising Data:12-33 bytes
    • Flags:12-14 bytes

    BLE协议分析_第15张图片

    • Device Name:15-27 bytes
    • Manufacturer Specific:28-33 bytes

    BLE协议分析_第16张图片

    BLE协议分析_第17张图片

  • CRC:34-36 bytes

    BLE协议分析_第18张图片

 2,SCAN_REQ 扫描

长度为21 bytes,由Master发出,也属于Link Layer层

 

包括Access Address,Packet Header,Scanning Address,Advertising Address。

 3,SCAN_RSP 扫描回复

长度为33bytes,Slave接收到SCAN_REQ之后广播回复消息

 

 除了Access Address,Packet Header,Advertising Address之外,还包含了一个UUID

BLE协议分析_第19张图片

 4,CONNECT_REQ 连接请求

前四个部分为Access Address,Packet Header,Initator Address,Adevrtising Address

BLE协议分析_第20张图片

在接下来的Link Layer Data中重新定义了Access Address,以及一些其它连接相关参数

BLE协议分析_第21张图片

5,Connection Parameter Update Request/Response 跟新连接参数

属于L2CAP层协议,

可以看到此时Access Adress已经变为373a2a690610,这里L2CAP使用了CID为0x0005的通道,为低功耗信令通道。

BLE协议分析_第22张图片

6,GATT Primary Service Declaration 声明服务

在L2CAP层,CID为0x0004,代表ATT属性协议。

在GATT数据包中包括了Opcode,Starting Handle,Ending Handle,还使用UUID 0x2800定义了Primary服务(Service)。

BLE协议分析_第23张图片

在回复的数据包中,定义了3个属性组(Attribute List),这些属性都是手机自定义的,每个属性里边包含有自己的Handle的起始和结束位置以及UUID。

BLE协议分析_第24张图片

 我们可以收集到我们的蓝牙设备返回的一系列Service,通过Linux系统下的工具Gatttool也可以获得,我们的设备一共有5个Services。其中前四个为Bluetooth SIG预先设定的,最后一个提供的是自定义的Service。

 7,GATT Include Declaration 

一般在跟在Primary Service Declaraion之后,询问一定handle范围(在一个Service)内的Characteristic,但是我抓到的包每次Server都回复的是error。

在网上查到:

BLE协议分析_第25张图片

GATT profile attributes defined by SIG, they are Primary Service(0x2800), Secondary Service(0x2801), Include(0x2802), and Characteristic(0x2803).

8,GATT Characteristic Declaration 声明特征

用来声明特征值的读写权限,存放value的handle,对应的UUID。

BLE协议分析_第26张图片

由前边的Service可以判断出,handle范围在0x002a~0x0036之间的为设备自定义的一些特征,可以提供某些自定义功能。比如说后边抓包发现Write Command是通过改变handle为0x002c中存放的value实现的。通过向0x002c/0x002f的handle发送命令,可以实现控制蓝牙显示屏的内容以及动作。

 9,Find Information 查找信息

查找某些handle的UUID

handle UUID
0x000f Client Characteristic Configuration (0x2902)
0x0026 Client Characteristic Configuration (0x2902)
0x0027 Characteristic User Description (0x2901)
0X002d Characteristic User Description (0x2901)
0x0030 Characteristic User Description (0x2901)
0x0033 Characteristic User Description (0x2901)
0x0036 Client Characteristic Configuration (0x2902)

 

 

10,Write Request

 像handle为0x0036请求。

 BLE协议分析_第27张图片

 11,Write Command

像Handle 0x002c写入value。

BLE协议分析_第28张图片

 

 BLE协议分析_第29张图片

 最终我们可以画出整个属性表的结构:

Handle UUID Type Of Attribute Attribute Permission Attribute Value
0x0001 00002800-0000-1000-8000-00805f9b34fb Service Declaration Read Only UUID: 0x1800 Generic Access Profile
0x0002 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration 0x0a

Value Handle(0x0003)

UUID(0x2a00)

0x0003 00002a00-0000-1000-8000-00805f9b34fb Device Name 由上定义  
0x0004 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration 0x02  

Value Handle(0x0005)

UUID(0x2a01)

0x0005 00002a01-0000-1000-8000-00805f9b34fb Appearance  由上定义  
0x0006 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration 0x0a  

Value Handle(0x0007)

UUID(0x2a02)

0x0007 00002a02-0000-1000-8000-00805f9b34fb Peripheral Privacy Flag 由上定义  
0x0008 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration 0x02  

Value Handle(0x0009)

UUID(0x2a04)

0x0009 00002a04-0000-1000-8000-00805f9b34fb Peripheral Preffered Connection Parameters 由上定义  
0x000a 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration 0x0e  

Value Handle(0x000b)

UUID(0x2a03)

0x000b 00002a03-0000-1000-8000-00805f9b34fb Reconnection Address 由上定义  
0x000c 00002800-0000-1000-8000-00805f9b34fb Service Declaration Read Only UUID: 0x1801 Generic Attribute Profile
0x000d 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x000e 00002a05-0000-1000-8000-00805f9b34fb      
0x000f 00002902-0000-1000-8000-00805f9b34fb      
0x0010 00002800-0000-1000-8000-00805f9b34fb Service Declaration Read Only UUID: 0x180a Device Information
0x0011 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x0012 00002a29-0000-1000-8000-00805f9b34fb      
0x0013 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x0014 00002a24-0000-1000-8000-00805f9b34fb      
0x0015 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x0016 00002a25-0000-1000-8000-00805f9b34fb      
0x0017 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x0018 00002a27-0000-1000-8000-00805f9b34fb      
0x0019 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x001a 00002a26-0000-1000-8000-00805f9b34fb      
0x001b 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x001c 00002a28-0000-1000-8000-00805f9b34fb      
0x001d 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x001e 00002a23-0000-1000-8000-00805f9b34fb      
0x001f 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x0020 00002a2a-0000-1000-8000-00805f9b34fb      
0x0021 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x0022 00002a50-0000-1000-8000-00805f9b34fb      
0x0023 00002800-0000-1000-8000-00805f9b34fb Service Declaration Read Only UUID: 0xfee8 Quintic Corp.
0x0024 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x0025 003784cf-f7e3-55b4-6c4c-9fd140100a16      
0x0026 00002902-0000-1000-8000-00805f9b34fb      
0x0027 00002901-0000-1000-8000-00805f9b34fb      
0x0028 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x0029 013784cf-f7e3-55b4-6c4c-9fd140100a16      
0x002a 00002800-0000-1000-8000-00805f9b34fb Service Declaration Read Only UUID: 0xfee9 (自定义)
0x002b 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x002c d44bc439-abfd-45a2-b575-925416129600      
0x002d 00002901-0000-1000-8000-00805f9b34fb      
0x002e 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x002f d44bc439-abfd-45a2-b575-92541612960a      
0x0030 00002901-0000-1000-8000-00805f9b34fb      
0x0031 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x0032 d44bc439-abfd-45a2-b575-92541612960b      
0x0033 00002901-0000-1000-8000-00805f9b34fb      
0x0034 00002803-0000-1000-8000-00805f9b34fb Charactristic Declaration    
0x0035 d44bc439-abfd-45a2-b575-925416129601      
0x0036 00002902-0000-1000-8000-00805f9b34fb      

 

这是我在processon上将整个通讯抓包过程绘制成的流程图,可以更加清楚地了解BLE协议的细节。

 https://www.processon.com/view/link/5bb06eb3e4b0d4d65c1d9d77

 

转载于:https://www.cnblogs.com/bl8ck/p/9710454.html

你可能感兴趣的:(BLE协议分析)