☰

Wireshark 捕获中有效 MAC 地址的几个变异版本

tag-icon • tag-icon wireless-networking wireshark
Wireshark 捕获中有效 MAC 地址的几个变异版本

我使用 Wireshark 监控模式，在 802.11ac 5GHz 频谱的单个通道（通道 36）上，在 3 个小时内捕获了 250 万个数据包。

我打开了 Wireshark 中的“统计信息”>“对话”，查看了所有通过 Wi-Fi 相互通信的 MAC 地址。随后，我将 Wireshark 提供的“对话”列表保存为 Google Sheet，并在下面分享以供参考和分析。

https://docs.google.com/spreadsheets/d/1RE72s7DYXDhRdMopXQ9zIqNkww6OhzUeZbLeQvYqpPc/edit?usp=sharing

我在 Android 上的 Wi-Fi 管理应用的“附近的设备”扫描中看到的有效设备列在“Device_Validity”表中。在主对话表中，它们被标为绿色。但是，只有前 1000 行（共 169,242 行）以某种方式进行了格式化，以保持合理的性能。

现在来谈谈这个问题：我在 Wireshark 日志中看到，我的设备和邻居设备的 MAC 地址有多个变异版本。

我所说的变异是指，如果18:56:80:7e:0d:c9是一个有效的 MAC 地址，那么我会在 Wireshark 中观察到的数据包的源/目标或发送器/接收器地址中的以下变体：

  • 18：56：80：7e：0d：49- 仅更改最后 1 或 2 个八位字节。如果设备具有多个网络接口稍微修改了 MAC 地址。

  • 19:56:80:7e:0d:c9 - 其中前 N 个八位字节发生更改。这可能发生在数据包通过范围扩展器。尽管据我所知通常3八位字节发生了改变，而不只是 1 个。

  • 原始 MAC 地址看似随机的变异如下：

    18：56：80：7e：0d：a9
    18：56：80：7e：0d：二十九- 一个设备可以有多少个接口？
    18:56:80:7e:4天：76
    18：56：80：7e：6天：39
    18：56：80：7e：广告：05- 在那儿很多附近是否有来自同一制造商的其他设备，而这些设备在上文提到的“我附近的设备”扫描中不知何故被遗漏了？有可能，但可能性不大
    00:56:80:7e:0d:c9 - 前缀更改了两次，一次改为 19:56，另一次改为 00:56。有多少个范围扩展器？而且，只更改了第一个八位字节？
    02：56：80：7e：0d：c9-前缀再次改变。
    02:56:80:7e:广告：2b- 两端都转换了 3 个八位字节。
    98：6f：80：7e：0d：05- 两端都转换了 3 个八位字节。
    01:18:56:80:7e:0d- 所有八位字节移至正确的，并填充01在左边。
    4b:27：80：7e：0d：63- 另一次多重替换。18
    :56:80:7e：b9:c4-还有很多很多

我在 Google Sheet 中对八位字节子字符串进行了简单搜索80:7e，并只查看了 7354 个结果中的 55 个，从而找到了上述 14 个突变。只需通过搜索不同的八位字节子字符串有效的 MAC 地址，或者通过检查更多的搜索结果。

此外，如果你按“未解析地址”列之一对提供的 Google 表格进行排序，并分析任何有效 MAC 的邻域，你会看到地址不断变化直到几乎所有的八位字节都不同。

这是仅适用于一台设备. 类似突变也出现在多种的设备，既属于我自己，也属于我的邻居。下面是另一组示例：

5c:f9:38:a7:d9:32 – 原始
d0:f9:38:a7:d9:32
三十二:f9:38:a7:d9:32
30:fa:38:a7:d9:32
铁:f9:38:a7:d9:32
5e:f9:38:a7:d9:5a
00：5c：f9：38：a7：d9- 右移并添加前缀
f9：38：a7：d9：32：98- 左移后缀
59:f9:38:a7:d9:f2- 和 d9：b2
5c:f9:38:a7:71：2d- 不存在的设备
5c:f9:38:a7:41:45- 不存在的设备
等等

这些是我编目的图案仅需两台设备，在我的显示器范围内有十多个设备。对于工作表的 Device_Validity 选项卡中的任何设备，这些位移/掩码模式都很容易被观察到搜索特定的八位字节子字符串在“对话”选项卡中。

网络流量模式：

这些移位或掩码的 MAC 地址是不参与信标请求/响应、身份验证/取消身份验证帧等等，或者其他你期望的地方新的设备甚至“攻击者”设备不断出现或消失。相反，它们通常会在有效流量中间突然发送/接收随机 RTS/CTS、Block-Ack、Null Function 和 Beamforming（VHT/HE NDP 公告帧）的一次性数据包。我再说一遍，仅限一次性框架，而不是整个对话。

最终导致数以万计的一次性变异 MAC 地址，与有效设备或其他变异 MAC 地址交换一次性数据包。

鉴于上述所有证据，

这么多有效设备的 MAC 地址发生变异，最有可能的来源是什么？

请注意，我们最终会得到一个区域中数以万计的 MAC 地址，这些地址仅来自无线邻居中物理存在的十几个有效 MAC 地址。设备数量已通过前面提到的“附近的设备”扫描验证（这些扫描会查找附近的关联和未关联的设备）。

可能的理论：

  1. 高概率- 数据包错误 - 由于某种原因，这些错误未在 Wireshark 中标记为错误。为什么它们甚至会出现在 Wireshark 中？为什么它们没有被网卡/操作系统拒绝？（具体来说，2013 年中 MacBook Air 上的 macOS 10.14.5）
  2. 低概率- 恶意行为者 - 他们通过注入信标帧、RTS/CTS 等可能实现什么？此外，似乎需要付出很大努力才能实现……到底是什么？
  3. 还有什么？

答案1

这些是错误。处于监控模式的 802.11 WNIC 会尽最大努力接收和报告您设置的信道上可以看到的每个帧，但由于无线介质的不可靠性，它总是会看到许多数据包，而 SNR 不够强，无法正确接收和解码每个位。

它们之所以没有被拒绝，是因为您已将 WNIC 置于 802.11 监控模式，而监控模式通常被 802.11 工程师用于调试 802.11 问题，包括数据包错误问题，因此工程师希望能够看到错误，而不是让 WNIC 自动拒绝它们。

它们没有被 Wireshark 标记，因为处理 FCS 错误总是NIC 和嗅探器一直存在巨大的问题（这可以追溯到有线以太网的早期，因此远早于 802.11）。有些 NIC 能够将 FCS 失败的帧传递给主机，有些则不能。有些 NIC 能够在传递给主机的数据包中包含 FCS，有些则不能。嗅探器一直没有好的方法可以自动找出它正在处理的是哪种 NIC，因此它不知道是否会看到 FCS 或坏帧。

因此，据我回忆，Wireshark 默认处于安全位置，即假设帧不附加 FCS，因此它不进行 FCS 验证检查，因此它不会标记坏帧。Wireshark 有几种设置可让您控制它如何处理 FCS。

例如：

Preferences > Protocols > 802.11 Radiotap  
Preferences > Protocols > IEEE 802.11  
Preferences > Protocols > Ethernet

相关内容