其他分享
首页 > 其他分享> > BLE协议分析

BLE协议分析

作者:互联网

一,Bluetooth Low Energy协议基本组成

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

BLE Application和BLE Host 属于应用层API

HCI(Host Controller Interface)为中间层

BLE Controller为底层蓝牙芯片

 

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

1,ATT(Attribute Protocol)

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

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

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

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。

  (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出现。

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

  

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

  

  (3)GATT Service Characteristics

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

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

  

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

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

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

其它协议

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:

其中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中的设备连接过程:

 

 (3)Packet Types

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

Advertising Channel PDU:

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

Data Channel PDU:

  

 二,wireshark抓取数据包分析

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

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

 

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

1,ADV_IND 广播

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

  

  

  

    

    

    

    

 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

 4,CONNECT_REQ 连接请求

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

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

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

属于L2CAP层协议,

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

6,GATT Primary Service Declaration 声明服务

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

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

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

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

 7,GATT Include Declaration 

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

在网上查到:

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。

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

 9,Find Information 查找信息

查找某些handle的UUID

handleUUID
0x000fClient Characteristic Configuration (0x2902)
0x0026Client Characteristic Configuration (0x2902)
0x0027Characteristic User Description (0x2901)
0X002dCharacteristic User Description (0x2901)
0x0030Characteristic User Description (0x2901)
0x0033Characteristic User Description (0x2901)
0x0036Client Characteristic Configuration (0x2902)

 

 

10,Write Request

 像handle为0x0036请求。

 

 11,Write Command

像Handle 0x002c写入value。

 

 

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

HandleUUIDType Of AttributeAttribute PermissionAttribute Value
0x000100002800-0000-1000-8000-00805f9b34fbService DeclarationRead OnlyUUID: 0x1800 Generic Access Profile
0x000200002803-0000-1000-8000-00805f9b34fbCharactristic Declaration0x0a

Value Handle(0x0003)

UUID(0x2a00)

0x000300002a00-0000-1000-8000-00805f9b34fbDevice Name由上定义 
0x000400002803-0000-1000-8000-00805f9b34fbCharactristic Declaration0x02 

Value Handle(0x0005)

UUID(0x2a01)

0x000500002a01-0000-1000-8000-00805f9b34fbAppearance 由上定义 
0x000600002803-0000-1000-8000-00805f9b34fbCharactristic Declaration0x0a 

Value Handle(0x0007)

UUID(0x2a02)

0x000700002a02-0000-1000-8000-00805f9b34fbPeripheral Privacy Flag由上定义 
0x000800002803-0000-1000-8000-00805f9b34fbCharactristic Declaration0x02 

Value Handle(0x0009)

UUID(0x2a04)

0x000900002a04-0000-1000-8000-00805f9b34fbPeripheral Preffered Connection Parameters由上定义 
0x000a00002803-0000-1000-8000-00805f9b34fbCharactristic Declaration0x0e 

Value Handle(0x000b)

UUID(0x2a03)

0x000b00002a03-0000-1000-8000-00805f9b34fbReconnection Address由上定义 
0x000c00002800-0000-1000-8000-00805f9b34fbService DeclarationRead OnlyUUID: 0x1801 Generic Attribute Profile
0x000d00002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x000e00002a05-0000-1000-8000-00805f9b34fb   
0x000f00002902-0000-1000-8000-00805f9b34fb   
0x001000002800-0000-1000-8000-00805f9b34fbService DeclarationRead OnlyUUID: 0x180a Device Information
0x001100002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x001200002a29-0000-1000-8000-00805f9b34fb   
0x001300002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x001400002a24-0000-1000-8000-00805f9b34fb   
0x001500002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x001600002a25-0000-1000-8000-00805f9b34fb   
0x001700002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x001800002a27-0000-1000-8000-00805f9b34fb   
0x001900002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x001a00002a26-0000-1000-8000-00805f9b34fb   
0x001b00002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x001c00002a28-0000-1000-8000-00805f9b34fb   
0x001d00002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x001e00002a23-0000-1000-8000-00805f9b34fb   
0x001f00002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x002000002a2a-0000-1000-8000-00805f9b34fb   
0x002100002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x002200002a50-0000-1000-8000-00805f9b34fb   
0x002300002800-0000-1000-8000-00805f9b34fbService DeclarationRead OnlyUUID: 0xfee8 Quintic Corp.
0x002400002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x0025003784cf-f7e3-55b4-6c4c-9fd140100a16   
0x002600002902-0000-1000-8000-00805f9b34fb   
0x002700002901-0000-1000-8000-00805f9b34fb   
0x002800002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x0029013784cf-f7e3-55b4-6c4c-9fd140100a16   
0x002a00002800-0000-1000-8000-00805f9b34fbService DeclarationRead OnlyUUID: 0xfee9 (自定义)
0x002b00002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x002cd44bc439-abfd-45a2-b575-925416129600   
0x002d00002901-0000-1000-8000-00805f9b34fb   
0x002e00002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x002fd44bc439-abfd-45a2-b575-92541612960a   
0x003000002901-0000-1000-8000-00805f9b34fb   
0x003100002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x0032d44bc439-abfd-45a2-b575-92541612960b   
0x003300002901-0000-1000-8000-00805f9b34fb   
0x003400002803-0000-1000-8000-00805f9b34fbCharactristic Declaration  
0x0035d44bc439-abfd-45a2-b575-925416129601   
0x003600002902-0000-1000-8000-00805f9b34fb   

 

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

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

标签:分析,协议,0000,UUID,GATT,Declaration,BLE,8000,1000
来源: https://blog.csdn.net/daocaokafei/article/details/114745019