1. 先划清楚这条线：Kali 下的 WiFi 密码测试能做什么、绝对不能做什么
几年前我在一个内网安全兴趣小组里，第一次看到有人用 Kali 抓到隔壁办公楼的握手包，然后跑了两小时字典什么都没出来。当时大家笑他"网卡不行"，但真正的问题不是网卡——是他压根没搞清楚自己在做什么。很多人搜"Kali 暴力破解 WiFi 密码"，脑子里想的是输入一条命令、等几分钟、密码自己跳出来。现实是：这套流程有明确的适用前提、有非常硬的算力天花板，而且一旦用错对象，性质就完全变了。这篇东西写给两类人：一类是想在自己搭的无线实验环境里搞懂 WPA2 认证到底怎么被攻防的、准备考安全相关认证的；另一类是自己路由器密码忘了、或者怀疑自家网络被蹭、想从防守侧理解风险点的。如果你打算拿它去试别人家的网，后面所有内容对你都没意义——那不是技术问题，是法律问题。
先把结论摆在最前面，省得有人跳过前面直接翻到命令部分：在没有书面授权的网络设备上抓包、重放、跑字典，属于未经授权访问他人网络的行为，绝大多数地区都有明确的法律后果。我在实际工作里接触过的合规做法只有三种场景：一是自己名下的路由器或自己搭建的测试 AP；二是客户签了授权书、明确了测试范围和时段、有联系人待命的渗透测试项目；三是纯离线的实验靶场，比如用树莓派做个独立热点，跟任何真实生产网络物理隔离。除了这三种，别碰。
1.1 WPA2-PSK 的四次握手到底保护了什么
要理解"暴力破解"这四个字为什么有点名不副实，得先知道 WPA2-PSK 在认证那一刻发生了什么。家用路由器绝大多数跑的是 WPA2-PSK，也就是预共享密钥模式——所有设备共用一个口令，这个口令本身从不上网传输，所以你在空中接口上永远抓不到它。
流程是这样的：客户端和 AP 各自拿"口令 + SSID"经过 PBKDF2-HMAC-SHA1 迭代 4096 次，算出一个 256 位的 PMK（成对主密钥）。这一步是纯本地的、确定性的——同样口令和 SSID，算出来永远是同一个 PMK。然后四次握手里，AP 发一个随机数 ANonce，客户端回一个 SNonce，双方用 PMK 加上两个随机数和双方 MAC 地址，推导出 PTK。最后客户端发一个带 MIC 校验值的 EAPOL 帧，AP 验证通过就建立连接。
关键就在这个 MIC。它是用 PTK 算出来的，而 PTK 依赖 PMK，PMK 依赖口令。所以攻击者抓到的不是口令，而是 ANonce、SNonce、两个 MAC 和一个 MIC 这一组数据。接下来做的是离线穷举：猜一个口令——算 PMK——算 PTK——算 MIC——跟抓到的 MIC 比对。一样，口令就对了。这里面没有任何"在线攻击"的成分，纯粹是本地算力对撞。
这个机制的好处是：抓包只需要一瞬间，攻击者拿到握手包之后可以在自己机器上慢慢算，受害者毫无察觉。坏处是：它把安全性完全押在口令的熵上。口令弱，握手包一抓，等于密码交出去了；口令强，握手包抓到了也就是个 300 字节的废数据。
1.2 授权测试和非法入侵中间那条模糊的线
很多人会自我安慰："我只是抓个包，又没真正连进去。"这条线其实没那么模糊。在大多数司法管辖区，未经授权干扰无线电通信、截取通信内容、尝试获取网络访问权限，各自都可能是独立的违规项——你可能连"算出密码"这一步都没走到，光是在别人的信道上发去认证帧，就已经越界了。
我在做授权测试时有个习惯：把授权范围打印出来放在桌上，写上 SSID、BSSID 前六位、测试时间窗口、紧急联系电话。这不是形式主义。有次我测一个客户的办公区，隔壁公司用的是同型号路由器、默认 SSID 前缀都一样，扫出来十几个 AP，靠 BSSID 才能确定哪个是授权目标。要是一时手快把隔壁的也给去认证了，那场面很难看。
还有个容易被忽略的点：去认证攻击本质上是干扰服务。即使你有授权测自己的 AP，实验期间那台 AP 上的其他设备（家人的手机、电视、智能音箱）会被反复踢下线。所以做实验最好用一台没有任何业务设备连接的独立热点，别拿家里正在用的主路由折腾。
1.3 这套流程真正能解决的三个现实问题
说到底，学这套东西的价值在哪？我总结下来是三个。
第一，理解风险从哪来。你不是为了黑别人，是为了知道自己家网络被盯上时，对方大概会怎么做、卡在哪一步、什么防护措施真正有效。知道了 PBKDF2 迭代和 MIC 比对的原理，你就明白为什么"改个复杂密码"比"换个贵路由器"有用得多。
第二，评估自己的口令强度。你可以用自己抓的握手包和不同的字典去测，直观感受到"我那个 8 位生日密码"在字典面前撑了几秒。这种体感比看任何安全建议都有说服力。
第三，排查自家网络异常。频繁掉线、网速莫名其妙变慢、路由器后台出现陌生设备——这些现象背后可能是蹭网，也可能是信道干扰，或者设备故障。掌握扫描工具的基本用法，至少能让你在投诉宽带之前先看一眼周围有几个 AP、自己占的信道挤不挤。
注意：本文所有操作步骤均以"自己拥有或已获书面授权的无线设备"为前提。任何针对非授权网络的操作，本文不提供支持，也不建议尝试。
2. 把实验室框在自己路由器上：Kali 环境与网卡的坑
环境这一块，我见过太多人卡在第一天。不是 Kali 装不上，就是网卡不认、监听模式起不来。这些问题跟"破解"本身没关系，但会消耗掉你 80% 的耐心。所以先把地基打牢。
2.1 Kali 的四种装法，按实验需求选
Kali 装法大概有这么几种，选哪种取决于你要不要 USB 直通无线网卡——这是核心变量。
| 安装方式 | 适合场景 | 无线网卡直通 | 主要坑 |
|---|---|---|---|
| 虚拟机（VMware/VirtualBox） | 日常学习、课程实验、随时快照回滚 | 需要 USB 直通，配置稍麻烦 | USB 控制器版本选错，网卡认不到 |
| 物理机双系统 | 长期做无线实验，要跑满网卡性能 | 原生支持，最省事 | 分区风险、驱动缺失 |
| U 盘 Live 模式 | 临时应急、一次性实验 | 原生支持 | 重启后配置和抓包文件全丢 |
| WSL / 容器 | 纯命令行工具链练习 | 基本不可能直通无线网卡 | 没内核无线子系统，监听模式免谈 |
如果你只是想把命令跑一遍看输出，虚拟机最省事，快照一下随便折腾。但要做真正的无线抓包，WSL 这条路直接排除——它跑在 Windows 内核的兼容层上，没有独立的无线子系统，iw这类工具基本没戏。U 盘 Live 模式我踩过坑：有一次抓了两小时的包，重启全没了，因为 Live 环境的文件系统是内存盘。要用 U 盘，务必配合持久化分区。
虚拟机的 USB 直通是重灾区。以 VMware 为例，你得在虚拟机设置里把 USB 兼容性调到 3.x，然后把外置网卡从宿主机断开、连线到虚拟机里。这里有个细节：如果你直接勾选"连接"，宿主机和虚拟机可能会抢设备，表现为网卡在虚拟机里一闪就消失。正确做法是先让宿主机把设备"弹出"（不是拔掉），再在虚拟机的可移动设备菜单里选连接。VirtualBox 类似，需要装扩展包才有 USB 2.0/3.0 支持。
2.2 无线网卡才是决定成败的硬件
笔记本自带的无线网卡，99% 做不了这件事。不是驱动问题，是芯片本身不支持监听模式和帧注入——厂商为了省电和合规，把这些能力在固件层面阉割了。所以你必须要一块外置 USB 网卡，而且得挑芯片。
判断标准就两条：能不能进监听模式（monitor mode），能不能注入帧（packet injection）。前者让你能收到不属于自己的所有帧，后者让你能发出伪造的去认证帧。市面上常见的方案里，基于 Atheros AR9271 的芯片兼容性最好、价格便宜，但只支持 2.4GHz；Ralink 的 RT3070 系列也是老牌选择；如果想要同时覆盖 5GHz，得找支持双频且驱动开放的芯片，通常贵不少，而且 Kali 里可能要额外编译驱动。
还有个隐蔽的坑：接口带宽。USB 2.0 在高速抓包时会丢帧，尤其是周围 AP 多的时候。建议优先用 USB 3.0 口，并且在虚拟机里也确保走的是 USB 3.x 控制器。我有次怎么都抓不全握手包，换了个口就好了——后来发现是插在了 USB 2.0 的延长线上。
2.3 监听模式跑通前的三次确认
进系统之后，别急着敲工具，先按顺序确认三件事。
第一步，看网卡认没认出来。iwconfig或者ip link能看到接口名（通常是wlan0这种）。如果根本没有无线接口，说明驱动没加载或者 USB 直通没成功。这时候别去网上乱找教程，先回虚拟机设置确认设备连接状态。
第二步，检查是否支持监听。iw list输出里搜 "Supported interface modes"，看到monitor才算过关。这一步能过滤掉一大半"看起来能用其实不能用"的网卡。要是这里没有 monitor，后面所有操作都是白费。
第三步，起监听模式。传统做法是airmon-ng start wlan0，它会创建一个wlan0mon之类的接口。不过现在有些驱动直接支持iw dev wlan0 set monitor none，方式更干净。起完之后用iw dev确认接口类型变成了 monitor。
这里有个经验：airmon-ng 有时会把 NetworkManager 搞挂，表现为监听模式起来了但网卡完全收不到包。原因是 NetworkManager 在后台抢管理接口。稳妥的做法是先airmon-ng check kill，把可能干扰的进程停掉，用完再重启服务。别嫌麻烦，这一步能省掉你半小时的困惑。
3. 一次完整的握手包捕获：扫描、逼认证、判断完整性
环境搞定之后，真正的操作其实只有三步，但每一步都有判断标准，不是敲完命令等结果就完事。
3.1 扫描阶段：读懂 airodump-ng 那一屏信息
启动扫描的命令是airodump-ng wlan0mon。屏幕上会刷出一堆 AP 和客户端信息，第一次看会觉得眼花。挑几个关键列说清楚。
BSSID是 AP 的 MAC 地址，这是唯一标识，SSID 可以重名但 BSSID 不会。做授权测试时，就是你确认目标的依据。CH是信道，2.4GHz 常用 1、6、11 三个互不重叠的，周围 AP 多了之后这里会非常拥挤。ENC是加密方式，WPA2是目标，WEP基本已经绝迹了（真有的话处理方式完全不同），OPN是开放网络。CIPHER是加密算法，一般是 CCMP。AUTH是认证方式，PSK就是预共享密钥。
下半屏是客户端列表，STATION列是已连接设备的 MAC，BSSID列是它连着哪个 AP。这一列非常关键——后面"逼认证"需要一个在线客户端做靶子，这里就是找靶子的地方。
实际操作里我一般会加参数筛一下：airodump-ng --band a wlan0mon只扫 5GHz，或者--channel 6锁定单一信道。锁定信道是必须的，因为网卡一次只能待在一个信道上，跳频扫描虽然能看到更多 AP，但抓握手包时如果正好跳到别的信道，关键帧就错过了。确定目标后，立刻用-c锁死信道。
3.2 抓包阶段：为什么非得"逼"客户端重新认证
确定目标之后，命令变成这样：airodump-ng -c 6 --bssid AA:BB:CC:DD:EE:FF -w capture wlan0mon。这会锁定信道 6、只盯这一个 AP，把抓到的包写进capture开头的文件里。
问题是，握手包只在设备连接的那一刻产生。如果你只是安静地监听，很可能等半天一个握手都抓不到——因为周围设备早就连上了，不会无缘无故重新认证。这时候就需要去认证环节。
原理很直白：给已连接的客户端发一个伪造的、来自 AP 的"断开"帧，客户端信以为真，掉线，然后自动重连，重连过程就是一次完整的四次握手。工具是aireplay-ng，命令形如aireplay-ng -0 5 -a <AP的BSSID> -c <客户端MAC> wlan0mon，-0表示去认证，5是发送次数。
这里有几个必须知道的点。第一，发送次数别贪多，5 到 10 次足够，狂发只会干扰周围一片设备，还容易触发部分路由器的防护机制。第二，-c指定单个客户端比广播式去认证干净得多，广播会把所有连着的设备全踢掉，在授权测试里这是很不专业的做法。第三，如果目标启用了 802.11w（管理帧保护），去认证帧会被丢弃，这招就失效了——这恰恰是 WPA3 的默认配置之一，后面防守那节会再展开。
去认证之后回到 airodump-ng 的界面，右上角会有一个提示，大致是WPA handshake: AA:BB:CC:DD:EE:FF。看到这行才算成功。没看到就再试一次，但别连续试超过两三分钟，反复踢同一个设备会很明显。
3.3 握手包到底完整不完整
抓到提示不等于抓全了。四次握手由四个 EAPOL 帧组成，做离线比对至少需要包含 MIC 的那个帧（通常是第 2 帧或第 4 帧）。如果只抓到前半段，后续跑字典会直接报错说"没有有效的握手"。
判断方式有这么几种。最直接的是看 airodump-ng 的提示，现代版本会显示抓到的是完整握手还是部分。其次是用aircrack-ng capture-01.cap检查，它会列出所有识别到的网络和握手状态。再进一步可以用tshark或 Wireshark 打开，过滤eapol，看有几个包、哪个带 MIC。
我踩过一个坑：同一次捕获里有多个 AP 的握手包混在一起，因为早期没锁信道。这时候 aircrack-ng 会让我选编号，选错了就是给别的网络跑字典，白费算力。所以从抓包那一刻起就锁信道、锁 BSSID，是最省事的做法。
还有一个细节：捕获文件是分卷的（-01.cap、-02.cap……），跑字典时要针对正确的那个文件，或者干脆用带前缀的通配。文件名混乱是这个环节最常见的低级错误。
4. 从握手包到明文：字典和算力的真实较量
到这一步，最难的部分其实已经过去了。剩下的就是纯粹的算力问题——也是大多数人对"暴力破解"这个词误解最深的地方。
4.1 PBKDF2 的 4096 次迭代：慢在哪
前面提过，每个候选口令都要先算 PMK，这个过程是 PBKDF2-HMAC-SHA1，迭代 4096 次。这意味着什么？如果你用一块普通 CPU，单核每秒大概只能算几十到几百个候选。一块主流显卡，靠并行计算能跑到每秒几十万个候选（具体数字取决于显卡型号和哈希实现）。
看起来挺快？我们把密钥空间摆出来就明白了。
| 口令构成 | 密钥空间 | 按 20 万次/秒估算 | 现实结论 |
|---|---|---|---|
| 纯 8 位数字 | 10^8 | 约 500 秒 | 字典覆盖到位的话，几分钟内出结果 |
| 6 位小写字母 | 26^6 ≈ 3.1 亿 | 约 26 分钟 | 也很脆弱 |
| 8 位小写字母 | 26^8 ≈ 2.1e11 | 约 12 天 | 单独穷举性价比很低 |
| 8 位小写字母+数字 | 36^8 ≈ 2.8e12 | 约 160 天 | 基本不考虑纯穷举 |
| 10 位大小写+数字 | 62^10 ≈ 8.4e17 | 天文数字 | 不必想 |
这张表是我自己实测后整理的量级估算，实际速度受显卡、驱动、系统负载影响，可能有数倍偏差，但数量级不会错。看到"160 天"这几个字，你就该明白：所谓暴力破解，99% 的情况下并不是真的穷举，而是"字典命中"。
也就是说，这套流程能不能成功，几乎完全取决于受害者的口令是否落在一个精心构造的候选列表里。纯随机 12 位口令，用家用设备是算不出来的——这就是 WPA2 至今没有被彻底打穿的原因。
4.2 字典决定成败：真实口令的分布规律
既然靠字典，那字典质量就是命门。常见的字典来源大概有这几类。
泄露口令集是最基础的原料，包含大量真实世界的弱密码，比如各种password变体、12345678、qwerty之类。这类字典的问题是有明显的年代特征和语言偏向，对非英语地区的用户命中率会打折。
数字模式字典在特定地区特别有效。比如 8 位或 11 位手机号、生日（年月日各种拼接格式）、门牌号、身份证后几位。我做过一次统计，一个地区里被蹭网成功的案例，口令是纯数字的占了相当大比例——因为很多人图省事，直接拿手机号当 WiFi 密码。
规则变形是把基础词库用规则引擎扩展。比如拿一个常见词，套上"首字母大写""末尾加 123""中间插年份"这些规则，能生出一个数量级更大的候选集。这套思路比单纯堆词库高效得多。
路由器默认口令表也值得单独列出来。有些型号的默认密码是固定的或者有可预测的生成规则，如果用户从没改过，字典里几行就能覆盖。
我的经验是：不要指望下载一个"万能字典"，先分析目标场景再选字典。如果目标是个家庭网络，用户很可能是普通家庭成员，优先上生日、手机号、姓名拼音加数字这几类；如果是小公司，重点在店名、地址、电话号码。盲目堆一个几十 GB 的大字典，跑起来几天几夜还不一定命中，性价比极低。
4.3 aircrack-ng 还是 hashcat：工具怎么选
抓完包之后，跑字典的主流工具是两个。
aircrack-ng capture-01.cap -w wordlist.txt是最经典的组合。优点是直接读.cap文件，不需要转换格式，CPU 就能跑，适合小字典快速验证。缺点是 CPU 效率低，大字典跑起来非常慢。
hashcat是性能路线。它把抓包文件转成自己的格式（新版本用hcxpcapngtool转成.hc22000），然后交给 GPU 并行计算。同样一块显卡，hashcat 的速度可能比 aircrack-ng 高一个数量级以上。代价是环境配置麻烦一点，要装显卡驱动、OpenCL 运行时，有时候还要处理驱动版本冲突。
我的实际做法是分两段：先用小字典加 aircrack-ng 快速筛一遍，几万条的字典几十秒就出结果，能中就中了；不行再上 hashcat 和大字典，跑通宵。这样既省时间也省电。
hashcat 有几个参数值得说。-m 22000是指定 WPA-PBKDF2 的哈希模式（老版本是 2500，现在更新了格式）。-w 3是工作负载档位，日常用 2 或 3，别直接拉 4，容易把机器跑到过热降频。还有--session参数，长任务一定要起个会话名，中断了可以--restore恢复，不然跑了十小时断电一次全白费。
4.4 关于成功率的心理预期
说个可能让人扫兴的现实：这套流程的成功率，跟目标口令强度强相关，而且随着路由器固件的演进在持续下降。我做过几十次实验（都是自己的 AP 或授权设备），大概的分布是这样的：默认口令或者纯数字口令，基本秒破；常见的"姓名拼音+123"这类，字典到位的话几分钟到几小时；稍微有点随机性的 8 位混合口令，成功率断崖式下跌；一旦超过 10 位且有大小写和符号，家用设备就别想了。
还有个容易被忽略的因素：SSID 参与 PMK 计算。这意味着你不能把 A 网络跑出来的字典结果套到 B 网络，哪怕口令完全一样。有些工具支持预计算 PMK 表来加速，但表的大小和 SSID 数成正比，实际意义有限。
提示：如果字典跑了几小时毫无动静，别怀疑工具，先怀疑字典。换个思路，从目标的可获取信息（名字、生日、店名、手机号）重新构造候选列表，命中率比堆量高得多。
5. 把同一套知识反过来用：给自己的网络加几道锁
学攻击的最终目的是防守。下面这几条，是我给别人做网络加固时必查的清单，也是我从实验里得到的最有用的部分。
5.1 WPA3、802.11w 和 WPS：三个开关要认清
WPA3 是第一优先级。它把认证换成了 SAE（对等实体同时认证），握手过程不再能被离线字典攻击——因为每次尝试都要跟 AP 实际交互，速率被物理限制死。如果你的路由器支持 WPA3，哪怕只是 WPA2/WPA3 混合模式，也建议开起来。混合模式有个妥协：为了兼容老设备，WPA2 那条路仍然可被攻击，但至少新设备走的是安全通道。
**802.11w（管理帧保护）**是另一个关键项。开启之后，去认证帧会被加密验证，前面那招"逼客户端重连"直接失效。WPA3 默认要求开启，WPA2 模式下手动开启有时会导致个别老旧设备连不上，需要权衡。
WPS 必须关掉。这个功能本意是方便用户一键配网，但它的 PIN 码机制存在设计缺陷，PIN 的尝试次数可以被绕过，理论上几小时内能穷举出来。很多路由器默认开启，且藏在高级设置里。进了后台第一件事就是找到它、关掉。
5.2 什么样的口令才算"够"
结合前面的密钥空间表，我给的建议很具体：至少 12 位，包含大小写字母、数字，最好再加一到两个符号，而且不能是任何有意义的词或它们的简单变形。
为什么是 12 位？因为从算力角度看，12 位随机混合字符的密钥空间已经远超家用设备的处理能力，字典又不可能覆盖随机串，两条路都堵死了。为什么强调"不能有意义的词"？因为字典和规则引擎最擅长的就是捕捉"人脑可记忆"的模式——你觉得自己想了个很妙的组合，可能正好落在某个规则的第 37 条上。
一个实用技巧：用四个不相关的词拼起来，中间插符号和数字。比如把几个毫不相干的词组合，长度够、好记、还不在任何字典里。这种"口令短语"的思路在业界已经推了很多年，比强行记一串乱码靠谱得多。
5.3 家庭和小型办公网络的加固清单
除了上面三项，还有几条低成本高收益的：
- 改掉默认 SSID。不是为了"隐藏"，而是避免暴露路由器型号，同时减少跟邻居撞名导致的连接混乱。
- 关闭远程管理。很多路由器有"云管理""远程访问后台"功能，默认开着，这是比 WiFi 口令更大的风险面。
- 固件保持更新。厂商会修补认证相关的漏洞，老固件可能连已知问题都没修。
- 访客网络隔离。给客人单独开一个访客 SSID，并且开启客户端隔离，避免访客设备互访你家内网设备。
- 定期看设备列表。路由器后台一般能看到当前连接设备，发现陌生物理地址就查一下，必要时改口令并踢掉。
不要用"隐藏 SSID"当安全措施。隐藏只是不发广播，扫描工具照样能通过客户端探测帧发现，而且会给自己的设备连接带来麻烦，收益几乎为零。
6. 我在实验里踩过的那些坑，以及对应的排查思路
这部分是最"脏"的，但也是最值钱的。上面所有流程听起来顺，实际动手时八成会卡在某个环节，而且报错信息往往毫无指向性。我把自己反复遇到过的几类问题整理出来。
6.1 网卡认得到但起不了监听模式
现象是iwconfig能看到接口，但airmon-ng start之后没生成 mon 接口，或者生成了却收不到任何包。排查顺序是这样：先用iw list确认芯片固件是否报告支持 monitor；如果不支持，换网卡，没有别的办法。如果支持但起不来，检查是不是 NetworkManager 在抢——airmon-ng check kill一下再试。还有一种情况是接口被 rfkill 软屏蔽，rfkill list能看到，rfkill unblock all解决。
虚拟机的场景更复杂。USB 直通后，网卡在虚拟机里可能出现两个接口（一个虚拟的、一个真实的），监听模式必须起在真实那个上。判断方法是看驱动名，虚拟接口通常是virtio之类。
6.2 提示抓到了握手，跑字典却说无效
这个我遇到过至少三次，原因各不相同。最常见的是捕获文件搞错了——抓包时生成了-01.cap、-02.cap，跑字典时指向了不含握手包的那个。解决办法是先对每个文件都跑一次aircrack-ng检查，看哪个报告有有效握手。
第二种原因是握手不完整，只有前两帧，没有带 MIC 的帧。这时候只能重抓，建议多踢几次、并且保证抓包设备和目标之间的信号质量。信号弱的时候丢帧率极高，握手包本身就是两三帧的事，丢掉关键帧的概率不小。
第三种比较隐蔽：同一信道上有多个 BSSID，工具识别错了目标。用--bssid明确指定，能规避这个问题。
6.3 跑字典跑到一半系统卡死或重启
hashcat 把显卡跑到满载，散热跟不上就会降频甚至触发保护性关机。我在笔记本上跑过一次通宵，第二天早上发现机器重启了，进度全丢。
对策有三条。一是限制负载，用-w 2或者手动限制功率，速度损失一部分但能跑完。二是用会话恢复机制，--session=xxx加定期检查点，中断后能续上。三是监控温度，跑之前先看看散热环境，笔记本垫高、清灰，别放在床上或者沙发上。台式机的话，机箱风道比显卡型号更重要。
还有一种"假卡死"：内存不够，系统开始疯狂换页。大字典加规则引擎展开后，候选数量可能爆炸式增长，内存吃满。这时应该分段跑，把大字典拆成几个小文件依次处理，而不是一次性喂进去。
6.4 虚拟机里一切正常，物理机换过去就不行
反过来也常见。原因是虚拟机和物理机的驱动栈不同，同一个网卡在两个环境下的表现可能完全不同。我的建议是：实验环境选定一个就别乱换。如果你在虚拟机里跑通了全流程，就一直用虚拟机，快照功能在反复实验时太香了。如果确实需要更好的性能（比如要跑 GPU 字典），那就把字典计算放到物理机上，抓包环节留在虚拟机里，两边通过共享文件夹交换.cap文件。
共享文件夹这块也有个坑：虚拟机里挂载的共享目录，hashcat读文件时可能因为权限或者文件锁报错。稳妥做法是把文件复制到本地磁盘再跑，别直接跑共享目录里的文件。
6.5 关于时间和心态
最后说点技术之外的。这套流程从环境搭建到跑出结果，第一次做很可能花掉一整个周末，而且大概率以"没跑出来"告终。这不是你操作错了，是这件事本身就这样——弱口令秒破，强口令永远破不了，中间地带靠字典质量碰运气。
我自己最有收获的一次，不是成功跑出了一个口令，而是拿自己的路由器做实验时发现：我自以为"挺复杂"的密码，用针对性构造的字典跑了不到十分钟就出来了。那一刻的震撼，比任何安全培训都管用。后来我把家里和工作室所有网络的口令全换成 15 位以上的短语组合，访客网络做了隔离，WPS 关掉，固件更新到最新。
如果你也打算动手，记得把范围框死在自己名下或者有书面授权的设备上。测完记得把监听模式关掉、NetworkManager 重新启起来，别留下一个半残的网络栈影响日常使用。抓包文件也别随手乱放，里面包含你网络的 BSSID、客户端 MAC 和握手数据——哪怕是自己的，处理完删掉也比留着安心。
