大一学生掌控科罗拉多矿业学院投影仪和摄像头，扫描技术揭秘与问题修复情况曝光
在科罗拉多矿业学院开启大一生活时，我发现当地 DNS 服务器会为每个连网设备分配子域名，如 “meow” 设备在校园无线网络显示为 “meow.mines.edu”，但网络会屏蔽所有流量。这让我思考能否借此追踪网络设备。
主要问题解决方式
主要问题是访问将特定子域名指向特定 IP 的底层 DNS 记录，可通过以下方式解决：
区域传输
这或许是最简单的方法，但学校 IT 部门大概率不会轻易为我进行区域传输（他们也确实不应随意为他人做）。而且网络有新设备加入或移除时，我的列表不会自动更新，这样做也没什么乐趣。
证书
许多子域名会注册证书确保数据来源准确（如 TLS、HTTPS 证书），这些证书会被添加到只追加的账本或日志，像 Let's Encrypt 的 CT 日志。可我不明白学校为何要为连入无线网络的每个设备都注册 TLS 证书，毕竟这些设备无法从互联网访问。
暴力破解
这是我想到的最后一种方法，也是本文重点。有几种实现方式，如搜索所有可能的域名，或用常见主机名字典减少查询次数。就这个项目而言，我不太喜欢用字典的方法，虽现实中更实用，但我对编写快速程序暴力破解所有组合更感兴趣。随着子域名字符长度增加，可能的域名数量呈指数级增长，为 37^n（n 为子域名的字符长度）。
程序开发过程
决定采用暴力破解方法后，我开始行动。先用 Python 写程序深入理解问题，用 `itertools` 库的排列函数生成子域名（这成了性能瓶颈）。我知道程序需采用异步方式，否则会因等待每个 DNS 响应而阻塞。程序有简单的文本用户界面（TUI），但即便异步，速度还是慢，不过能在合理时间内枚举完 3 个字符的子域名。
大约这时，我转向使用 Rust。此前虽了解很多用 Rust 开发的优秀项目，但觉得没必要用它开发。现在 Python 对我来说不够快了。我还开始尝试用 [Helix](https://helix-editor.com/) 这个模态编辑器，很喜欢它。编写 Python 代码时我很少用超出语法高亮功能的编辑器，但 Rust 开发中语言服务器必不可少。
我第一次尝试用 Rust `itertools` 库中的多笛卡尔积函数，很快发现递增整数再转换为 36 进制会快得多。排列线程速度很重要，因为它是唯一需大量 CPU 运算且难并行化的部分。Python 版本中我用相同排列方法生成前缀并分配给线程，Rust 中我不想处理这些，就用 Bash 脚本为程序创建多个进程，告知每个进程总进程数和特定偏移量。每个进程从偏移值开始，将表示 IP 的整数按总进程数递增（而非 1），这样所有进程就能覆盖所有可能的值。
在 Rust 中，我可直接访问处理 DNS 服务器连接的 UDP 端口，读写操作能在不同异步函数中进行。我让读取器在循环中持续运行，直到从套接字读取次数与发送请求次数相同，只打印响应不是 NXDOMAIN（域名不存在）的结果。处理响应很重要，一开始我用 `grep` 过滤域名，它消耗的 CPU 几乎和程序本身一样多。写入器则是将整数转换为 36 进制值，把 DNS 查询写入套接字后退出。
有次我遇到严重内存泄漏问题，进程占用数百 GB 内存。原因是我把每个写入器函数调用添加到列表，等进程结束时等待所有写入器函数退出。为解决问题，我先尝试丢弃句柄，等读取器完成，但仍无法阻止内存泄漏。我认为 Tokio（Rust 的异步库之一）内部的异步栈是泄漏根源，因为我生成查询的速度比执行速度快。解决办法是查询达到一定数量时暂停，等所有查询完成再继续。理想方案是让异步栈大小恒定，但这样虽能提升性能，却需重写大量代码，所以我维持现状。
经过优化，程序最终达到每个 2 线程 200 Mibps 的速度（线程数很重要，我用的服务器最多支持 500 个线程，且只有 96 个核心）。按此速度，480 个线程可达约 50.33 Gbps，但测试的满负荷版本最高只到 4.04 Gbps，实际上我最多只能用 96 个线程（约 10.06 Gbps）。
有次我让 DNS 服务器不堪重负崩溃，导致校园内托管计算机约 15 分钟网络中断，因为计算机无法进行 DNS 查找挂载网络驱动器。之后 IT 部门礼貌要求我停止对 DNS 服务器的大量请求，我照做了。
IT 部门知道是我干的，因为我连续两周都在谈论此事。
新方法与后续行动
现在我获取了很多子域名，但处理 37^n 个查询不现实，我找到了另一种方法：
PTR 记录
这是另一种 DNS 记录，用于将 IP 映射回域名，如将 `10.0.0.0` 映射回 `meow.mines.edu`。这意味着我只需扫描网络中分配的 IP 地址。为此我编写了更简单的 Rust 脚本，为学校拥有的每个域名或网络中的域名发送 DNS 查询。这个方法效果不错，我看到了网络中一些有趣的设备，可惜大多很普通，比如 `computer-precision-tower-5810`。
知道所有计算机信息后，我开始开发端口扫描器。
一开始我用 Tokio 的 `TcpStream` 实现网络连接，简单检查能否连接后关闭。它枚举 /16 子网中的每个 IP 地址，扫描一组端口，每台机器每次只允许扫描约 4000 个端口。这个方法可行，但需大量 CPU 资源，我知道能让它更快。
大约这时，我开始研究 AF_XDP，它是 Linux 内核的一部分，允许创建可绕过内核网络栈的网络套接字（程度不同）。我围绕它编写了名为 `convoy` 的新程序。内核会创建 4 个队列和名为 Umem 的内存区域，用于与网卡驱动程序交互。对 `convoy` 来说，最复杂的交互发生在 Umem、TX 队列和完成队列之间。分配 Umem 后，将数据包写入其中，通过 TX 队列将与数据包对应的偏移量（帧描述）发送给驱动程序。处理完数据包后，驱动程序将偏移量返回给 `convoy`，以便写入更多数据包。
在这个版本中，我采用水平扫描方式：扫描下一个端口前，先扫描所有机器的同一个端口。这样能分散机器（及网络）的并发负载。这个方法效果很好，在免费虚拟机的单核上，每秒可扫描约 30 万个端口，且比之前方法使用的带宽少得多。测试时我一开始以为扫描器有问题，局域网中的设备有响应，而它们本不应如此。我花了很长时间才弄清楚，看到结果很担心。
我尝试通过 RTSP 和设置 RTMP 服务器连接到摄像头流，但没成功。我认为是学校在部分网络中使用了 Palo Alto，我被针对该子网的 RTSP 和 RTMP 的深度数据包检测规则阻止了，也可能是学校防火墙在起作用，但我对学校 IT 部门处理这种情况的能力不太有信心。
我发现能控制 36 个摄像头，就编写 Bash 脚本，通过逆向工程从网页界面获取的 API 与它们交互，命令它们同步移动。
然后，我发现能控制校园内几乎每个房间的投影仪，可切换输入源，还能让屏幕伸缩。
发现这些问题后不久，我就向 IT 部门报告了，因为情况严重，我也不想被讲座摄像头跟踪。他们说会在暑假期间修复，现在看来大部分问题已修复。我被告知，开放这个网段是为实现部分投影仪的无线投屏功能（我只遇到过 2 个真正支持此功能的投影仪）。可惜我没得到任何补偿。
AI 的使用
我曾遇到 Rust 作用域问题，谷歌没给出明确答案，于是用 AI 解决了。
