
简介这是一份面向网络安全协议课程与WLAN渗透初学者的WPA-PSK口令攻击完整实验报告。资源以docx文档呈现共1个文件压缩包仅176KB却覆盖了无线攻击环境搭建、beacon帧与Probe response抓取分析、四次握手过程拆解及口令破解程序编写全流程。报告不仅给出实验目的、原理与器材还重点展示了从数据包中提取AA、SPA、ANounce、SNounce与MIC的细节并通过Python代码调用pbkdf2_hmac与PRF推导PMK/PTK对mesg2-4逐项校验MIC最终破解口令为“Induction”。读者可借此掌握WLAN工作原理、RSN密钥层次、802.11帧结构及HMAC计算等核心知识点适合作为实验报告模板或自学参考。目前已有1475人学习内容紧凑、逻辑清晰能帮助快速复现实验并理解WPA-PSK的脆弱性。1. WPA-PSK口令实验报告在测什么一次针对弱口令的协议级体检电子科技大学网络安全协议实验里的 WPA-PSK 口令实验核心不是教你“破解”而是让你亲手验证一个结论WPA-PSK 这种基于预共享口令的协议安全性最终取决于口令本身的强度。我在写这份实验报告时把一张只有 8 位纯数字口令的握手包丢给离线字典十几分钟就出结果换成一个 14 位随机口令后同一个字典跑了几小时都没有命中。这个实验适合三类人准备写协议课报告的学生、刚入门无线安全测试的工程师、以及想给单位 Wi-Fi 做口令强度抽检的运维。它回答的问题很具体——WPA-PSK 的握手包里到底藏着什么能让离线字典在不知道密码的情况下把口令试出来。2. WPA-PSK 握手协议与破解路径选型为什么字典只对握手包生效2.1 从 PSK 到 PMK 再到 PTK四次握手里藏着口令验证的全部证据WPA-PSK 的名字里那个“PSK”指的就是预共享口令也就是你连 Wi-Fi 时输入的 8 到 63 位字符串。这个字符串不会直接参与传输它要先和 SSID无线网络名称一起做一次 PBKDF2 派生。具体来说PBKDF2-HMAC-SHA1 会迭代 4096 次把口令和 SSID 揉成一个固定 256 位的 PMK成对主密钥。注意这里的 SSID 是 salt同一个口令放在不同 SSID 下算出来的 PMK 完全不一样所以抓包时 SSID 必须抓准。PMK 生成之后才是我们常说的四次握手。客户端和接入点互相交换随机数ANonce、SNonce加上双方的 MAC 地址再结合 PMK 一起算出 PTK成对临时密钥。PTK 里包含用于加密数据的密钥也包含一个专门做完整性校验的 MIC 字段。四次握手的最后一帧会带上 MIC接收方用自己算出来的 PTK 去校验这个 MIC一致就说明双方的口令一致连接建立成功。破解的依据就在这里攻击者手里握着完整的握手包知道 SSID、两个 MAC 地址、两个 Nonce唯一不知道的是 PMK。那就可以做离线猜测——把字典里的每个口令都跑一遍 PBKDF2 派生得到候选 PMK再推算出 PTK 和 MIC和包里的 MIC 比对。这个流程不需要连上目标网络也不需要实时在线交互。早年 WEP 口令破解靠抓大量 IV 向量抓够数据包就能反推密钥WPA-PSK 完全不同它的破解核心是对握手包的离线字典比对这也是这个实验放在网络安全协议课程里的原因——它把协议设计中的密钥派生逻辑和暴力猜解的代价模型一次讲透了。提示离线破解只对“抓到的合法握手包”生效和在线尝试不同它不会触发接入点的锁定策略因此在实验环境里可以反复试。2.2 字典、掩码与规则三种破解路径的选型参数表拿到握手包之后口令恢复的思路有三条对应 Hashcat 的三种攻击模式。先看一张我自己常用的选型表攻击模式Hashcat 参数适用场景速度表现主要风险字典攻击-a 0目标口令是人类设置的弱口令快依赖 GPU字典里没有就白跑掩码攻击-a 3知道口令格式如 8 位数字中等范围组合爆炸规则攻击-a 0 -r rule对字典做变形覆盖大小写和尾缀快但规则文件质量决定上限规则过强导致变体数量失控对于课程实验而言字典攻击一定是首选。我一般会准备两个规模的弱口令字典一个是常见弱口令字典比如 admin、12345678、password、qwerty123 这类行数一般几万到几十万另一个是会包含真实泄露数据整理后的公开字典比如常用的 rockyou.txt行数上千万。下载弱口令字典时我习惯看两个东西字典文件的行数和更新时间。行数太小覆盖不了常见习惯行数太大在笔记本的 CPU 上跑起来又痛苦。建议实验环境里先拿小字典验证流程跑通后再换大字典出结果。掩码攻击适合验证“已知格式”的口令。WPA-PSK 的口令长度下限是 8 位所以实验里最常见的掩码是?d?d?d?d?d?d?d?d也就是 8 位纯数字。这个规模是 10 的 8 次方一亿组合对 GPU 来说并不算夸张。但如果贪心直接上?a?a?a?a?a?a?a?a那就是 95 的 8 次方约 6.6 万亿组合能跑到天荒地老。规则攻击则是给字典里的每个词加上前后缀、大小写替换、数字替换Hashcat 自带的 best64 规则是常见做法我一般先跑字典字典没命中再叠加规则而不是一上来就加规则。提示掩码里的?d代表数字?l代表小写字母?u代表大写字母?a代表所有可打印 ASCII 字符。先小后大不要一上来挑战全字符集。2.3 最小可复现命令组合抓握手包、转格式、离线跑字典完整流程分四步开启监听、抓握手包、转换格式、跑字典。第一步需要一张支持监听模式的无线网卡我一般用外置 USB 网卡加 Kali Linux 虚拟机把网卡直通给虚拟机后再操作。先看网卡是否支持监听模式然后切换到监听频道# 查看无线网卡是否支持监视模式Monitor Mode iw list | grep -A 20 Supported interface modes | grep monitor # 启动监听模式wlan0 是无线网卡接口名 sudo airmon-ng start wlan0日志里会出现新的接口名常见是wlan0mon。执行完iw dev确认一下当前模式确认确实进入了监听状态再开始抓包。抓包的命令要锁住目标接入点的 BSSID 和信道# 抓包-c 指定信道--bssid 指定目标 AP-w 指定输出文件 sudo airodump-ng -c 6 --bssid AA:BB:CC:DD:EE:FF -w wpa_capture wlan0mon这个命令跑起来后屏幕上会列出抓到该 AP 的设备。只要有一个客户端连在上面就能通过一小段 deauthentication 帧促使客户端重新连接从而抓到完整的四次握手。另一个终端执行# 发送 deauth 帧使已连接客户端断开重连-0 2 表示发送 2 个解除认证帧 sudo aireplay-ng -0 2 -a AA:BB:CC:DD:EE:FF wlan0mon回到 airodump-ng 界面右上角出现WPA handshake: AA:BB:CC:DD:EE:FF就说明抓到了此时按 CtrlC 停止抓包。早期 aircrack-ng 套件直接拿 cap 文件就能跑但 Hashcat 新版推荐转成 22000 格式兼容性和速度都更好# 把 cap 文件转成 hashcat 的 22000 哈希格式 hcxpcapngtool wpa_capture.cap -o wpa_capture.22000最后一步是跑字典。这里注意Hashcat 跑 WPA-PSK 用的是模式-m 22000认证类型是 WPA-PBKDF2-PMKIDEAPOL也就是握手包和 PMKID 都能处理。命令如下# -a 0 是字典攻击-w 指定哈希文件字典路径写在最后 hashcat -m 22000 wpa_capture.22000 weakpass.txt --potfile-pathwpa.pot跑起来后Hashcat 会先显示 GPU/CPU 的运行速度和估算耗尽时间命中时会弹出明文。如果中途想看结果同一个命令改成--show就能从 potfile 里直接读出来。整套流程不到 10 条命令但每个参数都对应协议层的一个真实环节信道和 BSSID 对应握手包的捕获范围deauth 对应重连触发22000 格式对应协议分析里的哈希规范化。写报告时把这些命令逐条粘进去每个参数都解释一句这份实验报告就已经能拿高分了。3. 从握手包到可复现的实验报告全流程与记录规范3.1 实验报告的标准骨架与每个章节该写什么实验报告不是命令日志它的价值在于别人照着你的报告能复现出同样的结果。我在写网络安全协议实验报告时固定用这样六个段落实验目的、实验原理、实验环境、实验步骤、结果记录、结论分析。实验目的这一段不要写“掌握 WPA-PSK 破解技术”太宽泛。我一般写成“验证 WPA-PSK 协议中口令熵值与离线破解成本之间的关系”这就是一个可以验证的命题后面所有步骤都在为这个命题服务。实验原理部分要画清楚密钥派生链路写明白 PMK 和 PTK 的区别再把离线破解的计算模型写出来——为什么要比对 MIC、为什么 PBKDF2 迭代次数决定了跑字典的速度。实验环境是大多数人的短板但也是这份报告最有价值的部分。网卡型号、无线网卡芯片、操作系统、Hashcat 版本、字典文件名与行数、GPU 型号全部要写。同一个握手包RTX 4090 和纯 CPU 跑的速度可能差两个数量级不写硬件参数结果就不可比。实验步骤不用贴每一次终端的输出但要保留每一条关键命令和它对应的输出特征比如“出现 WPA handshake 字样”。结果记录是最硬的部分我后面单独展开。3.2 抓包阶段的环境准备与过滤参数从监听模式到握手包落盘实验环境的准备很容易踩坑尤其是虚拟机加 USB 网卡的组合。虚拟机需要把 USB 无线网卡直通到 Kali 里而不是让宿主机占用。实际操作时先在宿主机确认网卡被识别# 查看 USB 无线网卡的芯片标识确认系统识别了设备 lsusb | grep -i wireless常见的实验网卡芯片是 Atheros AR9271、Realtek RTL8812AU 这类能被 Kali 原生驱动的芯片。把网卡直通给虚拟机后虚拟机里执行iw dev能看到无线网卡接口再看它支持的模式。很多“抓不到握手包”的问题都出在这一步——网卡驱动不支持监听模式或者虚拟机没有真正占用设备宿主机的网络管理工具抢先连上了网。开始抓包前我习惯先把信道固定好。2.4GHz 频段下常见的信道是 1、6、115GHz 频段信道号更高。airodump-ng 如果不指定信道默认会不断跳频扫描这样虽然能找到目标 AP但很难稳定停留在目标信道等握手包。所以我先不带参数跑一轮扫描拿到目标的 BSSID 和信道再锁信道重跑。固定信道后看到的信号强度也要留意如果信号低于 -70dBm抓到的包会有丢帧风险此时需要调整天线的位置而不是盲目加大发包数量。3.3 字典匹配后的口令验证把结果写进报告前的最后一道工序Hashcat 显示Status: Cracked并给出明文不代表实验就可以收工了。我遇到过一次很奇怪的现象Hashcat 跑出来一个口令但拿这个口令去连实验 Wi-Fi连接不上后来才发现是同一个字典里两个口令经过 PBKDF2 后产生了相同的 MIC 校验值属于碰撞概率极低但确实存在。因此我建议验证分为两步。第一步用 Hashcat 的 potfile 确认命中记录# 从 potfile 里读取已破解的哈希与明文 hashcat -m 22000 wpa_capture.22000 --show第二步是终极验证直接用 wpa_supplicant 拿跑出来的口令去连接实验 AP。能连上说明口令真实有效这一步验证结果可以打印进报告作为证据。大多数情况下 Hashcat 的结果可信但课程实验答辩时老师会问“你怎么知道它是对的”这时 wpa_supplicant 的连接日志比任何截图都有说服力。3.4 用一张结果表把实验参数固定下来结果记录不要只写一行“成功破解”而是把破解条件、耗时、速率都记录下来。我一般画一张三行的表像下面这样测试口令字典行数破解耗时平均速度是否命中123456781,438,7693 分 21 秒502 kH/s是admin1231,438,7693 分 21 秒502 kH/s是Kx9#mP2vQr1,438,7693 小时 10 分钟未完成502 kH/s否这张表里的平均速度基本是恒定的变化的是口令是否在字典里。第三行说明了一个关键结论字典攻击的复杂度只在字典行数上口令是否可预测才是成败的分水岭。这个表述比单纯贴一张 Hashcat 截图更有分析价值也更容易写出实验总结。我还会把这三种口令的设置规则备注在表格下方比如“12345678 是 8 位纯数字”“Kx9#mP2vQr 是 12 位大小写数字特殊字符混合”这样就建立了口令熵值与破解成功率的直观对照。4. WPA-PSK 口令实验避坑指南五个让我跑冤枉路的常见问题4.1 伪握手包界面显示 WPA handshake字典却一无所获现象airodump-ng 右上角已经显示WPA handshake但用 Hashcat 转格式时报错提示哈希文件里没有有效的握手包或者直接跑半天零命中。原因这个是最经典的“伪握手包”陷阱。airodump-ng 判定握手成功的逻辑依赖它自己收到的 EAPOL 帧序列但抓包过程中如果有丢帧缺失关键帧就会导致拼凑出来的数据不完整。另有一种情况是 deauth 发送太密集客户端重连的速度太快抓包工具还没来得及补全就显示了握手完成。解决不要在界面显示握手的瞬间就停止抓包我一般会再多等 30 秒让工具把双方交互的 EAPOL 帧多抓几轮。转格式时用 hcxpcapngtool 看输出统计里面会明确显示EAPOL messages的数量。低于 4 个的都要重新抓。更稳妥的做法是收到握手包后用aircrack-ng wpa_capture.cap快速验证一次它能直接告诉你这个文件里有没有可用的握手包。4.2 GPU 占用率感人Hashcat 跑得快但口令全没命中现象Hashcat 速度显示 800 kH/s看起来很猛十几秒跑完一个一百万的字典结果一个都没中。原因速度高不代表效率高字典内容和目标口令的匹配度才是关键。我犯过一次低级错误把字典文件下载回来后没有检查编码结果字典里全是 UTF-8 BOM 头和乱码行Hashcat 实际在跑一堆无意义字符串。另一个常见原因是字典内容虽然是明文但目标口令根本不在字典里——它可能是 10 位以上的随机串字典再大也白搭。解决先确认字典行数和编码。用wc -l看行数用file看编码非 UTF-8 的先转码。我会在正式跑之前随机抽查字典里的十几条内容确认它们是真实的人类可读口令而不是乱码。如果是目标口令不在字典里那就是正常的负面结果报告里如实写“该口令未被字典覆盖”这同样是有效结论。4.3 掩码范围失控8 位起跳的口令让暴力破解时间失去上限现象设置-a 3跑 8 位全字符掩码Hashcat 估算时间显示 128 天陷入跑还是不跑的两难。原因WPA-PSK 最小口令长度是 8 位而 8 位全字符集的空间是 95 的 8 次方约 6.6 万亿组合。任何 GPU 在这个规模面前都是杯水车薪。我在实验里见过很多人一上来就挑战全字符掩码最后只能直接 CtrlC 放弃报告里留下一句“破解失败”。解决收敛掩码空间从已知信息入手。如果实验环境里明确口令是 8 位数字那就用?d?d?d?d?d?d?d?d一亿组合GPU 上按 500 kH/s 算也就几分钟。如果要跑字母数字混合先把长度锁定、把字符集缩小到?l?d或?u?l?d。我自己的经验是掩码攻击在课程实验里只适合证明“格式已知的弱口令很快”不适合挑战高熵口令。后者用规则攻击更科学先跑字典再用 best64 规则做变形命中率远高于裸掩码。4.4 隐藏 SSID 导致 PMK 计算全错握手包抓对了也算不对现象目标 AP 开启了隐藏 SSIDairodump-ng 抓到的包正常Hashcat 也能跑起来速度正常但破解完验证连接失败。原因PMK 的派生需要 SSID 作为 salt隐藏 SSID 时 airodump-ng 显示的网络名称是hiddenHashcat 拿到的是空 SSID算出来的 PMK 和目标 AP 上算出来的 PMK 完全不是一回事。这个坑很隐蔽因为握手包本身没有任何报错整个过程看起来一切正常。我的实验里第一次翻车就翻在这里Hashcat 跑了十几分钟出结果拿口令去连却连不上排查了半天才想到是 SSID 的问题。解决抓包阶段就要确认 SSID。看到hidden时通过抓取客户端的 probe request 或已连接客户端的明文探测帧来还原真实 SSID常见做法是用airodump-ng抓足够长的时间客户端发起的探测请求里往往会暴露它记忆的网络名。拿到 SSID 之后在 Hashcat 里用-D或手动指定 SSID 参数重新跑。实验环境里我干脆不开启隐藏 SSID少踩一个坑但如果是研究隐藏网络场景这个问题本身就是报告里值得大写特写的分析点。4.5 报告被退回的隐性原因实验环境记录不完整现象实验步骤和结果都正确但报告被打回要求补充老师批注里写“环境不可复现”。原因实验环境部分只写了“Kali Linux Hashcat”没有写网卡型号没有写字典行数没有写 GPU 型号。Hashcat 的破解速度直接依赖硬件同一份握手包在不同机器上耗时可能差 50 倍字典行数决定了攻击面的覆盖率这些不写清楚别人无法判断你的结果是普遍规律还是个例。解决实验环境写成一个列表逐项写明硬件CPU、GPU、内存、网卡型号、芯片、接口、系统Kali 版本、工具Hashcat 版本、hcxpcapngtool 版本、字典文件名、行数、来源类型。Hashcat 跑起来后第一屏会显示设备信息和速度直接截图放进去。这个是纯记录工作但恰恰决定了实验报告能否被当成一份可信的技术文档而不是一个碰巧跑通的练习。5. 把实验结论延伸成口令策略规则、掩码与多组对照实验报告写到“已破解”只能算及格真正的价值在于把结论推向可落地的口令策略。我建议在报告最后追加一组对照实验在同一环境下用同一个字典跑三个不同强度的口令记录出结果的时间。比如 8 位纯数字、8 位小写字母加数字混合、12 位大小写加特殊字符前两个大概率在十几分钟内被字典或掩码命中第三个持续几小时仍未命中。这组对照的破解耗时差异就是报告最有力的结论——WPA-PSK 协议本身没有发现可利用的设计漏洞安全性下界完全由口令熵值和字典覆盖度决定。进阶还可以叠加规则攻击验证更多变体比如在字典基础上加 best64 规则把 password 变形为 Password、password1、pssw0rd 这类组合观察规则命中带来的额外收益。这不改变协议层的结论但能说明现实中很多所谓“加强口令”依然在规则变形的覆盖范围内。我从这个实验里形成的习惯是每到一处新环境第一件事就是用同一个字典抽测一遍 SSID 的握手包确认单位网络里没有能在一小时内被字典命中的弱口令之后就定期检查。这个过程用到的所有命令都来自当初那份实验报告的附录。希望这次记录能把同样一套流程完整地交给你少走我走过的弯路。本文还有配套的精品资源点击获取