Kali Linux蓝牙安全测试实战：用Crackle破解BLE配对加密

很多人做无线安全测试，一提到"无线"就条件反射般打开Aircrack-ng，抓WiFi握手包、跑字典、破解WPA2，玩得很顺。但蓝牙这个攻击面，被绝大多数人忽略了。鼠标、键盘、耳机、智能门锁、传感器网关，几乎每个IoT设备里都藏着蓝牙模块，而其中相当一部分的配对流程和连接加密做得相当草率。这篇文章主题很直接：用Kali Linux把蓝牙安全测试完整跑一遍，重点聚焦Crackle这个专用工具，从环境搭建、硬件选型到一次真实的数据捕获与解密分析。里面会插进不少我在实际测试中踩过的坑和总结的排查经验，不是demo演示那种浅尝辄止。

适合谁看？有WiFi渗透基础、想横向拓展蓝牙安全的新人，或者做IoT设备评估、想补充蓝牙测试链路的安全工程师。整个过程不需要昂贵设备，几十块的USB蓝牙适配器加一台能跑Kali的笔记本，就能把协议层面的问题看得明明白白。

1. 为什么劝你别只盯着 Aircrack-ng

1.1 Aircrack-ng 的能力边界

Aircrack-ng 是WiFi测试的入门利器，这没得说。但它能解决的问题相对集中：802.11 协议族中的抓包、握手分析、弱口令破解，以及一部分无线IDS。这套流程跑多了你会发现，它本质上只回答"某个AP在某种加密模式下有没有弱Key"这一个问题。

但无线安全远不止AP与客户端这一层。一个实际的IoT设备，往往同时具备WiFi和蓝牙两条无线链路，WiFi负责连网，蓝牙负责与外设交互或近场配网。只测WiFi链路，等于只看了一个侧面。蓝牙侧的信道、配对和数据加密机制完全独立，隐藏的问题形态也完全不同。我见过不少设备，WiFi侧固若金汤，蓝牙侧一捅就破，恰恰因为很多人把精力都堆在AP测试上，蓝牙模块就成了无人看管的后门。

所以我的建议是：Aircrack-ng要继续学，但不能成为唯一技能。把蓝牙安全测试补上之后，你对"无线攻击面"这个概念才算有完整认知。

1.2 蓝牙测试的具体切入点

蓝牙协议栈比WiFi更深，攻击面也更琐碎。结合我做过的评估，比较核心的几个切入点是这样：

• 配对机制：PIN码是否可猜测、是否允许Just Works、是否可离线穷举
• 加密协商：连接时能否被降级成不加密或弱加密模式
• 服务暴露：设备发布了哪些RFCOMM通道、哪些GATT服务，可写特征值是否开放
• 隐私与可追踪性：BLE地址是否定期轮换，广播包是否泄漏设备行为
• 协议差异：BR/EDR与BLE同时开启时，两条链路的保护强度是否一致

如果你只做过WiFi，一开始会不适应：蓝牙设备不像AP那样固定在某个信道，而是在79个信道上跳频，传统抓包方法完全不是一回事。

1.3 一个关键认知：蓝牙不是缩小版的WiFi

蓝牙跑在2.4GHz频段，但物理层用的是自适应跳频扩频（AFH），大部分连接建立逻辑由控制器（Controller）完成，主机（Host）只负责上层协议。也就是说，安全测试不能靠无线网卡加驱动解决，更多时候要靠BlueZ这类蓝牙协议栈接口去和控制器交互。很多人第一反应是打开抓包工具对着空气抓，结果抓了个寂寞。

正确思路是先理解设备怎么被发现、怎么配对、怎么加密，再选工具。Crackle解决的是配对加密层的问题，不是万能钥匙，但它是理解整个流程最好的切入点之一。

2. 环境搭建：让Kali也能管好蓝牙

2.1 硬件选型踩过的坑

蓝牙安全测试对硬件的要求不高，但刀必须选对。我踩过的坑先说在前头：

• 只在虚拟机里装Kali，宿主机蓝牙往往拿不到。要么把蓝牙适配器通过USB直通给虚拟机，要么干脆用物理机装Kali。
• 部分笔记本内置蓝牙芯片在Linux下没有正常加载固件，导致接口根本不上电。买一个便宜的USB蓝牙适配器反而最省心。
• 虚拟机里USB直通时，蓝牙设备的自动挂起策略会捣乱，连接几分钟后就掉线，一定要在虚拟机和宿主机的电源管理里把蓝牙相关设备设为永不挂起。

我自己的测试环境是这样搭的：一台装了Kali的物理笔记本，内置蓝牙模块做日常扫描，另配一个USB蓝牙适配器专门用于Crackle抓包。两个接口可以同时用，互不干扰。实测下来，这套组合比单纯依赖虚拟机的稳定性高太多。

