kr00k漏洞深度解析：从AES-CCMP密钥清零到PoC实战

我第一次完整看完 kr00k 的 PoC 源码时，心里其实有点失望——实现它需要的硬件远没有想象中那么神秘。但等自己真在实验环境里把整个过程跑通后，那种“原来加密协议可以这样被撕开一个口子”的冲击感，还是会持续很久。

今天想聊的 CVE-2019-15126，也就是常说的 kr00k，是 2020 年初被公开的一类 Wi-Fi 芯片级漏洞。它的核心问题出在 WPA2/WPA3 个人版与企业版都依赖的 AES-CCMP 加密流程里：当一台设备因为某种原因从 AP 断开时，某些无线芯片会把会话密钥的关键部分清零，但连接状态又没有完全复位，后续发出的数据帧仍会照常加密——只不过加密用的密钥已经变成了一串全零值。r00kie-kr00kie 就是围绕这个漏洞设计的 PoC 利用工具，它通过特殊方式接管 Wi-Fi 芯片，把密钥凭空“拧出来”，再配合抓包数据还原明文。

这篇文章适合三类人：一类是做无线安全研究的同学，想了解 kr00k 的完整攻击链路；一类是网络运维或固件工程师，需要判断自己的设备、AP 和终端是否受影响；还有一类是刚入门的 CTF 或安全爱好者，想弄清楚这种“Wi-Fi 密文为什么能被解开”的经典案例。我会把背景、原理、工具使用、实验步骤、防护手段全部串起来讲，尽量让基础薄弱的人也能跟上。

1. kr00k 到底是什么，为什么值得关注

1.1 一枚藏在固件里的“失忆”逻辑

很多 Wi-Fi 芯片在实现加密引擎时，都会把加密要用的密钥暂存在内存里，方便硬件加速器直接读取。正常流程下，当设备正常断开 Wi-Fi，固件会清理这些密钥；当设备因为信号弱、漫游或被攻击者强制断开时，固件也会走类似的清理逻辑。

kr00k 的问题在于，某系列无线芯片在“异常断开”路径里犯了一个低级但影响巨大的错误：它清掉了密钥中用于数据加密的 Temporal Key（TK），却没有同步重置硬件加密引擎的当前状态。于是芯片后续仍会继续发送“加密”的数据帧，但加密时真正参与计算的密钥其实是清空后的全零值。更麻烦的是，这类芯片在发生这种情况后，接收端依然按照正常流程处理，不会主动报错。

用一个生活类比来说：门锁设计了一个“锁舌全部缩回”的应急状态，本意是断电时让门能打开，结果断一次电之后，门锁提示“已上锁”，可实际上任何一把钥匙都能拧开。被清零的 Wi-Fi 加密密钥，就是这么一把形同虚设的锁。

1.2 影响范围比想象中大得多

kr00k 影响的是采用某主流无线芯片厂商相关系列 Wi-Fi SoC 的终端设备。公开评估的说法是“数十亿台设备”，包括大量智能手机、平板、笔记本、IoT 设备、路由器和无线网卡都是受影响对象。原因很简单：这家芯片厂商的 Wi-Fi 模块出货量太大，几乎每个品牌的中低端设备里都可能见到它的身影。

值得注意的是，影响不区分 WPA2 还是 WPA3。虽然 WPA3 引入了更安全的握手与加密套件，但 kr00k 漏洞发生在连接断开后的数据面加密过程，与握手协议的新旧关系不大。只要底层芯片固件存在清零缺陷，WPA2 和 WPA3 的个人版、企业版都可能被打穿。

1.3 它和 KRACK、KR00K 的常见混淆

• KRACK（CVE-2017-13077 等）：针对 WPA2 四次握手过程的重装攻击，攻击者通过操纵握手消息，导致随机数 nonce 重用，从而重放或解密数据。问题出在协议交互逻辑。
• kr00k（CVE-2019-15126）：不需要干预握手过程，是在异常断开后，芯片固件错误地使用全零密钥对后续数据帧加密。问题出在固件实现。
• 两者唯一的共同点：都能绕过正常的 WPA2/WPA3 数据加密，让攻击者读到明文流量，但攻击阶段和利用思路完全不同。

