BLE协议栈为什么要分层?怎么理解BLE“连接”?如果BLE协议只有ATT层没有GATT层会发生什么? 1. 协议栈框架 一般而言,我们把某个协议的实现代码称为协议栈(protocol stack),BLE协议栈就是实现低功耗蓝牙协议的代码,理解和掌握BLE协议是实现BLE协议栈的前提。 在深入BLE协议栈各个组成部分之前,我们先看一下BLE协议栈整体架构。 ? 可以看出BLE协议栈是连接芯片和应用的桥梁,是实现整个BLE应用的关键。那BLE协议栈具体包含哪些功能呢? 在IEEE802.15.4 中共规定了 27 个信道: 在 2.4GHz 频段,共有 16 个信道,信道通信速率为 250kbps: 在 915MHz 频段,共有 10 个信道,信道通信速率为 40kbps
本章介绍蓝牙协议(重点介绍:BLE)的基本特点、版本演进、协议的构成、等基础知识,本章重在了解,目的是对BLE协议有个大概的认知,即了解BLE协议栈的全貌。 我们常说的蓝牙4.0不等同于BLE,BLE只是蓝牙4.0的子集;蓝牙4.0是一个综合性协议规范。 BLE协议栈的实现方式采用分层的思想: 控制器部分包括:物理层(PHY)、链路层(LL)、控制接口层(HCI) 主机部分包括:裸机链路控制及自适应协议层(L2CAP)、安全管理层(SMP)、属性协议层( 图片 03-链路层(LL) 低功耗蓝牙参考 《Core_v5.3.pdf》中 Part B: Link Layer Specification 章节部分,LL层是整个BLE协议栈的核心,也是BLE协议栈的难点和重点 没有GATT,BLE协议栈也能跑,但互联互通就会出问题。
在实践中,根据所使用设备的限制,您可以期望每秒5- 10kb。就距离而言,BLE专注于非常短的距离通信。 蓝牙BLE组成 BLE由三个主要构建模块组成:应用程序、主机和控制器。顾名思义,应用程序块是与蓝牙协议栈交互的用户应用程序。主机覆盖蓝牙协议栈的上层。控制器覆盖下层。 现在我们可以转到BLE设备的主机部分。 逻辑链路控制和适配协议(L2CAP) L2CAP负责两项任务:1、它需要来自上层的多个协议,并将它们封装成标准的BLE数据包格式(反之亦然)。 层负责或路由两个主要协议:属性协议(ATT)和安全管理器协议(SMP)。 属性协议(ATT) 属性协议(ATT)是基于设备呈现的属性的简单客户端/服务器协议。客户端从服务器请求数据,然后服务器将数据发送给它的客户端。
环境搭建 上面介绍了数据包和各层协议,接下来我们将使用Ubertooth One来捕获通信过程中的蓝牙数据包。 ? /configure make && make plugins sudo make suidinstall sudo make plugins-install (6)安装BLE解密工具crackle crackle capture occurs. ubertooth-btle -f -ctest.pcap抓包&保存到本地 使用这条命令我们可以把设备捕获到的数据包保存到本地,完成后可导入wireshark进行数据包、协议分析 使用规则过滤数据包:参考Capturing BLE in Wireshark btle.data_header.length > 0 || btle.advertising_header.pdu_type understanding-bluetooth-advertising.html 路人甲@乌云drops:Bluetooth Low Energy 嗅探 疯狗@乌云drops:物联网安全拔“牙”实战——低功耗蓝牙(BLE
对 RxSwift 及 BLE 感兴趣的同学可以看看,或有所得。
数据包格式 BLE的数据包格式确保了数据传输的完整性和可靠性,其基本结构包括前导序列、访问地址、PDU(Protocol Data Unit,协议数据单元)报头、PDU长度、PDU数据和CRC(Cyclic 简化的协议栈:降低了开发成本和复杂性,提高了设备的兼容性和互操作性。 BLE技术的起源与基础版本 BLE技术起源于蓝牙4.0版本,该版本首次引入了低功耗蓝牙协议栈,旨在降低蓝牙设备的功耗,延长电池寿命。 特点:BLE以其低功耗著称,适用于不需要高数据传输速率但对功耗有严格要求的应用场景,如健康监测设备、智能家居控制等。BLE技术还具备快速连接与断开、短距离通信以及简化的协议栈等优势。 3.2. BLE:通信范围相对较短,通常为10米左右(也受环境因素影响)。 3.3. 功耗与电池寿命 BR/EDR:功耗相对较高,不太适合需要长时间运行且依赖电池供电的设备。
Attribute Protocol(ATT)— GATT 在 ATT 协议基础上建立,也被称为 GATT/ATT。ATT 对在 BLE 设备上运行进行了优化,为此,它使用了尽可能少的字节。 // 使用此检查确定 BLE 是否支持在设备上,然后你可以有选择性禁用 BLE 相关的功能 if (! ---- 你的 app 能与 BLE 通信之前,你需要确认设备是否支持 BLE,如果支持,确认已经启用。 如果不支持BLE,那么你应该适当地禁用部分BLE功能。如果支持BLE但被禁用,你可以无需离开应用程序而要求用户启动蓝牙。使用BluetoothAdapter两步完成该设置。 BluetoothAdapter mBluetoothAdapter; private boolean mScanning; private Handler mHandler; // 10
UDP 协议 UDP (用户数据报)协议,是传输层的另外一个协议 一、简单概念 1、特点 .不需要建立连接,直接发送数据,不会去重新排序,不需要确认 2、报文宇段 ·源端口 ·目标端口 · UDP
低功耗蓝牙BLE外围模式(peripheral)-使用BLE作为服务端 Android对外模模式(peripheral)的支持 从Android5.0开始才支持 关键术语和概念 以下是关键BLE术语和概念的摘要 : 通用属性简档(GATT) - GATT简档是用于通过BLE链路发送和接收称为“属性”的短数据块的一般规范。 属性协议(ATT) -GATT建立在属性协议(ATT)之上。 这也称为GATT / ATT。 ATT经过优化,可在BLE设备上运行。 为此,它使用尽可能少的字节。 角色和职责 以下是Android设备与BLE设备互动时适用的角色和职责: 中央与外围。 这适用于BLE连接本身。 处于中心角色的设备扫描,寻找广告,并且外围角色中的设备进行广告。 然后在运行时,您可以通过使用PackageManager.hasSystemFeature()确定BLE可用性: // Use this check to determine whether BLE
BLE 考虑功耗, 使用了3个广播信道,顺序广播。 两个蓝牙设备想要建立连接, 第一步是 从机(server) 向外广播, 主机(client) 搜索到后发起请求。
characteristic的发现、读、写、通知(Notifing)、指示(Indicating) 及配置characteristic的广播 GATT可以被Application或其他Profile使用 其协议栈如下图 Characteristic Value with response using procedures defined in Section 4.9.3 or Section 4.9.4 Notify 0x10 高层协议也可以定义协议相关的Characteristic Descriptors Characteristic Descriptors在服务端上是无序的,Client不应该理所当然 Characteristic Descriptors Declarations Permissions由高层协议定义或协议相关的 Client不应该理所当然地认为是可读的 Characteristic Descriptor Declarations Indication of a Characteristic Value 10. Reading a Characteristic Descriptor 11.
,但是后面我也说道 Http 协议无论是 GET 还是 Post 方法传输数据。 本文将详细探讨HTTPS协议的工作原理、HTTP与HTTPS的区别、加密技术的应用以及如何通过证书认证保障安全通信 1.1 HTTPS 是什么及其工作原理? HTTPS协议则通过在 应用层 和 传输层 之间增加一个加密层(SSL/TLS),为数据传输提供安全保障。 HTTPS 也是一个应用层协议. 只是 在 HTTP 协议的基础上引入了一个加密层. 加密方式的定义? HTTPS加密传输与数据安全 传输过程加密 HTTPS协议:所有数据传输均通过SSL/TLS加密,防止中间人攻击或数据窃取。
最早了解 BLE 中继攻击是在 2022 年 3 月份,在网上搜了一堆关于 BLE 攻击方法的介绍,但当时并不知道无钥匙进入系统这么个东西,所以没感觉到中继攻击有什么大用途,当时接触的是些手环、灯泡这类的物联网设备 后来在 5 月份的时候 NCC 发布了 BLE 链路层中继解锁特斯拉的视频(https://youtu.be/5mdU4ksOc2w),发现原来 BLE 中继还挺有用的,就回头看了看之前搜集的资料,尝试搭建了 btlejuice 这个用来 BLE 中继攻击的工具(再吐槽一次 npm 安装东西太难了叭) 先把 btlejuice 以及 gattacker 这些中继攻击思路简单描述一下: 用两台带有蓝牙适配器的电脑 钥匙就无能为力了,与 NCC 发的视频实现的效果差距太大,便没有深入研究了 后来在网上冲浪的时候发现 NCC 在 hardware.io 分享了他们对 BLE 进行链路层中继的实现思路(https:/ 不会嵌入式开发,告辞 后来看到了小米的师傅们要在 KCon 分享他们实现的 BLE 链路层中继,斥巨资买了张门票(真就为了这个议题去的哈哈哈)然后心满意足的听了小米的师傅们对 BLE 攻击的分享(还说工具要在
索尼相机现在支持基于蓝牙低功耗 (BLE) 的控制协议。该接口允许客户端控制以及从支持 BLE 的遥控器获取状态。 遙控器 对于启用了索尼 BLE 的相机,发现过程相当简单。 相机控制服务 该服务支持对 BLE 的各种相机控制。相信这个服务比 DIRC 有更多的功能,但它的使用目前受到客户的限制。一旦客户端开始使用此接口,您就可以确定我们会窥探该接口。 相机控制服务目前正被索尼应用程序用于 BLE 到 Wifi 切换。它的许多特征似乎是为了支持FTP 服务器,但这并没有得到证实。 命令 回应 如果存在协议错误,IRC 将返回 0x0185 GATT 状态。如果拍摄照片或开始录制等过程,将发送各种通知。 原生的遥控器260元,有了协议,几十块钱就可以做一个,而且功能可以做的更多。 至于实现,我应该是写过。大家感兴趣的去翻翻。
打开手机app,扫描周围的设备(从机),支持过滤功能 (2)设备信号强度(RSSI)查看 可以很清晰的观察rssi的变化: (3)连接设备 点击“CONNECT”按钮,即可连接目标设备,这里以“BLE-UART (5)特征读写 ble是通过特征传输数据的,特征又有不同的属性,ff05这个特征只支持写。 (6)修改MTU 通过Request MTU可以修改MTU,提高数据的传输量。 2、BLE调试助手 这个是南京沁恒开发的app,调试起来也比较方便,支持从机模式,用法和nRF Connect差不多。 (3)特征读写 (4)修改MTU 上面3个ble调试app,都可以使用,个人推荐nRF Connect和BLE调试助手。
射频通道,编号0-39,每个2M,分为广播通道和数据通道,广播通道是37,38,39,其余都是数据通道。
Android BLE基础操作框架,基于回调,操作简单。包含扫描、多连接、广播包解析、服务读写及通知等功能。 项目地址:https://github.com/xiaoyaoyou1212/BLE 项目依赖:compile 'com.vise.xiaoyaoyou:baseble:2.0.0' 功能 支持多设备连接管理 该库是 BLE 操作的基础框架,只处理 BLE 设备通信逻辑,不包含具体的数据处理,如数据的分包与组包等。 /蓝牙相关配置修改 ViseBle.config() .setScanTimeout(-1)//扫描超时时间,这里设置为永久扫描 .setConnectTimeout(10 更多关于广播包解析可以参考Android BLE学习笔记中数据解析部分。
本文根据实际使用经验,介绍了每种抓包方案的环境配置与抓包方法,对比分析目前几种 BLE 的空口抓包方案(只讨论普通人用得起的,ellisys 这类神器摸都没摸过 Orz) PART1 方案一 ubertooth CC2540 是 TI(德州仪器)的一款芯片,优点是价格便宜,淘宝购买大概40,缺点同样是只能同时抓一个信道 TI 有配套的官方软件:Packet Sniffer,直接安装就行,安装好之后接上 CC2540 协议类型选择蓝牙就可以抓包了 wireshark 可以识别的 pcap 格式: https://github.com/joswr1ght/tibtle2pcap PART3 方案三 Hollong + wireshark 纬图出品的 BLE 找到Global Extcap path 里面的路径 把刚才的 extcap 文件夹里的内容拷贝过去 运行这条命令,若如下图所示这样就是成功了,Linux 下用 .sh nrf_sniffer_ble.bat
BLE 安全 蓝牙的安全管理分为control端也就是LL层的安全管理和host端的安全管理, LL层的安全机制主要包括白名单管理,私有可解析地址管理,以及SM管理中的链路加解密等。 - **KP**字段是keypress,仅在 Passkey Entry 协议中使用,在其他协议中被忽略。 Passkey Entry 协议是 Legacy Pairing 和 Secure Connection 的典型配对方法。 BLE的SM常用密钥介绍 常用的密钥定义简单介绍下,具体的使用会在后面章节详细介绍。 在选择好了合适的配对和鉴权方式后,接下来就是BLE配对的阶段二 ,在该阶段会通过配对流程生成STK或者LTK,该阶段不同的配对和鉴权方式导致情况较多,会专门在下章节详细介绍。
说明: rtmp协议wireshark中过滤音频数据包的条件为: rtmpt.header.typeid == 0x08 通过抓包文件,我们看到音频数据也是按照RTMP Header + Rtmp Body 因为rtmp是Adobe公司开发的协议,所以对自己东西当然是青睐有加,音频的数据的Body部分正是按照FLV的格式进行组装的。 我们来看抓包中的例子,rtmp Body中的数据是audio类型,audio类型的第一个字节表示header,其值为0xaf=0x10101111,将二进制隔开为4段: 0x1010=100x11=30x1=10x1