Wireshark 分析 wep 的 icv（not verified）问题

我想很多人应该和我有一样的困惑，那就是读取802.11b的数据时候，本来应该是明文数据和ICV在传输前，都被加密的，为什么wireshark可以显示出 icv 的值呢？

例如: WEP ICV: 0x12345678 (not verified)

我再官方网站找到了答案

给大家简单翻译一下（虽然我翻译的很烂）：

我知道专门给一个人的问题回复是不太好的，不过我需要更正我的错误。

当Wep一开始的时候，ICV值 是 作为一个数据包明文有效负载的混杂计算出来的，4-byte的 ICV 然后加再 数据有效负载之后，然后 （数据+ICV）一起用RC4加密。

随着 Wep 算法的完成，一个CRC32的值 被 计算 用于 检测是否有传输过程中的数据损坏，而不是作为一种安全机制，用来保护数据被篡改。CRC32值作为 帧检查段（FCS）,添加到帧的最后，跟在加密数据的后面。

所以，icv是加密数据的一部分也是对的，显示为 “not verified”icv，但是其实只是 加密数据的最后4-byte数据。并不是从明文计算出的icv值。

不过如果你指明 wep 用来加密的密钥，包解析器将会解密wep并显示真实的ICV值。

FCS没有包含再文件最后我很吃惊，但是阅读802.11包解析器的源码之后，我意识到有一些设备并不会将FCS报给libpcap，所以也没法知道packet的正确长度了。我们也没法确定FCS到底显示了没有。选择 “Assume packets have FCS”选项将让显示的时候，把最后4-byte作为FCS显示，然后吧之前的4位，作为ICV显示（如果是wep的话），但是这个会不会发生，完全取决于设备。

---

我的测试：

在设置wep密钥之前，我只能分析出数据链路的帧的。

在 编辑-首选项-协议 中找到wep，添加密钥为 “31：32：33：34：35” 因为我的密钥是123345

可以再打开文件，数据包就回被解密为 tcp 或者 http的报文格式了