wifit3 深度解析EAPOL 识别、WPA 四向握手配对到 hc22000 哈希行的完整链路【免费下载链接】wifit3Wifite but USB-only cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3盯着目标 AP 抓了十分钟M1 到 M4 四帧齐全信心满满地拼出一条 hc22000 行丢给 hashcat-m 22000——invalid hash。wifit3 把混杂模式原始字节 → EAPOL 解析 → M1–M4 分类 → 配对 → 可破解哈希行做成一条自动管线EAPOL 解析发生在 src/wifit3/dot11/parser.py 的纯 Python 解析器里握手配对与 hc22000 生成集中在 src/wifit3/crack/handshake.py中间不依赖 aircrack-ng 或 reaver。问题几乎从不出在没抓到而出在下面这条链路的每一环判定标准。全链路从 USB 原始字节到一条可破解的 hc22000 行先把地图铺开。五个环节每个环节有且只有一个负责文件#环节输入 → 输出位置1帧结构校验与 EAPOL 定位原始 MPDU → EAPOL 帧或丢弃parser.py_parse_eapol2M1–M4 分类Key Info Key Data 长度 → 消息编号 1–40 无关帧parser.py_classify_eapol_msg3消息入模分类帧 → 每客户端Handshake消息表带时间戳、AKMmodels/handshake.pyHandshakeMessage4配对消息表 → 全部可破解实例M1M2 / M2M3 / M3M4 / M1M4handshake.py_pairs_ignoring_akm5哈希行每实例 → 一条WPA*02*…handshake.pyhc22000_line第 1 环的两个细节值得展开。签名定位不是按固定偏移取而是在 MAC 头后 16 字节窗口内滑动查找AA AA 03 00 00 00 88 8ELLC/SNAP EAPOL 以太类型常量定义在 eapol.py 第 9 行——DMA 会把 802.11 头做 4 字节对齐填充固定偏移会取错位置。字段抽取则按 802.1X 固定偏移Key Info 在偏移 5、重放计数器在 98 字节、Nonce 在 1732 字节、MIC 在 8116 字节偏移对照见 parser.py 的注释块。分类规则由 Key Info 三个位决定parser.py 第 260–277 行消息ACK 位MIC 位INSTALL 位Key Data角色M1100任意纯 ANonce 供体M2010非空RSN IE关键帧M3111任意ANonce 供体M4010空条件关键帧M2 和 M4 的位模式完全相同靠 Key Data 是否为空区分——M2 携带客户端的 RSN IEM4 什么都不带。第 4 环是整条链路的枢纽crackable_pairshandshake.py是 UI 横幅的已捕获判定、Handshake.is_complete属性models/handshake.py、以及落盘保存persist/save.py 的save_handshake共同调用的同一个函数。模块头部注释handshake.py把这个设计称为 single source of truth——界面声称捕获成功落盘就必然能导出对应行两者物理上不可能矛盾。第 5 环的哈希行格式是固定的 8 字段WPA*02*MIC*AP MAC*STA MAC*SSID hex*ANonce*EAPOL 原文*message_pair规范注释在 hc22000_format.py。三个关键决策链路里真正决定这条行 hashcat 认不认的是三个设计取舍。下面按遇到什么问题 → 怎么设计 → 代价与边界拆开。5 秒窗口时间戳缺席时靠什么拒绝跨关联的假配对重放计数器是精确层的绑定依据但无线丢包会让 AP 重传、计数器跳变供体帧的计数器与预期值差几格是常态。只靠计数器还有一类真实故障客户端断开重连时 AP 会把计数器清零旧关联里残留的 M3 和新关联刚发出的 M2 在M21 M3这条规则上撞车被错误配对。设计是三层约束叠加都在 _pairs_ignoring_akm 的候选循环里计数器层供体计数器与预期值的偏差rcgap必须 ≤ 8且 rcgap 越小候选优先级越高排序键在 handshake.py 第 278–280 行到达顺序层四向握手必然 M1→M2→M3→M4 到达编号小的帧必须出现在消息表更早的位置倒序候选直接剔除handshake.py 第 295–297 行时间层两帧到达时间差超过 5.0 秒直接拒绝即_EAPOL_PAIR_WINDOW_Shandshake.py 第 65–69 行注释写明对齐 hcxpcapngtool 的EAPOLTIMEOUT经验值。代价与边界任一帧时间戳为 0.0 时时间检查整体跳过_within_window 第 218–219 行退化为计数器 到达顺序双规则。这对回放老 pcap 和测试夹具是正确行为但顺序层因此承担更重的绑定责任——test_reconnect_spam_does_not_cross_pairtests/crack/test_wpa_handshake.py 第 103–127 行复刻的正是无时间戳条件下 NETGEAR AP 每关联重置计数器、陈旧 M3 与新 M2 撞车的情形仅凭到达顺序就产出唯一正确配对而注释提到早期的纯时间戳守卫在这个场景下会产生 5 个跨会话假配对。±8 计数器漂移Nonce 纠错位是无条件写进哈希行的为什么AP 重传让供体计数器跳变的捕获里配对即使成功哈希行本身也可能被 hashcat 拒——-m 22000的 Nonce Error Correction 只在 message_pair 字段的高位0x80被置起时才开启不置位时 hashcat 要求 ANonce 与重放计数器逐字节精确。wifit3 的策略与 hcxpcapngtool 的--nonce-error-corrections 8一致分两处生效配对端_NC_MAX 8handshake.py供体计数器偏差 ≤ 8 才进入候选rcgap _NC_MAX直接 continuehandshake.py 第 300–302 行输出端message_pair 恒为pair_byte | _NC_BIT_NC_BIT 0x80handshake.py即 NC 位无条件置起handshake.py 第 334–337 行注释解释了为什么默认开。代价是 hashcat 对每条 wifit3 产出的行都会跑一小段 nonce 漂移穷举即使配对本来就精确。这是刻意取舍候选排序保证 rcgap 0 的精确配对永远优先排序键的第一位NC 位只是兜底保险保证损耗场景下哈希行依然有效而不是靠侥幸配对成功。M2 关键帧为什么 MIC 帧只能是 M2或极少数 M4hashcat-m 22000的破解动作是猜密码 → PBKDF2-HMAC-SHA14096 轮派生 PMK → 用 ANonce SNonce 双端 MAC 派生 PTK → 对被 MIC 保护的那段 EAPOL 原文重算 MIC 比对模块注释见 handshake.py 第 7–33 行。它从 MIC 帧内部读回 SNonce所以 MIC 帧必须自身携带 SNonce——M3 的 nonce 是 ANonceM1 没有 MIC两者都当不了 MIC 帧M4 只有客户端没把 nonce 清零时才行。因此一个帧要当 MIC 帧必须同时满足三条_mic_frame_usable非零 16 字节 MIC、802.1X 载荷 ≥ 97 字节_MIC_OFFSET _MIC_LEN截断帧在此判废、非零 32 字节 nonce。message_pair 字节按 hashcat 的 MESSAGEPAIR 表取handshake.py 第 50–54 行0x00 M1M2、0x02 M2M3 恒定可破0x05 M3M4、0x01 M1M4 仅在 M4 nonce 非零时成立EAPOL 取自 M3 的 0x03/0x04 被 hashcat 标记 unusedwifit3 从不输出。怎么自查配对逻辑真的按预期在工作吗最小路径是一条不需要硬件的单元测试命令配对层是纯数据类逻辑python -m pytest tests/crack/test_wpa_handshake.py -q三个断言点逐一对应上面的机制基线配对——test_m1_m2_crackabletests/crack/test_wpa_handshake.py 第 37–43 行M1M2 恰好产出一个 pairpair_byte 0x00NC 容差生效——test_replay_gap_within_nc_pairstests/crack/test_wpa_handshake.py 第 69–76 行M2 计数器 5、M3 计数器 9预期 6偏差 3 ≤ 8依然配出对紧接着的test_replay_gap_beyond_nc_not_pairs第 79–82 行验证偏差 14 8 时返回空——边界两侧各有一个用例钉住阈值 8哈希行形态——test_hc22000_line_shapetests/crack/test_wpa_handshake.py 第 411–419 行第 3 字段是 M2 的 MIC第 6 字段是 ANonce64 个 hex 字符第 8 字段恰为800x00 | 0x80。有了真实捕获文件后做出口侧验证打开保存出的.hc22000文件找WPA*02*行确认第 8 字段两位 hex 的高位 nibble 恒为8NC 位第 7 字段EAPOL 原文按 hex 解码后偏移 81 起的 16 字节必须全零——hc22000_line在 handshake.py 第 338–339 行显式把 MIC 段覆写为零值再编码hashcat 靠这段MIC 置零的原文重算比对。两个特征都在这条行就是 wifit3 配对算法的产物而非手工拼接。不覆盖的场景与排查方向四类抓到了但不出行的边界各有明确表象SAE / EAP / OWE / FTPMK 不由口令派生SAE 走 ECDH 交换、EAP 的 PMK 来自 802.1X MSK、OWE 无密码、FT-PSK 没有对应的-m 22000模式crackable_pairs在 handshake.py 的 AKM 闸门直接返回空。AKM 族常量在 handshake.py 第 100–107 行_SAE_AKMS {8, 9, 24, 25}、_EAP_AKMS {1, 3, 5, 11, 12, 13}、_OWE_AKMS {18}、_FT_PSK_AKMS {4, 19}。表象是横幅标 SAE / EAP/Enterprise / OWE / FTuncrackable_labelhandshake.py而不是静默丢弃。过渡模式 AP同时提供 PSKSAE下只有协商了 PSK 的那个实例出行SAE 实例保留徽章行为由test_transition_ap_psk_client_is_crackable与test_sae_only_ap_suppresses_handshake钉住tests/crack/test_wpa_handshake.py 第 189–213 行。排查方向看 AP beacon 的 RSN IE 里 AKM 列表纯 SAE 网络没有-m 22000路径这不是配对失败。无时间戳的旧 pcap时间检查被跳过不是 bug是刻意豁免handshake.py。表象是无明显报错但跨关联帧可能进入候选——此时绑定全靠计数器规则 到达顺序。排查时确认回放工具是否保留了逐帧时间戳没有的话用test_reconnect_spam_does_not_cross_pair的场景理解顺序层如何兜底。计数器漂移 8rcgap _NC_MAX的供体被直接 continuehandshake.py不配对、不出行、无日志。表象是四帧都在但横幅不亮。往哪查对比 M1/M3 与 M2 的重放计数器字段差值过 8 说明中间丢了多个重传实例NC 纠错覆盖不了这个量级只能等下一次握手的完整实例。截断的 M2802.1X 载荷没传完整弱信号截断eapol_complete为 False该 M2 被_mic_frame_usable判废——测试用例test_clipped_m2_is_not_crackabletests/crack/test_wpa_handshake.py 第 54–58 行复刻的正是捕获丢失的真实形态。解析器对截断帧是尽力而为返回残缺EapolPacketparser.py 第 203–207 行文档说明而不是丢弃判废统一交给配对层这样横幅、判定、保存三处看到的仍是同一套事实。常量与阈值速查常量值含义位置_EAPOL_PAIR_WINDOW_S5.0 s两帧时间差上限超限拒绝配对对齐 hcxpcapngtoolEAPOLTIMEOUThandshake.py_NC_MAX8供体重放计数器允许偏差上限handshake.py_NC_BIT0x80message_pair 高位置起后 hashcat 启用 Nonce Error Correctionhandshake.py_MIC_OFFSET81802.1X 载荷内 MIC 起始偏移hashcat 读取位置handshake.py / eapol.py_MIC_LEN/_NONCE_LEN16 / 32MIC 与 Nonce 字节数handshake.py_FULL_EAPOL97可作 MIC 帧的最小 802.1X 载荷长度81 16handshake.pyLLC_SNAP_EAPOLAA AA 03 00 00 00 88 8ELLC/SNAP EAPOL 以太类型签名eapol.pyMESSAGEPAIR0x00 / 0x01 / 0x02 / 0x05M1M2 / M1M4 / M2M3 / M3M40x03、0x04 从不输出handshake.pyPMK 派生PBKDF2-HMAC-SHA14096 轮口令 → 32 字节 PMKwpa.pyM2 Key Info0x010A组装 M2 帧时的固定标志version 2 pairwise MICwpa.pyAKM 族SAE {8,9,24,25} · FT {4,19} · EAP {1,3,5,11,12,13} · OWE {18}不可-m 22000破解的 00-0F-AC 族集合handshake.py【免费下载链接】wifit3Wifite but USB-only cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考