2. 攻击原理拆解：密钥为何会在瞬间归零

2.1 先回顾 WPA2 的加密链路

正常情况下，一台设备连接 WPA2-PSK 网络时，会通过四次握手生成一对 Pairwise Transient Key（PTK）。PTK 拆开后包含三个关键部分：

• KCK：用于生成握手消息的 MIC 校验，保证握手消息不可伪造。
• KEK：用于加密后续的组播/单播密钥分发消息。
• TK：真正用于数据面加密的 Temporal Key，AES-CCMP 加密时主要依赖它。

数据面加密采用 AES-CCMP 协议，它融合了 AES-CTR（计数器模式加密）与 CBC-MAC（完整性校验）。简单说，每一帧数据的加密不仅依赖 TK，还依赖一个由发送端维护的 PN（Packet Number）构成 nonce。PN 不能重复，否则计数器模式会直接暴露明文关系。这就是为什么接着出现的“全零密钥”会如此危险：如果 TK 变成 0，而 PN 依然递增，虽然 PN 没有重用，但密钥本身等于没有，加密形同虚设。攻击者只要知道明文的一部分，就能推测出密钥流，再扩展到解密其他数据帧。核心公式可以理解为：

C = E(TK, nonce) XOR P

当 TK 被清零，E(0, nonce) 变成一个完全可复现的固定序列，C 与 P 的关系直接退化为一层脆弱的异或。攻击者只要捕获足够多的密文，配合已知明文或协议规律，就能恢复完整明文。

2.2 断开与重连：密钥归零的触发条件

kr00k 的触发条件是“非正常断开”。这种断开可以由以下几类情况引发：

• 信号干扰导致设备与 AP 之间的关联超时；
• AP 下发 deauthentication 帧（可能是正常管理，也可能是攻击者伪造）；
• 设备从一片区域漫游到另一片区域，切换过程中出现断链；
• 设备主动关闭 Wi-Fi 再快速开启，驱动没有完成完整复位流程。

在这类断开发生时，固件里的清理函数会把密钥缓冲区覆盖为零。如果芯片本身被影响，那么清理之后，数据路径的状态没有完全恢复，后续硬件队列中残留的、尚未发送的数据帧会被“加密”并发出。攻击者此时如果已在附近监听，就能捕获这些使用全零密钥加密的帧，然后离线解密。

这里有个细节需要注意：并不是断开后所有后续帧都能被解密。芯片固件在发出残留帧后，通常会进入一个不发送数据的状态，直到重新关联完成。可用的“受害帧”窗口往往只有几毫秒到几十毫秒，所以攻击者必须提前准备好监听和触发工具。这也是为什么 PoC 工具一般会反复尝试断开-监听-重连，而不是一次性搞定。

2.3 为什么受害者毫无感知

受害者当然不会感知到数据被解密了，因为解密发生在攻击者的设备上，无线信道上的协议交互完全正常。受害者的芯片在清零密钥后，其实已经处于一种“假加密”状态，它发出帧时毫不知情，AP 收到后因为密钥不匹配会直接丢弃。但这不意味着攻击失败：攻击者抓到的正是密文，它不关心 AP 是否能够正确接收，只要能在本地解开即可。

更有意思的是，kr00k 攻击者不一定需要和目标在同一频道长时间保持同步。常用的做法是：

1. 先携带目标 AP 的 BSSID 和信道信息；
2. 用另一张无线网卡持续发送伪造的 deauthentication 帧，强制目标设备频繁断开；
3. 用 PoC 工具或专用接收设备在目标信道抓取所有数据帧，尤其是断开瞬间发出的那些帧；
4. 通过工具内置的解密模块，用全零密钥批量尝试解密。

理论上一旦捕获到足够多的密文帧，攻击者就能在事后慢慢还原。PoC 工具 r00kie-kr00kie 最核心的价值，就是把“触发断开、抓取帧、提取密钥、批量解密”这四步整合进自动化流程里。

2.4 解密过程的技术要点

解密单帧时，需要同时掌握以下信息：