2.2 蓝牙协议栈与工具包准备

Kali默认带BlueZ，这是Linux官方的蓝牙协议栈。建议把常用的工具包都装齐：

sudo apt update sudo apt install bluez bluetooth bluez-tools wireshark tshark

BlueZ组件里真正高频用到的是这几个：

• bluetoothd：蓝牙守护进程，管理适配器和设备
• bluetoothctl：现代交互式管理工具，功能最全
• hcitool：老牌HCI查询工具，脚本和快速验证时好用
• hciconfig：查看接口状态、启停配置
• btmon：HCI流量监控，能导出pcap，Crackle的数据源之一
• btmgmt：BlueZ 5.x推荐的管理接口，和hcitool部分功能重叠

装完后验证接口状态：

systemctl status bluetooth hciconfig -a hcitool dev

能看到hci0就算基本环境OK。注意，有些版本里hciconfig被移到了单独包里，装完bluez-tools后如果还是没有，就再补一个bluez-utils或者用btmgmt替代。

2.3 权限管理与服务调优

蓝牙测试大量操作需要root权限，同时还要能跟蓝牙守护进程通信。直接在普通用户下跑hcitool，很容易碰上"Can't open HCI socket"错误。实操里我习惯先切到root环境，再用脚本串起各个命令，避免每个命令都sudo，否则脚本一长，权限问题会让你debug到怀疑人生。

蓝牙服务偶尔会崩。新插入适配器后，第一时间执行：

systemctl restart bluetooth

另外有个很容易忽略的坑：btmon和hcitool如果同时打开同一个hci设备，会互相抢访问权限，报"Device or resource busy"。我自己都是开一个专门终端跑btmon，其它操作统一通过bluetoothctl完成，不混用。这个习惯让我少踩了很多次设备丢失的雷。

3. 动手之前：蓝牙协议里必须知道的三件事

3.1 传统蓝牙BR/EDR的PIN码机制

传统蓝牙（BR/EDR）配对时的核心密钥材料来源于PIN码。很多老旧设备用的是4位数字PIN，常见的就那么几个：0000、1234、8888。配对过程中，双方基于PIN码生成初始密钥Kinit，再用Kinit完成后续的链路密钥协商和认证。

PIN码空间很小，如果攻击者完整嗅探到双方交换的认证帧和挑战应答，就完全可以离线枚举PIN。4位数字最多一万种组合，哪怕是普通笔记本也只跑不了多久。安全测试要关注的是目标设备是否接受默认PIN、是否限制了失败尝试次数、链路密钥是否写死可被重放。这个点放在Crackle之前讲，是因为评估经典蓝牙时，PIN机制往往比加密算法本身更容易出问题。

3.2 BLE低功耗蓝牙的配对机制

BLE的配对流程和传统蓝牙不一样，尤其是传统LE配对，分三步走：

1. 特性交换：双方告知各自的I/O能力，进而决定使用哪种配对算法
2. 临时密钥（TK）生成：根据Just Works、Passkey Entry、Out of Band三种方式，生成不同的临时密钥
3. 短期密钥（STK）生成与链路加密：使用TK派生STK，保护后续通信

要注意的是，Just Works模式为了兼容没有屏幕没有键盘的小设备，直接把TK固定为0。Passkey Entry虽然需要输入6位数字PIN，但如果设备没做防爆破，或者默认PIN就是000000，作用也不大。

3.3 这就是Crackle工作的核心点

Crackle能做的，是在拿到配对过程的完整包后，识别出设备用的是哪种配对方式。碰到Just Works，TK已知为0，后续加密等于形同虚设；碰到可猜测的Passkey Entry，也有办法继续推算。

所以Crackle不是暴力破解，更像是一把"钥匙探测棒"：它先判断锁的型号（配对方式），再用标配钥匙（可推导的TK或STK参数）开门。理解了这一点，你就能明白为什么一次完整的配对过程数据对工具来说如此重要。很多人在这一步卡住，根本原因不是命令记不住，而是不理解要抓什么、为什么抓。

4. Crackle实战：捕获、分析、解密

4.1 编译安装Crackle

Kali自带仓库里没有Crackle，需要手工编译。先安装开发库：

sudo apt install -y libpcap-dev

然后从Crackle项目的公开源码仓库下载源码，解压后进目录跑：

make

编译成功后在目录里会生成可执行文件，把它丢到系统路径里方便后续调用：

sudo cp crackle /usr/local/bin/ crackle --help

第一次编译容易撞见"找不到pcap.h"，原因就是libpcap-dev没装到位。装完再跑make，基本一次过。如果是在ARM架构的单板电脑上编译，个别依赖可能需要手动指定路径，但不影响主线流程。

