鸿蒙上Flutter局域网扫描：network_tools适配实战与零信任分析

这周把 Flutter 的 network_tools 三方库在鸿蒙 HarmonyOS 真机上完整跑通了一遍。起因是团队要做一款局域网设备盘点工具需要在 ohos 平台上实现主机发现、端口探测和资产指纹收集本来以为直接引入第三方库就能搞定结果适配过程踩了一串坑。这篇文章就把整个过程和解决思路完整记录下来包括环境搭建、依赖处理、扫描引擎改造、真机调试以及零信任视角下的安全分析实践给同样要在鸿蒙上用 Flutter 做网络探测的开发者做个参考。1. 项目缘起与整体方案选型先说说为什么这个项目会落到“鸿蒙 Flutter network_tools”这个组合上。我们当时的目标很明确做一款局域网网络资产盘点工具要能自动发现同一 Wi-Fi 下所有在线设备扫描常见端口识别出设备类型和服务指纹最终交给安全团队做内部风险审计。这在 PC 端有成熟方案但移动端尤其是鸿蒙原生生态里可用的开源库还比较零散。1.1 为什么偏偏选 network_tools对比了几个方案之后我们锁定了 network_tools 这个 Flutter 库。它最核心的价值在于不需要依赖 nmap 二进制或者系统 shell 命令而是用纯 Dart 实现了局域网扫描能力。这个库主要提供四类能力主机发现通过 Ping 或 ARP 探测网段内存活主机端口扫描对指定 IP 或主机列表批量检测开放端口主机名解析通过反向 DNS 获取设备名称连通性检测判断设备是否在线、网络是否可用相比自己从头写 ICMP 报文、处理 ARP 缓存表、管理 Socket 连接池直接基于这个库开发可以省掉大量底层工作。而且它对 Android / iOS / Windows / Linux / macOS 都做了兼容理论上只要鸿蒙的 Flutter 引擎能跑 dart:io 里的 Socket就有机会复用它。团队内部也讨论过要不要用 FFI 调 hilog、或者直接用鸿蒙原生网络框架实现探测但结论是原生方案的工程量至少多一倍而且后续要维护两套核心逻辑不划算。network_tools 本身是业务无关的工具库没有复杂的原生插件依赖这给鸿蒙适配留下了很大空间。1.2 鸿蒙平台给网络探测设了哪些关卡真正动手之后才发现鸿蒙和安卓的网络行为差别不是“改几行代码”就能抹平的。最直接的问题集中在三块。第一是权限模型。鸿蒙对敏感权限的管控比安卓更细而且不同 API 版本对同一种网络行为的要求不一样。单纯声明普通网络权限还不够如果要读取 Wi-Fi 状态、获取设备热点信息可能还要申请定位权限因为系统会认为 Wi-Fi 信息涉及位置隐私。第二是 Socket 行为的差异。dart:io 的 Socket 在 ohos 上要经过鸿蒙网络栈的转发实际表现和安卓上并不完全一致。我们遇到最典型的情况是同一段代码在同一网段下安卓能正常扫描出设备鸿蒙上面会频繁报SocketException: Connection refused排查之后才发现是对端设备响应过快时鸿蒙侧的处理时序有问题后面细说。第三是后台运行限制。鸿蒙对应用在后台进行长时间网络操作的管束很严扫描这种持续时间动辄几十秒甚至几分钟的任务很容易被系统挂起或者直接杀掉。真机上跑的时候锁屏几秒钟再解锁扫描进度往往就丢了。这些限制决定了我们不能简单地把安卓上的扫描逻辑原封不动搬到鸿蒙上必须针对 ohos 的运行机制重新做适配层。1.3 零信任局域网分析的总体设计“零信任”这个词在安全圈已经快被说烂了但放在局域网资产盘点的场景里它是靠谱的默认不要信任任何内网设备所有接入网络的终端、IoT 设备、打印机都可能是风险点必须先被识别出来。基于这个思路我们把整个工具拆成了四层结构层级职责对应组件采集层主机发现、端口探测、Banner 获取network_tools 自研改造识别层设备类型判断、服务指纹匹配规则引擎 指纹库分析层风险端口汇总、异常设备标记自研分析逻辑展示层资产列表、扫描报告Flutter UI 界面network_tools 只负责把“采集层”的原始数据拿到后面三层都需要我们自己补齐。特别是设备识别仅靠端口号推断远远不够比如一台打印机可能同时开了 80、443、9100 端口需要结合 Banner 内容才能判断真实身份。2. 开发环境搭建与依赖适配鸿蒙上做 Flutter 开发环境搭建和安卓不太一样。社区里很多文章写到“配置一下就行”实际操作下来坑点不少这一节把完整流程和踩坑记录都列出来。2.1 搭建鸿蒙 Flutter 开发环境首先要明确一点目前官方 Flutter SDK 还不直接支持鸿蒙设备需要用 OpenHarmony SIG 维护的 flutter_flutter 分支。这个分支专门为 ohos 平台做适配支持通过 Flutter ENGINE 在鸿蒙设备上运行 Dart 代码。具体步骤如下安装 DevEco Studio 和 HarmonyOS SDK这个不做赘述官方文档很全。用 git clone 拉取 OpenHarmony SIG 的 flutter_flutter 仓库并切换到适配鸿蒙的 release 分支。配置 Flutter 环境变量执行flutter doctor确认能识别到 ohos 设备。在 DevEco Studio 里打开 Flutter 工程的 harmony 目录等待 Gradle 同步完成。这里最容易出问题的是版本匹配。DevEco Studio 的 API 版本、flutter_flutter 分支版本、ohos SDK 版本必须对得上我们当时用了 API 9 的 SDK配合对应的 flutter_flutter 分支跑起来没问题升级到 API 10 之后旧分支直接编译报错不得不重新切分支。注意鸿蒙真机调试比安卓多一步。安卓通过 adb 连接设备鸿蒙是通过 hdc 连接。执行hdc list targets能看到设备如果看不到先检查 USB 调试是否打开以及电脑和设备是不是在同一局域网内。2.2 把 network_tools 引入鸿蒙工程network_tools 本身是很轻量的 Dart 包没有强依赖的原生插件所以引入过程不算复杂。在 pubspec.yaml 里加上依赖然后执行flutter pub get就行。dependencies: flutter: sdk: flutter network_tools: ^3.4.2 permission_handler: ^10.0.2但这里有一个隐藏问题network_tools 内部依赖了一些常见的 Dart 基础包比如meta、collection、path这些包的版本如果和 Flutter 鸿蒙分支锁定的版本不一致pub get就会报版本冲突。我们当时就遇到了path包版本冲突处理方式是加依赖覆盖dependency_overrides: path: ^1.8.3 collection: ^1.17.0另外network_tools 在 Android 平台上为了获取 ARP 表会通过 MethodChannel 调用原生代码但鸿蒙分支的 Flutter 引擎对 MethodChannel 的支持已经比较成熟这部分不需要改。真正麻烦的是network_tools 源码里有些地方直接用了dart:io的InternetAddress和RawSocket鸿蒙的 socket 行为差异会在这里暴露出来后面第 4 节会重点讲。2.3 权限声明与网络访问配置鸿蒙的权限声明位置在module.json5文件里不像安卓那样是 AndroidManifest.xml。做网络扫描必须申请以下几个权限{ module: { requestPermissions: [ { name: ohos.permission.INTERNET }, { name: ohos.permission.GET_NETWORK_INFO }, { name: ohos.permission.ACCESS_WIFI_STATE }, { name: ohos.permission.APPROXIMATELY_LOCATION }, { name: ohos.permission.LOCATION } ] } }为什么要申请定位权限因为鸿蒙把 Wi-Fi 扫描、Wi-Fi 状态读取归入了位置信息相关的敏感权限。如果你不申请调用NetworkTools.connectedHosts时可能得到的设备列表是空的而且不报任何明确错误排查起来特别坑。注意鸿蒙 10 之前的 API 版本里ohos.permission.LOCATION是精准定位ohos.permission.APPROXIMATELY_LOCATION是模糊定位。如果同时声明了两个系统只弹一次授权框用户可以选择“模糊定位”或“精确定位”网络扫描这种场景模糊定位就足够了。Android 上你用 permission_handler 库可以在运行时弹窗请求权限鸿蒙这套流程也适用但需要注意适配——鸿蒙的权限弹窗文案、授权结果回调时机和安卓略有差异建议真机多测几轮。3. 核心功能实现从端口扫描到网络资产识别这一节是全文最重要的部分。我会把主机发现、端口扫描、服务识别三个核心模块的实现细节拆开讲包含代码示例、参数配置和设计思路。3.1 主机存活探测让设备“现身”主机发现是整条链路的起点。network_tools 提供了现成的connectedHosts方法用法如下import package:network_tools/network_tools.dart; FutureListHost discoverHosts() async { try { final hosts await NetworkTools.connectedHosts( 192.168.1.0/24, useArp: true, timeout: Duration(milliseconds: 3000), ); return hosts; } catch (e) { print(Discovery error: $e); return []; } }这里的useArp参数很关键。设为 true 表示用 ARP 协议探测主机速度快但需要系统网络栈提供 ARP 缓存表鸿蒙上必须配合 Wi-Fi 权限使用。设为 false 则退化为发 ICMP Ping兼容性更好但速度慢而且某些设备会禁 Ping。实际测试中我们发现在鸿蒙真机上useArp: true的表现不稳定经常漏掉设备。排查后发现network_tools 底层是通过解析系统 ARP 缓存文件来完成的这个路径在鸿蒙上不存在。我们的改造方案是放弃useArp改用 Ping 扫描为主然后对扫描到的设备再做一次端口探测用openPorts结果来校验设备是否真的在线。这样虽然多了几步请求但结果更可靠。FutureListHost robustHostDiscovery() async { final subnet 192.168.1; final onlineIps String[]; for (var i 1; i 254; i) { final ip $subnet.$i; final result await NetworkTools.pingHost(ip, count: 1, timeout: Duration(milliseconds: 800)); if (result.isSuccess) { onlineIps.add(ip); } } return onlineIps.map((ip) Host(ip: ip)).toList(); }254 个地址逐个 Ping串行跑会非常慢必须做并发控制。我们用的是 Dart 的Future.wait配合信号量保证同一时间最多 64 个 Ping 在跑实测一个 /24 网段大概 10 到 15 秒能完成一轮扫描。3.2 端口扫描引擎平稳跑完整个网段主机发现确认了哪些设备在线端口扫描则要进一步看出每台设备开了哪些口子。network_tools 提供了openPorts方法底层是 TCP connect 扫描核心逻辑就是尝试与目标 IP 的指定端口建立 TCP 连接连接成功说明端口开放连接被拒说明端口关闭超时则说明端口可能被防火墙过滤。FuturePortScanResult scanPortsForHost(String ip) async { const portsToScan [21, 22, 23, 25, 53, 80, 110, 135, 139, 143, 443, 445, 993, 995, 1433, 1521, 1723, 3306, 3389, 5432, 5900, 6379, 7001, 8080, 8443, 9000, 9200, 10051, 11211, 27017, 50070]; try { final openPorts await NetworkTools.openPorts( ip, ports: portsToScan, timeout: Duration(milliseconds: 2000), ); return PortScanResult(ip: ip, openPorts: openPorts); } catch (e) { return PortScanResult(ip: ip, openPorts: []); } }这段代码最大的问题是如果对每台在线设备都跑 30 多个端口网段里设备一多耗时和超时数量都会爆炸。我们的做法是把扫描任务拆成“两级调度”第一级设备级别并发同一时间最多 16 台设备同时扫第二级端口级别并发每台设备内部最多 20 个端口同时探测端口超时时间也要根据实际网络质量调整。网络状况好的时候 500 毫秒就够复杂的办公网络建议 2 秒否则容易误报。timeout 设太短路由器上有 QOS 限制时很多端口会漏报设太长整个扫描周期会拉到几分钟。提示影响扫描效率的最主要因素不是扫描速度而是超时等待。遇到不响应的端口最坏情况要等完整个 timeout。建议把端口列表按“常见高危端口”和“完整服务端口”拆开先用前者快速摸底再按需补扫。3.3 服务识别与资产指纹光知道端口开放还不够我们必须弄清楚端口背后跑的是什么服务。比如一台设备同时开了 80 和 443可能是路由器管理后台也可能是一台 Web 服务器开了 22 大概率是 SSH但具体是 OpenSSH 还是 dropbear安全等级完全不一样。Banner 抓取是实现服务识别最直接的方法。原理是对开放端口建立 TCP 连接发送一段探测数据比如 HTTP 场景下发GET / HTTP/1.0\r\n然后读取对端返回的响应头根据响应特征判断服务类型。我们用 Dart 的RawSocket手动实现了一个简易 Banner 抓取FutureString? grabBanner(String ip, int port) async { final socket await RawSocket.connect(ip, port); socket.timeout const Duration(seconds: 3); socket.write([0x47, 0x45, 0x54, 0x20, 0x2f, 0x20, 0x48, 0x54, 0x54, 0x50, 0x2f, 0x31, 0x2e, 0x30, 0x0d, 0x0a, 0x0d, 0x0a]); // GET / HTTP/1.0\r\n\r\n await socket.flush(); final response await socket.timeout(const Duration(seconds: 3)).first; socket.destroy(); if (response null) return null; return String.fromCharCodes(response); }拿到 Banner 之后可以按关键词做指纹匹配。比如包含 “SSH-2.0-OpenSSH” → OpenSSH 服务包含 “Server: nginx” → Nginx Web 服务器包含 “Microsoft-HTTPAPI” → Windows 系统服务包含 “TP-Link” → TP-Link 路由器管理界面我们把指纹规则做成了 YAML 配置文件方便安全团队持续扩充规则库。指纹匹配并不追求 100% 准确只要能给分析师提供参考依据效率已经比纯看端口列表高很多。4. 适配过程中的坑与排查实录任何跨平台适配都不可能一帆风顺这一节把我们在鸿蒙真机上遇到的几个典型问题逐一拆解包括问题现象、根因分析、解决方案和最终效果。4.1 Socket 行为差异Connection refused 频繁误报问题现象扫描局域网内一台树莓派22 端口明明是开放的但鸿蒙真机上跑openPorts总报SocketException: Connection refused同一段代码在安卓模拟器和 iPhone 上都能正确识别。排查过程先用配套的日志工具确认目标端口确实可达再用nc命令从电脑上测试也没问题说明问题出在鸿蒙侧代码。后来我们单独写了一个最小化测试工程用Socket.connect反复连同一个端口发现一个规律前 10 次连接大概有 2 次失败失败集中在系统刚完成一次网络切换之后。根因分析鸿蒙的网络栈在 Wi-Fi 和蜂窝网络切换时需要时间重建立路由表这个窗口期内的连接请求会被直接丢弃。network_tools 内部的超时判断逻辑把“连接被丢弃”的错误当成“连接被拒绝”处理了导致误报。解决方案在openPorts调用外层加了一层重试机制对“连接被拒”和“超时”的结果不立即采信而是做一次二次探测Futurebool checkPortOnce(String ip, int port) async { try { final result await NetworkTools.isOpenPort(ip, port, timeout: const Duration(milliseconds: 1500)); return result; } catch (_) { return false; } } Futurebool checkPortWithRetry(String ip, int port) async { for (var i 0; i 3; i) { if (await checkPortOnce(ip, port)) return true; await Future.delayed(Duration(milliseconds: 200)); } return false; }实测加上重试后误报率从 12% 降到了 1% 以下扫描周期增加了大概 15%这个代价可以接受。4.2 并发过高导致的内存溢出和崩溃问题现象第一版我们贪图速度直接把设备并发数调到 32端口并发数调到 50。跑了一会儿应用直接崩溃日志里出现大量Out of Memory和Too many open files错误。根因分析网络扫描本质上是一个高并发 IO 任务每个 Socket 连接都有自己的文件描述符和缓冲区。鸿蒙对单进程的文件描述符数量限制比安卓严格超过一定数量后新连接直接拒绝服务而且 Dart 侧的错误处理没接住异常一路冒泡到 Flutter 引擎就崩了。解决方案把并发放到了两层调度器里统一管理用的是 Dart 的pool包final devicePool Pool(16); final portPool Pool(20); Futurevoid scanAll() async { await for (final ip in onlineIps.stream) { devicePool.withResource(() async { await portPool.withResource(() async { await scanPortsForHost(ip); }); }); } }同时在关键环节加了try-catch保证单个端口扫描失败不会影响整个任务队列。调优之后稳定性明显提升连续跑 5 轮完整网段扫描没有出现崩溃。注意并发数不是越大越好关键看设备硬件和系统限制。鸿蒙真机上稳妥的参考值是——设备并发 16 以内、端口并发 20 以内。如果你要扫的网段很大优先考虑缩小范围分块扫而不是无限加大并发。4.3 锁屏和后台限制导致扫描中断问题现象真机连接调试线启动扫描大概 20 秒后手动锁屏再解锁发现扫描进度条停了日志显示进程被系统冻结。根因分析鸿蒙对后台任务的管束体现在两个层面一个是 CPU 限制一个是网络访问限制。应用进入后台之后如果长时间没有用户交互系统会逐步对网络请求做限速最后完全冻结应用进程。解决方案这个问题没有完美的解法只能在产品设计层规避。我们的做法是在扫描前弹出确认框提示用户“扫描期间请保持屏幕常亮”同时用wakelock_plus插件在扫描过程中持有唤醒锁import package:wakelock_plus/wakelock_plus.dart; Futurevoid startScanWithWakeLock() async { await WakelockPlus.enable(); try { await scanAll(); } finally { await WakelockPlus.disable(); } }如果扫描任务要作为后台服务长期运行更可靠的办法是把扫描逻辑放进鸿蒙的 WorkScheduler 扩展里但这需要写原生代码我们暂时没有走这条路径。5. 零信任视角下的局域网安全分析实践工具跑通只是第一步真正有价值的在于怎么用扫描结果支撑安全决策。拿零信任的思路来看内网所有设备都是“不可信”的只有被识别、被纳入管理、被持续监控才有资格进入可信域。5.1 资产盘点案例发现三台未知设备我们用这套工具在一家合作的创业公司做了一次实测。办公区同一 Wi-Fi 下有 50 多台设备网络资产盘点完成后结果分了三类已知设备员工笔记本电脑、手机、公司打印机、会议室投屏设备半已知设备访客手机、临时接入的开发板完全未知设备两台 IP 摄像头和一个路由器系统里没有登记过这两台摄像头和路由器就是典型的风险点。它们的共同特征是开了 80 端口的 Web 管理界面而且 Banner 指纹显示固件版本非常老旧存在已知漏洞。在零信任框架下这类设备不该出现在办公网的核心网段应该被划入隔离区或者直接下线。扫描结果还能画出每台设备的“暴露面清单”。比如一台打印机除了打印端口 9100 之外还意外开着 445 端口——这是 SMB 文件共享端口打印机根本不需要大概率是出厂默认配置没改需要禁用。5.2 从扫描结果到加固建议拿到资产和暴露面数据后最终输出给客户的不应该是“哪些端口开着”这种原始报告而是一套可执行的加固建议。我们结合零信任的落地原则总结了以下几类常见问题和对应动作风险类型扫描特征建议动作不必要的高危端口445、3389、23 等端口开放确认业务需求无必要则关闭或改成白名单访问默认凭据未改设备 Banner 显示默认固件常见端口暴露更换强口令、升级固件未知设备接入扫描出未登记的 IP/MAC 设备禁止接入核心网段启用 MAC 白名单内网服务过度暴露内网 IP 上运行数据库、管理后台限制源 IP增加认证和加密这个环节需要特别强调合规问题。网络扫描工具本身没有善恶但使用场景必须有边界。我们给客户做的所有扫描都提前获得了书面授权且限制在客户自有资产范围内操作。文章里分享的代码和思路仅适合用于你自己的网络、公司分配的测试环境或者经过明确授权的渗透测试项目中不对未授权目标发起任何形式的探测。5.3 把探测能力固化到日常安全运营这次的适配项目不仅是“跑通了一个库”更重要的意义在于我们把局域网探测能力固化成了可复用的安全运营工具。之前安全团队做资产梳理靠的是人工填报 Excel效率低还经常漏项现在可以定时触发扫描任务把扫描结果自动同步到资产台账系统发现新增设备或新开放端口时自动告警。比如我们可以每天凌晨 3 点跑一次全量扫描生成当日的资产列表。如果某个非工作时段出现一台新设备的 22 端口开放系统就会标记为异常事件推送给安全工程师复核。这个思路正是零信任强调的“持续验证”——资产状态不是一成不变的需要动态监控。我们也试过把扫描能力接入到内部告警平台做法很简单扫描结果转成 JSON 之后 POST 到 Webhook 地址。这样做虽然谈不上多智能但已经把人工巡检的重复劳动省掉了大半团队可以把精力放在真正需要人判断的风险事件上。最后再分享一点实际操作层面的心得鸿蒙生态的 Flutter 适配目前还在快速演进阶段依赖版本、SDK 版本经常变动做这类项目一定要把环境版本固定下来并写清楚 README。我们当时就因为一次 SDK 升级导致整个构建链断掉花了大半天才重新对齐。另外network_tools 这类工具库的源码不算复杂遇到平台差异问题直接读源码定位往往比在社区里翻旧 issue 更高效。如果你也在鸿蒙上做网络探测相关功能希望这份实录能帮你少走几步弯路。