• 完整密文数据，包含 802.11 数据帧头；
• 已知的 PN 值，它位于 CCMP Header 的 8 字节区域中，包含 6 字节 PN 和 2 字节保留字段；
• TK 为全零的 16 字节密钥；
• 目的 MAC、源 MAC，以及帧体中的 QoS 控制字段，用于构造 AAD（Additional Authentication Data）；
• 对应帧的明文长度和加密前是否包含扩展字段。

把这些数据组装后，按 AES-CCMP 的标准流程，先计算并验证 MIC，再对帧体做 AES-CTR 解密。解密出的结果如果是合法 IP 包或 ARP 包，就可以判定为成功。实际工作中，判断是否命中通常看三样东西：

• IP 头版本号是否为 4 或 6；
• 源/目的 MAC 地址是否与无线帧头吻合；
• 更高层的端口号或协议标识是否符合预期（比如 TCP、UDP、DHCP）。

只要有一两个帧能解出完整 IP 包，基本上就可以证明目标设备存在 kr00k 漏洞。

3. r00kie-kr00kie 工具解析

3.1 工具的设计思路

r00kie-kr00kie 这个名字很明显是在玩梗，“r00kie”代表新手，“kr00kie”则是把 kr00k 和“crook”混在一起。从一个研究者的角度看，这个工具的设计思路很直接：它不尝试在网络层做复杂注入，而是走“芯片固件层”路线。

具体来讲，工具运行的目标设备通常是一块带 SDIO/SPI 接口的无线芯片评估板，比如常见开发板上的板载 Wi-Fi 模块。工具通过定制的固件或调试接口，读取芯片内存里的密钥区域，并将这些信息导出到 PC 端。PC 端再配合 pcap 抓包文件，把所有可疑密文帧按“全零密钥”批量解密。

这种设计的好处很明显：

• 不需要和目标设备处于同一操作系统内；
• 不依赖传统无线网卡的 monitor 模式，因为普通的网卡驱动根本没有读取芯片内存的接口；
• 实验结果可靠，可以直接看到密钥清零前后的变化；
• 解耦了“抓包”和“解密”两个步骤，方便研究者反复调试。

3.2 环境准备与依赖

在复现这个 PoC 时，我的环境是这样准备的：

• 一台 Linux 主机，建议 Ubuntu 20.04 或 Kali；
• 一张支持 monitor 模式的无线网卡，用于发送 deauthentication 帧和抓取普通 802.11 流量；
• 一套带受影响芯片的开发板或无线模块，比如某些可刷写自定义固件的 Wi-Fi 模组；
• 工具有可能依赖 libpcap、libssl、cmake、arm-none-eabi-gcc 等编译组件；
• 如果采用 SDIO/SPI 读取方案，还需要逻辑分析仪或专用转接板，用于读取芯片与外设之间的总线信号。

依赖安装可以参考以下命令，具体按工具源码里的 README 为准：

sudo apt update sudo apt install -y libpcap-dev libssl-dev cmake build-essential git sudo apt install -y gcc-arm-none-eabi

这些依赖的核心作用是：libpcap 负责读写 pcap 文件，libssl 提供 AES 加解密实现，cmake 用来构建跨平台二进制，arm-none-eabi-gcc 用于编译芯片侧的自定义固件。

3.3 编译与部署流程

拿到工具源码后，通常的编译方式如下：

git clone <项目仓库地址> cd r00kie-kr00kie mkdir build && cd build cmake .. make -j$(nproc)

如果一切顺利，会在 build 目录下生成几个可执行文件，分别负责：

• 向目标板写入“密钥导出固件”；
• 读取导出的密钥快照；
• 对 pcap 文件执行批量解密。

把编译好的二进制烧录到开发板上时，需要注意接口连线：如果是 SPI 方案，一般要接 CLK、MOSI、MISO、CS、GND 五根线；如果是 SDIO 方案，则接 CLK、CMD、DAT0-DAT3 和 GND。接线错误很容易导致芯片识别不到，我在第一次实验时就是因为把 CLK 接到了别的引脚，整整排查了一个下午。

烧录完成并启动后，工具会在串口控制台输出类似“waiting for trigger...”的提示。此时就可以准备进入实战测试了。

3.4 工具自测与数据校验

正式测试之前，我强烈建议先做一轮自测。工具源码一般会附带一组构造好的 pcap 样本，里面包含了模拟的 kr00k 密文帧和对应明文。你可以先用样本跑一遍解密流程，确认工具本身工作正常。

