抓包的时候最烦的就是遇到加密的 WiFi 流量——明明 HTTP 请求就在眼前打开却是满屏的 802.11 协议乱码DNS、TCP 全被藏在密文后面。以前我处理这种问题都是打开 Wireshark 图形界面点鼠标配置解密密钥可一旦要批量分析几十个 pcap或者把解密流程写进自动化脚本手点就不现实了。后来我发现 pyshark 可以直接对接 tshark 的 802.11 解密能力用几行 Python 代码就能把 WEP、WPA-PWD、WPA-PSK 三种常见场景全部搞定从此再也不用靠手工点来点去。这篇文章把我自己踩过的坑、实测过的参数组合全写出来完整覆盖 WEP、WPA-PWD、WPA-PSK 的解密实操给到可以直接跑通的代码顺便再把背后的原理讲清楚。适合正在做无线网络安全分析、协议研究或者已经在用 Wireshark 做数据包分析但想转向 Python 自动化的朋友。提前说明所有解密演示必须用于你拥有合法授权的网络环境比如自己的 AP、实验室内网或者明确授权的渗透测试和 CTF 题目。1. 解密前的底层逻辑WEP/WPA 加密与 pyshark 的解密入口1.1 为什么加密流量打开全是乱码802.11 加密的目的很简单不让第三方直接看到数据内容。WEP 时代用的是 RC4 流加密密钥要么是 40 位要么是 104 位解密时只要拿到正确的密钥原始明文就能恢复。WPA/WPA2 就复杂一些TKIP 和 CCMPAES都不再用静态密钥直接加密数据帧而是通过四次握手协商出成对的临时密钥PTK再用 PTK 对数据帧做加密。这意味着解密 WPA 加密的数据包不是仅仅知道一个密码字符串就能解决的。抓包里必须有完整的四次握手过程或者你手上有预共享密钥PSK再加上准确的 SSID才能推导出成对主密钥PMK进而恢复出 PTK。这也是为什么 WPA 解密比 WEP 挑数据包完整性——抓包阶段丢了握手帧后面拿着真密码也白搭。1.2 pyshark 在解密链中的角色pyshark 并不是重新实现了一套解密算法它是 tshark 的 Python 封装。真正的帧解密、协议解析、PMK 推导全部由 tshark 在底层完成pyshark 负责拼装命令行参数、执行命令、解析输出。理解这个角色非常重要因为你会发现pyshark 能解密的范围和 tshark 一模一样很多诡异的问题其实是你传参的方式不对而不是 pyshark 本身不支持。举个例子Wireshark 图形界面里有一个“802.11 解密”设置面板你可以在里面填 WEP 密钥、WPA 密码、PSK 等。这些配置最终都会映射到 tshark 的命令行参数上pyshark 则通过decryption_key和decryption_key_type这两个参数帮你把这些配置传进去。1.3 成功解密的三个必要条件正确的密钥材料WEP 的真实密钥字节或者 WPA 的密码短语 SSID又或者是 64 位十六进制的 PMK/PSK。完整的数据包捕获WPA 需要捕获到四次握手帧WEP 则需要捕获到足够的 ARP 注入帧或其他交互帧否则即使密钥正确也无法还原出足够多的明文。正确的协议配置确保 tshark 的 802.11 解密开关被打开这对应 Wireshark 里的“Enable decryption”选项。这三个条件缺一不可后面所有实操都是围绕它们展开的。2. 环境准备装好 pyshark 和 tshark把解密开关点亮2.1 安装步骤与版本要求pyshark 本身用 pip 装就行pip install pyshark但真正干活的 tshark 需要单独装。Wireshark 安装包里会带上 tsharkLinux 下可以直接用系统包管理器安装。装完以后确认一下 tshark 版本tshark --version如果提示找不到命令多半是 tshark 没有加入 PATH。在 Windows 上常见的情况是 Wireshark 装好了但 tshark 不在系统路径里需要手动把C:\Program Files\Wireshark加进 PATH或者在 pyshark 构造捕获对象时用tshark_path参数明确指定cap pyshark.FileCapture(capture.pcapng, tshark_pathC:/Program Files/Wireshark/tshark.exe)pyshark 版本尽量选新一点的0.4 以上对解密参数的支持才比较稳定。如果你现在还停留在 0.3.x建议直接升级否则decryption_key_type这个参数很容易出现“传了等于没传”的诡异现象。2.2 准备一份可复现的测试文件实战中你可以用自己的无线网卡抓包获取实验素材。把网卡切入监听模式在目标网络附近抓一小段时间确保捕获到了客户端关联和四次握手过程sudo airmon-ng start wlan0 sudo airodump-ng -c 6 --bssid 00:11:22:33:44:55 -w lab_capture wlan0mon然后让某个设备重新连接一次该 WiFi这样握手的四个帧就能被完整抓下来。比如退出重连手机热点或者直接把路由器重启一下。如果你只是想做本地测试也可以直接用 Wireshark 自带的示例抓包文件或者自己搭一个无线热点用安装了抓包工具的客户端连接一次。关键是数据包质量不是数据量大小。2.3 验证 pyshark 能否正常调用 tshark先跑一段最简单的读取脚本确认整个链路是通的import pyshark cap pyshark.FileCapture(lab_capture.pcapng) count 0 for pkt in cap: count 1 print(ftotal packets: {count})能打出包总数说明 pyshark 到 tshark 的基本链路没问题。接下来就可以进入正题逐一开始 WEP、WPA-PWD、WPA-PSK 的解密实操。3. WEP 解密实操从 pcap 到明文只需两行参数3.1 WEP 密钥的类型40 位与 104 位WEP 密钥按位长分两种40 位5 字节和 104 位13 字节。很多老设备也支持 128 位 WEP但本质上就是 104 位密钥。这里的“位”指的是密钥实际长度而不是你在路由器管理界面输入的 ASCII 字符串长度。在 Wireshark/tshark 的体系里WEP 密钥可以用 ASCII 字符串表示也可以用十六进制字符串表示。ASCII 模式下 40 位密钥是 5 个字符104 位密钥是 13 个字符十六进制模式下则分别是 10 个字符和 26 个字符。实际抓包分析时路由器里配置的如果是短密码比如12345那就是 40 位 WEP如果是 13 位字符串则是 104 位 WEP。3.2 实操FileCapture 解密 WEP pcap解密 WEP 数据包时在 pyshark 里只需要传入密钥和类型import pyshark cap pyshark.FileCapture( wep_lab.pcap, decryption_key1234567890, # 10 位十六进制对应 40 位 WEP decryption_key_typewep ) for pkt in cap: if hasattr(pkt, http): print(HTTP found:, pkt.http.request_uri) elif hasattr(pkt, dns): print(DNS query:, pkt.dns.qry_name)如果你拿到的是 ASCII 类型的密钥比如路由器管理页面里显示的是helloworld10 个字符你就得先确认它到底是 ASCII 还是十六进制显示。不少二手路由器把 WEP 密钥显示成十六进制少数老设备会显示 ASCII混着用最容易出错。我的建议是统一转成十六进制传给 pyshark避免字符编码带来的歧义。转换方法也很简单Python 里key_hex password.encode(utf-8).hex()但要注意WEP 密钥的 ASCII 表示通常限定为 5 或 13 个字节如果你的密钥长度不在这个范围路由器在配置时就会拒绝。3.3 怎么确认真的解密成功了解密是否成功最直观的验证方式是看数据包还能不能解析出上层协议。加密状态下全部流量都蜷缩在 802.11 Data 帧里看不到 HTTP、DNS、TCP 等协议头解密成功后数据链路层之上会出现 LLC、IP、TCP乃至完整的应用层数据。还有一个辅助判断方法对比解密前后相同 pcap 的包数。解密开启后tshark 会把一个加密数据帧还原成包含明文净荷的帧结构有时会出现“从一个帧里拆出更多解析内容”的情况所以能看到的有效协议层数量明显变多这可以作为参考信号。提示WEP 破解在现实里已经几乎被淘汰了但 WEP 解密脚本在分析老旧嵌入式设备、工控系统或 CTF 题目时依然很常用。它的价值更多体现在“理解老协议的解密链路”上。4. WPA-PWD 解密实操密码短语 SSID 的完整配置4.1 什么是 WPA-PWDWPA-PWD 这个名字在不同工具里叫法不完全一样在 Wireshark/tshark 的 802.11 密钥 UAT 表里它表示“WPA Passphrase 方式”。这种方式的输入不是现成的 PMK而是两样东西密码短语passphrase和 SSID。tshark 拿到这两样东西后会按照 802.11i 标准里的 PBKDF2-SHA1 算法做 4096 次迭代生成一个 256 位的 PMK。整个过程可以理解为“密码 SSID 共同作为种子算出一个用于后续握手验证的密钥材料”。所以 WPA-PWD 方式下SSID 写错了哪怕密码完全正确最后得到的 PMK 也是错的。4.2 实操decryption_key 里直接写 password:ssidpyshark 里 WPA-PWD 的密钥格式比较特殊要把密码和 SSID 拼在一起中间用冒号分隔传给decryption_key类型指定为wpa-pwdimport pyshark cap pyshark.FileCapture( wpa2_lab.pcapng, decryption_keymysecret123:test_wifi, # 格式是 密码:SSID decryption_key_typewpa-pwd ) for pkt in cap: if hasattr(pkt, http): print(HTTP request:, pkt.http.request_uri) if hasattr(pkt, tcp): pass这里有一个非常考验人的细节pyshark 官方文档写的是decryption_key和decryption_key_type但底层的 tshark 实际生成的是类似uat:80211_keys:wpa-pwd,mysecret123:test_wifi的参数。如果你自己在 custom_parameters 里手动写也必须是这个结构拼错一个逗号位置解密就会静默失败。4.3 实操心得握手完整性、大小写和 SSID 编码这一节值得单独写因为 WPA-PWD 解密失败的案例里十有八九都栽在下面几个地方。握手不完整是头号问题。WPA 四次握手的四个帧不一定要 100% 全抓到但至少要抓到 key 交换的关键部分。最稳妥的做法是抓包的时候慢慢点客户端重连或者用专门工具反复触发关联流程确保 pcap 里的握手帧数量足够。SSID 必须精确匹配。有人会问密码明明是对的为什么还是解不开答案往往是 SSID 大小写不一致比如实际网络叫Test_WiFi你在代码里写成了test_wifiPMK 计算结果就完全不同。SSID 是二进制安全的字符串但不代表它对大小写不敏感至少在 PMK 推导这一步字节差异会直接导致结果不同。密码本身只能取 ASCII 范围内的字符吗也不是绝对但是很多路由器配置界面只接受可打印 ASCII。如果密码里有中文或者其他非 ASCII 字符你需要考虑编码问题抓包侧和计算 PMK 侧必须用同一个编码方式。我自己遇到过一次密码末尾带不可见空格的情况排查了很久才发现是复制粘贴过程引入了额外字符。再有一个细节pyshark 的decryption_key_type参数名在不同版本里可能有细微差异0.4 之后基本都稳定为decryption_key_type但如果你用的是笔记本里随手装的老版本建议先升级再排查问题。5. WPA-PSK 解密实操用 64 位十六进制密钥直接解5.1 PSK 和 PMK 的关系别再混着叫WPA-PSK 这个词在日常口语里经常指“WPA 预共享密钥”也就是你在手机里输入的密码短语。但在 Wireshark 的 80211_keys UAT 表里wpa-psk类型要求的值不是密码短语而是 64 位十六进制的 PMK。可以这样理解wpa-pwd是让 tshark 现算 PMK输入材料是密码和 SSIDwpa-psk是直接喂给它算好的 PMK省略了 PBKDF2 计算环节。二者本质上是同一个密钥材料的不同表达形式网络上有些人把wpa-psk和密码短语混为一谈到了传参这一步就会翻车。5.2 实操把密码短语转成 PSK 再喂给 pyshark如果你手头只有密码短语和 SSID可以先用工具生成对应的 PSK。Linux 下最简单的是wpa_passphrasewpa_passphrase test_wifi mysecret123输出里那个psk后面的 64 位十六进制字符串就是 PMK也就是 tshark 需要的 wpa-psk 值。不想依赖系统工具也可以用 Python 算import hashlib def passphrase_to_psk(passphrase: str, ssid: str) - str: pmk hashlib.pbkdf2_hmac( sha1, passphrase.encode(utf-8), ssid.encode(utf-8), 4096, 32 ) return pmk.hex()算好之后在 pyshark 里直接使用import pyshark psk_hex 9f9f...64 位十六进制 cap pyshark.FileCapture( wpa2_lab.pcapng, decryption_keypsk_hex, decryption_key_typewpa-psk ) for pkt in cap: if hasattr(pkt, dns): print(DNS:, pkt.dns.qry_name)特别注意传给decryption_key的字符串必须正好是 64 个十六进制字符任何多余的空格、换行符、前导0x都会让解析失败。有些工具会输出带0x前缀的格式记得剥掉。5.3 WPA-PWD 和 WPA-PSK 到底怎么选场景推荐方式原因手头只有 WiFi 密码wpa-pwd直接传 password:ssid让 tshark 推导 PMK手头已经有 PMK/PSKwpa-psk不依赖 SSID 二次计算适合自动化批处理多个 AP 同密码但 SSID 不同wpa-pwd每次指定不同 SSID分别解密大量 pcap 批量分析wpa-psk预计算好 PSK参数固定出错概率小只想验证某个握手包密钥wpa-psk离线分析时避免 PBKDF2 重复计算开销我自己做批量分析时更倾向于 wpa-psk。原因很简单PMK 算一次是固定的后续所有 pcap 用同一个 64 位十六进制值省掉了每次都拼接密码和 SSID 的麻烦也少了一层“SSID 大小写写错”的风险。6. 实时解密与高级参数LiveCapture 和 custom_parameters6.1 LiveCapture 实时抓包解密除了离线解析 pcap 文件pyshark 也支持实时抓包并同时解密。比如你已经知道某个热点的密码想实时看看当前连接的设备都在访问哪些域名可以这样import pyshark cap pyshark.LiveCapture( interfacewlan0mon, decryption_keymysecret123:test_wifi, decryption_key_typewpa-pwd ) for pkt in cap.sniff_continuously(): if hasattr(pkt, http): print(HTTP:, pkt.http.request_uri)这里有几个前提必须讲清楚。第一网卡必须支持并开启监听模式否则网卡驱动会把 802.11 帧转换成伪以太网帧很多加密信息在这一步就丢了。第二实时解密要求抓包进程和握手发生过程同步如果程序启动时客户端已经完成关联后续数据包仍然解不开。第三Linux 下监听模式抓包需要 root 权限pyshark 报权限错误的话检查一下是不是没有用 sudo。实时解密更适合做无线网络故障定位比如现场排查某个终端上网慢或者统计一个 AP 下的真实流量分布。它的性能开销比离线解析大流量高的时候容易丢包所以生产环境最好还是抓完包再离线解密。6.2 用 custom_parameters 手动控制 tshark说完 LiveCapture再补一个 pyshark 里容易被忽略但极其实用的功能custom_parameters。它可以让你直接向 tshark 命令行传递任意参数也就是说你能做出比 pyshark 默认参数更复杂的解密配置。举个例子如果 pcap 里有多个 WEP 密钥直接通过decryption_key只能填一个但用 custom_parameters 可以把 80211_keys UAT 表里的多行密钥全部写进去import pyshark cap pyshark.FileCapture( multi_key.pcap, custom_parameters[ -o, wlan.enable_decryption:true, -o, uat:80211_keys:wep,AAAA:1111, -o, uat:80211_keys:wep,BBBB:2222, ] )注意custom_parameters 接收的是一个列表列表的每个元素是按照命令行顺序排列的参数名和参数值。所以-o和uat:80211_keys:...必须成对出现。这个设计有点反直觉但它确实能让你绕过 pyshark 默认封装直接用 tshark 的完整能力。6.3 监控模式下的抓包小提示如果你准备自己抓取解密素材监听模式是绕不开的环节。Linux 下用 airmon-ng 切监听模式之后接口名通常会变成带mon后缀的名字比如wlan0mon。抓包的时候要注意监听模式下网卡不参与正常的网络通信也就是说你用同一块网卡一边抓包一边上网是行不通的。另外在 802.11 信道上很多网卡默认只抓管理帧和数据帧的控制部分数据帧的完整内容可能需要额外设置射频监控模式monitor flag才能全部收进来。不同无线网卡芯片支持度差异很大有些网卡比如部分高通芯片能很完整地抓全数据帧有些网卡则只能收到零散碎片。抓包质量不好后面解密再正确也没用。7. 常见问题与排查技巧实录7.1 高频问题速查表现象可能原因排查方向解密后仍然只有 802.11没有上层协议密钥错误、SSID 错误、抓包没有握手帧先用 tshark 命令行加相同参数测试WPA 解密能看到部分 ICMP但看不到 HTTP抓包过程中只捕获了部分会话数据检查抓包是否跨完整连接重新抓包pyshark 报错 tshark 命令执行失败tshark 路径不对、参数格式错误打印实际执行的 tshark 命令逐步拆分decryption_key_type 好像没生效pyshark 版本过旧或参数名拼写错误升级 pyshark检查源代码签名可以解析 DNS但应用层乱码解密正常但抓包存在分片丢失检查 pcap 是否存在大量 Fragmented 帧wpa-pwd 始终解不开 WPA3 网络WPA3 的握手机制与 WPA2 不同确认网络是 WPA2-Personal不是 WPA3-SAE7.2 三步定位法解密失败时不要盲目改参数我一般按照下面三步来排。第一步用 tshark 命令行直测绕过 pyshark。举一个 WPA-PWD 的例子tshark -r wpa2_lab.pcapng -o wlan.enable_decryption:true -o uat:80211_keys:wpa-pwd,mysecret123:test_wifi -Y http || dns如果 tshark 能正常解析出 HTTP 和 DNS说明 pcap 文件和解密密钥都没问题问题出在 pyshark 传参环节。如果 tshark 也解析不出来那基本可以断定是 pcap 缺握手帧或密钥本身有误。第二步检查握手帧是否存在。用显示过滤器筛选 EAPOLtshark -r wpa2_lab.pcapng -Y eapol如果 eapol 一个都看不到说明抓包根本没有覆盖四次握手这时候任何解密操作都是徒劳重新抓包才是出路。第三步打印 pyshark 实际生成的 tshark 命令。在 pyshark 里可以临时 hack 一下把命令打出来cap pyshark.FileCapture(wpa2_lab.pcapng, decryption_keymysecret123:test_wifi, decryption_key_typewpa-pwd) print(cap._get_tshark_command()) # 查看实际命令行对比打印出的命令和第 7.2 节第一步里的手工命令找出参数差异往往一眼就能看出问题所在。7.3 几个小技巧批量解密一堆 pcap 时建议把它封装成一个函数把密钥、SSID、文件路径作为参数传进去def decrypt_pcap(filepath, passwordNone, ssidNone, pskNone): if psk: key psk key_type wpa-psk else: key f{password}:{ssid} key_type wpa-pwd cap pyshark.FileCapture( filepath, decryption_keykey, decryption_key_typekey_type, display_filterhttp || dns ) result [] for pkt in cap: result.append(pkt) cap.close() return result另外解密时建议加上display_filter只筛选你关注的协议。环境复杂的时候一个 pcap 里可能有几千个包不做过滤的话pyshark 逐个包解析的上层协议会拖慢速度而且内存占用会明显上升。用keep_packetsFalse也可以减少内存压力适合只需要逐包流式处理的场景。我自己的习惯是正式跑批量任务前先抽出一个小 pcap 验证密钥和参数再放到完整文件上执行。不要一上来就对几百兆的文件跑解密一旦参数错误纯浪费时间。最后再分享一个个人体会解密类操作的成功率很大程度上取决于抓包阶段的质量而不是解密阶段的算法。很多朋友拿了一个缺握手的 pcap 反复调 pyshark折腾一晚上也没结果其实就是一开始数据就没抓全。所以现在我看到类似问题第一反应永远是先确认抓包素材的完整性再看密钥参数。先把这一步养成本能你会发现 WEP、WPA-PWD、WPA-PSK 这些解密操作本质上都只是“把正确的凭证喂给会算的家伙”而已。
抓包的时候最烦的就是遇到加密的 WiFi 流量——明明 HTTP 请求就在眼前打开却是满屏的 802.11 协议乱码DNS、TCP 全被藏在密文后面。以前我处理这种问题都是打开 Wireshark 图形界面点鼠标配置解密密钥可一旦要批量分析几十个 pcap或者把解密流程写进自动化脚本手点就不现实了。后来我发现 pyshark 可以直接对接 tshark 的 802.11 解密能力用几行 Python 代码就能把 WEP、WPA-PWD、WPA-PSK 三种常见场景全部搞定从此再也不用靠手工点来点去。这篇文章把我自己踩过的坑、实测过的参数组合全写出来完整覆盖 WEP、WPA-PWD、WPA-PSK 的解密实操给到可以直接跑通的代码顺便再把背后的原理讲清楚。适合正在做无线网络安全分析、协议研究或者已经在用 Wireshark 做数据包分析但想转向 Python 自动化的朋友。提前说明所有解密演示必须用于你拥有合法授权的网络环境比如自己的 AP、实验室内网或者明确授权的渗透测试和 CTF 题目。1. 解密前的底层逻辑WEP/WPA 加密与 pyshark 的解密入口1.1 为什么加密流量打开全是乱码802.11 加密的目的很简单不让第三方直接看到数据内容。WEP 时代用的是 RC4 流加密密钥要么是 40 位要么是 104 位解密时只要拿到正确的密钥原始明文就能恢复。WPA/WPA2 就复杂一些TKIP 和 CCMPAES都不再用静态密钥直接加密数据帧而是通过四次握手协商出成对的临时密钥PTK再用 PTK 对数据帧做加密。这意味着解密 WPA 加密的数据包不是仅仅知道一个密码字符串就能解决的。抓包里必须有完整的四次握手过程或者你手上有预共享密钥PSK再加上准确的 SSID才能推导出成对主密钥PMK进而恢复出 PTK。这也是为什么 WPA 解密比 WEP 挑数据包完整性——抓包阶段丢了握手帧后面拿着真密码也白搭。1.2 pyshark 在解密链中的角色pyshark 并不是重新实现了一套解密算法它是 tshark 的 Python 封装。真正的帧解密、协议解析、PMK 推导全部由 tshark 在底层完成pyshark 负责拼装命令行参数、执行命令、解析输出。理解这个角色非常重要因为你会发现pyshark 能解密的范围和 tshark 一模一样很多诡异的问题其实是你传参的方式不对而不是 pyshark 本身不支持。举个例子Wireshark 图形界面里有一个“802.11 解密”设置面板你可以在里面填 WEP 密钥、WPA 密码、PSK 等。这些配置最终都会映射到 tshark 的命令行参数上pyshark 则通过decryption_key和decryption_key_type这两个参数帮你把这些配置传进去。1.3 成功解密的三个必要条件正确的密钥材料WEP 的真实密钥字节或者 WPA 的密码短语 SSID又或者是 64 位十六进制的 PMK/PSK。完整的数据包捕获WPA 需要捕获到四次握手帧WEP 则需要捕获到足够的 ARP 注入帧或其他交互帧否则即使密钥正确也无法还原出足够多的明文。正确的协议配置确保 tshark 的 802.11 解密开关被打开这对应 Wireshark 里的“Enable decryption”选项。这三个条件缺一不可后面所有实操都是围绕它们展开的。2. 环境准备装好 pyshark 和 tshark把解密开关点亮2.1 安装步骤与版本要求pyshark 本身用 pip 装就行pip install pyshark但真正干活的 tshark 需要单独装。Wireshark 安装包里会带上 tsharkLinux 下可以直接用系统包管理器安装。装完以后确认一下 tshark 版本tshark --version如果提示找不到命令多半是 tshark 没有加入 PATH。在 Windows 上常见的情况是 Wireshark 装好了但 tshark 不在系统路径里需要手动把C:\Program Files\Wireshark加进 PATH或者在 pyshark 构造捕获对象时用tshark_path参数明确指定cap pyshark.FileCapture(capture.pcapng, tshark_pathC:/Program Files/Wireshark/tshark.exe)pyshark 版本尽量选新一点的0.4 以上对解密参数的支持才比较稳定。如果你现在还停留在 0.3.x建议直接升级否则decryption_key_type这个参数很容易出现“传了等于没传”的诡异现象。2.2 准备一份可复现的测试文件实战中你可以用自己的无线网卡抓包获取实验素材。把网卡切入监听模式在目标网络附近抓一小段时间确保捕获到了客户端关联和四次握手过程sudo airmon-ng start wlan0 sudo airodump-ng -c 6 --bssid 00:11:22:33:44:55 -w lab_capture wlan0mon然后让某个设备重新连接一次该 WiFi这样握手的四个帧就能被完整抓下来。比如退出重连手机热点或者直接把路由器重启一下。如果你只是想做本地测试也可以直接用 Wireshark 自带的示例抓包文件或者自己搭一个无线热点用安装了抓包工具的客户端连接一次。关键是数据包质量不是数据量大小。2.3 验证 pyshark 能否正常调用 tshark先跑一段最简单的读取脚本确认整个链路是通的import pyshark cap pyshark.FileCapture(lab_capture.pcapng) count 0 for pkt in cap: count 1 print(ftotal packets: {count})能打出包总数说明 pyshark 到 tshark 的基本链路没问题。接下来就可以进入正题逐一开始 WEP、WPA-PWD、WPA-PSK 的解密实操。3. WEP 解密实操从 pcap 到明文只需两行参数3.1 WEP 密钥的类型40 位与 104 位WEP 密钥按位长分两种40 位5 字节和 104 位13 字节。很多老设备也支持 128 位 WEP但本质上就是 104 位密钥。这里的“位”指的是密钥实际长度而不是你在路由器管理界面输入的 ASCII 字符串长度。在 Wireshark/tshark 的体系里WEP 密钥可以用 ASCII 字符串表示也可以用十六进制字符串表示。ASCII 模式下 40 位密钥是 5 个字符104 位密钥是 13 个字符十六进制模式下则分别是 10 个字符和 26 个字符。实际抓包分析时路由器里配置的如果是短密码比如12345那就是 40 位 WEP如果是 13 位字符串则是 104 位 WEP。3.2 实操FileCapture 解密 WEP pcap解密 WEP 数据包时在 pyshark 里只需要传入密钥和类型import pyshark cap pyshark.FileCapture( wep_lab.pcap, decryption_key1234567890, # 10 位十六进制对应 40 位 WEP decryption_key_typewep ) for pkt in cap: if hasattr(pkt, http): print(HTTP found:, pkt.http.request_uri) elif hasattr(pkt, dns): print(DNS query:, pkt.dns.qry_name)如果你拿到的是 ASCII 类型的密钥比如路由器管理页面里显示的是helloworld10 个字符你就得先确认它到底是 ASCII 还是十六进制显示。不少二手路由器把 WEP 密钥显示成十六进制少数老设备会显示 ASCII混着用最容易出错。我的建议是统一转成十六进制传给 pyshark避免字符编码带来的歧义。转换方法也很简单Python 里key_hex password.encode(utf-8).hex()但要注意WEP 密钥的 ASCII 表示通常限定为 5 或 13 个字节如果你的密钥长度不在这个范围路由器在配置时就会拒绝。3.3 怎么确认真的解密成功了解密是否成功最直观的验证方式是看数据包还能不能解析出上层协议。加密状态下全部流量都蜷缩在 802.11 Data 帧里看不到 HTTP、DNS、TCP 等协议头解密成功后数据链路层之上会出现 LLC、IP、TCP乃至完整的应用层数据。还有一个辅助判断方法对比解密前后相同 pcap 的包数。解密开启后tshark 会把一个加密数据帧还原成包含明文净荷的帧结构有时会出现“从一个帧里拆出更多解析内容”的情况所以能看到的有效协议层数量明显变多这可以作为参考信号。提示WEP 破解在现实里已经几乎被淘汰了但 WEP 解密脚本在分析老旧嵌入式设备、工控系统或 CTF 题目时依然很常用。它的价值更多体现在“理解老协议的解密链路”上。4. WPA-PWD 解密实操密码短语 SSID 的完整配置4.1 什么是 WPA-PWDWPA-PWD 这个名字在不同工具里叫法不完全一样在 Wireshark/tshark 的 802.11 密钥 UAT 表里它表示“WPA Passphrase 方式”。这种方式的输入不是现成的 PMK而是两样东西密码短语passphrase和 SSID。tshark 拿到这两样东西后会按照 802.11i 标准里的 PBKDF2-SHA1 算法做 4096 次迭代生成一个 256 位的 PMK。整个过程可以理解为“密码 SSID 共同作为种子算出一个用于后续握手验证的密钥材料”。所以 WPA-PWD 方式下SSID 写错了哪怕密码完全正确最后得到的 PMK 也是错的。4.2 实操decryption_key 里直接写 password:ssidpyshark 里 WPA-PWD 的密钥格式比较特殊要把密码和 SSID 拼在一起中间用冒号分隔传给decryption_key类型指定为wpa-pwdimport pyshark cap pyshark.FileCapture( wpa2_lab.pcapng, decryption_keymysecret123:test_wifi, # 格式是 密码:SSID decryption_key_typewpa-pwd ) for pkt in cap: if hasattr(pkt, http): print(HTTP request:, pkt.http.request_uri) if hasattr(pkt, tcp): pass这里有一个非常考验人的细节pyshark 官方文档写的是decryption_key和decryption_key_type但底层的 tshark 实际生成的是类似uat:80211_keys:wpa-pwd,mysecret123:test_wifi的参数。如果你自己在 custom_parameters 里手动写也必须是这个结构拼错一个逗号位置解密就会静默失败。4.3 实操心得握手完整性、大小写和 SSID 编码这一节值得单独写因为 WPA-PWD 解密失败的案例里十有八九都栽在下面几个地方。握手不完整是头号问题。WPA 四次握手的四个帧不一定要 100% 全抓到但至少要抓到 key 交换的关键部分。最稳妥的做法是抓包的时候慢慢点客户端重连或者用专门工具反复触发关联流程确保 pcap 里的握手帧数量足够。SSID 必须精确匹配。有人会问密码明明是对的为什么还是解不开答案往往是 SSID 大小写不一致比如实际网络叫Test_WiFi你在代码里写成了test_wifiPMK 计算结果就完全不同。SSID 是二进制安全的字符串但不代表它对大小写不敏感至少在 PMK 推导这一步字节差异会直接导致结果不同。密码本身只能取 ASCII 范围内的字符吗也不是绝对但是很多路由器配置界面只接受可打印 ASCII。如果密码里有中文或者其他非 ASCII 字符你需要考虑编码问题抓包侧和计算 PMK 侧必须用同一个编码方式。我自己遇到过一次密码末尾带不可见空格的情况排查了很久才发现是复制粘贴过程引入了额外字符。再有一个细节pyshark 的decryption_key_type参数名在不同版本里可能有细微差异0.4 之后基本都稳定为decryption_key_type但如果你用的是笔记本里随手装的老版本建议先升级再排查问题。5. WPA-PSK 解密实操用 64 位十六进制密钥直接解5.1 PSK 和 PMK 的关系别再混着叫WPA-PSK 这个词在日常口语里经常指“WPA 预共享密钥”也就是你在手机里输入的密码短语。但在 Wireshark 的 80211_keys UAT 表里wpa-psk类型要求的值不是密码短语而是 64 位十六进制的 PMK。可以这样理解wpa-pwd是让 tshark 现算 PMK输入材料是密码和 SSIDwpa-psk是直接喂给它算好的 PMK省略了 PBKDF2 计算环节。二者本质上是同一个密钥材料的不同表达形式网络上有些人把wpa-psk和密码短语混为一谈到了传参这一步就会翻车。5.2 实操把密码短语转成 PSK 再喂给 pyshark如果你手头只有密码短语和 SSID可以先用工具生成对应的 PSK。Linux 下最简单的是wpa_passphrasewpa_passphrase test_wifi mysecret123输出里那个psk后面的 64 位十六进制字符串就是 PMK也就是 tshark 需要的 wpa-psk 值。不想依赖系统工具也可以用 Python 算import hashlib def passphrase_to_psk(passphrase: str, ssid: str) - str: pmk hashlib.pbkdf2_hmac( sha1, passphrase.encode(utf-8), ssid.encode(utf-8), 4096, 32 ) return pmk.hex()算好之后在 pyshark 里直接使用import pyshark psk_hex 9f9f...64 位十六进制 cap pyshark.FileCapture( wpa2_lab.pcapng, decryption_keypsk_hex, decryption_key_typewpa-psk ) for pkt in cap: if hasattr(pkt, dns): print(DNS:, pkt.dns.qry_name)特别注意传给decryption_key的字符串必须正好是 64 个十六进制字符任何多余的空格、换行符、前导0x都会让解析失败。有些工具会输出带0x前缀的格式记得剥掉。5.3 WPA-PWD 和 WPA-PSK 到底怎么选场景推荐方式原因手头只有 WiFi 密码wpa-pwd直接传 password:ssid让 tshark 推导 PMK手头已经有 PMK/PSKwpa-psk不依赖 SSID 二次计算适合自动化批处理多个 AP 同密码但 SSID 不同wpa-pwd每次指定不同 SSID分别解密大量 pcap 批量分析wpa-psk预计算好 PSK参数固定出错概率小只想验证某个握手包密钥wpa-psk离线分析时避免 PBKDF2 重复计算开销我自己做批量分析时更倾向于 wpa-psk。原因很简单PMK 算一次是固定的后续所有 pcap 用同一个 64 位十六进制值省掉了每次都拼接密码和 SSID 的麻烦也少了一层“SSID 大小写写错”的风险。6. 实时解密与高级参数LiveCapture 和 custom_parameters6.1 LiveCapture 实时抓包解密除了离线解析 pcap 文件pyshark 也支持实时抓包并同时解密。比如你已经知道某个热点的密码想实时看看当前连接的设备都在访问哪些域名可以这样import pyshark cap pyshark.LiveCapture( interfacewlan0mon, decryption_keymysecret123:test_wifi, decryption_key_typewpa-pwd ) for pkt in cap.sniff_continuously(): if hasattr(pkt, http): print(HTTP:, pkt.http.request_uri)这里有几个前提必须讲清楚。第一网卡必须支持并开启监听模式否则网卡驱动会把 802.11 帧转换成伪以太网帧很多加密信息在这一步就丢了。第二实时解密要求抓包进程和握手发生过程同步如果程序启动时客户端已经完成关联后续数据包仍然解不开。第三Linux 下监听模式抓包需要 root 权限pyshark 报权限错误的话检查一下是不是没有用 sudo。实时解密更适合做无线网络故障定位比如现场排查某个终端上网慢或者统计一个 AP 下的真实流量分布。它的性能开销比离线解析大流量高的时候容易丢包所以生产环境最好还是抓完包再离线解密。6.2 用 custom_parameters 手动控制 tshark说完 LiveCapture再补一个 pyshark 里容易被忽略但极其实用的功能custom_parameters。它可以让你直接向 tshark 命令行传递任意参数也就是说你能做出比 pyshark 默认参数更复杂的解密配置。举个例子如果 pcap 里有多个 WEP 密钥直接通过decryption_key只能填一个但用 custom_parameters 可以把 80211_keys UAT 表里的多行密钥全部写进去import pyshark cap pyshark.FileCapture( multi_key.pcap, custom_parameters[ -o, wlan.enable_decryption:true, -o, uat:80211_keys:wep,AAAA:1111, -o, uat:80211_keys:wep,BBBB:2222, ] )注意custom_parameters 接收的是一个列表列表的每个元素是按照命令行顺序排列的参数名和参数值。所以-o和uat:80211_keys:...必须成对出现。这个设计有点反直觉但它确实能让你绕过 pyshark 默认封装直接用 tshark 的完整能力。6.3 监控模式下的抓包小提示如果你准备自己抓取解密素材监听模式是绕不开的环节。Linux 下用 airmon-ng 切监听模式之后接口名通常会变成带mon后缀的名字比如wlan0mon。抓包的时候要注意监听模式下网卡不参与正常的网络通信也就是说你用同一块网卡一边抓包一边上网是行不通的。另外在 802.11 信道上很多网卡默认只抓管理帧和数据帧的控制部分数据帧的完整内容可能需要额外设置射频监控模式monitor flag才能全部收进来。不同无线网卡芯片支持度差异很大有些网卡比如部分高通芯片能很完整地抓全数据帧有些网卡则只能收到零散碎片。抓包质量不好后面解密再正确也没用。7. 常见问题与排查技巧实录7.1 高频问题速查表现象可能原因排查方向解密后仍然只有 802.11没有上层协议密钥错误、SSID 错误、抓包没有握手帧先用 tshark 命令行加相同参数测试WPA 解密能看到部分 ICMP但看不到 HTTP抓包过程中只捕获了部分会话数据检查抓包是否跨完整连接重新抓包pyshark 报错 tshark 命令执行失败tshark 路径不对、参数格式错误打印实际执行的 tshark 命令逐步拆分decryption_key_type 好像没生效pyshark 版本过旧或参数名拼写错误升级 pyshark检查源代码签名可以解析 DNS但应用层乱码解密正常但抓包存在分片丢失检查 pcap 是否存在大量 Fragmented 帧wpa-pwd 始终解不开 WPA3 网络WPA3 的握手机制与 WPA2 不同确认网络是 WPA2-Personal不是 WPA3-SAE7.2 三步定位法解密失败时不要盲目改参数我一般按照下面三步来排。第一步用 tshark 命令行直测绕过 pyshark。举一个 WPA-PWD 的例子tshark -r wpa2_lab.pcapng -o wlan.enable_decryption:true -o uat:80211_keys:wpa-pwd,mysecret123:test_wifi -Y http || dns如果 tshark 能正常解析出 HTTP 和 DNS说明 pcap 文件和解密密钥都没问题问题出在 pyshark 传参环节。如果 tshark 也解析不出来那基本可以断定是 pcap 缺握手帧或密钥本身有误。第二步检查握手帧是否存在。用显示过滤器筛选 EAPOLtshark -r wpa2_lab.pcapng -Y eapol如果 eapol 一个都看不到说明抓包根本没有覆盖四次握手这时候任何解密操作都是徒劳重新抓包才是出路。第三步打印 pyshark 实际生成的 tshark 命令。在 pyshark 里可以临时 hack 一下把命令打出来cap pyshark.FileCapture(wpa2_lab.pcapng, decryption_keymysecret123:test_wifi, decryption_key_typewpa-pwd) print(cap._get_tshark_command()) # 查看实际命令行对比打印出的命令和第 7.2 节第一步里的手工命令找出参数差异往往一眼就能看出问题所在。7.3 几个小技巧批量解密一堆 pcap 时建议把它封装成一个函数把密钥、SSID、文件路径作为参数传进去def decrypt_pcap(filepath, passwordNone, ssidNone, pskNone): if psk: key psk key_type wpa-psk else: key f{password}:{ssid} key_type wpa-pwd cap pyshark.FileCapture( filepath, decryption_keykey, decryption_key_typekey_type, display_filterhttp || dns ) result [] for pkt in cap: result.append(pkt) cap.close() return result另外解密时建议加上display_filter只筛选你关注的协议。环境复杂的时候一个 pcap 里可能有几千个包不做过滤的话pyshark 逐个包解析的上层协议会拖慢速度而且内存占用会明显上升。用keep_packetsFalse也可以减少内存压力适合只需要逐包流式处理的场景。我自己的习惯是正式跑批量任务前先抽出一个小 pcap 验证密钥和参数再放到完整文件上执行。不要一上来就对几百兆的文件跑解密一旦参数错误纯浪费时间。最后再分享一个个人体会解密类操作的成功率很大程度上取决于抓包阶段的质量而不是解密阶段的算法。很多朋友拿了一个缺握手的 pcap 反复调 pyshark折腾一晚上也没结果其实就是一开始数据就没抓全。所以现在我看到类似问题第一反应永远是先确认抓包素材的完整性再看密钥参数。先把这一步养成本能你会发现 WEP、WPA-PWD、WPA-PSK 这些解密操作本质上都只是“把正确的凭证喂给会算的家伙”而已。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
