Python实现WPA2握手包离线破解：弱口令验证工具原理与PyInstaller打包实践

简介：一份基于Python实现的WiFi密码破译工具，采用暴力破解算法，提供封装完毕的exe可执行程序与完整Python源码，面向网络安全爱好者、Python初学者以及希望了解WiFi认证机制与弱口令风险的学习者。资源共2个文件，压缩包约247MB：py源码便于读者阅读与二次修改，观察破解流程中各模块的调用逻辑；exe程序则免去环境配置负担，可直接运行体验整体流程。工具使用简便，指定目标WiFi名称后即可自动发起破解与连接，破解耗时取决于密码复杂度，简单口令秒级完成，可供验证暴力破解思路与密码强度审计场景使用。目前该资源已有7336人浏览学习，适合作为入门级网络安全实操参考，也适合以工程化方式了解暴力破解的代码组织方式与终端交互设计。

1. 它是什么、能干什么：一个Python弱口令验证工具的真实定位

很多人第一眼看到「wifi密码破译器」这个标题，想的是拿去蹭网。但干过无线安全评估的人会立刻把它翻译成另一句话：这是一个针对 WPA/WPA2-PSK 网络的离线字典验证工具，核心逻辑是抓握手包、跑字典、验证密码。标题里的「附exe与源码」透露了项目形态——作者把抓包、碰撞、命令行交互打包成了可执行文件，让不懂 Python 的人也能在 Windows 上双击运行，同时把源码留出来给愿意折腾的人改。它真正能解决的问题有两类：一是你把自己家路由器密码忘了，又不想重置整个网络；二是在做无线网络巡检时，快速确认一批 AP 是不是在用「12345678」这种弱口令。它不适合用来碰别人的网络，也不适合对 WPA3 企业认证环境抱期待。适合读这篇文章的人：忘密码的普通用户、做无线评估的工程师、以及想搞懂握手包协议细节的 Python 初学者。

2. WPA2握手包与离线碰撞：这个破译器的原理骨架

2.1 WPA2-PSK为什么是「抓包+离线验证」，而不是「实时猜」

WPA2-PSK 的认证过程依赖一个叫做四次握手（4-way handshake）的协议。客户端和 AP 之间通过四次消息交换随机数（ANonce、SNonce），最终推导出用于加密数据的 PTK。攻击者不需要参与这个过程，只需要被动监听，把客户端和 AP 之间的握手帧完整抓下来，就拿到了离线验证所需的一切材料。

关键点在于「离线」。实时猜密码的意思是每猜一次就要和目标 AP 交互一次，速度和稳定性完全被无线链路卡死；而离线碰撞是把握手包存到本地，然后在自己电脑上成千上万次地尝试候选密码。速度只取决于 CPU/GPU 算力，和目标在不在线无关。这就是为什么这类工具几乎全部走离线字典路线——在线爆破 WPA2 在工程上根本不现实，抓包才是唯一高效路径。

从密码到密钥的推导也值得说清楚：每个候选密码先和 SSID 一起经过 PBKDF2-SHA1 迭代 4096 次，生成 256 位的 PSK，再由 PSK 通过 PRF-256 派生出 PTK。这个计算是纯数学运算，和网络无关。所以只要握手包里的 MIC 字段能和本地计算出来的结果对上，就能确定密码就是当前候选词。整套机制决定了这类工具的成功率不取决于破解技巧，而取决于字典质量和算力。

2.2 Python在链路里承担的角色：解析、生成、校验

有人以为「python wifi密码破译器」是纯 Python 写的抓包程序，实际工程里很少这么干。抓包要操作无线网卡进入监控模式，监听 802.11 帧，这一步最稳定可靠的做法是调用现成的无线工具链；Python 更多是承担胶水层：调用外部工具抓包、解析握手帧、按字典批量生成候选密码、完成 PBKDF2 与 MIC 校验，再把结果格式化输出。