执行解密的典型命令形态如下：

./kr00k-decrypt --key-file key.bin --pcap capture.pcap --output plain.pcap

如果工具内置了解密结果统计功能，运行后通常能看到类似：

Loaded 1024 frames from capture.pcap Decrypted 37 frames successfully Skipped 14 frames (non-CCMP)

看到成功解出 37 帧时，说明你的工具链路多半没问题。如果这一关过不了，后边的真实抓包基本没有意义，因为问题可能出在解密算法或帧解析逻辑上。

4. 从零开始的 PoC 实验

4.1 搭建隔离实验环境

要完整复现 kr00k 攻击，不建议直接拿办公室或家里的网络做实验，毕竟这属于安全研究里的“实弹演习”，边界必须清晰。最好的做法是搭一个完全隔离的测试环境：

• 准备一台旧的 AP 或无线路由器，设置独立 SSID，并启用 WPA2-PSK；
• 准备一台目标设备，例如旧款手机或 IoT 开发板，确认其 Wi-Fi 芯片属于受影响型号；
• 准备攻击设备：一台笔记本，插入支持 monitor 模式的无线网卡；
• 准备 PoC 硬件工具：r00kie-kr00kie 读取板，直接与被测设备的 Wi-Fi 芯片通过 SPI/SDIO 连接。

注意，实验环境里不要再接入任何其他真实业务流量。这不仅是为了合规，也是为了保证抓包文件干净，方便后续分析。

4.2 步骤一：抓取正常关联流量

在攻击触发之前，先把攻击网卡调到目标信道，抓取一段目标设备与 AP 之间的正常关联流量。目的是确认频道、BSSID、双方 MAC 地址，以及抓到正常的 CCMP 加密帧。

sudo airmon-ng start wlan0 6 sudo tcpdump -i wlan0mon -w normal.pcap

这里假设目标信道是 6。如果目标 AP 在别的信道，可以先用 airodump-ng 扫描确认：

sudo airodump-ng wlan0mon

找到目标 AP 的 BSSID 和信道后，重点观察目标设备的关联、认证、四次握手过程。这些流量可以帮助你确认加密参数，而且在后续解密时，可以用来验证密钥推导是否正确。

4.3 步骤二：强制断开与密钥归零

这一步是 kr00k 触发的重要拐点。攻击者向目标设备持续发送伪造的 deauthentication 帧，促使目标设备不断进入“断开-重连”状态。常用命令：

sudo aireplay-ng -0 5 -a <AP_BSSID> -c <Target_MAC> wlan0mon

其中-0 5表示连续发送 5 组 deauth 帧，-a是 AP 的 MAC，-c是目标设备的 MAC。如果不想在命令行里直接注入，也可以把 deauth 帧提前捕获下来，再反复重放。关键点是：让目标设备频繁异常断开。

在这期间，PoC 硬件工具同时在监听芯片总线。理想情况下，你会看到工具输出一个“key cleared”的信号，随后抓到的数据帧里开始出现疑似使用全零密钥加密的帧。这些帧与正常 CCMP 帧看起来几乎一样，只是用固定密钥无法解出合法明文。

如果发现目标设备断开后直接休眠了，或者芯片的发送队列本来就空，可以适当增大 deauth 发送频率、缩短重连间隔。还有一个实用技巧：把目标设备的省电模式关掉，或让它在断开前处于持续发包状态，可显著提高捕获概率。

4.4 步骤三：解密数据帧

抓包完成后，把 pcap 文件和工具导出的 key.bin 一起交给 r00kie-kr00kie 的解密模块：

./kr00k-decrypt --key-file key.bin --pcap attack.pcap --output decrypted.pcap

如果实验顺利，解密结果里会看到不少完整 IP 包。用 Wireshark 打开 decrypted.pcap，可以进一步确认：

• 帧的源 MAC 地址是否与被测设备一致；
• 帧的目的 MAC 地址是否是 AP；
• 帧体内是否包含 TCP/UDP/ARP 等上层协议；
• 协议字段和端口是否符合你预期看到的业务流量。

我在实际测试中，最常解出来的是 ARP 请求和 DNS 查询。因为这类报文长度短、特征明显，非常适合作为漏洞是否确认的判定依据。

