22、BLE安全补丁与更新：Android安全补丁机制、BLE协议栈更新、OEM厂商安全修复、用户端安全更新
聊到BLE安全，很多人只关注配对过程和加密算法。但说实话，真正决定设备安全下限的，往往是补丁更新机制。我见过太多案例——协议本身没问题，但厂商几个月不推送补丁，结果漏洞被公开后，设备就成了活靶子。
这一章，我们就把Android生态里BLE安全补丁的整个链条捋一遍。从Google官方到芯片厂商，再到OEM定制，最后到用户手机，每个环节都可能掉链子。
Android安全补丁机制：月月补，但你真的补了吗？
Google从2015年开始推行月度安全补丁。每个月初，Google会发布安全公告，里面会列出Android框架、内核、以及供应商组件的漏洞修复。
对于BLE来说，最关键的补丁集中在两个地方：
- Android框架层：比如BluetoothManagerService、BluetoothAdapter中的逻辑漏洞
- 系统蓝牙协议栈：也就是我们常说的Fluoride或Gabeldorsche（新版本）
我个人习惯是，每次Google发公告，第一时间去翻packages/modules/Bluetooth的commit log。你会发现，很多BLE漏洞其实很隐蔽——比如某个配对回调没做状态校验，或者GATT操作没加权限检查。
关键点：Android安全补丁级别（SPL）决定了设备已知漏洞的修复状态。如果SPL低于漏洞公开日期，那这台设备基本等于裸奔。
BLE协议栈更新：从Fluoride到Gabeldorsche
Android的蓝牙协议栈经历过一次大重构。早期是BlueZ，后来换成Fluoride，再后来Google内部搞了Gabeldorsche（简称Gd）。
为什么要换？说白了，Fluoride的代码太老了，很多设计还是2010年代的思路。比如它的HCI层处理是单线程的，一旦某个操作卡住，整个蓝牙服务就挂了。我在项目中遇到过，某款手机播放A2DP音乐时，同时扫描BLE设备，结果蓝牙进程直接crash——就是Fluoride的调度问题。
Gabeldorsche的架构更现代：
- 分层更清晰，HCI、L2CAP、ATT各层独立
- 支持更细粒度的权限控制
- 更容易做安全审计
但问题是，Gd的推进速度很慢。Android 13才开始默认启用，很多OEM厂商到现在还在用老协议栈。你想想看，一个2015年的协议栈跑在2024年的手机上，不出问题才怪。
我的建议：如果你在做BLE安全测试，先确认目标设备的蓝牙协议栈版本。用adb shell dumpsys bluetooth_manager就能看到。
OEM厂商安全修复：最薄弱的环节
Google修了漏洞，不代表你的手机就安全了。中间还隔着一层OEM厂商。
OEM厂商的修复流程大概是这样的：
- Google发布AOSP补丁
- 芯片厂商（高通、MTK、三星）适配自己的BSP
- OEM厂商集成到自己的ROM里
- 测试、认证、推送
每一步都可能拖延。我曾经分析过某款主流手机的BLE漏洞，Google在3月份就修了，但厂商直到8月份才推送。中间这5个月，攻击者完全可以利用公开的PoC进行攻击。
更麻烦的是，很多OEM厂商会修改蓝牙协议栈。比如加一些私有特性，或者为了性能砍掉安全检查。我见过一个案例——某厂商为了加快配对速度，跳过了MITM保护的检查。嗯，这操作直接让Secure Connections形同虚设。
警告：不要以为大厂就靠谱。我测过某国际品牌的旗舰机，它的BLE配对实现里居然没有验证蓝牙地址的随机性。这意味着攻击者可以伪造设备身份。
用户端安全更新：最后的防线
补丁推送了，用户不更新，等于白搭。
Android的用户更新率一直是个老大难。根据Google自己的数据，Android 14发布一年后，只有不到30%的设备升级。更别说那些低端机，出厂就是Android 12，然后永远停在那个版本。
对于BLE安全来说，用户能做的不多，但有几个习惯值得养成：
- 定期检查系统更新：设置里看看安全补丁级别
- 不要用第三方蓝牙工具：很多所谓的“增强”工具其实在滥用蓝牙权限
- 关闭不用的蓝牙：这个最简单，也最有效
我记得有一次帮朋友排查问题，他的手机蓝牙一直开着，结果连上了隔壁工位的假音箱。那个假音箱其实是个嗅探设备，专门抓BLE广播包。还好只是广播包，要是配对过程被中间人攻击，后果就严重了。
知识体系总览
下面这张图，我把整个BLE安全补丁的流转路径画了出来。你可以看到，从Google到用户，每一层都有风险点。
补丁类型与影响范围
不同类型的补丁，影响范围差别很大。我整理了一个表格，方便你对照：
| 补丁类型 | 影响范围 | 修复难度 | 典型例子 |
|---|---|---|---|
| Android框架层 | 所有使用该API的应用 | 低（Google直接推送） | 蓝牙权限绕过漏洞 |
| 蓝牙协议栈 | 系统蓝牙服务 | 中（需芯片厂商适配） | Fluoride HCI死锁 |
| 芯片固件 | 特定芯片型号 | 高（需OTA固件更新） | Broadcom BCM固件漏洞 |
| OEM定制层 | 特定机型 | 高（需厂商测试） | 配对流程跳过MITM |
实用技巧：检查设备蓝牙固件版本，可以用adb shell dumpsys bluetooth_manager | grep -i "firmware"。如果固件版本太老，建议联系厂商催更。
好了，这一章的内容就到这里。BLE安全补丁这件事，说白了就是一场与时间的赛跑。Google修得快，但链条太长，每一环都可能掉链子。作为开发者，我们能做的就是尽量缩短这个链条——比如直接使用最新的Gabeldorsche协议栈，或者至少确保自己的设备SPL是最新的。