4.2 抓取一条干净的配对过程

Crackle的输入是pcap文件，而pcap需要覆盖到完整的配对与连接过程。我的推荐场景是拿一个可重新配对的BLE设备来练手，比如常见的蓝牙插座或手环。操作顺序有讲究：

1. 先用bluetoothctl解除目标设备的历史配对记录
2. 让设备进入可发现/可配对状态
3. 启动btmon开始抓包
4. 从主机侧发起连接并完成整个配对流程
5. 配对完成后立刻停止btmon

抓包命令很简单：

sudo btmon -w ble_pair.pcap

等配对流程跑完，用Ctrl+C结束。这里最关键的细节是抓包窗口的起点：必须在配对发生前就开始记录，否则Crackle会因缺少设备能力信息或配对请求而无法分辨配对方式。我试过好几次，为了省时间少录几秒，结果整个pcap废掉，只能重来。

4.3 运行Crackle并解读输出

拿到pcap后，先让Crackle自动分析：

crackle -i ble_pair.pcap

如果目标设备的配对方式是Just Works，工具会输出类似这样的信息：

Reading from ble_pair.pcap Found pairing exchange Pairing method: Just Works Derived TK: 0x000000000000 Attempting to decrypt ...

看到这里就说明锁已经被打开了。用-o参数把解密后的流量导出：

crackle -i ble_pair.pcap -o ble_decrypted.pcap

这一步是Crackle的核心价值：它把本来被链路加密包裹的ATT层数据还原成了明文，后续在Wireshark里就能直接看到设备间的真实交互内容。

4.4 解密流量在Wireshark里的分析思路

用Wireshark打开解密后的pcap，重点看链路层的加密帧有没有被解析成明文。如果Crackle工作正常，这里已经是ATT/GATT层的数据了。

我常用的查看方式是先加一个组合过滤器，把广播帧和命令响应都滤掉，只看连接态下设备主动上报的特征值：

btle && !(btle.advertising) && (att.opcode || gatt.characteristic_value)

在这层流量里，你能看到设备上报的状态、App下发的控制指令、甚至固件升级时的数据流。蓝牙键盘的按键信息、智能门锁的开锁指令、传感器的上报数值，在这一步之后就全部暴露了。

注意：若目标用的是LE Secure Connections（ECDH那套），Crackle无能为力。这不算工具bug，只能说明设备的安全基线已经现代化了，你需要换一条路评估。

5. 不止Crackle：一条完整的蓝牙测试路径

5.1 设备发现：先知道周边有什么

排查蓝牙攻击面，第一步永远是扫描。经典蓝牙用：

hcitool scan sdptool browse 设备MAC地址

前者拿到设备名单，后者能看出设备对外暴露了哪些服务。

BLE设备多数不响应经典扫描，得用专门的低功耗扫描：

hcitool lescan

这个命令会持续刷新广播地址，执行几秒钟后Ctrl+C停掉。如果嫌命令行刷屏，bluetoothctl的scan子命令更友好，缺点是输出格式不够脚本化。

5.2 服务枚举：找出可交互接口

对BLE设备来说，扫描只是开始。价值更高的动作是连接后把GATT服务表拉出来：

bluetoothctl menu gatt connect 设备MAC地址 list-attributes

一个设备如果暴露了可写的特征值，就意味着可以直接往里写入数据控制它。这在IoT评估里是最典型的发现：厂商本来靠手机App下发控制，而对应的控制通道在协议层并没有额外鉴权，知道特征值UUID就能模拟写入。实测下来这种问题在低价智能家居设备里出现频率极高，值得重点测。

5.3 经典蓝牙与BLE的差异化测试清单

我在实际项目里习惯做成一张对照表，先定设备类型再选测试点：

这里的关键是：不同设备的安全短板差异极大。耳机往往不把配对当回事，门锁的天花板在于控制通道不鉴权，传感器网关则经常在广播包中泄漏业务数据。一套流程打天下不现实，得学会针对设备形态选重点。

5.4 其它值得关注的蓝牙测试工具

Crackle之外，还有几个在特定场景很有用的工具：

• Btlejack：支持BLE嗅探与数据包重放，适合验证重放类问题
• Bettercap：新一代网络测试框架，带BLE模块，适合做集成操作
• 各类GATT fuzz工具：用随机数据写特征值，看设备会不会崩溃

这些工具和Crackle配合起来，基本能走通"发现-连接-解密-控制"的完整评估闭环。当然，每个工具的搭建使用要另开篇幅，先把主线流程跑顺最重要。

6. 常见故障与排查记录

6.1 蓝牙接口不出现怎么办

现象：执行hciconfig -a没有任何输出。 排查顺序：