还有一条经验：不要只解一帧就下结论。解出来的帧如果只有零星几帧，也有可能是误报或偶然的密钥碰撞。正常情况下，一次完整的断连事件应该能解出连续十几帧甚至几十帧的明文。若连续事件后只解出 1~2 帧，建议检查是否抓到了其他网络的流量，或目标芯片可能只是部分受影响。

4.5 实验数据的判定标准

验证一个 kr00k 实验结果是否有效，可以参考这些标准：

• 触发前后分别抓到了相同信道、相同 BSSID 的 CCMP 帧；
• 工具导出密钥时，观察到密钥内容从完整的 16 字节变成全零或部分全零；
• 解密后的帧能通过 IP 首部校验，且源/目的 MAC 与无线帧头一致；
• 解密结果中出现的上层协议不是随机字节，而能看出明确的协议结构；
• 多个独立断连事件都能复现出相似效果。

建议把每次实验的抓包文件、工具日志、解密输出都归档保存，方便后续审计或写报告。归档文件命名最好包含时间、设备型号、固件版本、触发方式，例如test_bcm_x_20250101_times.log。

5. 修复方案与检测思路

5.1 固件升级是根本解法

kr00k 修复的重心不在上层应用，也不在 WPA2 配置，而在于芯片固件和驱动。设备厂商需要更新 Wi-Fi 芯片固件，重新实现密钥清理逻辑，确保异常断开后不会用全零密钥继续发送数据。作为普通用户，能做的事情很明确：

• 及时更新手机、笔记本、路由器和物联网设备的系统固件；
• 关注设备厂商发布的安全公告，搜索关键词 CVE-2019-15126 或 kr00k；
• 不要长期使用停止维护的旧路由器；
• 企业网络管理员应在补丁发布后尽快在测试环境验证，再推送到生产网段。

如果你是企业安全负责人，建议同时检查员工终端、访客 AP、IoT 设备三类资产的固件版本。因为攻击者只要把一个受影响终端放在办公网里，抓到 kr00k 密文后，就可能还原出该终端的部分明文流量，包括内网 DNS 查询、ARP 活动，严重情况下还可能泄露未加密的敏感协议内容。

5.2 网络侧检测方法

如果说固件升级是治本，那网络侧检测就是治标阶段的“侦察兵”。kr00k 攻击在无线链路上有明显特征：攻击者在短时间内高频发送 deauthentication 帧，然后目标设备频繁重连。这类行为可以用无线入侵检测系统（WIDS）监测：

• 统计同一 BSSID 下的 deauth 帧速率，超过阈值就告警；
• 观察目标设备在几秒内的关联/断开事件数量；
• 捕获断开后立刻出现的数据帧，用全零密钥批量解密验证。

不过要说明，网络侧检测并不能完全替代终端修复。因为你只能观察到“疑似攻击行为”，无法百分百判断对方是否真的用了 kr00k。更有效的做法还是利用 EDR 或终端管理平台，核查设备 Wi-Fi 芯片的固件版本，再结合无线侧告警联动。

5.3 临时缓解措施

如果设备暂时无法升级固件，以下措施可以降低风险：

• 优先使用有线网络，或把敏感业务切到不受影响的 Wi-Fi 芯片设备上处理；
• 将无线设备配置为更积极的漫游或断开策略，减少短时间内的异常断连窗口；
• 在 AP 侧关闭不必要的快速漫游功能，增加攻击者触发断开的难度；
• 对开放网络、访客网络单独隔离，避免漏洞设备与核心业务同处一个广播域；
• 加密上层应用流量，例如启用 HTTPS、DNS-over-TLS、IPsec 隧道，即使底层 Wi-Fi 密文被解，攻击者看到的也是二次加密后的内容。

必须强调的是，上层加密只能算缓解，不是根治。kr00k 让底层数据加密失效后，即便最上层有 TLS，攻击者依然能观察到流量长度、目标地址等元数据。对于某些应用，这些元数据本身就有很高价值。

6. 常见问题排查与实战避坑

6.1 工具运行中的常见报错

这里整理一张我在复现过程中遇到的高频问题表，供你对照排查：