这套分工的好处是每一层都能单独替换。抓包环节换成 hcxdumptool 也完全可以，碰撞环节也可以跳过自研逻辑直接调用 aircrack-ng 或 hashcat。所谓「源码」，真正值钱的往往不是碰撞循环本身，而是把这几层串起来并且处理各种异常边界的代码。理解了这一点，再看那些开源项目就不会觉得神秘。

2.3 三条攻击路径怎么选：字典、掩码、PMKID

常见的路径有三条，选哪条取决于你能拿到什么信息。字典攻击是最通用的：准备一个密码集合，逐个验证，适合目标密码是常见弱口令、姓名拼音、生日组合的场景。掩码攻击适合你掌握了密码构成规则的情况，比如知道对方习惯用 8 位纯数字，或者手机号后八位，这时可以用掩码生成候选密码，命中率远高于通用字典。

PMKID 攻击是另一个思路，它不需要等客户端上线，也不需要抓四次握手。AP 在关联阶段会主动发送包含 PMKID 的帧，攻击者只要拿到这个值就能离线验证。它的限制是 AP 固件必须支持 PMKID 发送，老一点的路由器反而不一定发。实际评估中我的习惯是优先探测 PMKID，抓不到再退回握手包方案；如果目标环境一直有设备在线，握手包方案反而更可靠。无论走哪条路，到最后一步都是同一个动作：把候选密码放进 PBKDF2 和 MIC 校验里跑一遍。

3. 本地跑通最小链路：从监控模式到Python字典碰撞

3.1 硬件这关：哪些网卡能进监控模式

很多人在这一步就卡住了，而且卡得很冤——不是命令错，是网卡根本不支持。笔记本内置的 Intel 无线网卡大多屏蔽了监控模式，或者驱动不开放相关接口，跑 airmon-ng 看着正常，但抓包就是一片空白。做这事的首选是 USB 外置网卡，芯片方案优先看老款 Atheros 和 Ralink，这两类是无线安全圈验证过最省心的。

拿到网卡先插上，用一条命令确认能力：

# 查看无线网卡支持的模式列表 iw list | grep -A 8 "Supported interface modes" # 如果输出里能看到 monitor mode，这块卡就能用 # 看不到就换卡，不要浪费时间折腾驱动

这条命令的输出里出现monitor mode字样才算通过。很多免驱 USB 网卡在 Windows 下能上网，但 Linux 下驱动不完整，同样看不到这个字段。我的习惯是随身带一块确认兼容的 USB 网卡，而不是去赌现场设备的驱动状态。无线评估这行，硬件兼容性就是第一道门槛。

3.2 抓握手的完整链路：四条命令与参数

环境就绪后，抓握手的标准流程是四步：杀干扰进程、开监控模式、扫描目标、触发握手。用 airmon-ng 开监控模式，airodump-ng 找目标和看握手状态，aireplay-ng 发解除认证报文把客户端打掉线，逼它重新连一次，趁机抓到握手。

# 1. 杀掉可能干扰无线网卡的 NetworkManager 等进程 sudo airmon-ng check kill # 2. 将 wlan0 切换到监控模式，成功后网卡名通常变为 wlan0mon sudo airmon-ng start wlan0 # 3. 先全信道扫描，确认目标 AP 的 BSSID 和信道 sudo airodump-ng wlan0mon # 4. 锁定信道并监听目标 AP，握手包会写入 /tmp/cap 开头的文件 sudo airodump-ng -c 6 --bssid AA:BB:CC:DD:EE:FF -w /tmp/cap wlan0mon

确认目标信息后，另开一个终端发解除认证报文：

# -0 表示发送 deauth 报文，2 是发送次数；-a 是 AP 的 MAC，-c 是客户端 MAC sudo aireplay-ng -0 2 -a AA:BB:CC:DD:EE:FF -c 11:22:33:44:55:66 wlan0mon

deauth 发完，回到 airodump-ng 的界面看右上角，出现WPA handshake字段才算成功。注意 airodump-ng 是默认跳频扫描的，锁定-c 6是为了避免信道来回跳导致握手帧漏抓。抓到握手包后立刻按 Ctrl+C 停止，/tmp/cap-01.cap就是后续所有工作的输入。整个过程常见失败点不是命令不对，而是目标客户端不在覆盖范围内，或者换了 5GHz 频段但你锁的是 2.4GHz 信道。

