ESP32实战：DNS劫持与NCSI欺骗实现强制门户-北京尧图网络

几周前我在折腾一个室内定位项目手里捏着一块ESP32开发板本来只想让它当个BLE信标结果一不留神把它连成了“假AP”还顺手把DNS、NCSI、强制门户这一整套机制都摸了一遍。这篇文章就聊聊ESP32到底能不能当一台正经的DNS服务器以及“NCSI欺骗”和“DNS劫持”这两个名词在嵌入式环境里到底是怎么落地实现的。如果你做过公共Wi-Fi认证、设备BSP开发或者对物联网安全感兴趣这篇文章能给你一套可复现的玩法。它解决的核心问题只有一个当用户设备掉进一个“受控网络”时系统如何一步步被引导到我们指定的Web页面读完之后你可以自己搭一个最小化强制门户同时把现代操作系统Windows、Android、iOS的联网检测机制吃透。1. 这个项目到底在做什么——一张“会撒谎”的Wi-Fi1.1 从“ESP32当DNS服务器”说起DNS服务器在大部分人印象里是跑在路由器或者云端的“电话簿”和一块几十块钱的开发板似乎八竿子打不着。但实际上只要硬件有完整的网络协议栈哪怕主频只有240MHz、内存只有320KB处理一个家庭或小型实验室规模的DNS查询也绰绰有余。ESP32和ESP8266都自带完整的TCP/IP协议栈而且Wi-Fi既可以做Station连接外部Wi-Fi也可以做SoftAP自己发射Wi-Fi这为在嵌入式设备上“自建DNS服务器”提供了天然条件。当设备创建了一个SoftAP后连上该AP的客户端设备通常会自动以AP的IP作为DNS服务器。也就是说这个IP一旦被我们控制客户端所有域名解析请求都会送过来。这就是本项目的地基先让ESP的AP成为DHCP和DNS的权威来源再通过DNS响应把客户端的任何域名请求“带偏”到我们想让它去的地方。这个过程在行业内有个直白的名词——DNS劫持。1.2 那么NCSI欺骗又是什么NCSINetwork Connectivity Status Indicator是Windows系统用来判断“当前网络是否真的能访问互联网”的一套检测机制。简单来说Windows连上一个Wi-Fi后并不会只根据“拿到IP地址”就说自己联网成功它还会主动向微软的服务器发送几个探针请求拿到预期响应后才认为“网络通畅”。一旦连上我的ESP APWindows根本不会意识到自己处在局部网络里因为它的域名解析已经被ESP接管了。假如Windows向微软服务器发出探针检测解析出来的目标IP是192.168.4.1也就是ESP自己那么ESP完全可以假装成微软的服务器返回一个“一切正常”的响应。这个行为就叫NCSI欺骗。这里有层很重要的逻辑转折NCSI欺骗并不是让检测失败而是让检测“成功”地把用户留在受控页面里。传统的强制门户是让检测失败让系统弹出“需要登录”的横幅而我们用欺骗之后系统认为网络是正常的用户不会收到任何警告但他实际访问的网站都已经被ESP接管了。区别在于一个是高调的门卫一个是低调的引导员。1.3 这个项目能用在哪儿很多人第一反应是“这不就是个钓鱼路由器么”。确实类似技术被滥用后很危险但它本身是一种非常经典的网络安全教育工具也有正经的工程价值企业或校园Wi-Fi的访客上网认证系统需要让用户自动跳到“同意条款”页面。网络安全教学里演示DNS劫持风险让学员直观感受不校验证书的后果。智能家居调试时临时抓包分析设备在上电后访问了哪些域名。CTF比赛、红蓝对抗演练中的攻击路径还原。所以这不是一个只有恶意黑客才研究的项目反而更像是嵌入式开发者和安全研究者的“基础素养”。关键在于你拿它做实验得清楚边界在哪里。后面我会专门用一节讲合规问题。2. 准备环境和工具2.1 硬件选型ESP32还是ESP8266我手头有ESP32和ESP8266两种板子折腾下来体验是E推荐ESP32ESP8266也能跑但有两个坑。对比项ESP32ESP8266主频240MHz双核160MHz单核SRAM320KB用户可用约240KB160KB用户可用约80KBWeb服务压力轻松处理多个客户端客户端多了容易卡TLS相关扩展可以尝试做简单TLS拦截几乎没有余量稳定性较稳网络中断损耗较高如果你只是演示单客户端连接ESP8266完全能做。但一旦有多台手机、电脑同时连入ESP8266的80端口服务和DNS服务会频繁抢CPU网页加载会明显卡顿。ESP32双核替我省了很多麻烦。2.2 开发环境搭建我的开发环境是VS Code PlatformIO而不是Arduino IDE。不是Arduino IDE不行而是当代码达到两三百行以上多文件组织和编译速度还是PlatformIO更舒服。而且PlatformIO对工程的配置一目了然设置板子型号、烧录口很方便。也可以用Arduino IDE安装好esp32支持包之后直接就能编译。两个环境本质一样的核心其实取决于使用什么SDK/框架。2.3 关键依赖库如果你用Arduino框架核心就三个库WiFi.h负责SoftAP模式、IP配置。DNSServer.h提供轻量DNS服务器能力可以通过通配符方式将所有域名解析到指定IP。WebServer.h负责接收HTTP请求回应不同的页面或内容。这三个库在ESP32的Arduino核心包中都是内置的不需要额外安装第三方库。ESP8266对应的库名也基本一样只是头文件从WiFi.h换成ESP8266WiFi.h。PlatformIO工程下的platformio.ini可以这样写[env:esp32dev] platform espressif32 board esp32dev framework arduino monitor_speed 1152003. DNS劫持的核心原理与实现3.1 一次DNS解析的完整链路客户端要访问example.com时浏览器首先会发起DNS查询。在常规网络中这个查询会发到运营商或公共DNS服务器最后拿回example.com对应的真实IP地址。但在ESP创建的SoftAP里DHCP服务器给客户端分配的DNS地址就是ESP自己的IP一般是192.168.4.1所以DNS查询全部落到ESP身上。ESP里的DNSServer库监听在UDP 53端口收到DNS请求后直接将自己设置的IP作为解析结果返回。这样客户端以为example.com的地址是192.168.4.1于是后续的HTTP请求都会发往ESP。整个过程对客户端来说是透明的它完全不知道真正的example.com并没有被访问到。用生活化的比喻快递员本来要把包裹运往A大厦结果在小区门口被人塞了一张地图地图上写着“A大厦就在这栋楼下”快递员一看确实是这栋楼就把包裹扔进去了完全没意识到真正的A大厦还在两条街外。3.2 用DNSServer库实现通配域名劫持DNSServer库最方便的地方是支持“通配域名”在start方法里用*表示所有域名dnsServer.start(53, *, apIP);这行代码意味着所有域名请求无论是什么都直接返回apIP。这是最快见效的劫持方式也是整个项目最核心的那一行。之后我们只要再跑一个HTTP服务就能根据请求路径决定返回什么内容。这里必须注意一个问题*通配会让所有域名都被解析到本地IP包括系统NCSI检测用的域名。这既是好事也是坏事好处所有流量都汇聚到ESP上。坏处有些系统对DNS解析结果有额外核对逻辑后续我们需要针对部分场景做“精准施策”。3.3 DNS响应中的细节TTL和递归标志用DNSServer库的时候很多时候我们会忽略DNS报文里的TTLTime To Live生存时间字段。客户端操作系统会把DNS解析结果缓存一段时间在TTL过期前不会重新发起查询。这就意味着如果TTL设得太长你修改了劫持规则后客户端要等很久才会生效。如果TTL设为零则客户端每次都要重新查询网络开销大但在调试阶段非常丝滑。ESP的DNSServer库默认TTL并不会写得很长这反而适合做实验。我在调试时经常需要切换“劫持到本地”和“劫持到外部IP”两种模式把客户端网络断开重连就能立刻看到新解析结果。如果你自己实现了DNS响应逻辑记得不要把TTL设成86400这种过长的值否则一旦规则写错排错成本会直线上升。另一个细节是DNS响应里的递归可用标志。很多公共DNS会在响应里把RARecursion Available位置为1表示“我支持递归查询已经帮你查到底了”。ESP这种简易DNS服务器本质上并没有做真正的递归查询它是直接返回一个伪造答案。部分严格的客户端会检查这个标志如果发现不允许递归可能会放弃这个DNS响应。DNSServer库内部会自动处理合理的标志位通常不会有问题但如果遇到玄学不生效可以抓包看看响应报文。3.4 进阶精准控制不同域名的返回结果在实际测试中我发现有些系统尤其是较新版本的Windows会对dns.msftncsi.com这个域名做专门的IP核验。Windows期望这个域名解析到131.107.255.255如果DNS返回的是192.168.4.1它会认为“网络受限”。虽然HTTP层面的NCSI检查往往才是最终判定依据但最好把这一步也做对。DNSServer库默认不支持为不同域名返回不同IP。想实现“只针对部分域名做劫持其他域名放行到真实互联网”有两个方案方案一自己解析DNS报文写得比较底层但灵活。核心思路是在UDP上监听53端口收到查询后解析域名符合条件则返回本地IP否则把包转发给上游真实DNS再将结果转发回去。这样能做到“某些域名被劫持其他域名正常解析”。方案二如果你只想要“劫持到本地”的效果却对dns.msftncsi.com做特殊响应那就需要重写parsePacket逻辑或者在收到DNS查询后先检查域名内容再决定返回什么IP。下面我给出一个简化思路// 伪代码展示你在处理DNS请求时的判断流程 void handleDnsRequest(uint8_t* buffer, size_t len) { String domain extractDomainFromDnsPacket(buffer, len); IPAddress responseIP; if (domain dns.msftncsi.com) { responseIP IPAddress(131, 107, 255, 255); } else { responseIP apIP; } buildDnsResponse(buffer, len, responseIP); }实际上DNSServer库不允许直接在外部进行这样的拦截所以如果你需要完整精准控制就得自己实现DNS服务。我测试时用过这个方案代码量并不大核心是掌握DNS报文格式。但因为这是进阶内容后续无法用默认库时再展开写。注意如果你的目标只是做一个标准强制门户不追求“欺骗已联网”的状态那么通配劫持到本地IP就够了完全不需要精准控制。4. NCSI欺骗的原理与实现4.1 Windows的NCSI检测机制Windows系统自Windows Vista开始引入了NCSI用来判断当前网络是否“已连接Internet”。它的检测逻辑大致分三步DNS查询dns.msftncsi.com期望得到IPv4地址131.107.255.255。向http://www.msftncsi.com/ncsi.txt发送HTTP GET请求期望HTTP状态码200且响应体内容为Microsoft NCSI。在Windows 10/11中还会额外检查http://www.msftconnecttest.com/connecttest.txt期望文本为Microsoft Connect Test。如果三步都符合预期系统就认为当前网络可以正常访问Internet状态栏显示“已连接”。如果HTTP层面的检查失败比如返回了302跳转到其他页面系统会认为当前网络是强制门户弹出“需要登录”的通知。NCSI欺骗的核心就是在HTTP层面让系统误判为“已连接”。我们的ESP在收到/ncsi.txt的GET请求时就返回“Microsoft NCSI”文本收到/connecttest.txt时返回“Microsoft Connect Test”文本。这样Windows就认为网络一切正常不会弹出强制门户提示。4.2 Android和iOS的联网检测机制做这个项目时不能只考虑电脑。手机几乎是现代Wi-Fi使用场景里最主流的终端而Android和iOS的检测逻辑和Windows不同。Android特别是原生的检测逻辑会请求http://connectivitycheck.gstatic.com/generate_204期望HTTP 204状态码同时不返回任何内容体。部分国产ROM还会检查connectivitycheck.platform.hicloud.com/generate_204等域名。如果被解析到本地IP后ESP返回了一个302或者其他非204的内容Android就会判断当前网络需要“登录”弹出门户提示。iOS系统检测captive.apple.com/hotspot-detect.html期望响应内容里包含Success字符串。所以一个“看着像正常网络”的ESP强制门户要同时维护多个“官方探针”的伪响应。我整理了一个表格方便你对照系统检测域名期望响应Windowswww.msftncsi.com/ncsi.txt200 Microsoft NCSIWindows 10/11www.msftconnecttest.com/connecttest.txt200 Microsoft Connect TestAndroidconnectivitycheck.gstatic.com/generate_204204无内容Android部分国产ROMconnectivitycheck.platform.hicloud.com/generate_204204无内容iOScaptive.apple.com/hotspot-detect.htmlSuccess4.3 在ESP上实现多平台“已连接”欺骗一个完整的ESP Web服务器只需要把上面表格中的路径都注册上返回对应的预期内容即可。这样无论Windows还是手机连进来都不会弹“需要登录”但所有HTTP流量最终仍会被引导到本地HTTP服务。这就是“NCSI欺骗”与“DNS劫持”的合体效果。我在实际项目里通常用前三个路径来做兼容webServer.on(/ncsi.txt, HTTP_GET, []() { webServer.send(200, text/plain, Microsoft NCSI); }); webServer.on(/connecttest.txt, HTTP_GET, []() { webServer.send(200, text/plain, Microsoft Connect Test); }); webServer.on(/generate_204, HTTP_GET, []() { webServer.send(204, text/plain, ); }); webServer.on(/hotspot-detect.html, HTTP_GET, []() { webServer.send(200, text/html, Success); });4.4 两种模式欺骗还是触发强制门户在项目里可以设计一个开关用来切换两种工作模式模式ANCSI欺骗模式让系统认为“有网络”不弹提示。用户打开浏览器才看到我们的页面。适合钓鱼体验、隐蔽测试。模式B强制门户模式对NCSI请求返回非预期结果比如302跳转到本地页面系统会弹出“需要在登录后继续使用Wi-Fi”的横幅。适合公共Wi-Fi认证、访客网络。两种模式没有绝对好坏取决于应用场景。做Wi-Fi认证系统时模式B更符合用户预期做隐蔽测试时模式A更合适。代码上模式B只需要把对/ncsi.txt和/connecttest.txt的响应改成redirect(302, http://192.168.4.1/)即可。5. 完整代码与实操记录5.1 工程结构我采用PlatformIO管理工程目录结构如下esp_dns_ap/ ├── platformio.ini └── src/ └── main.cpp5.2 主代码实现下面是可以直接编译烧录的完整代码我加了详细注释。重点看三个部分SoftAP配置、DNS劫持通配解析、Web多路径响应。#include WiFi.h #include DNSServer.h #include WebServer.h // ------- 配置参数 ------- const char* AP_SSID ESP-Portal; const char* AP_PASS 12345678; const IPAddress AP_IP(192, 168, 4, 1); const IPAddress AP_MASK(255, 255, 255, 0); // ------- 组件 ------- DNSServer dnsServer; WebServer webServer(80); // 对非NCSI域名请求统一返回一个测试页面 const String HIJACK_HTML RHTML( !DOCTYPE html html langzh-CN head meta charsetutf-8 title受控网络测试/title /head body h2你已进入受控实验网络/h2 p当前页面由ESP32内置Web服务器返回。/p p这说明DNS劫持已经生效。/p /body /html )HTML; void setup() { Serial.begin(115200); delay(200); // 1. 配置SoftAP WiFi.mode(WIFI_AP); // 固定IP、网关和掩码 WiFi.softAPConfig(AP_IP, AP_IP, AP_MASK); // 开启AP第3个参数是信道第4个参数是隐藏网络第5个参数是最大连接数 WiFi.softAP(AP_SSID, AP_PASS, 1, 0, 8); // 2. DNS劫持所有域名解析到AP_IP dnsServer.start(53, *, AP_IP); // 3. Web服务先处理系统联网检测探针 // Windows webServer.on(/ncsi.txt, HTTP_GET, []() { Serial.println([NCSI] ncsi.txt hit); webServer.send(200, text/plain, Microsoft NCSI); }); webServer.on(/connecttest.txt, HTTP_GET, []() { Serial.println([NCSI] connecttest.txt hit); webServer.send(200, text/plain, Microsoft Connect Test); }); // Android webServer.on(/generate_204, HTTP_GET, []() { Serial.println([Android] generate_204 hit); webServer.send(204, text/plain, ); }); // iOS webServer.on(/hotspot-detect.html, HTTP_GET, []() { Serial.println([iOS] hotspot-detect hit); webServer.send(200, text/html, Success); }); // 4. 其余所有HTTP请求统一返回劫持页面 webServer.onNotFound([]() { String host webServer.hostHeader(); String uri webServer.uri(); Serial.printf([WEB] caught host%s, uri%s\n, host.c_str(), uri.c_str()); webServer.send(200, text/html, HIJACK_HTML); }); webServer.begin(); Serial.println(ESP DNS Hijack AP is running); Serial.print(AP IP: ); Serial.println(AP_IP); } void loop() { // 这两行是整个项目的发动机 dnsServer.processNextRequest(); webServer.handleClient(); }这段代码的流程很清晰客户端连上AP任何域名解析都被定向到192.168.4.1随后它访问某个网站的HTTP请求会打到ESP的80端口。如果请求路径正好是系统联网检测的路径就返回“一切正常”的响应否则就返回一个自定义页面。实际效果是Windows会把ESP的网络判定为“Internet已连接”所以不会弹任何通知。此时用户打开浏览器输入任何网址看到的都是我们定义的HIJACK_HTML页面。5.3 烧录与部署步骤在PlatformIO里选好开发板型号连接USB线点击Upload。打开串口监视器波特率选115200可以看到AP启动日志。手机或电脑搜索名为ESP-Portal的Wi-Fi密码12345678连上。连接成功后先用系统自带浏览器访问任意HTTP网站比如http://example.com观察页面是否被替换为HIJACK_HTML。如果是Windows可以打开命令行执行ping www.msftncsi.com你会发现解析出的IP不是微软服务器的真实地址而是192.168.4.1。我在测试时用一台Windows 11笔记本连接任务栏的Wi-Fi图标确实显示为“已连接Internet访问”而不是“需要登录”。当打开Edge浏览器输入neverssl.com时0.5秒内就被重定向到了本地测试页。5.4 抓包验证想更直观地看整个流程可以开Wireshark抓包。我建议抓三个环节DHCP阶段看客户端是否拿到了192.168.4.x的地址DNS服务器是否为192.168.4.1。DNS查询阶段看全部的DNS查询请求注意请求的域名五花八门但响应里的Answer都是192.168.4.1。HTTP阶段看客户端发起GET请求时请求的Host是否是你的目标域名但响应内容全部来自ESP的Web服务。通过这些包就能把“DNS劫持 Web响应”的完整闭环看清了。6. 常见问题与排查技巧6.1 手机连上之后浏览器不弹窗很多人一开始会把NCSI欺骗和强制门户模式搞混。手机连上后如果系统没有弹“需要登录”这不是程序没跑恰恰说明NCSI欺骗生效了。它把系统判定为“网络已连接”自然不会弹提示。此时你打开手机浏览器手动输入域名访问才会看到劫持页面。如果怎么访问都打不开先检查是否连接的是HTTPS网址。比如直接打开https://www.baidu.com由于ESP的Web服务器只是HTTP服务没有有效的TLS证书HTTPS握手必然失败浏览器会直接报错。解决方法是手动输入http://开头的网址或者使用neverssl.com这类纯HTTP网站测试。6.2 HTTPS网站全都劫持不了这是本项目最大的认知瓶颈。DNS劫持能改的只是域名解析但HTTPS请求在域名解析之后还会经历TLS握手。浏览器会校验证书是否由受信任的CA签发并校验证书域名是否匹配。ESP返回的响应来自一个内置HTTP服务器它并没有www.baidu.com的合法证书。因此浏览器必然终止连接。所以做这个项目时要明确一点DNS劫持拦截的是DNS层真正影响的只是HTTP流量。如果想要劫持HTTPS流量需要配合证书相关能力和中间人技术这部分超出了ESP作为微型设备的常规能力范围。6.3 系统一直显示“无Internet”如果你不特意处理NCSI路径Windows会显示“无Internet访问”然后弹“是否继续连接此Wi-Fi”或者“需要登录”。如果你希望的是强制门户模式那这反而是正确的。但如果你希望实现“无感欺骗”请确保这四个路径都正确返回/ncsi.txt、/connecttest.txt、/generate_204、/hotspot-detect.html。还需要特别检查dns.msftncsi.com的解析结果。个别系统对DNS的核验很严格如果你的DNS劫持把dns.msftncsi.com解析成了192.168.4.1Windows即使在HTTP层面通过了也可能在某段时间内显示“受限”因为它要求这个域名解析到特定IP。针对这个问题的解法就是前面提到的精准DNS控制。6.4 性能与环境注意事项ESP32虽然双核但想要应对大量客户端同时访问时还是会吃力。实测下来单台ESP32带3-5个客户端做HTTP承载没有问题连到10个以上时就可能出现响应变慢、DNS查询丢包。解决方案是改用树莓派这类真ARM板做AP网关ESP32只做挂机的大外设。同时要注意供电ESP32在工作时瞬间电流可能冲到500mA用劣质USB线容易出现掉电重启。另一个环境坑是信道选择。ESP32发射的AP默认信道是1如果你办公室周围信道1也非常拥挤连上后的体验会断断续续。可以在WiFi.softAP调用中指定其他信道比如设成6或11。7. 合规使用与安全边界7.1 合法使用场景这个项目最大的危险就在于它把“让用户无感进入受控页面”变成了一件低成本的事稍微改一改就能变成一个钓鱼页面采集用户输入。所以务必只在下面几类场景里使用自己的实验环境、自己开发的测试网络中。获得明确授权的渗透测试、安全评估项目中。教学课堂里在可控网络环境下演示DNS漏洞。开发访客Wi-Fi接入认证系统让用户访问任意网站时先跳到服务条款页。7.2 绝对不能做的红线在公共场合私自搭建伪装AP诱导公众连接并收集数据这在中国涉及网络安全法、个人信息保护法性质严重。对公司、他人的私有Wi-Fi做未授权嗅探和中间人攻击。将项目改造成钓鱼页面后冒充银行、社交网站等平台骗取账号密码。不要觉得“我只是研究一下技术”一旦你把它部署到真实公共环境并产生实质性影响法律后果远比想象中严重。我在文末专门强调是因为这类帖子很容易被误读成“教人做钓鱼Wi-Fi”实际上它更应该被看作安全穿刺的教材。7.3 后续可以扩展的方向如果你对这个主题感兴趣建议往这些方向延伸NCSI之外加入企业级802.1X认证、Portal认证等正规的无线接入流程。将ESP的Web服务器与外部后端对接实现自定义认证页面把用户确认信息发送到服务器。了解HTTPS的证书链机制理解为什么DNS劫持无法拿下HTTPS从而学会更安全的防护手段。在局域网里用域名拦截做“内容管控”比如屏蔽特定视频网站或游戏服务器这是很多路由器插件已经在做的事情。我自己的体会是折腾完这个项目最大的收获不是“我会写一个DNS劫持了”而是把操作系统的联网检测逻辑、DNS报文结构、HTTP服务的响应时机这些零散知识点串成了一条线。ESP32能做的事远不止读传感器它把很多只有服务器能跑的技术拉到了嵌入式边缘这才是最迷人的地方。

ESP32实战：DNS劫持与NCSI欺骗实现强制门户

相关推荐

WPS在线编辑前端接入实战：Vue + jwps.es6.js调用链解析

Verilog硬件建模本质：从语法到FPGA可综合设计

Plate 编辑器基准实验室：剪贴板超预算（over-budget）调查与证据登记（Evidence Kit）实战解析

更多资讯

C#性能杀手TOP10：你的代码中招了吗？

无刷电机Maxwell仿真建模关键技术与实践指南

硬盘技术实战指南：选型、部署、故障预判与演进

线束工程：复杂系统中的多物理场耦合与优化策略

Abaqus USDFLD实现积分点间材料弹性连续变化详解

雅高第800家酒店为何选常州索菲特？选址与品牌策略解析

今日更新

基于高阶循环谱的MPSK载波频率估计与MATLAB实现

MiniPdf方：.NET开源Office转PDF的高效解决方案

Solon AI v3.10：Java全栈智能体开发框架解析

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？