wifit3 四向握手配对拆解：5 秒窗口与 ±8 容差从哪来，配不上时去哪排查

wifit3 四向握手配对拆解：5 秒窗口与 ±8 容差从哪来，配不上时去哪排查

【免费下载链接】wifit3Wifite but USB-only & cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3

抓满 EAPOL 帧，导哈希时却一条 hc22000 都没有？wifit3 的判定里，握手"抓到"与"配得上"是两回事。这篇回答三件事：配对规则为什么长成这样，5 秒、±8、N/N+1 三个数字的出处，以及配不上时该往哪看。

四向握手帧的角色表：hashcat 22000 到底要三样什么

hashcat 跑 -m 22000 的破解循环是：猜密码 → 派生 PMK/PTK → 拿某帧被 MIC 保护的 EAPOL 原文重算 MIC 做比对。要喂哈希，一次握手必须凑齐 ANonce、SNonce 和那帧自带 SNonce 的 MIC 原文——少任何一样都导不出哈希行。四帧各自贡献了什么，见 handshake.py 顶部注释（L14-L33）：

由此推出全部合法组合只有四种：M1+M2、M1+M4、M2+M3、M3+M4，对应 hashcat message_pair 字节 0x00、0x01、0x02、0x05（L25-L29）；M3 的 nonce 是 ANonce、M1 没有 MIC，所以以它们为 MIC 源的组合在 hashcat 侧标为 unused，wifit3 永不输出。M4 想顶 keystone 还有个前提：客户端没把 SNonce 清零——_mic_frame_usable与describe的 M4 分支（L179-L180）都要求它真的带着非零 nonce。

EAPOL 配对参数溯源：5 秒配对窗口、±8 Nonce 纠错容差与 N/N+1 计数器规则

5 秒从哪来？常量_EAPOL_PAIR_WINDOW_S = 5.0（L65-L69）。问句先放这：为什么是 5，不是 3 或 10？注释写得很直白：对齐 hcxpcapngtool 的 EAPOLTIMEOUT（同为 5 秒），这是 ZSteg 团队拿大量真实抓包验证的经验值——同一次握手的四帧之间不可能隔 5 秒。作用位置是_within_window（L214-L220）：两帧到达时差超过 5.0 秒直接拒配。改大会怎样？两次不同关联的帧，重放计数器恰好相同就会被误配成一次握手——窗口就是给计数器精确层兜底的粗筛。

±8 从哪来？常量_NC_MAX = 8（L71-L76）。问题：AP 重传、弱信号会让供体帧的重放计数器（replay counter，每帧 EAPOL 里那个 8 字节编号，类似帧的时间戳）偏离预期几格，直接按"逐字节相等"配对会丢掉大片真实握手。hcxpcapngtool 的答案是--nonce-error-corrections 8，wifit3 原样照抄：配对时供体计数器与预期偏差 ≤8 就保留（L300-L302），随后输出哈希行时把 message_pair 字节高位固定置_NC_BIT = 0x80（L78），见hc22000_line的pair.pair_byte | _NC_BIT（L331-L349）。这个 0x80 位等于告诉 hashcat：请在小窗口内暴力补偿 ANonce 与计数器的漂移——代价是 hashcat 要多试几轮，换来弱信号抓包也能喂哈希。

N/N+1 从哪来？四向握手自身的计数器规律：M1 与 M2 同为 N，M3 与 M4 同为 N+1。配对时按 keystone 的消息号推出供体的预期计数：M2 配 M1 期望 rc，M2 配 M3 期望 rc+1，M4 配 M1 期望 rc-1，M4 配 M3 期望 rc（L285-L290）。这是三层约束里最精确的一层，5 秒窗口只兜底、不替代。候选排序也是"精确优先"：计数器间隙 → 置信度（AP 确认对 M2+M3、M3+M4 优于挑战对）→ 到达距离（L278-L306），间隙 0 的命中永远排在 ±8 命中前面。

配对失效图鉴：时间够近，为什么还是配不上

现象：M2 先到、M1 后到。判废处：_pairs_ignoring_akm的顺序检查（L295-L297）——四向握手必然 M1→M2→M3→M4 到达，编号小的帧必须先出现，倒序候选直接剔除，连候选列表都进不去。界面：既没有 "Handshake captured" 横幅，也不给不可破解标签，等于这次握手的 ANonce 根本没被收进任何配对；排查方向是先确认抓包起点早于客户端的连接时刻。

现象：供体帧计数器与预期值差了 9 格或更多。判废处：rcgap > _NC_MAX的 continue（L300-L302）。这类帧多来自重传风暴或跨关联撞号，容差只救 ≤8 的小漂移。界面：横幅沉默；排查方向是信号强度——把网卡挪近、换信道、重新触发一次关联。

现象：四帧齐全、组合也合法，帧却标注"不可破解"。判废处：eapol_verdict（L110-L121）对照 AKM 黑名单_EAPOL_BAD_AKMS（L100-L104）——SAE 的 PMK 来自临时密钥交换、EAP 的 PMK 来自 802.1X 会话的 MSK，都没有可供暴破的密码短语。界面：不是静默丢弃，横幅照样报捕获，四向握手树上挂 ✗ 徽章写明 SAE/FT/EAP/OWE 哪一种，describe的 useful 判定同步生效（L171-L181）。

还有一条豁免：时间戳为 0.0 的旧捕获在_within_window里直接返回 True（L218-L219），跳过时间检查，仅靠计数器规则配对，保证老 pcap 的回放测试不受影响。

在 Focus 页跑通一次四向握手捕获

最小操作路径：插一张支持监听模式的 USB 网卡 → 扫描页锁定目标 AP → 进入 Focus 页，等客户端重新关联或触发重连。成功长什么样：横幅打出 "Handshake captured"，四向握手树出现 "✓ Valid 4-Way Handshake (M1+M2)" 这类组合标注，客户端行亮起握手标记（eapol_aggregate.py）。还有个容易忽略的细节：树往往在 M2 到达时就宣告完成——可破解性在 M2 处已经成立，wifit3 甚至不需要 M4（L16）。而横幅与自动保存走的是同一条crackable_pairs代码路径（single source of truth，L231-L236）：界面说"已捕获"，保存就一定导得出一行 WPA*02 哈希，二者永不矛盾。

一行公式与文件地图

计数器精确匹配（N/N+1）+ 5 秒时间兜底 + 到达顺序约束 + ±8 的 NC 容错 ＝ 一条 hashcat 可直接开跑的哈希行。

【免费下载链接】wifit3Wifite but USB-only & cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3