Wireshark WiFi解密实战：从监听模式到看清HTTP明文

先说个我自己的经历。之前帮同事排查家里网络“偶尔打不开网页”的问题抓了一晚上包打开一看满屏都是 Beacon、ACK、NULL Data翻了几百行连个 TCP 的“毛”都没看见。那一瞬间我意识到光会抓 802.11 没用看不到网页访问内容的抓包等于抓了个寂寞。后来才搞明白真正的问题在于 WPA/WPA2 加密。WiFi 数据帧里的上层数据全被加密了Wireshark 不知道密钥自然只能看到一堆乱码一样的东西。这篇文章就是把我的完整实操过程梳理一遍从监听模式抓包开始到把 WPA/WEP 密钥交给 Wireshark再到清清楚楚看到某台设备访问了什么网页、发了什么 HTTP 请求。整个过程不需要什么高深数学功底你需要的就是一块支持监听模式的网卡、一个你自己知道密码的 WiFi以及耐心看完下面这几步。1. 为什么盯着 802.11 抓包却看不到任何网页内容1.1 802.11 帧不像以太网帧那样“裸奔”很多从有线网络转过来抓包的人第一反应是用 Wireshark 打开无线接口期待看到像 eth0 上那样的 IP 包、TCP 包、HTTP 包。结果往往很失望协议那一列全是 802.11Info 列全是 “Beacon frame”、“ACK”、“Probe Request”这类东西。这里要先了解 802.11 的帧结构。无线帧分成三大类管理帧负责连接建立和维护比如 Beacon信标、Probe Request/Response、Authentication、Association Request/Response。控制帧负责冲突避免和确认比如 ACK、RTS/CTS。数据帧真正承载上层数据IP 包、ARP 包等的帧。管理帧和控制帧为了正常工作必须能被任何设备识别所以它们基本是明文传输的。而数据帧里装的才是我们关心的网页访问内容但在 WPA/WPA2 加密的网络里数据帧的整个 payload 都会被加密。所以你抓到的 802.11 帧并不少但大部分都是“连接管理”层面的信息。真正的 IP/TCP/HTTP 数据全都藏在被加密的数据帧里面。用一句生活化的话说你看到了快递单上的地址和邮戳但拆不开里面的信封。1.2 你以为抓到的是数据包其实是密文我最早犯过的错误是抓到大量 Data 帧后以为里面应该有内容于是点开一个 Data 帧结果在 Wireshark 的 Packet Details 面板里看到的是这样的结构IEEE 802.11 Data802.11 header 里能看到源 MAC、目的 MAC、BSSID剩下的 payload 部分显示成乱码、十六进制字节如果你用的网卡驱动不支持解密Wireshark 不会自动解开这些密文。原因很简单WPA/WPA2 的加密粒度是“帧 payload”也就是说整个 MSDUMAC Service Data Unit都被加密了。802.11 header 是明文这个没问题但后面跟着的数据部分是看不懂的。网卡驱动层面可能会帮你做一层处理但绝大多数 WiFi 网卡的驱动默认只做“收包”不做“解密”。有些网卡支持所谓的“monitor mode 硬件解密”但那是针对当前已连接网络的而且往往只开放给驱动内部使用不会把解出来的明文回传给抓包工具。所以你在 Wireshark 里看到的仍然是密文。1.3 监听模式是前提但监听模式不等于解密这里还要澄清一个概念开启监听模式Monitor Mode只是让网卡能捕获所有经过空口的帧包括那些目的 MAC 不是自己的帧。普通模式下网卡只会把发给自己或广播/组播的帧交给驱动处理其他帧直接丢弃。监听模式相当于把网卡变成了一个“旁观者”能拿到所有原始帧。但监听模式解决的是“能不能收到”解决不了“收到后能不能看懂”。加密问题必须靠密钥来解。我当时就是卡在这一步监听模式开了包抓了一大堆却误以为监听模式 Wireshark 就是全部。后来查了很多文档才明白Wireshark 的无线解密功能是独立于抓包的需要手动把密钥喂给它它才能把数据帧里的密文还原成 IP 包。2. WEP/WPA 加密原理搞懂密钥你才知道怎么“解密”2.1 WEP 的老故事为什么会被时代淘汰WEPWired Equivalent Privacy是很早的无线加密协议用 RC4 流密码对数据帧进行加密。它的结构是24 位的初始化向量IV加上 40 位或 104 位的密钥拼起来作为 RC4 的种子对明文进行异或加密。听起来简单实际上问题非常大IV 只有 24 位总共 1600 万个组合。对于一个繁忙的网络几个小时就可能重复使用同一个 IV。RC4 流密码的特点是“密钥流重用”极其致命。两个不同明文用同一段密钥流加密异或在一起就能把密钥流抵消掉直接暴露出两个明文的异或结果。帧校验用的是 CRC32不是密码学意义上的消息认证码。CRC32 是线性的攻击者可以在不知道密钥的情况下篡改密文重新计算 CRC32让接收方接受伪造帧。所以 WEP 在 2000 年代中期基本被证明不可靠抓足够多的包就能在几分钟内算出密钥。现在家用路由器早就不用 WEP 了但某些老设备、实验室教学网络里偶尔还能看到。Wireshark 的解密设置里仍然保留了对 WEP 的支持做法也最简单直接填 16 进制密钥或 ASCII 密钥即可。2.2 WPA/WPA2 的密钥派生流程比你想的聪明WPA/WPA2 分个人版和企业版。个人版最常见预共享密钥PSK就是你在路由器里设置的那串 WiFi 密码8 到 63 个字符。关键点在于这串密码并不会直接用来加密数据帧。真正的过程是第一步由密码生成 PMKPairwise Master Key。算法是 PBKDF2-SHA1迭代 4096 次salt 是 SSID。也就是说对于同一个密码不同 SSID 会产生不同的 PMK。第二步PMK 经过四次握手4-Way Handshake生成 PTKPairwise Transient Key。四次握手过程中AP 会发一个随机数 ANonce终端会发一个随机数 SNonce双方交换各自的 MAC 地址再把这些信息连同 PMK 一起放进伪随机函数里算出 PTK。第三步PTK 再被拆分成几个子密钥KCK用于给四次握手消息做完整性校验。KEK用于加密后续要广播的 GTKGroup Temporal Key。TK真正用来加密单播数据帧的 Temporal Key。数据帧的加密方式在 WPA 初期是 TKIP也是基于 RC4但有完整的密钥混合和 MIC 机制到 WPA2 则全面改用 AES-CCMP安全性大幅提升。现在的 WPA2/WPA3 网络基本都是 AES-CCMP。2.3 为什么只要有密码Wireshark 就能解开很多教程只说“在 Wireshark 里填上密码就能解密”但没解释为什么。理解了上面的密钥派生过程就清楚了Wireshark 解密时输入的信息是 SSID 和密码或者 PMK 十六进制。只要它同时捕获到了四次握手包EAPOL 帧就能从握手过程里提取出 ANonce、SNonce、双方 MAC再配合输入的 PMK在本地重新计算一遍 PTK 和 TK然后用 TK 去解密后面的所有单播数据帧。也就是说解密的关键不仅在于你拥有密码还在于抓包文件里必须有完整的四次握手过程。如果只有密码而没有握手包Wireshark 算不出 TK后面的一切依然是密文。这就是为什么很多人填了密码依然解不开——他们抓的包里根本没有 EAPOL 握手或者握手被截断了。顺带一提管理帧里的信息元素如 SSID、支持的速率始终是明文所以 Wireshark 能显示 SSID、BSSID、信号强度等。看到这些不代表网络可解数据帧才是真正的战场。2.4 WPA3 的情况略有不同WPA3 使用 SAESimultaneous Authentication of Equals握手替代了 PSK 四次握手具备前向保密。这意味着即使知道密码也不能像 WPA2 那样“事后”对离线抓包数据直接解密。Wireshark 新版本支持从捕获的 SAE 握手中解密但条件更苛刻必须完整抓到 SAE 鉴权过程的帧且抓包期间要同步捕获关联过程。家用场景里 WPA3 已经不少见如果你要调试的是 WPA3 网络建议还是把路由器临时切换成 WPA2 模式省得在握手细节上浪费时间。3. 抓包前的准备监听模式与网络环境3.1 网卡选型不是所有网卡都能开监听这一步决定了你后面会不会浪费一下午。普通笔记本内置的无线网卡很多芯片的驱动根本不支持监听模式尤其是在 Windows 环境下。我的建议是准备一块 USB 外置无线网卡芯片方案优先考虑 Atheros、Ralink、Realtek 中明确标注支持 Linux/Windows 监听模式的型号。我自用的是某款采用常见芯片方案的 USB 网卡。在 Linux 下即插即用直接支持 monitor 模式Windows 下则需要装配套驱动并把模式切换到监控模式。如果你不知道手里的网卡行不行可以先用iw list查一下有没有monitor这个 supported interface mode。3.2 Linux 下开启监听模式的完整命令Linux 下的操作比较直观我直接用命令行演示。先用iw查看无线接口名称一般是wlan0或者phy0对应的接口。然后创建监听模式的虚拟接口# 查看无线网卡信息 iw dev # 创建名为 mon0 的监听接口 iw phy phy0 interface add mon0 type monitor # 激活接口并关闭网络管理器的干扰 ip link set mon0 up如果你习惯用 Aircrack-ng 工具集也可以直接airmon-ng start wlan0它会自动把wlan0切换成wlan0mon。之后在 Wireshark 里选择这个接口抓包即可。有一点需要注意如果系统里的 NetworkManager 还在自动管理该网卡会时不时把它拉回普通模式。稳妥起见抓包前可以先停掉网络管理服务或者至少在抓包期间不要用同一块网卡联网。3.3 Windows 下开启监听模式的差异Windows 下的 Wireshark 是支持通过 Npcap 抓包的但监听模式的开关通常不在 Wireshark 里而在网卡驱动自带的配置工具中。我看到过的做法有某些网卡工具里有“Monitor Mode”或“RF Monitor”开关打开后 Wireshark 里会出现一个新的无线接口。有些驱动不支持切换但会在抓包时自动把接口置于“RF Monitor”状态你可以直接看到 802.11 帧。如果你在 Windows 下拉不出 802.11 帧大概率是网卡不支持别硬折腾换一块 Linux 下公认能开监听模式的 USB 网卡更省心。3.4 抓包时如何“逼”出一次握手解密必须依赖四次握手所以抓包过程中要确保有一台设备完成连接过程。最稳妥的办法是先用手机或电脑连接目标 WiFi。开启 Wireshark 抓包。手动断开 WiFi再重新连接。重新连接时Wireshark 会捕获到 EAPOL 帧。过滤表达式可以直接用eapol || wlan.fc.type_subtype 0x08其中的0x08是 QoS Data 帧类型。当你能看到四条 EAPOL 消息Message 1 到 Message 4说明握手抓全了。我第一次抓握手没经验一直开着抓包等“自然”的重新连接结果等了好几小时。后来学乖了直接在手机上开关一次飞行模式几秒钟就能抓到完整握手。4. Wireshark 解密设置把密钥告诉它4.1 准备工作确认 SSID 和密码要解密Wireshark 需要知道两样东西目标网络的 SSID 和密码PSK。这两个信息必须和你抓包时网络的实际情况完全一致包括大小写。SSID 配错一个字符解密就会静默失败。如果你不想直接填明文密码也可以先把自己网络的 PMK 算出来用十六进制形式填进去。计算 PMK 常用这个命令# 格式wpapsk 密码 SSID wpapsk MyPassphrase MySSID或者用现成的在线工具/脚本算出 64 位十六进制 PMK。不过对大多数场景直接在 Wireshark 里填密码加 SSID 就够了。4.2 编辑解密密钥的具体步骤在 Wireshark 里依次打开菜单栏编辑Edit- 首选项Preferences。左侧协议列表里找到 IEEE 802.11。勾选 “Enable decryption” 启用解密。在 “Decryption Keys” 区域点击 “Edit...”。添加密钥类型选择wpa-pwd密钥格式是密码:SSID。举个例子如果你的 WiFi 密码是MyHome123SSID 是MyHomeWiFi那么密钥字符串写成MyHome123:MyHomeWiFi如果你用的是 WEP 加密则类型选择wep密钥填十六进制或 ASCII 字符串即可。个人经验是在实验室老设备上偶尔会遇到 WEP填完后立刻能解开没有什么额外条件。4.3 验证配置是否正确配置完成后不需要重新抓包Wireshark 可以对已保存的抓包文件直接重新解析。你在抓包文件里随便点开一个 Data 帧如果解密成功Packet Details 里会从 IEEE 802.11 Data 下面多出一层显示为Logical-Link ControlInternet Protocol Version 4Transmission Control Protocol同时Wireshark 顶部的协议列里也会出现 TCP、HTTP、DNS 等而不是清一色的 802.11。如果你发现设置没问题但依然解不开最常见的两个原因是抓包文件里没有完整四次握手。你抓到的网络不是这个 SSID或者密码不对。这时候不要急着怀疑 Wireshark先回看抓包文件里的 EAPOL 消息是否完整。4.4 密钥格式速查表加密类型密钥类型格式示例说明WEPwepabcde或十六进制直接用 WEP 密钥WPA/WPA2wpa-pwdMyHome123:MyHomeWiFi密码在前SSID 在后WPA/WPA2wpa-psk64 位十六进制 PMK已算好的 PMKWPA3需要 SAE 握手同上 wpa-pwd必须抓完整 SAE 过程我强烈建议日常调试直接把类型用wpa-pwd因为它最直观也最容易排查密码是否填对。只有在不想明文暴露密码、或需要在多个抓包文件之间复用同一个 PMK 时才用wpa-psk。5. 看清网页访问的实际效果从密文到明文5.1 先拿 HTTP 页面练手一眼看到 GET 请求配置好解密后找一个 HTTP 网站在浏览器里打开一次页面。EAPOL 握手仍然是解密的前提所以建议流程是先抓包开关一次 WiFi 重连再访问 HTTP 网站。然后用过滤表达式定位http.request这时候你会看到的请求大概是GET /index.html HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 ... Accept: text/html Cookie: sessionxxxx没错这些都是明文。浏览器访问一个普通 HTTP 网站时请求头、Cookie、POST 内容在 WiFi 这一层完全没有遮挡。这也是我一直强调“自家网络调试别访问敏感站点”的原因——虽然最后一段链路是 WiFi一旦抓包解密HTTP 层面的隐私等于谁拿到抓包文件谁就能看。我实测过用手机连上自家 WiFi打开一个纯 HTTP 站点Wireshark 里能看到手机发出的完整 GET 请求响应头、HTML 内容也都明明白白。这一过程对学习 HTTP 协议非常直观。5.2 HTTPS 情况解开了 WiFi但 TLS 还在里面现在大部分网站都是 HTTPS。解密 WiFi 后你看到的不再是加密的 802.11 帧而是明文 IP 包里的 TLS 记录。具体能看到的包括TCP 三次握手。TLS ClientHello其中包含 SNI服务器名称指示也就是你访问的域名。TLS ServerHello 和证书消息。但 TLS 的应用数据是使用会话密钥加密的。如果你没有额外配置 Wireshark 的 TLS 解密需要网站的私钥或者配置 SSLKEYLOGFILE那么在 Info 列看到的仍然是 “Application Data”点开也只是一堆二进制。这里要记住一个很容易绕晕的概念Wireshark 的 802.11 解密解决的是“WiFi 链路层加密”TLS 解密解决的是“应用层加密”两层互不替代。我见过有朋友以为解密 WiFi 后就能看到 HTTPS 的全部明文结果解完发现还有 TLS 密文直接懵了。如果你想进一步看到 HTTPS 明文方法也有在支持 SSLKEYLOGFILE 的浏览器/客户端里把 TLS 会话密钥导出来给 Wireshark。但那属于另一个话题本文就不展开了。你只需要明确WiFi 解密解决的是第一层封套。5.3 顺手分析网页访问的关键节点解密之后最大的意外收获是你终于可以用抓包数据来精确排障了。比如之前同事“偶尔打不开网页”的问题解密后我在抓包文件里看到了典型的 TCP 重传风暴某个 DNS 请求发出后没有响应。随后 TCP 建连时 SYN 包反复重传。路由器或 AP 的信号强度很低数据帧频繁重传。最后浏览器超时。如果是未解密状态这些 TCP 细节全都隐藏在海量 802.11 帧里根本没法分析。解密后一切回到你熟悉的“有线网络排障模式”dns.flags.response 0 # 查看发出的 DNS 请求 tcp.analysis.retransmission # 查看重传 tcp.analysis.fast_retransmission这些过滤条件在有线抓包中常用在解密后的 WiFi 抓包里同样可用。我当时就是靠这个把问题定位到路由器到某台设备的链路质量上而不是笼统地怀疑“运营商有问题”。5.4 还能看到哪些意外信息解密后能看到的不仅是 HTTP。你还能看到DHCP 请求/响应确认终端拿到的 IP、DNS、网关。ARP 请求排查 IP 冲突。组播 DNSmDNS和 SSDP看智能家居设备在干什么。各种 App 发起的长连接。对平时做协议分析或者智能家居调试的人来说解密 WiFi 相当于把家里的网络“透明化”了设备后台连了什么服务器、发了什么包全部一览无余。当然这只限于你自己拥有路由器和密码的网络环境抓别人的网属于另一个严肃话题后文我会专门强调。6. 常见问题与避坑指南6.1 输入了密钥但还是解不开先查握手这是出现频率最高的问题。很多人配置密钥后发现数据帧依然没有解出 IP 层。我建议按照下面顺序排查过滤eapol确认抓到 4 条握手消息。看wlan_rsna_eapol的 Key Descriptor Version 和 Key Information 字段确认握手类型。确认密钥格式没写反。wpa-pwd必须写成密码:SSID而不是SSID:密码。如果你的网卡在普通模式下抓到包而不是监听模式可能根本拿不到完整的 802.11 帧头解密自然失败。还有个容易忽略的点如果你抓包文件里只有一个方向的握手消息比如只有 AP 发来的 Message 1 和 Message 3没有终端的 Message 2 和 Message 4Wireshark 不算完整握手。此时最好的办法就是重新开关一次 WiFi强制进行一次新的完整连接。6.2 802.11r 快速漫游环境下的解密问题现在很多路由器默认开启了 802.11r 快速漫游Fast BSS Transition终端在不同 AP 之间漫游时用 FTFast Transition握手指纹来快速切换。这会导致 Wireshark 在漫游后的 AP 上无法直接解析出 PTK因为它需要的 FT 认证信息是在快速切换握手过程中确认的。如果你在家里组了 Mesh 网络且开了解密还是只能解出一部分帧问题很可能就出在这里。解决方式是在路由器后台临时关闭 802.11r重新抓包。对于只调试单个 AP 的场景关闭 802.11r 是最省事的选择。6.3 部分帧没有解出明文是正常的解密成功不代表所有数据帧都变成 IP 包。以下情况仍然会显示为 802.11 密文或干脆看不见QoS Null 帧不携带实际数据只用于省电和信道占用没有明文内容可看。组播/广播数据帧它们可能使用 GTK 加密。如果 Wireshark 没有从握手包中提取到 GTK就解不开组播帧。这个问题一般出现在 Wireshark 只捕获了部分握手的情况下。某些管理帧的 protected 位比如受保护的 Block Ack 请求/响应在部分驱动下不解密。遇到这些别慌重点确认单播的数据帧能解开就能覆盖 99% 的网页访问分析场景。6.4 合规与边界只做自己的网络或授权测试这一点必须强调。解密 WiFi 的前提是拥有该网络的合法访问权。最典型的合法场景包括自己家里的路由器。公司/学校分配给自己的网络。获得明确授权的渗透测试或安全实验。千万不要对不认识的 WiFi 抓包并尝试解密。这不仅涉及隐私问题在很多地方可能直接违反相关法律法规。我做这类实验都是在自己的路由器上、用自己设备完成的。文章里给出的所有操作都假设你对目标网络拥有合法授权。6.5 常见问题速查表现象可能原因解决办法只有 802.11 帧没有 EAPOL网卡不是监听模式抓包期间没有设备重连确保监听模式开关一次 WiFiEAPOL 有但缺消息握手被截断重新完整连接一次填了密钥仍不解密密钥格式、SSID、密码错误检查密码:SSID格式确认大小写部分数据帧解不开GTK 未提取或 802.11r 干扰关 802.11r重新抓完整握手解开了 WiFi 仍看到乱码上层是 HTTPS/TLS需要 TLS 解密属于另一层级WPA3 网络解不开SAE 握手未全部捕获抓完整 SAE 过程或临时切到 WPA2最后分享一个小技巧。我每次抓 WiFi 包之前都会先看一眼抓包文件里的wlan_rsna_eapol确认握手抓齐了再开始访问网站而不是抓完再检查。这个习惯帮我省了很多重新抓包的时间。你如果刚接触 Wireshark 解密建议也养成这个习惯先抓握手再测流量最后再谈分析。解密 WiFi 看起来是一行配置的事但背后的握手与密钥派生逻辑搞懂了日后遇到 WPA3、802.11r、企业认证时都不会发怵。