1. 看系统有没有识别到硬件：lsusb
2. 查内核日志：dmesg | grep -i bluetooth
3. 确认守护进程在跑：systemctl status bluetooth
4. 尝试手动挂载模块：modprobe btusb

我在虚拟机里遇到最多的就是情况1：宿主机蓝牙设备没有直通给虚拟机，或者直通配置错了。物理机上如果蓝牙模块固件没加载，查dmesg一般能看到固件路径相关报错。有个比较笨但有效的办法：换一个USB蓝牙适配器试一下，能快速区分是系统问题还是硬件兼容问题。

6.2 hcitool与bluetoothd的冲突

现象：hcitool scan执行后长时间无响应。 新版BlueZ默认走全新的内核管理接口，老hcitool的调用路径会变慢或受阻。这时候别硬等，直接用：

bluetoothctl scan on

或者用btmgmt做接口管理。如果一定要用hcitool做脚本自动化，可以试试重启蓝牙服务后再运行，有时能恢复。我在自动化脚本里已经全面切到btmgmt和bluetoothctl了，hcitool只留到做快速手测时用。

6.3 btmon抓包不全怎么办

现象：配对已经完成，但pcap里只有广播包和少量链路控制包。 原因多半是抓包窗口晚了，或者蓝牙设备在省电模式下没有把全部HCI事件上报。解决思路是把抓包起点提前到配对启动之前，另外关掉蓝牙相关的自动挂起：

echo on | sudo tee /sys/bus/usb/devices/*/power/control

这个命令会把所有USB设备的自动挂起关掉，对蓝牙这种需要持续响应的设备特别有效。跑完测试后记得把控制文件改回auto，不然一直保持唤醒状态会白白耗电。

6.4 Crackle报错

现象：Crackle提示"No usable pairing"之类的信息。 多数情况是抓包不完整，缺少配对参数交换；少数情况是目标用了LESC或其它Crackle不支持的安全模式。排查时先确认btmon记录里的配对请求、配对响应、临时密钥分发都有，再考虑协议兼容。我自己自测时遇到的这类报错，九成出在抓包时机上，重抓一次基本就好。

6.5 连上设备却控制不了

现象：GATT写入时报权限错误。 这其实不是故障，而是特征值本身没开放写权限。BLE服务表里每个特征值都有独立的读、写、通知权限，不是所有特征值都能改。要测控制类问题，得找到那些设置成可写（Write或Write Without Response）的特征值。这个信息在list-attributes的输出里会有，注意看权限字段。

7. 经验总结与两条忠告

7.1 给刚上手者的实操建议

蓝牙安全测试的试错成本比WiFi高，因为设备连接状态和协议状态机耦合得很紧。我建议刚上手的同学先固定一套最小环境：一台Kali物理机、一个USB蓝牙适配器、一个可重新配对的BLE开发板。在这个环境里反复练"发现-配对-抓包-解密"闭环，再考虑去评估真实设备。

操作时养成三个习惯：每次抓包前存时间戳；每个阶段的命令输出都截图或存日志；每次测试前都把目标设备重新恢复出厂配对状态。这三点能帮你省掉大量debug时间，尤其是最后一个习惯，很多时候设备连不上根本不是你的问题，而是它记住了上一次的配对状态。

7.2 授权测试与法律边界

蓝牙安全测试和WiFi测试有完全相同的底线：未经授权不得扫描、连接、抓包或破解。所有操作只能在你自己拥有的设备、或者已经取得明确书面授权的目标上进行。未授权行为，包括扫描身边不认识的设备，都是法律风险而不是技术能力。专业安全人员的价值正是在合规前提下帮别人发现和修复问题，而不是制造问题。

我不止一次在社区看到有人拿这套技术去"测试"公共场合的未知设备，结果给自己惹上不必要的麻烦。技术本身没有立场，但使用技术的人必须清楚边界。

7.3 后续学习方向建议

Crackle这条线走通后，下一步值得研究的方向有几个：

• 学习LE Secure Connections的配对细节，搞清楚新协议如何抵抗这一类破解
• 研究GATT服务的Fuzz测试，用脚本往各个特征值写入随机数据，观察设备稳定性
• 研究BLE中继攻击的原理，理解为什么"距离近"不等于"认证合法"
• 有条件的话做固件分析，把蓝牙协议栈固件拉出来逆向，排查隐藏后门

这条路越往深走，越需要综合能力：协议栈知识、无线射频知识、逆向工程能力都要补。但起点并不高，一台笔记本、一个适配器、一个愿意配合测试的开发板，完全足够。如果你也想试试，别犹豫，先把环境搭起来。蓝牙安全这扇门一旦进去，你会发现和WiFi是完全不同的世界。我到现在还记得第一次用Crackle解出一个设备的加密流量时，那种"居然这么轻易就破开了"的感觉。希望这篇记录能帮你少走点弯路。