3.3 用Python把字典跑起来：核心验证逻辑

拿到握手包之后，源码的核心才进场。先用 scapy 从 cap 文件里提取握手参数，然后对字典里的每个候选密码做一次完整的密钥推导和 MIC 校验。以下是教学级的最小验证逻辑：

import hashlib import hmac def gen_psk(password: str, ssid: str) -> bytes: # WPA2-PSK 的固定推导参数：PBKDF2-SHA1，4096 轮，输出 32 字节 return hashlib.pbkdf2_hmac( "sha1", password.encode("utf-8"), ssid.encode("utf-8"), 4096, 32, ) def verify_password(password: str, ssid: str, handshake: dict) -> bool: psk = gen_psk(password, ssid) # 实际工程中这里要调用 PRF-256 生成 PTK， # 再取 PTK 前 16 字节作为 KCK，对 EAPOL 帧除 MIC 外的部分计算 HMAC-SHA1 # 最后与握手包里携带的 MIC 比对，一致即命中 mic = compute_mic( psk, handshake["ap_mac"], handshake["client_mac"], handshake["anonce"], handshake["snonce"], handshake["eapol_frame"], ) return mic == handshake["mic"] # 主循环：逐行读字典，逐词验证，命中即输出 def crack(ssid: str, handshake: dict, dict_path: str): with open(dict_path, "r", encoding="utf-8", errors="replace") as f: for line in f: word = line.strip() if verify_password(word, ssid, handshake): print(f"命中密码: {word}") return word print("未命中，字典太弱或者握手包不完整") return None

gen_psk是每个候选密码都会被调用一次的热点函数，也是性能瓶颈所在。字典里有一万条，它就要跑一万次 PBKDF2，而每一次内部是 4096 轮 SHA1 迭代。这就是为什么纯 Python 写碰撞慢：解释器逐条执行的开销叠加在 4096 轮哈希计算上，效率很难和直接用 C 写的 aircrack-ng 比。代码里的compute_mic实际需要按 802.11 协议规范实现 PRF-256 和帧拼接逻辑，完整源码里这是最绕的部分，网上能找到的项目基本都是在解析 EAPOL 帧的细节上拉开差距的。教学版能让你理解链路，真要跑出结果，建议把碰撞环节交给 hashcat，Python 只负责组织和解析，这一点在下文还会展开。

4. 把脚本打包成exe：PyInstaller的失败与依赖补齐

4.1 打包无线脚本为什么比其他脚本更容易翻车

普通 Python 工具打包成 exe 很简单，pyinstaller -F main.py一键搞定。但无线破解脚本是另一个物种：它大概率在代码里用subprocess调用了外部命令，比如 aircrack-ng、hcxdump 或者 hcxpcapngtool。PyInstaller 只会把 Python 字节码和它认识的库打进去，外部可执行文件一概不管。打包时如果不手动把这些工具一起塞进包，用户双击 exe 后会看到「找不到 aircrack-ng」或者「不是内部或外部命令」之类的报错。

常见的坑还有 scapy 对底层抓包库的依赖。Windows 下 scapy 要通过 Npcap 提供的驱动访问网卡，PyInstaller 打包不会自动安装或捆绑 Npcap 驱动，结果就是 exe 在打包机器上跑得好好的，换一台机器直接报错。这类问题排查起来很费劲，因为报错信息往往是一长串 Python 回溯，普通用户根本看不懂。

# 最小打包命令，但对带外部工具的脚本基本不够用 pip install pyinstaller pyinstaller -F --console crack_wifi.py

这条命令能生成一个 exe，但它假装不知道你的脚本还依赖外部命令。看到这你应该理解标题里「附exe与源码」的微妙之处：exe 是作者在特定环境下打包的产物，不代表它在任何 Windows 机器上都能跑。源码的价值恰恰在于让使用者可以根据自己的网卡和驱动环境重新打包。