6.2 实验结果不稳定的原因

很多人在复现时最容易踩的坑，就是觉得“我明明按步骤做了，怎么结果时好时坏”。这不是工具不稳定，而是和无线环境的随机性直接相关：

• 2.4GHz 频段干扰极大，其他 Wi-Fi、蓝牙、微波炉都会影响抓包质量；
• 目标设备如果离攻击网卡太远，抓到的帧信号质量差，可能导致帧体损坏；
• deauth 发送次数过多，目标设备可能直接进入“拒绝重连”的保护状态；
• 芯片固件版本不同，密钥清零的窗口和残留队列长度不同；
• 被测设备处于省电模式时，发送队列几乎是空的，自然没有可解的帧。

建议将实验放在 5GHz 频段、选择相对空旷的室内环境，并且固定目标设备的位置，不要移动。条件允许的话，用三脚架把天线架高，减少地面反射和多径干扰。我当时为了拿到稳定的实验结果，专门清空了一个小房间里的其他无线设备，只保留一套测试 AP、一块目标开发板、一张攻击网卡和 r00kie-kr00kie 读取板。

6.3 合规与边界：安全研究必须守住红线

这一点我每次都要强调。像 r00kie-kr00kie 这类工具，属于典型的“双刃剑”。如果你把它用在未经授权的网络上，那不只是道德问题，还可能触犯相关法律法规。个人安全研究者如果想做验证实验，请务必遵守这些基本原则：

• 只在自己拥有或拿到明确书面授权的设备和网络里测试；
• 不使用工具影响正常生产业务；
• 不以窃取他人数据为目的进行任何抓包或破解；
• 实验结束后及时清理抓包文件，删除可能含敏感信息的 pcap；
• 不在公开场合发布他人的明文流量片段。

安全研究的价值在于发现和修复问题，而不是制造破坏。建议在文章、报告或发布工具配置时，都明确标注“仅供授权的安全测试使用”。我见过不少入门者因为好奇踩了红线，最后后悔莫及。做研究之前，先想清楚边界，比学会工具本身更重要。

6.4 实操中总结的几条硬经验

最后分享几条我在整个复现过程中反复验证过的经验，希望能帮你少走弯路：

第一，抓包的位置和天线方向很重要。PoC 工具读取芯片密钥是通过有线接口，但解密用的密文帧还是要靠无线监听。如果监听网卡离目标太远，即使 PoC 工具触发成功，也很难抓到干净的数据帧。

第二，先确认目标设备是否真的处于“待发送”状态。断开之后，目标设备如果刚好没有数据流量，就不会有残留帧发出。你可以在触发前，让目标设备持续产生一些背景流量，比如放一个循环 ping 或 UDP 小包发生器。

第三，工具导出的密钥，不一定每次都是 16 字节全零。有些芯片可能只清零了 TK 中的部分字节，或只清零了 KEK。遇到这种情况，不要死板地用全零密钥去解，可以先检查导出密钥的十六进制内容，分析清零模式，再调整解密参数。

第四，保存好每一次抓包和日志。kr00k 的复现，很多时候是靠“多跑几轮”堆出来的。第一次失败、第二次失败，第三次可能就成功了。把每次失败的现场记录保存下来，对比差异，比盲目重试高效得多。

我在实际测试中发现，把目标设备的无线省电模式关闭、发送速率固定到较低档位，能让 kr00k 的成功率提升非常明显。原因是低速率发送时帧间隔变长，断连瞬间队列中残留的帧数更多，能给解密提供更充分的样本。如果你的实验一直不出结果，建议从这几个方面逐一调整。

玩了一圈下来，这个漏洞给我的最深印象不是“解密了多少帧”，而是芯片固件里一个看似不起眼的清理逻辑失误，能够把多年积累的 Wi-Fi 加密防线打出一个口子。安全研究的意义，往往就是把这样隐藏的工程问题挖出来，让整个行业重新审视那些“默认安全”的底层组件。我自己做完这轮实验之后，对无线设备采购、固件更新和网络分区都有了更敏感的判断习惯。希望这篇文章能帮你在 kr00k 的原理和实操层面建立清晰的认知，也提醒你：如果手上的设备还有未修复的固件，抓紧处理才是正事。