本仓库包含 FragAttacks 工具。它可以测试 Wi-Fi 客户端和接入点是否存在碎片化 与聚合攻击。这些漏洞会影响_所有_受保护的 Wi-Fi 网络。有关这些漏洞的更多信息， 请参阅 fragattacks.com。
以下附加资源可用：
有关自 2020 年 8 月 11 日以来对工具所做出更新的详细概述，请参阅更新日志。 该更新日志还包含 FragAttacks 工具所基于的 hostap 版本信息。
请注意，针对 WPA2 和 WPA3 的攻击是相同的，因为它们的 CCMP 和 GCMP 加密算法完全相同。 较旧的 WPA 网络默认使用 TKIP 加密，而针对 TKIP 的攻击 的适用性已在论文和网站中讨论。为了说明 Wi-Fi 从诞生之初就一直存在漏洞，论文和网站 还简要讨论了针对 WEP 的攻击的适用性。
仅支持特定的无线网卡。这是因为某些网卡可能会覆盖注入帧的序列号或片段号，或者可能重新排列 不同优先级的帧，这会干扰测试工具（即工具可能会判定某个设备是安全的，而实际上它并不安全）。 我已确认以下网卡可以正常工作：
最后两列的含义如下：
_是_表示该网卡在给定模式下开箱即用。已修补驱动/固件 表示该网卡在配合修补后的驱动和/或固件时兼容。 _否_表示该网卡不支持此模式。 我建议在混合模式下使用测试工具。
请注意，USB 设备可以在虚拟机中使用，并且修改后的驱动和/或固件可以安装在该虚拟机中。 不过，我发现使用虚拟机会使网卡可靠性降低；如果你无法原生安装修改后的驱动/固件， 我建议改用 Live USB 镜像。
我对上述网卡的使用经验可在此处找到。总结如下：
混合模式下的 AWUS036ACM 配合我们最新的驱动 表现可靠，这也是我推荐的型号。一个更便宜但几乎相同的设备是采用 MT7612U 芯片组的设备。更多信息请参见此处。
我之前推荐在混合模式下使用 Technoethical N150 HGA。该适配器与 TP-Link TL-WN722N v1.x 相同，需要使用修补后的驱动和固件。这是经过 最充分测试的适配器之一，但很难买到。因此我现在推荐使用 AWUS036ACM。
Intel 3160 和 8265 受支持并经过了广泛测试。有时它们的固件会崩溃，但 重启后网卡即可再次使用。Intel AX200 与测试工具不兼容。
WN111v2 似乎工作良好，尽管我没有对其进行广泛测试。
AWUS036ACH 的驱动不是 Linux 内核的一部分，需要安装单独的 驱动。在 Kali 上，你可以通过包管理器安装此驱动。该网卡未经广泛测试。
如果你找不到上述网卡，可以搜索替代网卡，这些网卡 有很大概率也能正常工作。当使用未明确支持的网卡时， 我强烈建议先运行注入测试，然后再使用该网卡， 并针对已知存在漏洞的实现使用该工具，以确认工具可以正常工作。
测试工具已在 Ubuntu 20.04 上使用内核 5.8 进行了测试。如果你使用其他 Linux 发行版，请注意 仅支持低于或等于 5.12 的内核版本。
使用 Ubuntu 20.04 时，你必须首先按如下方式安装内核 5.8。请注意，你现有的内核 将继续保留，并且默认情况下仍会被使用：
sudo apt install linux-image-5.8.0-63-generic linux-headers-5.8.0-63-generic linux-hwe-5.8-headers-5.8.0-63 \
linux-modules-5.8.0-63-generic linux-modules-extra-5.8.0-63-generic
现在重启 Ubuntu，启动时按住 shift 键，选择“Advanced options for Ubuntu”，然后通过选择 “Ubuntu, with Linux 5.8.0-63-generic”来启动内核 5.8。你可以编辑 GRUB 配置 使 Ubuntu 默认使用该内核版本。在当前运行的内核下继续执行后续说明。
安装所需依赖：
sudo apt-get update
sudo apt-get install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
libdbus-1-dev git pkg-config build-essential macchanger net-tools python3-venv \
aircrack-ng rfkill firmware-ath9k-htc
# 注意：在 Kali Linux 上使用 firmware-atheros 包而不是 firmware-ath9k-htc
现在克隆此仓库、构建工具，并配置一个虚拟 python3 环境：
git clone https://github.com/vanhoefm/fragattacks.git fragattacks
cd fragattacks/research
./build.sh
./pysetup.sh
上述说明只需执行一次。使用 git 拉取新代码后，你需要再次执行 ./build.sh 和 ./pysetup.sh。
使用以下命令安装已修补的驱动：
sudo apt-get install bison flex linux-headers-$(uname -r)
git clone https://github.com/vanhoefm/fragattacks-drivers58.git fragattacks-drivers58
cd fragattacks-drivers58
make defconfig-wifi
make -j 4
sudo make install
这将为 Linux 支持的大多数网卡编译驱动。如果你只想编译
我明确测试过的网卡的驱动，请改用 make defconfig-experiments。
你可能会看到以下警告：
make defconfig-wifi 时，你可能会看到与 -Wyacc 和 -Wformat-overflow 相关的警告。
只要驱动能成功编译，就可以忽略这些警告。.. needs unknown symbol .. 的警告。只要这些警告不包含
/lib/modules/*/updates/ 目录且编译出的驱动正常工作，就可以忽略它们。SSL error 和 sign-file 命令的警告。这意味着对内核模块进行
数字签名失败。通常可以忽略。cat /sys/module/mac80211/parameters/fragattack_version
来验证修改后的驱动是否已就位。如果该文件存在，则说明修改后的驱动已成功安装。现在安装已修补的 ath9k_htc 固件：
cd research/ath9k-firmware/
./install.sh
# 现在重启
./install.sh 脚本假定 ath9k_htc 固件镜像位于
目录 /lib/firmware/ath9k_htc 中。如果你的系统不是这种情况，
则必须手动将 htc_7010.fw 和 htc_9271.fw 复制到适当的目录。
安装已修补的驱动和固件后，你必须拔掉 Wi-Fi 适配器并 重启系统。如果你的 Linux 内核被更新或已修补的驱动被更新， 则必须再次执行上述说明。
请注意，即使你的设备开箱即用，我仍然建议安装修改后的 驱动，因为这可以确保内核和驱动代码中不会出现意外的回归问题。
如果你无法原生安装修改后的驱动/固件，可以下载一个 Live USB 镜像，其中包含修改后的驱动/固件以及我们的测试工具。 或者，你可以使用带有 USB 网卡的虚拟机，尽管我发现 在实际使用中虚拟机不太可靠。
每次要使用测试工具时，你都必须首先以 root 身份加载虚拟 python 环境。 可以使用以下命令完成：
cd research
sudo su
source venv/bin/activate
你现在应该在网络管理器中禁用 Wi-Fi，
以免它与测试工具发生干扰。同时确保没有其他网络服务在产生
出站流量。你可以通过执行 ./droptraffic.sh 使用 iptables 阻止流量来确保这一点
（重新启动即可恢复）。可选地，使用 sudo airmon-ng check 检查还有哪些
其他进程可能正在使用无线网卡并可能干扰我们的工具。
测试工具既可以测试客户端，也可以测试 AP：
测试 AP：通过编辑 research/client.conf 配置你要测试的 AP。这是一个
标准的 wpa_supplicant 配置文件，有关其支持的所有选项的概览，
请参阅 hostap 文档。
测试客户端：你必须使用 --ap 参数执行测试工具（见下文）。这会
指示工具创建一个名为 testnetwork、密码为 abcdefgh 的 AP。使用你要测试的
客户端连接到该网络。默认情况下，客户端必须使用 DHCP 请求 IP。
要编辑所创建 AP 的属性（例如其创建信道），
你可以编辑 research/hostapd.conf。
此模式只需要一张无线网卡，但通常需要已修补的驱动和/或 固件。有关如何安装已修补驱动/固件，请参阅已修补的驱动，有关兼容的 网卡，请参阅受支持的网卡。在此模式下使用以下命令执行测试 工具：
./fragattack.py wlan0 [--ap] $COMMAND
此模式的一个优点是，在测试可能进入睡眠状态的客户端时，它的表现相当好。 不过，如果可能，我建议禁用被测客户端的睡眠功能， 参见处理睡眠模式。
此模式需要两张无线网卡：一张将作为 AP 或客户端，另一张 将用于注入帧。其优点是，此模式可能无需已修补的 驱动即可工作。在此模式下使用以下命令执行测试工具：
./fragattack.py wlan0 --inject wlan1 [--ap] $COMMAND
这里接口 wlan0 将充当合法的客户端或 AP，wlan1 将用于注入 帧。对于 wlan0，可以使用任何在 Linux 上支持普通客户端或 AP 模式的网卡。对于 wlan1，必须使用根据受支持的网卡支持注入模式的网卡。
在此模式下测试客户端时，注入的帧可能是在客户端处于睡眠状态时发送的。 这会导致攻击失败，因此你必须确保客户端不会进入睡眠状态。
此模式是实验性的，仅供研究使用。更多信息请参见 hwsim 模式详情。
你可以按照接口模式中的说明运行测试工具来测试设备，
并将 $COMMAND 替换为下表中的命令之一。我们假定客户端会
使用 DHCP 请求 IP（如果不是这种情况，请参阅静态 IP 配置）。
除非另有说明，所有命令都同时适用于客户端和 AP。
如果设备对给定 $COMMAND 对应的攻击存在漏洞，工具会输出 TEST COMPLETED SUCCESSFULLY；
如果设备不存在漏洞，则输出 Test timed out! Retry to be sure, or manually check result。
测试完成后，你可以使用 CTRL+C 关闭测试工具。
大多数攻击都有若干细微变体，由不同的 $COMMAND 值表示。
验证某些测试的结果需要在被测设备上运行 tcpdump 或 wireshark（下 表会说明是否必须使用 tcpdump）。该 tcpdump 抓包必须只包含通过 PHY 和 MAC 层处理的报文。例如，在 Linux 上，应在无线接口处于 “managed”或“ap”模式（而非 monitor 模式）时进行抓包，这意味着抓包 只会包含在 Wi-Fi 层通过处理的报文。有关如何在不于 AP 上运行 tcpdump 的情况下 执行某些测试的讨论，请参见避免在 AP 上使用 tcpdump。
要验证你的测试环境，下表中的第一个命令会执行一次普通 ping，该 ping 必须 成功。第二个命令以两个碎片化 Wi-Fi 帧发送 ping，只应在 被测设备不支持碎片化这一罕见情况下失败。如果这些测试之一 无法正常工作，请按照网卡注入测试中的说明 确保你的网卡正确注入帧。如果被测客户端可能进入睡眠模式， 请参阅处理睡眠模式。
第三个、第四个和第五个命令不是攻击，而是验证设备的基本去碎片化行为， 将在下表之后进一步讨论。
命令与 CVE 的对应关系如下所列。请注意，对于实现缺陷，我们列出的是参考 CVE 标识符，但厂商可能会使用不同的 CVE，因为实现漏洞通常 会为每个受影响的代码库分配一个唯一的 CVE。不过，我们仍建议始终引用这些参考 CVE，以此作为一种简便方式来指代所发现的每类实现缺陷。
ping：此测试必须始终成功。如果失败，则说明测试环境有问题。- ping I,E,E：此测试应能在所有现代笔记本电脑、智能手机和 AP 上成功。如果失败，则测试设置可能存在问题。尝试添加 --icmp-size 100 参数作为修复。如果加上此额外参数后测试成功，则所有其他测试也必须使用此额外参数执行。我唯一一次遇到此测试因正当理由失败，是被测设备不支持接收分片帧的情况，这在轻量级 IoT 设备以及例如 OpenBSD 上可能出现。ping I,E,E --delay 5：此测试用于检查两个分片之间可接受的最大延迟。如果此测试不成功，请尝试使用 --delay 1.5 或更低的值重试。例如，Linux 会在 2 秒后从内存中移除分片，这意味着 1.8 的延迟可以成功，而 2.2 将导致无应答。如果最大可接受延迟较低，则其他测试中发送的所有分片都必须在该最大可接受延迟内发送。否则，测试将因琐碎原因失败，你可能会得出设备不易受攻击的结论，尽管它实际上易受攻击。
ping-frag-sep：此测试发送一个被无关帧分隔的分片 Wi-Fi 帧。也就是说，它先发送第一个分片，然后是一个（正常的）无关 Wi-Fi 帧，最后是第二个分片。如果此测试失败，则（默认的）混合密钥攻击和缓存攻击很可能也会失败（因为它们需要在两个分片之间发送其他帧）。如果接收方检查分片是否具有连续的数据包编号（见下一个测试 ping-frag-sep --pn-per-qos），此测试也会失败。
ping-frag-sep --pn-per-qos：与上述相同，但添加 --pn-per-qos 参数可确保 ping 请求的两个分片具有连续的数据包编号（PN）。这是接收方为了安全起见_应该_验证的内容。不幸的是，在我们的结果公开之前，许多实现并不验证 PN 是否连续。如果接收方不按 QoS TID 跟踪最新收到的数据包计数器，此测试可能会失败，在这种情况下，你可以忽略其他包含 --pn-per-qos 参数的测试。
测试 ping I,E --amsdu 检查实现是否_支持_非 SPP A-MSDU（它不检查设备是否易受 CVE-2020-24588 攻击）。为防止攻击，理想情况下网络必须强制使用 SPP A-MSDU 并丢弃所有非 SPP A-MSDU。然而，目前大多数供应商正在实施临时缓解措施（见论文第 7.2 节）。因此，你必须使用以下两个测试来检查设备是否易受聚合（A-MSDU）攻击（CVE-2020-24588）：
amsdu-inject：此测试模拟论文第 3.2 节中描述的 A-MSDU 注入攻击。具体来说，它发送一个开头同时也是有效 LLC/SNAP 头的 A-MSDU 帧（因为我们的参考攻击中也会出现这种情况）。如果此测试成功，则设备易受 CVE-2020-24588 攻击。
amsdu-inject-bad：某些设备错误地解析以有效 LLC/SNAP 头开头的 A-MSDU 帧，导致上述测试失败。在这种情况下，请改用 amsdu-inject-bad（见论文第 3.6 节）。请注意，如果此测试成功，攻击的影响实际上与正确解析此类帧的实现相同，即设备易受 CVE-2020-24588 攻击。
对 AP 运行混合密钥测试时，AP 必须配置为定期（例如每分钟）执行新的四次握手来更新会话密钥（PTK）。在等待此 PTK 重更新握手时，工具将显示 Client cannot force rekey. Waiting on AP to start PTK rekey。对于少数 AP，测试工具还可以通过添加 --rekey-req 参数来请求更新 PTK，这意味着无需将 AP 配置为定期更新密钥。
某些 AP 无法配置为定期更新会话密钥（PTK）。对于这些 AP，你可以改为尝试缓存攻击测试。如果 AP 易受缓存攻击，那么它很可能也易受混合密钥攻击（除非有强有力的证据反驳这一点，例如代码审计表明混合密钥攻击已被阻止）。如果 AP 不易受缓存攻击，那么我们对它是否易受混合密钥攻击无法作出判断，在这种情况下，我建议改为进行代码审计。
ping I,F,BE,AE --pn-per-qos：额外的 --pn-per-qos 参数确保两个注入的分片具有连续的数据包编号，这是混合密钥攻击针对某些设备（例如 Linux）成功所必需的。
一些设备以不同方式实现四次握手，这将影响这些测试是否成功。如果测试失败，建议同时执行扩展漏洞测试中列出的混合密钥攻击测试。
测试 AP 时，工具先发送第一个分片，然后尝试与 AP 重新关联，最后发送第二个分片。然而，并非所有 AP 都能正确支持重新关联过程。在这种情况下，请添加表中所示的 --full-reconnect 选项，它使测试工具在发送第一个分片后_解除认证_。
测试客户端时，工具发送第一个分片，_解除关联_客户端，一旦客户端重新连接，就发送第二个分片。理想情况下，客户端会在发送解除关联帧后立即重新连接。这可能需要在被测客户端上禁用所有其他网络。我还发现某些客户端似乎无法正确处理解除关联，在这种情况下，你可以添加表中所示的 --full-reconnect 选项，改发解除认证帧。
我发现最好将每个缓存攻击测试执行多次。有时缓存攻击测试可能会失败，尽管实现_确实_易受攻击。这可能是由于背景噪声、其他设备向被测设备发送帧等原因造成的。
ping I,E,R,AE [--full-recon]：此处第二个分片在与被测设备重新连接后立即发送，这在设备在短时间内从内存中清除分片的情况下很重要。请注意，full-recon 是 full-reconnect 的简写。
ping I,E,R,E [--full-recon]：此处第二个分片在与被测设备重新连接 1 秒后发送，这在握手完成与安装协商密钥之间存在较小延迟时可能有用。
总的来说，测试设备是否易受缓存攻击可能相当繁琐。因此，我还建议进行代码审计，以检查分片在解除关联或解除认证离开网络后，或在重新关联后，是否仍保留在内存中（这也可以通过调试打印进行动态检查）。如果分片保留在内存中，即使尚不清楚它是否可被利用，你也应将其视为风险。这类似于知道某个实现存在缓冲区溢出，但（尚）不知道如何利用它。
在我们的实验中，此测试仅对 Linux 和不支持分片的设备失败。
ping I,E,P 和 linux-plain：如果此测试成功，所产生的攻击在论文第 6.3 节中有描述。概括而言，与 A-MSDU 或缓存漏洞结合时，可利用它来注入数据包。当不与任何其他漏洞结合时，其影响因实现而异（CVE-2020-26147）。
ping I,P,E：如果此测试成功，那么_如果_网络正在使用分片，向设备注入明文帧将易如反掌（CVE-2020-26147）。
ping I,P：如果此测试成功，则该实现接受受保护 Wi-Fi 网络中的明文帧，从而允许轻易地注入数据包（CVE-2020-26140）。
ping I,P,P：如果此测试成功，则该实现接受受保护 Wi-Fi 网络中的_分片_明文帧，从而允许轻易地注入数据包（CVE-2020-26143）。
以下两个测试发送广播帧，这些帧不会被自动重传，因此建议多次执行它们。这是因为背景噪声可能会阻止被测设备接收注入的广播帧。在我的实验中，主要受影响的是客户端（在被测 AP 中，只有 Free/NetBSD 的 AP 受影响）。
ping I,D,P --bcast-ra：连接后，在明文广播的第二分片中发送单播 ping。此攻击变体的结果由测试工具自动检查。
ping D,BP --bcast-ra：此处上述帧在连接到网络时（即在四次握手期间）发送。这很重要，因为某些客户端和 AP 仅在完成四次握手之前易受攻击。要确认此测试的结果，你必须在受害者上运行 wireshark 或 tcpdump，并监视注入的 ping 请求是否被受害者收到。在 tcpdump 中，你可以使用过滤器 icmp，在 wireshark 中，你还可以使用过滤器 frame contains "test_ping_icmp" 来更容易地检测此 ping 请求。在我的实验中，主要受影响的是客户端。
eapol-amsdu I,P：这是针对论文第 6.5 节中讨论的实现特定漏洞的标准测试。客户端和 AP 都可能易受攻击。其结果由测试工具自动检查。
以 BP 结尾的测试（eapol-amsdu BP 和 eapol-amsdu-bad BP）：这些测试在四次握手执行期间注入恶意帧。要确认此测试的结果，你必须在受害者上运行 wireshark 或 tcpdump，并监视注入的 ping 请求是否被受害者收到。在 tcpdump 中，你可以使用过滤器 icmp，在 wireshark 中，你还可以使用过滤器 frame contains "test_ping_icmp" 来更容易地检测此 ping 请求。
以 eapol-amsdu-bad 开头的测试（eapol-amsdu-bad BP 和 eapol-amsdu-bad I,P）：某些实现会错误地处理前 6 个字节同时也等于有效 EAPOL RFC1042 头的 A-MSDU 帧。要测试这些实现，你必须使用 eapol-amsdu-bad 测试变体。请注意，如果此测试成功，攻击的影响与正确解析此类帧的实现相同（详细信息见论文第 3.6 节和第 6.6 节）。
如果测试工具似乎无法正常工作，请检查以下各项：
检查没有其他进程正在使用网卡（例如，终止你的网络管理器）。
如果之前一切正常，请尝试拔下 Wi-Fi 适配器，重启计算机或虚拟机，然后重试。还可以尝试使用 disable-hwcrypto.sh 脚本禁用硬件加密（执行此脚本后重启计算机）。
确保被测设备不会进入睡眠状态（导致其错过注入的帧）。我建议在混合模式下运行测试工具，因为它能更好地处理可能进入睡眠状态的客户端。
运行注入测试以确保注入正常工作。同时确保使用 20 MHz 信道，其他信道上的注入未经测试。
检查你的机器是否正在产生干扰测试的背景流量。特别是，禁用操作系统中的网络，手动终止 DHCP 客户端/服务器等。另请参阅每次使用前。
确认你连接到了正确的网络。仔细检查 client.conf。
确保被测 AP 使用（AES-）CCMP 作为加密算法。不支持 TKIP 或 GCMP 等其他加密算法。
如果你使用 git 更新了代码，请再次执行 ./build.sh 和 ./pysetup.sh（见先决条件）。如果修补过的驱动程序已更新，请记得同时重新编译它们。
如果你使用虚拟机，请尝试从 live USB 镜像运行测试工具。
检查被测设备是否阻止 ICMP ping 请求。如果它不回复 ping，你可以在设备上运行 tcpdump 或 wireshark，或者尝试不支持 ICMP中列出的任何其他方法。
使用附加参数 --debug 2 运行工具，以从 wpa_supplicant 或 hostapd 以及测试工具本身获取额外的调试输出。
使用第二个监听接口确认分片之间没有发送其他帧。例如，我发现我的 Intel 设备有时会在分片之间发送 Block Ack Response Action 帧，这干扰了被测设备的去分片过程。
请再次确认，如果你的无线网卡需要修改后的固件，你正在使用它。测试工具已经为 ath9k_htc 设备自动检查了这一点。测试工具还会自动检查你是否使用了修改后的驱动程序，不过在特定的 Linux 发行版上手动仔细检查这一点可能更好。
在获取 IP 地址与发送第一个分片/帧之间添加延迟可能会有所帮助。使用 --pre-test-delay 参数进行设置。
由于实现存在差异，确认/利用某些漏洞可能很困难，尤其是混合密钥攻击和缓存攻击在实践中可能难以确认。因此，我建议仅当代码中存在防止这些攻击的显式检查时，才将设备视为安全的。此外，如果时间允许，我还建议进行以下更高级的测试。这些测试发现新漏洞的可能性较低，但可能揭示普通测试无法检测到的攻击变体或特定设备行为。
如果漏洞测试中的正常测试已经确认存在某一类漏洞，则几乎没有必要测试该漏洞的其他攻击变体。除非另有说明，所有命令均适用于客户端和 AP。
仅当主测试 ping I,E --amsdu 失败并且你想更好地了解被测设备如何处理 A-MSDU 帧时，执行这两个测试才有意义：
ping I,E --amsdu-fake：如果此测试成功，则接收方将所有帧视为普通帧（意味着它不支持 A-MSDU 帧）。这种行为并不理想，尽管攻击者不太可能在实践中滥用这一点（见论文第 3.5 节）。
ping I,E --amsdu-fake --amsdu-spp：如果此测试成功，则接收方对每个收到的帧的 QoS A-MSDU 标志进行认证（即它不会在接收时将其屏蔽为零），但随后将所有收到的帧视为普通帧（意味着它不支持接收真正的 A-MSDU 帧）。这种行为并不理想，尽管攻击者不太可能在实践中滥用这一点（见论文第 3.5 节）。
我测试的大多数设备都易受混合密钥攻击。如果正常的混合密钥攻击测试表明设备不易受攻击，但 ping-frag-sep 测试确实成功，则强烈建议尝试这些替代的混合密钥攻击测试。一般来说，在测试 AP 时，你可以向任何混合密钥攻击测试添加 --rekey-req 参数，以
主动请求重新密钥握手。然后，少数 AP 会执行重新密钥握手。不过，大多数 AP 会忽略
此请求，并且必须显式配置为定期更新会话密钥（PTK）。
关于这些测试的一些说明：
ping I,F,BE,E 和 ping I,E,F,AE：这些是相当直接的混合密钥攻击测试，两个分片
会在不同的时间被注入。
ping I,E,F,AE --rekey-plain：某些驱动程序（例如 MediaTek）会以明文执行重新密钥握手。要测试
使用此类驱动程序的设备，你必须添加 --rekey-plain 参数。
ping I,E,F,AE --rekey-plain --rekey-req：这种特定组合对于测试使用 MediaTek 驱动程序的
路由器非常有用。这些路由器以明文执行重新密钥握手，并且客户端可以主动请求重新密钥握手。
ping I,E,F,AE --rekey-early-install：少数客户端会在成对会话重新密钥期间（错误地）过早
安装密钥。要可靠地测试这些客户端，请添加 --rekey-early-install 参数。此测试
对 AP 没有意义。
ping I,E,F,E [--rekey-pl] [--rekey-req]：此测试变体与之前的 ping I,E,F,AE * 测试相同，
区别在于第二个分片在四次握手后 1 秒发送。这可能很重要，因为在
少数设备中，安装新密钥之前会有较小的延迟。请注意，--rekey-pl 是
--rekey-plain 的简写。
最后，如果 ping-frag-sep 测试未成功，你应该尝试以下混合密钥攻击测试：
ping I,F,BE,AE --freebsd：这基本上是对 FreeBSD 实现或借用 FreeBSD 代码的
驱动程序执行重新密钥握手，而不会影响数据帧的重组过程。详细信息请参阅
论文中的附录 E。ping I,E,R,AE --freebsd --full-reconnect：此测试可用于检查 FreeBSD AP 或借用 FreeBSD 代码的
驱动程序是否容易受到缓存攻击。有关此测试的工作原理，请参阅论文中的附录 E。
你还应尝试不带 --full-reconnect 参数运行此测试。此测试也适用于
客户端，但客户端不太可能受影响。
ping I,E,R,AP --freebsd --full-reconnect：此测试是针对 FreeBSD AP 或借用 FreeBSD 代码的
驱动程序的变体，其中第二个分片在与 AP 重新连接后以明文发送。在 FreeBSD 上针对某些
USB 网卡（dongle）时，此测试更可靠，并且仍能证明旧分片在重新连接后仍保留在 AP 的内存中。
你还应尝试不带 --full-reconnect 参数运行此测试。此测试也适用于
客户端，但客户端不太可能受影响。
ping I,E,R,AP [--full-reconnect]：在此测试中，第二个分片以明文发送。如果
被测设备在四次握手后没有立即安装密钥，这会很有用。如果此测试成功，则
表明设备在（重新）连接到网络后将分片保留在内存中，这意味着它容易受到缓存
攻击。与上述两条命令不同，此命令也适合对客户端（以及 AP）执行。
ping I,E,E --amsdu：此测试发送一个分片的 A-MSDU 帧，并非所有设备都能正确接收。
它并不用于测试漏洞。相反，此测试有助于确定“混合明文/加密攻击”的
实际可利用性。也就是说，如果此测试成功，当第二个分片可以
以明文发送时（测试 ping I,E,P），攻击该设备会更容易。详细信息请参阅论文第 6.3 节。
ping I,E,P,E 和 linux-plain 3：如果所有其他混合明文/加密攻击测试均未成功，你
还可以尝试这两个额外的测试。我认为这不太可能发现新的漏洞。
以下大多数测试都会发送广播帧，这些帧不会被自动重传，因此 建议多次执行这些测试。这是因为背景噪声可能会阻止被测设备 接收注入的广播帧。在我的实验中，主要受影响的是客户端。大多数客户端 只在连接网络时（即四次握手执行期间）容易受到攻击。
ping I,P --bcast-ra：这会在一个明文广播 Wi-Fi 帧内发送单播 ICMP ping 请求（CVE-2020-26145）。
此测试可同时对客户端和 AP 执行。
ping BP --bcast-ra：与上述测试 ping I,P --bcast-ra 类似，但 ping 是在客户端与网络
完成认证之前发送的，即在四次握手执行期间发送（CVE-2020-26145）。你必须运行 tcpdump
或 wireshark 来检查客户端是否接受该帧。在 tcpdump 中可以使用过滤器 icmp，在 wireshark 中你
也可以使用过滤器 frame contains "test_ping_icmp" 来更轻松地检测此 ping 请求。
ping BP --bcast-ra --bcast-dst：此测试与上一个测试相同，但如果你无法在目标 AP 上运行 tcpdump，
它会很有用。请注意，此测试仅对 AP 有意义。此测试中的额外 --bcast-dst 参数
会使易受攻击的 AP 将注入的 ping 请求广播给所有已连接的客户端。换句话说，要检查 AP
是否易受攻击，请执行此命令，并在连接到该 AP 的第二台设备上监听广播 Wi-Fi 帧，
使用过滤器 icmp 或 frame contains "test_ping_icmp"。
ping BP [--bcast-dst]：这是上述两个测试 ping BP --bcast-ra [--bcast-dst] 的一个变体，区别在于 ping
请求现在以明文单播帧而不是广播帧发送（尚未分配 CVE——它与
CVE-2020-26145 相关）。此测试必须同时对客户端和 AP 执行。ping 在客户端与网络完成认证之前发送
（即四次握手执行期间），这意味着你必须运行 tcpdump 或 wireshark 来检查
设备是否接受此帧。或者，在测试 AP 时，你可以像上述测试一样添加 --bcast-dst 参数，
然后在连接到该 AP 的第二台设备上使用 tcpdump 或 wireshark，并使用过滤器 icmp 或
frame contains "test_ping_icmp"。
eapfrag BP,BP：这是上述广播分片测试的一个特化版本，在客户端完成认证之前
执行。这是一种基于泄露代码分析的_非常实验性_攻击。它首先发送一个明文分片，
该分片以 EAPOL 头开头，由于四次握手仍在执行，因此会被接受。然后它发送一个
具有相同序列号的第二个广播分片。根据对泄露代码的分析，某些设备现在可能会接受
此分片（因为前一个分片被允许），但后续代码会将其作为正常帧处理
（因为该分片是广播的）。你必须使用 tcpdump 或 wireshark 在受害者上确定该帧是否
被正确接收，例如使用过滤器 icmp 或 frame contains "test_ping_icmp"。如果常规变体不起作用，
另一种变体是 eapfrag BP,AE。
如果你想执行 eapol-amsdu[-bad] BP 测试但无法在 AP 上运行 tcpdump 或 wireshark，可以使用此测试。
此测试仅对 AP 有意义：命令 eapol-amsdu[-bad] BP --bcast-dst 会使易受攻击的 AP
将注入的 ping 请求广播给所有已连接的客户端。换句话说，要检查 AP 是否易受攻击，请执行此
命令，并在连接到该 AP 的第二台设备上使用过滤器 icmp 或
frame contains "test_ping_icmp" 监听广播 Wi-Fi 帧。
eapol-inject 00:11:22:33:44:55：此测试仅对 AP 有意义。要执行此测试，你必须使用第二台设备
连接到网络，并将 MAC 地址 00:11:22:33:44:55 替换为这台第二台设备的 MAC 地址。
在_完成认证之前_，测试工具将向 AP 发送一个 EAPOL 帧，其最终目的地是这台第二台
设备。如果 AP 将该 EAPOL 帧转发到第二台设备，则认为该 AP 易受攻击。要确认 AP 是否转发
该 EAPOL 帧，你必须在第二台设备上运行 tcpdump 或 wireshark。你可以使用 wireshark 过滤器 frame contains "forwarded_data"
在第二台设备的无线接口上监控解密流量时（或使用 tcpdump 过滤器 ether proto 0x888e
来监控所有 EAPOL 帧）。有关详细信息及影响，请参阅论文第 6.6 节。
eapol-inject-lage 00:11:22:33:44:55：如果上述 eapol-inject 测试成功，你还可以尝试 eapol-inject-large，看看
此漏洞是否可以被滥用以强制传输加密分片。你同样需要使用 tcpdump 或 wireshark
来检查。使用 wireshark 或 tshark 过滤器 (wlan.fc.frag == 1) || (wlan.frag > 0) 来检测分片帧。我发现
这种攻击很少能够成功。
ping I,D,E：如果此测试成功，则说明该客户端或 AP 不支持（去）分片，但仍然容易受到攻击。
问题在于接收方将_最后_一个分片视为完整帧。有关详细信息以及如何
利用这一点，请参阅论文第 6.8 节。
ping I,E,D：如果此测试成功，则说明该客户端或 AP 将_第一个_分片视为完整帧。虽然这种行为
并不理想，但目前尚不清楚这是否可以单独在实际中被利用。
脚本 test-injection.py 可用于测试在使用
_注入模式_时帧是否正确注入：
./test-injection.py wlan0 wlan1
这里我们测试网卡 wlan0 是否正确注入帧，并使用网卡 wlan1
来监控帧是否正确注入。请注意，要运行此测试脚本，两个接口都需要支持
监听模式。
如果你没有第二张网卡，可以执行部分注入测试，使用：
./test-injection.py wlan0
不幸的是，上述测试只能测试内核是否会覆盖注入帧的字段， 无法测试固件或无线芯片本身是否会覆盖字段。
要测试网卡在_混合模式_下是否正确注入帧（这是我 推荐使用的模式），你可以执行以下两条命令：
./fragattack.py wlan0 ping --inject-test wlan1
./fragattack.py wlan0 ping --inject-test wlan1 --ap
这里我们使用第二张网卡 wlan1 监控注入的帧，以测试 wlan0 是否正确注入帧。
第一条命令测试在作为客户端使用混合模式时帧是否正确注入，
第二条命令测试在作为 AP 使用混合模式时帧是否正确注入。
要开始测试，客户端必须能够连接到网络，并且
AP 会等待有客户端连接后才开始注入测试（参见 每次使用前
了解客户端和 AP 的连接设置配置）。
如果你还想测试 wlan0 在混合模式下的重传行为，可以执行：
./fragattack.py wlan0 ping --inject-test-postauth wlan1
./fragattack.py wlan0 ping --inject-test-postauth wlan1 --ap
如果你没有第二张网卡，可以执行部分混合模式注入测试， 使用：
./fragattack.py wlan0 ping --inject-test[-postauth] self
./fragattack.py wlan0 ping --inject-test[-postauth] self --ap
不幸的是，上述测试只能测试内核是否会覆盖注入帧的字段， 无法测试固件或无线芯片本身是否会覆盖字段。
测试脚本将详细输出哪些测试成功或失败，并在最后输出
==> The most important tests have been passed successfully 或一条消息，指示重要测试失败，
或无法捕获某些注入的帧。
请注意，注入脚本只测试最重要的行为。确认注入是否正常工作的最佳方法是 对已知易受攻击的设备执行漏洞测试， 并确认该工具能正确地将这些设备识别为易受攻击。
当某些注入的帧无法被捕获时，可能是因为背景噪声，也可能是因为
被测网卡无法正确注入某些帧（例如 Intel AX200 的固件在注入分片帧时会崩溃）。
也可能是帧实际上已被正确注入，但用于监控帧是否正确注入的网卡
（上述示例中的 wlan1）不可靠，并且
例如由于背景噪声而丢失了大部分帧。也可以尝试在不同的信道上运行测试。
当注入测试正常工作时，如果你无法可靠地执行攻击测试，这可能是 由于被测设备进入了睡眠模式。有关此问题的更多说明，请参阅 处理睡眠模式 。
使用 wireshark 检查设备的注入行为时，建议使用第二台 处于监听模式的设备来查看帧是如何注入的。
如果你打开用于注入帧的接口，你应该会看到注入帧两次：（1）首先 你会看到该帧由发送它的工具注入的样子，然后（2）第二次你会看到该帧 由驱动程序注入的样子。如果内核覆盖了某些字段，这两个帧可能会略有不同。 如果你只看到一次注入帧，那么它可能已被内核丢弃。
如果你测试的设备不支持 DHCP，你可以手动指定测试工具应使用的 IP 地址。 例如：
./fragattack.py wlan0 [--ap] ping --inject wlan1 --ip 192.168.100.10 --peerip 192.168.100.1
这里测试工具将使用 IP 地址 192.168.100.10，并向对端 IP 地址 192.168.100.1 注入一个 ping 请求。
当测试在使用 DHCP 获取 IP 地址之前发送 IP 数据包时，它将使用默认 IP
地址 127.0.0.1。要使用不同的（默认）IP 地址，你也可以使用 --ip 和 -peerip
参数。
大多数攻击测试通过以特殊方式发送 ICMP ping 请求，并查看是否
收到 ICMP ping 响应来工作。如果被测设备不支持 ICMP ping，你可以改为
在所有测试中添加 --arp 参数来使用 ARP 请求。如果某个测试不支持发送
ARP 请求，工具将显示错误 Cannot override request type of the selected test，在
这种情况下，该特定测试只能使用 ICMP ping 请求来执行。
TODO：当作为客户端时，我们也可以注入 DHCP 请求来代替。
如果你无法获得推荐的无线路网卡之一，第二个选择 是获取一张在 Linux 上使用相同驱动程序的网卡。具体来说，你可以尝试：
我推荐基于 ath9k_htc 的网卡。并非所有使用 iwlmvm 的网卡都兼容。当
使用替代网卡时，我强烈建议先运行注入测试
以确认网卡兼容。
为了在 5 GHz 信道上使用测试工具，所使用的网卡必须允许
在 5 GHz 信道上注入帧。不幸的是，由于监管
限制，这并不总是可行的。要查看可以在哪些信道上注入帧，你可以执行 iw list 并在
Frequencies 下查找_未_标记为 disabled、no IR 或 radar detection 的信道。请注意，这些
条件可能取决于你的网卡、当前配置的国家/地区以及你所连接的 AP。
更多信息请参阅，例如，Arch Linux 文档。
请注意，设备可能使用不同的驱动程序来处理 2.4 GHz 和 5 GHz 频段。因此， 在这两个频段上测试设备非常重要，因为设备可能因所使用的频段不同 而表现不同。
请注意，在混合模式下，即使允许发送正常帧，Linux 内核也可能不允许注入帧。
这是因为在函数 ieee80211_monitor_start_xmit 中，当 cfg80211_reg_can_beacon 返回 false 时，内核会拒绝
注入帧。因此，即使实际上允许注入帧，Linux 也可能拒绝
注入帧。让 cfg80211_reg_can_beacon 在正确的条件下返回 true
可以避免此 bug。
在实践中，有些人发现你必须先将无线网卡手动设置到 AP 所在的 5GHz 信道。有关详细信息，请参阅 此 GitHub issue 。
手机或 IoT 设备等设备可能会将其 Wi-Fi 无线电置于睡眠模式以减少能耗。 处于睡眠模式时，这些设备无法接收 Wi-Fi 帧，这可能会干扰我们的测试。有 一些选项可以尝试缓解此问题：
尝试在测试设备上禁用睡眠模式。这是最可靠的解决方案，但不幸的是 并不总是可行。
在混合模式下运行测试工具。大多数网卡会将注入的帧排队，直到设备 再次唤醒。
尝试使用不同的网卡来执行测试。我发现不同的网卡会在（略有）不同的时间注入帧， 这可能决定注入帧是正确到达还是 被错过。例如，在测试 Pixel 4 XL 时，使用 TL-WN722N 时测试工具不可靠，但 使用 Intel 8265 时则稳定可靠。
为被测试设备分配静态 IP，并让测试工具使用静态 IP（参见 静态 IP 配置）。 对于许多测试，这可能更可靠，因为测试工具可以立即发送测试帧，而不是 先使用/等待 DHCP。
ping I,P --bcast-ra --bcast-dst 和 ping BP --bcast-ra --bcast-dst
eapol-amsdu BP --bcast-dst 和 eapol-amsdu-bad BP --bcast-dst
使用这些命令，您可以在连接到该 AP 的另一台客户端上监听 ping 请求。如果在此独立客户端上收到 ping 请求，则被测 AP 存在漏洞。遗憾的是，目前在没有于客户端上运行 tcpdump 的情况下，似乎很难针对这些攻击变体测试客户端。
如果由于某种原因 Linux 无法自动识别此无线网卡，请执行 sudo modprobe mt76x2u 手动加载驱动程序。该无线网卡在我们最新的驱动程序中似乎很可靠。如果该无线网卡不可靠，请创建文件 /etc/modprobe.d/mt76.conf，内容如下：```
options mt76_usb disable_usb_sg=1
然后重新启动你的机器。另外务必使用质量好的 USB 线连接此适配器！我之前遇到这个适配器行为不稳定，原因就是 USB 3.0 线缆质量差。因此，如果你遇到问题，可以尝试直接将适配器插入而不用线缆。
使用 VirtualBox 时，请确保启用 USB3.0，这样适配器才能被识别。详情参见[此问题](https://github.com/vanhoefm/fragattacks/issues/22)。
AWUS036ACM 内部使用 MT7612U 芯片组。现在也有采用 MT7612UN 芯片组的适配器，它们同样可以可靠地配合我们的测试工具使用。例如 [CSL Wireless Network Adaptor](https://www.amazon.de/dp/B0873BNBD8?tag=modwiffir-20)。
### ath9k_htc
Technoethical N150 HGA、TP-Link TL-WN722N v1.x 和 Alfa AWUS036NHA 都使用 `ath9k_htc` 驱动程序。
对我来说，这些设备在虚拟机中表现还不错，尽管与所有设备一样，原生使用时更为可靠。使用虚拟机时，我建议将虚拟机配置为使用 USB2.0 控制器，因为这看起来更稳定（至少在 VirtualBox 中如此）。
在较新的内核中，`ath9k_htc` 驱动程序曾出现一个（[现已修复](https://www.spinics.net/lists/linux-wireless/msg200825.html)）回归问题，导致其无法工作。只需使用最新的内核或我们打过补丁的驱动程序即可避免此问题。
#### AWUS036ACH
此设备在大多数 Linux 发行版中默认通常不被支持，需要手动安装驱动程序。在 Kali Linux 上，你可以使用 `sudo apt install realtek-rtl88xxau-dkms` 安装驱动。要在其他发行版上安装驱动，请检查你的软件包管理器，或按照 [GitHub](https://github.com/aircrack-ng/rtl8812au) 上的安装说明进行操作。在插入设备之前，建议执行 `modprobe 88XXau rtw_monitor_retransmit=1`。
不幸的是，此设备无法在推荐模式 mixed mode 下工作，并且难以与我们修改后的驱动程序配合使用。实际上，你必须卸载修改后的驱动程序，然后使用参数 `--no-drivercheck` 和 `--inject wlan0` 运行测试工具，其中 wlan0 指 AWUS036ACH 网卡。由于这些限制，不建议使用此设备。
### Intel AX200
我测试了 Intel AX200，发现它与测试工具_不_兼容：在注入设置了 More Fragments 标志的帧后，其固件会崩溃。如果有 Intel 开发人员看到这里，请更新固件，使其能够注入分片帧。
### 基于 RT5572 的芯片
我使用通用的 [CSL USB 2.0 WLAN Adapter 300Mbit adapter](http://www.amazon.de/dp/B00LLIOT34?tag=modwiffir-20) 测试了该芯片组。在通过执行 `disable-hwcrypto.sh` 脚本禁用硬件解密后，我能够执行基本的 ping 测试（`ping`）。分片 ping 测试（`ping I,E,E`）非常不可靠，但有时也能成功。
目前的结论是，RT5572 芯片在禁用硬件加密后_可能_可以配合测试工具使用。但还需要额外的实验来确认这一点（欢迎反馈）。
<a id="id-hwsim-details"></a>
## 9.9. Hwsim 模式详解
**警告**：*目前这是一个实验性模式，仅用于研究目的。*
此模式只需要一张支持监听模式的网卡，与 mixed mode 不同，网卡不需要支持虚拟接口。缺点是在此模式下帧的处理速度稍慢，而且当网卡不确认帧时并不可靠：
- 由于提交 1672c0e31917（“mac80211: start auth/assoc timeout on frame status”），作为客户端进行认证会立即超时，这意味着我们目前无法以客户端身份使用 hwsim 模式。
_TODO：我们需要修补内核以避免此超时。_
- 如果我们测试的客户端使用了提交 1672c0e31917（“mac80211: start auth/assoc timeout on frame status”），那么（作为 AP）我们必须确认发往我们的帧。否则被测试的客户端将无法连接。
_TODO：测试哪些设备在监听模式下会确认帧，并测试 `iw set wlanX monitor active`。_
- 某些 AP 还要求客户端确认认证和关联帧。这意味着（作为客户端）我们必须再次确认发往我们的帧。
_TODO：测试哪些设备在监听模式下会确认帧，并测试 `iw set wlanX monitor active`。_
- 出于某些奇怪的原因，Intel/mvm 在 4-way HS 之后无法接收来自 Android/iPhone/iPad 的数据帧？这是一个非常奇怪的 bug。_TODO：进一步调查此问题。_
在使用此模式之前，创建两张虚拟网卡：
./hwsim.sh
这将输出两个已创建的虚拟 “hwsim” 接口，例如 wlan1 和 wlan2。在此模式下测试 AP 时，你必须先搜索 AP 所在信道，并将真实网卡置于该信道上：
./scan.sh wlan0
ifconfig wlan0 down
iw wlan0 set type monitor
ifconfig wlan0 up
# Pick the channel that the AP is on (in this example 11)
iw wlan0 set channel 11
此处 wlan0 指的是_真实_网卡（不是由 `hwsim.sh` 创建的接口）。在测试客户端时，你不需要先配置信道（它会从 `hostapd.conf` 中获取）。现在你可以按如下方式启动测试工具：
./fragattack.py wlan0 --hwsim wlan1,wlan2 [--ap] $COMMAND
工具执行完毕后，你可以直接使用新的 `$COMMAND` 再次运行它。
<a id="id-wpa3-sae"></a>
## 9.10. 测试 WPA3 和 SAE 设备
你可以通过在 `client.conf` 中包含以下两行来测试 WPA3/SAE AP：
key_mgmt=SAE
ieee80211w=1
要测试 WPA3/SAE 客户端，你可以修改 `hostapd.conf` 并设置以下参数：
wpa_key_mgmt=SAE
ieee80211w=2
我们使用 Intel 8265、Intel 3160、Netgear WN111v2（`carl9170`）、TP-Link TL-WN722N（`ath9k_htc`）和 WNDA3200（`ath9k_htc`）测试了上述配置。使用这些设备，我能够连接 AP 并运行一些测试。因此，这似乎应该适用于所有已支持的适配器。请注意，我尚未对此进行详细测试：我的假设是，设备运行在 WPA2 还是 WPA3 模式下不会影响测试结果。
提供的 `client.conf` 默认同时启用 hunting-and-pecking 方法和 hash-to-element 方法。要设置一个支持 hash-to-element 的 AP（从而测试最新的 WPA3/SAE 客户端），你可以修改 `hostapd.conf` 并设置以下参数：
sae_pwe=2
通过设置此值，AP 将同时接受 hunting-and-pecking 方法和 hash-to-element 方法。
<a id="id-live-image"></a>
## 9.11. Live USB 镜像
下载 [Live USB 镜像](https://people.cs.kuleuven.be/~mathy.vanhoef/fragattacks/ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso) 并使用以下命令将其写入 USB：
# Unmount in case there's an old partition on the USB
sudo umount /dev/sdb*
# Copy the image
sudo dd bs=4M if=ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso of=/dev/sdb conv=fdatasync status=progress
该镜像的 sha256sum 为 `4b973452a08b981778285a33accfd4ce58625a91e8e0eab20941facf54904bba`。将 `/dev/sdb` 替换为你的 USB 闪存盘。如果你不是在使用 Linux，请在网上搜索如何将 ISO 镜像写入 USB 闪存盘。
启动 Live 镜像时，请在启动过程中点击 “Try Ubuntu”。通过右键单击桌面并选择 “Open in Terminal” 打开终端，然后执行：
cd ~/fragattacks/research
sudo su
nmcli radio wifi off
source venv/bin/activate
现在你可以运行 `./fragattacks.py`，并按照本 README 中的常规说明操作。请记住，如上所示使用 `nmcli radio wifi off` 禁用 Wi-Fi，否则 Ubuntu 的网络管理器会干扰测试工具。本 README 也存在于 Live 镜像的 `~/fragattacks/README.md` 中。
请注意，airmon-ng 在 Live 镜像上可能不可靠，最好使用 [iw](https://github.com/vanhoefm/fragattacks/issues/36)。
<a id="id-design-notes"></a>
# 10. 设计说明
传给 ping 命令的参数定义了测试工具将执行哪些操作以及何时执行这些操作。每个操作之间用逗号（`,`）分隔。默认情况下，操作在客户端连接后执行，此时单个字母表示要执行的操作。请注意，这实现在 [`stract2action`](https://github.com/vanhoefm/fragattacks/blob/master/research/fragattack.py#L23) 函数中。可能的操作有：
- `I`：获取 IP 地址。默认通过 DHCP 完成，除非使用 `--ip` 和 `--peerip` 参数显式提供了 IP 地址，此时不执行任何操作。
- `E`：注入 ping 请求的一个加密数据包/片段。
- `P`：注入 ping 请求的一个明文数据包/片段。
- `F`：通过发起 4-way 握手（作为 AP）或等待 4-way 握手（作为客户端）来刷新会话密钥。
- `R`：让客户端重新连接到网络。
- `D`：这是一个特殊的“元操作”。将其视为 ping 请求的一个空片段，但实际上并不发送。
如果只有一个 `E` 或 `P` 操作，则 ping 请求将作为单个帧注入。如果有多个 `E`、`P` 操作，则 ping 请求会被分片，分片数量等于 `E` 或 `P` 操作的数量。如果存在特殊的 `D` 操作，则 ping 请求会在剩余的 `E` 或 `P` 操作之间进行分片（参见上表示例）。此分片行为在 [PingTest](https://github.com/vanhoefm/fragattacks/blob/master/research/tests_common.py#L47) 类中实现。
可以在上述操作前面加上一个字母，以改变操作的执行时机：
- `S`：在 4-way 握手的第 1 或第 2 条消息上执行该操作。
- `B`：在 4-way 握手的第 3 或第 4 条消息上执行该操作。
- `A`：在 4-way 握手完成后立即执行该操作。
- `C`：在 4-way 握手完成 1 秒后执行该操作。可以使用 `--connected-delay` 参数更改等待的秒数。
例如，请参见上面两个包含命令的表格。
<a id="id-change-log"></a>
# 11. 更新日志
**版本 1.3.4（进行中）：**：
- 始终加密 EAPOL（Rekey）Request 帧，即使使用了 `--rekey-plaintext` 也是如此。
- 客户端现在接受重放的 EAPOL 帧。这确保即使被测 AP 错误地实现了 rekey，rekey 也能正常工作。
- 更新了 wpa_supplicant，重新启用到使用 MS-CHAPv2 的企业网络的连接。此前，当操作系统使用 OpenSSL 3.0 或更高版本时，MD4 默认被禁用，这意味着无法使用 MS-CHAPv2。
- 新增 `--pre-test-delay` 参数。该参数在获取 IP 地址与发送第一批分片/帧之间增加延迟。参见 Michael Trimarchi 和 Angelo Compagnucci 的[拉取请求](https://github.com/vanhoefm/fragattacks/pull/44)。
- 更新了修改后的驱动程序，使其也能在 Linux 内核 5.13 上编译。这是实验性的。
- 通过在 reorder 测试中等待帧的时间更长，使注入测试更加可靠。
- 进行了一些小的修改，使代码更容易在较旧的平台（使用较旧版本的 Python 和 OpenSSL 库）上编译。
- 更新了 README，增加了如何在 Ubuntu 20.04 上安装受支持的较旧内核的示例。增加了设计说明。现在推荐使用 AWUS036ACM。
**版本 1.3.3（2021 年 5 月 11 日）**：
- 更新了修改后的驱动程序，使其能在 Linux 内核 5.10、5.11 和 5.12 上编译。
- 更新了 `ath9k_htc` 设备的固件（应该不会对测试产生影响）。
- 为公开发布重组了仓库。移除了内部文档和幻灯片，改为引用这些文档的公开版本。
- 在使用 `--inject-test[-postauth]` 参数测试注入时，对 40 MHz 信道提供基本支持。在实际漏洞测试中，40 MHz 信道的使用尚未经过测试（如有需要，可在 `client.conf` 中使用 `disable_ht40`）。
**版本 1.3.2（2021 年 3 月 8 日）**：
- 添加了演示文稿[讲义](https://papers.mathyvanhoef.com/fragattacks-slides-2021-03-8.pdf)和每个漏洞根本原因及影响的[摘要](https://papers.mathyvanhoef.com/fragattacks-overview.pdf)。
- 更新了本 README 以[说明](#id-test-sanity)，如果被测设备只接受特定最小大小的分片，则可以在所有发送分片帧的测试中添加参数 `--icmp-size 100` 或类似参数。
- 修复了本 README 中的少量拼写错误。
**版本 1.3.1（2021 年 3 月 1 日）**：
- 在本 README 中新增了测试 [`ping BP [--bcast-dst]`](#id-extended-bcast-check-ping-bp)。该测试在连接期间（即 4-way 握手中）注入一个明文 ping。客户端和 AP 都可能受此攻击影响。
- 更新了[攻击概述](#id-paper-clarifications)，增加了有关数据包注入漏洞在实际中如何被滥用的新示例。其中包括诱骗仅支持 IPv4 的客户端使用恶意 DNS 服务器的技术，以及直接与 NAT/防火墙后面的设备通信的技术（例如利用本地服务）。
- 澄清了[广播分片测试](#id-extended-bcast-check)可以针对客户端和 AP 执行。
- 测试工具现在将检查是否已加载预期版本的 Python Scapy 库。
- 修复了本 README 中对论文的一些引用（现在正确引用了 6.4、6.6 和 6.8 节）。
- 更新到论文的草案版本 3。与草案版本 2 相比没有重大变化，仅有一些小的文本和结构调整。就内容而言，这现在是论文的最终版本。
**版本 1.3（2021 年 1 月 20 日）**：
- 此版本基于 hostap 提交 `a337c1d7c`（“New TWT operations and attributes to TWT Setup and Nudge”）。
- 添加了攻击及其前提条件的[概述](https://github.com/vanhoefm/fragattacks/blob/HEAD/attacks.pdf)，并制作了[这些幻灯片](https://github.com/vanhoefm/fragattacks/blob/HEAD/amsduattack.pdf)，以更好地说明聚合攻击（CVE-2020-24588）在实际中是如何运作的。
- 添加了如何使用 hunting-and-pecking 或 hash-to-element 方法测试 WPA3/SAE 设备的<a href="#id-wpa3-sae">说明</a>。这也意味着测试工具支持管理帧保护（MFP）。
- 在本 README 中增加了关于如何使用 tcpdump 验证某些测试结果的说明。
- 在本 README 中新增了额外测试 `ping BP --bcast-ra --bcast-dst`，以便针对无法运行 tcpdump 的 AP 测试 CVE-2020-26145（使用此测试时，tcpdump 必须在独立连接的客户端上运行）。
- 在本 README 中新增了额外测试 `ping I,E,F,E [--rekey-pl] [--rekey-req]`，以更好地检测某些设备中的混合密钥攻击（CVE-2020-24587）。
- 修复了将 ath9k_htc 适配器与 802.11n 结合使用时注入分片帧的问题。
- 添加了 `pysetup.sh` 脚本来创建 Python 虚拟环境。该脚本还修复了 scapy 库在 Python 3.9 下的[一个 bug](https://github.com/secdev/scapy/commit/46fa40fde4049ad7770481f8806c59640df24059)。
- 已更新补丁驱动程序，使其能在 Linux 5.9.0 上正确编译。
- 修复了 `ping-frag-sep` 测试。此前它的行为类似于 `ping-frag-sep --pn-per-qos`。请注意，此测试不用于检测漏洞，而仅用于更好地理解实现。
**版本 1.2（2020 年 11 月 15 日）**：
- 此版本（及更低版本）基于 hostap 提交 `1c67a0760`（“tests: Add basic power saving tests for ap_open”）。
- 测试完成或超时后，工具会自动退出。
- 工具会检测 4-way 握手是否在循环，或者 rekey 请求（`--rekey-req`）是否没有回复。
- 使用外部 DHCP 服务器时，工具现在始终将 EAPOL 帧的目的地址设为 AP（而不是 DHCP 服务器）。这在混合密钥和缓存攻击测试中使用外部 DHCP 服务器时非常重要。
- 当使用 `--rekey-req` 测试 AP 时，工具现在将发送重放计数器为 1 而不是 0 的 EAPOL Rekey Request。
- 调试输出现在在加密广播/组播帧时显示正确的（组）密钥。这不会影响任何测试结果，只会改变测试工具的输出。
- 澄清了本 README 中的所有命令都可以同时测试客户端和 AP，除非另有说明。
- 澄清了本 README 中缓存攻击、广播分片和 A-MSDU EAPOL 攻击测试的描述。
- 澄清了在本 README 中同时测试 2.4 和 5 GHz 频段的重要性。
**版本 1.1（2020 年 10 月 20 日）**：
- 修复了命令 `ping I,E,D` 会发送正常加密 ping 请求的 bug。现在它会发送一个在报头中设置了 More Fragments 标志的加密 ping 请求。
- 将 `amsdu-inject-[bad]` 命令移到了本 README 的第 7 节。这些命令模拟真实攻击，可用于验证临时缓解措施是否有效（参见论文第 7.2 节）。
- 修复了本 README 和测试工具中 A-MSDU SPP 的拼写。新的 `--amsdu-spp` 参数现在是旧 `--amsdu-ssp` 参数的同义词。
**版本 1.0（2020 年 8 月 11 日）**：
- 为在保密期内使用准备了初始版本。
| 网卡 | USB | 5GHz | 混合模式 | 注入模式 |
|---|
| Technoethical N150 HGA | 是 | 否 | 已修补驱动/固件 | 已修补驱动/固件 |
| TP-Link TL-WN722N v1.x | 是 | 否 | 已修补驱动/固件 | 已修补驱动/固件 |
| Alfa AWUS036NHA | 是 | 否 | 已修补驱动/固件 | 已修补驱动/固件 |
| Intel Wireless-AC 8265 | 否 | 是 | 已修补驱动 | 是 |
| Intel Wireless-AC 3160 | 否 | 是 | 已修补驱动 | 是 |
| Alfa AWUS036ACM | 是 | 是 | 已修补驱动 | 是 |
| Netgear WN111v2 | 是 | 否 | 已修补驱动 | 是 |
| Alfa AWUS036ACH | 是 | 是 | 否 | 是 |
| 命令 | 简短描述 |
|---|
ping | 发送一次普通 ping。 |
ping I,E,E | 发送一次普通的碎片化 ping。 |
ping I,E,E --delay 5 | 发送一次普通的碎片化 ping，片段之间延迟 5 秒。 |
ping-frag-sep | 发送一次普通的碎片化 ping，片段之间被另一帧分隔。 |
ping-frag-sep --pn-per-qos | 与上相同，但目标只接受连续 PN 时也能工作。 |
ping I,E --amsdu | 发送封装在普通（非 SPP 保护）A-MSDU 帧中的 ping。 |
amsdu-inject | 模拟攻击：发送起始部分同时也是有效 rfc1042 头的 A-MSDU 帧。 |
amsdu-inject-bad | 与上相同，但针对错误解析该帧的目标。 |
ping I,F,BE,AE | 注入两个在不同密钥下加密的片段。 |
ping I,F,BE,AE --pn-per-qos | 与上相同，但目标只接受连续 PN 时也能工作。 |
ping I,E,R,AE | 注入一个片段，尝试触发_重新关联_，然后注入第二个片段。 |
ping I,E,R,E | 与上相同，但在发送第二个片段前有更长的延迟。 |
ping I,E,R,AE --full-recon | 注入一个片段，_解除认证_并重新连接，然后注入第二个片段。 |
ping I,E,R,E --full-recon | 与上相同，但在发送第二个片段前有更长的延迟。 |
ping I,E,E --inc-pn 2 | 发送带有非连续包号的碎片化 ping。 |
ping I,E,P | 发送碎片化 ping：第一个片段加密，第二个片段明文。 |
ping I,P,E | 发送碎片化 ping：第一个片段明文，第二个片段加密。 |
ping I,P | 发送明文 ping。 |
ping I,P,P | 发送碎片化 ping：两个片段都以明文发送。 |
linux-plain | 特定于 Linux 的混合明文/加密碎片化攻击。 |
ping I,D,P --bcast-ra | 连接后在明文广播的第 2 个片段中发送单播 ping。 |
ping D,BP --bcast-ra | 与上相同，但帧在 4 次握手期间发送（使用 tcpdump 检查）。 |
eapol-amsdu I,P | 发送一个伪装成 EAPOL 帧、包含 ping 请求的明文 A-MSDU。 |
eapol-amsdu BP | 与上相同，但帧在握手期间发送（使用 tcpdump 检查）。 |
eapol-amsdu-bad I,P | 发送格式错误的明文 A-MSDU，其中包含伪装成 EAPOL 帧的 ping 请求。 |
eapol-amsdu-bad BP | 与上相同，但帧在连接期间发送（使用 tcpdump 检查）。 |
| 命令 | 简短描述 |
|---|
ping I,E --amsdu-fake | 如果此测试成功，则忽略 A-MSDU 标志（§3.5）。 |
ping I,E --amsdu-fake --amsdu-spp | 检查 A-MSDU 标志是否经过认证但随后被忽略（§3.5）。 |
ping I,F,BE,E | 适用于新密钥安装相对较晚的情况。 |
ping I,E,F,AE | 在重更新握手期间不接受数据帧时的变体。 |
ping I,E,F,AE --rekey-plain | 如果设备以明文执行重更新握手。 |
ping I,E,F,AE --rekey-plain --rekey-req | 与上述相同，并作为客户端主动请求重新生成密钥。 |
ping I,E,F,AE --rekey-early-install | 在发送四次握手的消息 3 后安装新密钥。 |
ping I,E,F,E [--rekey-pl] [--rekey-req] | 与上述 4 个测试相同，但在第二个分片之前有更长的延迟。 |
ping I,F,BE,AE --freebsd | 针对 FreeBSD 或类似实现的混合密钥攻击。 |
ping I,E,R,AE --freebsd [--full-reconnect] | 特定于 FreeBSD 实现的缓存攻击。 |
ping I,E,R,AP --freebsd [--full-reconnect] | 特定于 FreeBSD 实现的缓存攻击。 |
ping I,E,R,AP [--full-reconnect] | 缓存攻击测试，其中第二个分片以明文发送。 |
ping I,E,E --amsdu | 将普通 ping 作为分片的 A-MSDU 帧发送。 |
ping I,E,P,E | 第一个分片加密、第二个明文、第三个加密的 ping。 |
linux-plain 3 | 与 linux-plain 相同，但诱饵分片使用 QoS 优先级 3 发送。 |
ping I,P --bcast-ra | 在四次握手后在明文广播帧中发送 ping。 |
ping BP --bcast-ra [--bcast-dst] | 在四次握手期间在明文广播帧中发送 ping（使用 tcpdump）。 |
ping BP [--bcast-dst] | 在四次握手期间在明文帧中发送 ping（使用 tcpdump）。 |
eapfrag BP,BP | 实验性广播分片攻击（使用 tcpdump）。 |
eapol-amsdu[-bad] BP --bcast-dst | 与 eapol-amsdu BP 相同，但更容易针对 AP 进行验证（使用 tcpdump）。 |
eapol-inject 00:11:22:33:44:55 | 测试 AP 是否在认证前转发 EAPOL 帧（使用 tcpdump）。 |
eapol-inject-large 00:11:22:33:44:55 | 通过 EAPOL 注入使 AP 发送分片帧（使用 tcpdump）。 |
ping I,D,E | 在加密的第二个分片中发送 ping（无第一个分片）。 |
ping I,E,D | 在加密的第一个分片中发送 ping（无第二个分片）。 |