4.2 把外部工具与资源一起打进exe：spec文件写法

PyInstaller 提供了 spec 文件机制，可以在打包时把外部可执行文件和字典资源一并捆绑进去。先让 PyInstaller 生成一个初始 spec：

pyinstaller -F --console crack_wifi.py # 执行后同目录下会自动生成 crack_wifi.spec

然后编辑 spec 文件，把依赖命令加进binaries，把字典数据加进datas：

# crack_wifi.spec binaries = [ ("aircrack-ng.exe", "."), ("hcxpcapngtool.exe", "."), ("dict.txt", "dicts"), ] datas = [("wordlists/", "wordlists")] a = Analysis( ["crack_wifi.py"], pathex=[], binaries=binaries, datas=datas, hiddenimports=["scapy.layers.all"], ... ) exe = EXE( a, name="wifi_verify", console=True, ... )

关键点是binaries里的外部工具建议用静态编译版本，避免目标机器缺 VC 运行库再翻车；datas打包字典时要注意路径，代码里读取资源文件的位置要和打包后的相对路径一致，这是新手最容易忽略的差异。改完 spec 后重新执行：

pyinstaller crack_wifi.spec

生成物在dist/wifi_verify.exe。这里有个经验：不要贪图单文件模式漂亮而硬用-F，带外部工具的单文件 exe 在运行时要把二进制释放到临时目录，杀毒软件对「自解压释放 exe」的行为非常敏感，目录模式的误报率低很多。

4.3 exe在别人机器上跑不起来的前三个原因

即便打包成功，exe 到另一台机器上跑不起来也很正常。最常见的原因是权限不够：无线网卡进入监控模式需要管理员权限，双击运行时没有「以管理员身份运行」，程序会在切换网卡模式时报错。这不是代码缺陷，但很多用户会误以为是工具坏了。打包时在 spec 里加上uac_admin=True可以强制弹 UAC 提权，能减少一部分售后问题。

第二个原因是 Npcap 驱动缺失。抓包环节只要涉及 scapy 或者底层库调用，目标机器就必须装 Npcap；而且要注意 WinPcap 和 Npcap 的 API 兼容问题，现在新版本基本只认 Npcap。打包解决不了驱动安装，只能在文档里明确写清楚前提条件。第三个原因是网卡本身不支持监控模式，这在 Windows 上尤其明显——你的 exe 写得再好，用户的 Intel 笔记本内置网卡干不了这活。打包工具的作者一般会把兼容的 USB 网卡型号列在说明里，用 exe 的人不看说明直接跑，失败率高是必然的。

提示：标题里「附exe」的卖点在于降低使用门槛，但这类工具的 exe 永远只是半成品，硬件的兼容性说明和文档才是真正的门槛。给自己用就老老实实源码跑，给别人用就得把环境写清楚。

5. 避坑与排查：五条实测踩坑记录

5.1 握手包没拿全，字典再大也是白跑

现象：脚本跑了一整晚，一个密码都没命中，把目标密码放字典第一行都验证不过。原因：airodump 界面显示「WPA handshake」不等于拿到了完整可靠的四次握手，有时只抓到 1/4 或 2/4 的消息，包里缺少计算 MIC 所需的随机数。解决：重新抓包，deauth 报文多发几次，或者等客户端自然重连后再抓；抓包时盯紧右上角状态，看到 WPA handshake 后不要立刻停，等多一两秒让后续帧落盘。

5.2 字典文件编码读乱，候选词全是「锟斤拷」

现象：跑出来的候选密码一堆乱码，英文词正常，中文词和数字组合全废。原因：没有确认字典文件编码，Windows 下很多字典是 GBK 或者 UTF-8 with BOM，Python 按无 BOM 的 UTF-8 读取时直接替换成乱码符号。解决：读取前先做编码探测，或者统一用工具转码；代码里不要用errors="ignore"，那会静默丢掉本来能命中的候选词，应该用errors="replace"让问题暴露出来，配合chardet探测原始编码。

