简介一份基于Python实现的WiFi密码破译工具采用暴力破解算法提供封装完毕的exe可执行程序与完整Python源码面向网络安全爱好者、Python初学者以及希望了解WiFi认证机制与弱口令风险的学习者。资源共2个文件压缩包约247MBpy源码便于读者阅读与二次修改观察破解流程中各模块的调用逻辑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 校验再把结果格式化输出。链路环节常用工具Python 的职责网卡进入监控模式airmon-ng通过 subprocess 调用并确认状态扫描与抓包airodump-ng读取输出文件路径做后续解析触发握手aireplay-ng按目标参数组装命令握手包解析scapy 或 hcxpcapngtool提取 ANonce、SNonce、MAC、MIC密码碰撞自研代码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 wlan0mondeauth 发完回到 airodump-ng 的界面看右上角出现WPA handshake字段才算成功。注意 airodump-ng 是默认跳频扫描的锁定-c 6是为了避免信道来回跳导致握手帧漏抓。抓到握手包后立刻按 CtrlC 停止/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-SHA14096 轮输出 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, encodingutf-8, errorsreplace) as f: for line in f: word line.strip() if verify_password(word, ssid, handshake): print(f命中密码: {word}) return word print(未命中字典太弱或者握手包不完整) return Nonegen_psk是每个候选密码都会被调用一次的热点函数也是性能瓶颈所在。字典里有一万条它就要跑一万次 PBKDF2而每一次内部是 4096 轮 SHA1 迭代。这就是为什么纯 Python 写碰撞慢解释器逐条执行的开销叠加在 4096 轮哈希计算上效率很难和直接用 C 写的 aircrack-ng 比。代码里的compute_mic实际需要按 802.11 协议规范实现 PRF-256 和帧拼接逻辑完整源码里这是最绕的部分网上能找到的项目基本都是在解析 EAPOL 帧的细节上拉开差距的。教学版能让你理解链路真要跑出结果建议把碰撞环节交给 hashcatPython 只负责组织和解析这一点在下文还会展开。4. 把脚本打包成exePyInstaller的失败与依赖补齐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 把外部工具与资源一起打进exespec文件写法PyInstaller 提供了 spec 文件机制可以在打包时把外部可执行文件和字典资源一并捆绑进去。先让 PyInstaller 生成一个初始 specpyinstaller -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[], binariesbinaries, datasdatas, hiddenimports[scapy.layers.all], ... ) exe EXE( a, namewifi_verify, consoleTrue, ... )关键点是binaries里的外部工具建议用静态编译版本避免目标机器缺 VC 运行库再翻车datas打包字典时要注意路径代码里读取资源文件的位置要和打包后的相对路径一致这是新手最容易忽略的差异。改完 spec 后重新执行pyinstaller crack_wifi.spec生成物在dist/wifi_verify.exe。这里有个经验不要贪图单文件模式漂亮而硬用-F带外部工具的单文件 exe 在运行时要把二进制释放到临时目录杀毒软件对「自解压释放 exe」的行为非常敏感目录模式的误报率低很多。4.3 exe在别人机器上跑不起来的前三个原因即便打包成功exe 到另一台机器上跑不起来也很正常。最常见的原因是权限不够无线网卡进入监控模式需要管理员权限双击运行时没有「以管理员身份运行」程序会在切换网卡模式时报错。这不是代码缺陷但很多用户会误以为是工具坏了。打包时在 spec 里加上uac_adminTrue可以强制弹 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 BOMPython 按无 BOM 的 UTF-8 读取时直接替换成乱码符号。解决读取前先做编码探测或者统一用工具转码代码里不要用errorsignore那会静默丢掉本来能命中的候选词应该用errorsreplace让问题暴露出来配合chardet探测原始编码。import chardet with open(dict_path, rb) as f: raw f.read(4096) encoding chardet.detect(raw)[encoding] with open(dict_path, r, encodingencoding, errorsreplace) 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 轮 SHA1Python 的哈希计算走的是通用实现没有针对现代 CPU 指令集做优化又没有 GPU 加速。解决把碰撞核心交给 hashcat 或 aircrack-ngPython 只负责生成 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.rulePython 在这个阶段还有角色——根据 SSID 自动猜测密码构成动态生成掩码。比如看到zhangsan_wifi5G这样的 SSID先尝试姓名拼音加数字的组合看到商户 SSID优先试手机号段和固定电话规则。把这些判断逻辑写成脚本把 hashcat 的输出拉回来解析才算一个完整可用的验证工具。验证工具是否真的可靠建议自己搭环境走一遍全链路找一台支持 WPA2 的旧路由器设一个 8 位纯数字密码整个流程跑通再设一个包含大小写和符号的复杂密码确认工具能明确报「未命中」。做完这两组测试你才知道自己的工具在什么条件下能信什么条件下是白忙。测试场景预期结果验证要点弱密码如 12345678快速命中全链路抓包、解析、碰撞是否通复杂密码未命中字典覆盖不足时程序是否正常退出5GHz 频段目标可抓到握手网卡与信道锁定是否生效换一台电脑跑 exe可运行或明确报错依赖文档是否写清了前提条件我自己的习惯是任何一次无线评估先确认目标授权范围再花十分钟检查网卡支持频段、驱动版本、字典编码最后才动手抓包。有一次带着打包好的工具到某公司做测试现场网卡驱动不支持 5GHz 监控浪费了近半小时才切回 2.4GHz 频段锁定信道从那以后工具包里永远放一张纸条写着「先看频段再谈密码」。这类问题几乎全是环境和细节不是算法。希望这篇文章能帮你少踩几个坑把这套链路稳稳跑通。本文还有配套的精品资源点击获取