wifit3固件加载全解析：24个厂商固件blob的上传与字节校验

wifit3固件加载全解析：24个厂商固件blob的上传与字节校验

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

wifit3 是一款跨平台、纯 USB 的 Wi-Fi 审计工具（Wifite 的 USB-only 跨平台重写），内置 24 个厂商固件 blob，无需系统内核驱动即可完成网卡固件加载。本文带你完整走一遍固件加载流程：从 USB 复位、FCE 编程、分块 bulk 上传、IVB 触发到 FW_READY 轮询，并解析 MediaTek / Realtek / Ralink / Atheros 四大厂商的差异，以及 wifit3 如何对每个 blob 做字节级校验。

一、24 个固件 blob 清单：谁管哪些芯片

所有固件统一放在各芯片驱动的assets/目录下，随源码、wheel 安装包和 PyInstaller 可执行文件一起分发。总账本见 docs/FIRMWARE.md，按厂商分四组：

两个有意思的细节：

• 一个 blob，两刀切：Ralink 的 4 个固件其实全部来自同一个linux-firmware的rt2870.bin——RT3070 用前 4KB（PCI 半片），RT5370/RT5372/RT5572 用后 4KB（USB 半片），其中rt5370_fw.bin与rt5372_fw.bin逐字节相同。
• 同名陷阱：MT7612U（MT76x2U）加载的是mt7662.bin切出的 ILM/DLM 两段，而不是名字更像的mt7662u.bin——docs/FIRMWARE.md 专门写了这一段，防止 provenance 和 license 记错。

每个 blob 旁边都随附其厂商的LICENCE.*许可证原文，保证"许可证跟着二进制一起走"。

二、固件加载通用五阶段流程

虽然各家协议不同，但 wifit3 的加载器都遵循同一个骨架，以 src/wifit3/chips/mt76x0u/firmware.py 中的load_firmware为例，完整移植了 Linux 内核mt76x0u_load_firmware的 15 步序列：

1. 解析固件头：32 字节头里读出 ILM/DLM 长度、版本号、构建时间，并校验"头长 + ilm_len + dlm_len == 文件总长"，尺寸不符直接拒绝。
2. 芯片冷复位：先做 chip OFF 预清理，再 chip ON + 硬件复位。源码里有一段关键注释：温态芯片必须先做 WLAN_RESET 硬复位，否则后续 bulk 上传会在中途截断。
3. 编程 FCE（前端命令引擎）：写 5 个寄存器（DMA 地址/长度、PDMA 全局配置等），为 bulk 数据通道铺路。
4. 分块上传：固件按固定块大小切片，每块走「控制传输写目标地址 → 写长度 → bulk-OUT 发[4B 头 | 数据 | 4B 零填充]→ 自增描述符索引 → 睡眠 5~10ms」。
5. 触发 IVB 并轮询就绪：发 64 字节 IVB 引导体，之后每 1ms 轮询MT_MCU_COM_REG0的 FW_READY 位，最长 1000ms，读到置位即宣告上传完成。

加载过程还支持进度回调（progress_cb），UI 可以实时显示"ILM 块 12: 49152/58000 字节"这类信息。

三、三大厂商的上传协议差异

3.1 MediaTek：MT7612U 的双阶段加载

MT7612U 最特别：要先打ROM patch，再传主固件（ILM + DLM），见 src/wifit3/chips/mt76x2u/firmware.py。ROM patch 阶段还带一个"幂等检查"——读寄存器发现 patch 已生效就跳过；如果是带蓝牙的组合芯片，还要先抢硬件信号量防止和片上 BT 核打架。主固件传完后轮询 FW 运行位，并额外做一次 RMW "确认握手"。

MT7921AU 则是"ROM patch 先行 + WM RAM blob 随后"的多阶段加载器 src/wifit3/chips/mt7921au/firmware.py，并且用一次芯片 ID 读取顺带探测控制端点是否存活：温态/卡死的芯片读不到 ID，程序会明确提示"请物理拔插冷启动"，而不是反复重试。

3.2 Realtek：内部 DMA 搬运的复杂路径

RTL8822CU 的加载器（src/wifit3/chips/rtl8822cu/firmware.py）完全不走"直接传内存"的路线：先把每 4KB 固件块暂存到保留页（附 48 字节 TX 描述符 + 异或校验和），再启动片内 iDDMA 通道把数据从 TX 缓冲搬进目标内存，搬运完校验CHKSUM_OK位。固件容器本身是 64 字节 HALMAC 头 + DMEM/IMEM/（可选）EMEM 三段，parse_firmware会逐段校验边界，尺寸不匹配直接报错。

3.3 Atheros AR9271：最简单的控制传输流式下载

AR9271 冷启动时根本没有固件，主机通过厂商控制传输（bRequest 0x30）把 blob 按 4KB 一片流入芯片 RAM，wValue 携带addr >> 8的加载地址；传完后发一条 0x31 "complete" 控制写，芯片直接跳到 text 入口执行并重新枚举 USB。整个过程见 src/wifit3/chips/ar9271_v2/firmware.py，只有几十行。

四、字节校验：三重手段保证 blob 没被改过

wifit3 是 GPL-2.0 项目，但 24 个厂商二进制不是GPL——它们按各厂商原始许可证原样再分发。所以每个 blob 出厂前都要过字节级验证，docs/FIRMWARE.md 的表格里每一行都有对应的验证方式，归纳起来是三层：

仓库里还有两道"保险"：

• 运行时防呆：加载器读入资产时校验期望尺寸，例如 MT76x2U 的_load_asset发现mt7662_ilm.bin字节数不符立即抛错（firmware.py）；MT76x0U 则解析 32 字节头做总长校验。
• 测试防丢失：tests/test_firmware_sanity.py 检查关键 blob 存在且大小合理（如 AR9271 固件 > 10KB、MT7921AU RAM 码 > 100KB），防止打包时漏带。

五、合规要点：许可证如何跟随 blob

四份厂商许可证原文（LICENCE.rtlwifi_firmware.txt、LICENCE.mediatek、LICENCE.ralink-firmware.txt、LICENCE.ralink_a_mediatek_company_firmware）与各自 blob 同目录存放，随源码、wheel 和 PyInstaller 包一起走。MediaTek 的许可证措辞是关键依据：固件授予"与含 MediaTek 芯片的设备配套使用"的再分发权，但不能归入 GPL/LGPL——这就是 wifit3 把 blob 当作 bundle 数据、隔离在 GPL-2.0 代码边界之外的上游依据。

规则也写进了文档：任何新增 blob 都必须登记进 docs/FIRMWARE.md，记录来源与逐字节验证结果，流程细则见 docs/porting/METHODOLOGY.md。

总结

• wifit3 内置24 个厂商固件 blob，按 Realtek / MediaTek / Ralink / Atheros 四家分组，统一存放于chips/<chip>/assets/；
• 上传骨架是「冷复位 → FCE 编程 → 分块 bulk 上传 → IVB 触发 → 轮询就绪」，但各家协议差异明显：MediaTek 双阶段、Realtek 内部 DMA、Atheros 控制传输流式下载；
• 每个 blob 都经过哈希、抓包 diff、厂商源码三重字节校验，并有许可证随行、测试兜底；
• 想深入某颗芯片的线级细节，直接看src/wifit3/chips/<chip>/<CHIP>.md的 ground-truth 文档即可。

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