import chardet with open(dict_path, "rb") as f: raw = f.read(4096) encoding = chardet.detect(raw)["encoding"] with open(dict_path, "r", encoding=encoding, errors="replace") as f: for line in f: word = line.strip() if word: # 逐词验证 ...

5.3 5GHz频段握手包反复丢失

现象：目标 AP 在 5GHz，客户端就在旁边，deauth 也发了，就是抓不到握手。原因：airodump-ng 默认全信道跳频扫描，5GHz 信道多、每个信道停留时间短，客户端断线重连的那一瞬间刚好落在别的信道上。解决：先用airodump-ng确认目标信道，再用-c锁定该信道抓包；有条件的话选一块原生支持 5GHz 监控模式的外置网卡，别用 2.4GHz 的旧卡凑合。

5.4 打包后的exe被安全软件秒删

现象：双击 exe，还没来得及看界面就弹窗报毒，文件被隔离。原因：Python 打包的单文件 exe 本身就有加壳特征，加上内部还捆绑了无线攻击工具，特征库匹配命中率极高。解决：打包时优先用目录模式而非单文件模式；不要再用 UPX 加壳，加壳只会让误报更严重；代码里避免出现明显的攻击性字符串。说句大实话，只要工具形态是「无线密码验证」，误报很难完全杜绝，文档里明确告知用户添加信任即可，别把精力耗在对抗特征库上。

5.5 自研碰撞速度被 aircrack-ng 吊打

现象：同一个字典，自研 Python 脚本跑十分钟，aircrack-ng 四十秒跑完。原因：PBKDF2 每次迭代 4096 轮 SHA1，Python 的哈希计算走的是通用实现，没有针对现代 CPU 指令集做优化，又没有 GPU 加速。解决：把碰撞核心交给 hashcat 或 aircrack-ng，Python 只负责生成 URL、解析结果、汇总报告。这个取舍很重要——自己写代码的价值在于理解协议和定制流程，不在于重造一个比 C 工具更快的轮子，硬要优化纯 Python 碰撞，大概率是浪费时间。

6. 从字典到规则引擎：让工具从「能跑」变得「能用」

把工具跑通只是第一步，真正决定它有没有用的是「命中率」。纯字典攻击面对稍微讲究一点的密码就歇菜，所以进阶方向是掩码和规则引擎。hashcat 一条命令就能覆盖「8 位纯数字」这类场景：

# 六位数字密码的掩码攻击，?d 代表数字 hashcat -m 22000 capture.hc22000 -a 3 ?d?d?d?d?d?d # 规则攻击：基于字典词根做变形，加年份、加数字后缀 hashcat -m 22000 capture.hc22000 -a 0 dict.txt -r rules/best64.rule

Python 在这个阶段还有角色——根据 SSID 自动猜测密码构成，动态生成掩码。比如看到zhangsan_wifi5G这样的 SSID，先尝试姓名拼音加数字的组合；看到商户 SSID，优先试手机号段和固定电话规则。把这些判断逻辑写成脚本，把 hashcat 的输出拉回来解析，才算一个完整可用的验证工具。

验证工具是否真的可靠，建议自己搭环境走一遍全链路：找一台支持 WPA2 的旧路由器，设一个 8 位纯数字密码，整个流程跑通；再设一个包含大小写和符号的复杂密码，确认工具能明确报「未命中」。做完这两组测试，你才知道自己的工具在什么条件下能信，什么条件下是白忙。

我自己的习惯是：任何一次无线评估，先确认目标授权范围，再花十分钟检查网卡支持频段、驱动版本、字典编码，最后才动手抓包。有一次带着打包好的工具到某公司做测试，现场网卡驱动不支持 5GHz 监控，浪费了近半小时才切回 2.4GHz 频段锁定信道，从那以后工具包里永远放一张纸条，写着「先看频段，再谈密码」。这类问题几乎全是环境和细节，不是算法。希望这篇文章能帮你少踩几个坑，把这套链路稳稳跑通。

本文还有配套的精品资源，点击获取