你有没有想过，一台彻底拔掉网线关闭 WiFi，甚至连手机信号都屏蔽的物理隔离电脑，被植入一枚小小的蓝牙硬件，就有可能在完全离线的状态下，悄悄泄露内部数据？
在很多人的认知里，这种物理隔绝的气隙系统就是数据安全的终极防线，常见于涉密机房、工厂工控系统，几乎不可能从外部访问，内部数据也传不出来。但开源项目 hzgl-air-bridge(HouzuoGuo/hzgl-air-bridge) 给出了一个意料之外的答案。
它借助苹果遍布全球的 Find My 网络，只需要一枚硬币大的 ESP32 蓝牙模块，就能让完全离线的设备悄无声息地把数据传到千里之外，全程不需要设备自身接入任何网络。完整的数据流：气隙电脑→物理连接→ESP32 模块缓存→拆分编码进广播包→周边苹果设备捕获转发→苹果服务器存储→服务端拉取解密→拼接还原原始数据。
要理解这套方案，得先搞清楚苹果 Find My 网络的运行逻辑。
Find My 本来是苹果为自家设备打造的丢失找回功能。哪怕你的 iPhone 或者 AirPods 彻底断网甚至关机，只要附近有其他处于联网状态的苹果设备，这些设备就会通过蓝牙接收到丢失设备发出的 beacon 广播信号，再把对应的位置信息匿名上传到苹果服务器，失主就能在查找应用里看到设备的实时位置。这套网络依靠全球十几亿台苹果设备组成，相当于一张无处不在的低功耗无线传输网络，而且几乎不需要运营成本。
早年间就有安全研究团队破解了 Find My 的广播协议，推出了 openhaystack 和 send-my 等开源项目，能让普通 ESP32 芯片伪装成苹果的丢失设备，借助这套网络免费上报位置。而 hzgl-air-bridge 在这些研究的基础上做了延伸，不仅能传输位置信息，还能把自定义的传感器数据甚至文件片段编码进广播包，通过 Find My 网络完成外传，真正实现了针对气隙系统的数据窃取能力。
FindMy 网络协议研究和信标固件代码。https://github.com/seemoo-lab/openhaystack
FindMy 网络协议研究。https://github.com/positive-security/send-my
项目构成：从硬件到前端的完整链路
整个项目形成了从硬件发射到服务端接收再到前端展示的完整链路，主要分为三个核心模块。
该项目由以下核心部分组成：
ESP32-C3 自定义信标固件：可同时广播位置报告和环境条件数据（如温度、湿度等）。
无需 Apple 设备的 Web 服务器：用于读取 Find My 网络返回的报告。
轻量级 Web 应用：方便存储和查看最近的报告数据。
整个方案基于多个开源项目的研究成果，实现了在完全隔离环境下通过 Apple 生态的全球定位网络进行低调数据传输。
自定义 beacon 固件
这是运行在终端硬件上的核心程序，目前适配 ESP32-C6 芯片，采用 NimBLE 蓝牙协议栈开发，相比旧版 BlueDroid 协议栈社区维护更活跃，对新款 ESP32 系列芯片的兼容性也更好。
固件的核心工作是按照 Find My 协议格式发送蓝牙广播，同时把需要传输的数据拆分后塞进广播包的可用字段。如果外接 BME280 环境传感器，就能实时上报温湿度气压等环境数据，也可以外接 0.96 寸 I2C 屏幕显示运行状态。就算不接任何外设，固件也能正常广播位置信息，只是环境数据会默认返回 0。
服务端对接组件
正常情况下，要读取 Find My 的上报数据，必须用苹果设备登录对应 Apple ID 才行。这个项目借鉴了 macless-haystack 的思路，通过两个服务实现了无需苹果设备也能拉取解密数据。
其中 anisette-v3-server 服务负责模拟苹果设备的身份认证信息，绕过苹果的设备校验机制。air-bridge-ws 服务则负责登录 Apple ID，在账号下注册一台虚拟 MacBook 设备，通过这台虚拟设备拉取所有 beacon 上报的原始报告。两个服务都通过 docker 部署，搭建起来非常方便。
数据还原与前端展示
这部分是用 Go 语言编写的 websvc 工具，负责从本地的 air-bridge-ws 服务拉取原始上报数据，用对应的私钥解密出位置信息和数据片段，再按照序号把零散的片段拼接成完整的可读数据。工具支持把所有报告保存到本地 JSON 文件，同时自带轻量 web 前端，可以通过浏览器直观查看历史上报记录。
完整搭建步骤
要跑通整套系统，一共需要六个核心步骤。
1. 准备 Apple 账号
项目作者不建议使用日常的主账号，最好单独注册一个全新的 Apple ID，并且开启短信二次验证。苹果内部对账号有信任等级评估，新账号先在真实苹果设备上登录使用一段时间，能有效提升信任度，减少后续登录失败或者账号被封禁的概率。
2. 生成上报密钥
进入项目的 provision 目录，运行 genkey.py 脚本，就会自动生成对应的密钥文件，包含位置解密私钥和广播密钥。后续解密位置数据需要用到私钥，而固件广播时会使用公钥衍生出的标识作为广播 ID。
3. 配置并刷写固件
进入 firmware/src 目录，把 custom.h.example 复制一份并重命名为 custom.h，文件里包含了位置广播和数据传输的全部可调参数，可以根据需求修改。需要注意的是，密钥文件里的 hashed adv key 字段在实际运行中不会被用到。
配置完成后，在 VS Code 中安装 PlatformIO 插件，打开 firmware 目录，修改 platformio.ini 里的串口号匹配你的开发板，执行上传操作就能把固件刷写到 ESP32 开发板中。
4. 部署服务端基础设施
首先创建专用的 docker 网络，再分别启动 anisette 和 air-bridge-ws 两个容器。启动 air-bridge-ws 容器时需要使用交互式终端，按照提示输入 Apple 账号密码和二次验证码，服务会自动在账号下注册一台虚拟 MacBook 设备。
如果登录过程中遇到操作无法完成，或者输入验证码后提示密码错误的异常，可以先在浏览器无痕模式下登录appleid.apple.com，在绑定的真实设备上允许登录请求但不要输入验证码，关闭网页后重启容器再重试，一般就能成功登录。
如果需要更换账号或者重新注册虚拟设备，只要删除对应容器和数据卷，重新执行部署流程即可，所有本地保存的账号凭证和设备信息都会被清空。
5. 拉取并还原数据
进入 websvc 目录，通过 go run main.go 启动数据拉取工具，需要传入一系列参数来匹配配置。
其中 days 参数控制拉取多少天内的上报记录，建议保持在 3 天以内，减少对苹果服务器的不必要请求。spreadmins 参数是数据拼接的时间容差，也就是还原完整数据时，允许前后两个数据片段的上报时间间隔多久，默认 20 分钟适合大多数场景，设置过短可能导致数据包无法完整拼接。
除此之外还要传入位置私钥、广播密钥，以及和固件中 custom_magic_key 对应的 base64 值，用来校验和还原自定义数据。工具支持把所有报告保存到本地 JSON 文件，同时可以指定 web 服务地址和端口，开启可视化前端页面。
6. 日常维护
作者建议每隔几周就执行一次重置流程，删除旧的虚拟设备后重新注册部署。如果长期不更新虚拟设备信息，苹果有可能检测到异常并封禁账号。
技术细节与更新动态
这套方案最巧妙的设计，是把数据传输完全隐藏在正常的位置上报流程中。
Find My 广播包本身存在可利用的字段空间，项目把需要传输的完整数据拆分成多个细小片段，每次广播携带一个片段，接收端再根据序号和时间戳把所有片段拼接还原。
因为不同苹果设备上报的时间并不固定，所以才需要 spreadmins 参数来调整拼接的容错范围，提升数据还原成功率。
安全层面，所有广播数据都通过公钥加密，只有持有对应私钥的接收方才能解密内容，苹果服务器本身也无法获取传输的具体数据，这其实也是 Find My 网络原生隐私保护机制的延伸。
项目至今也在持续更新，2026 年初移除了旧的 ESP32-C3 开发环境，把 ESP32-C6 固件全面迁移到 NimBLE 协议栈，提升了兼容性和稳定性。同时修复了短信二次验证的登录问题，补充了登录失败的临时解决方案，整体可用性比早期版本提升很多。整个项目基于 AGPLv3 协议开源，因为衍生自同样采用 AGPLv3 的 openhaystack、send-my，以及 GPLv3 协议的 macless-haystack 项目。
这项技术本身是中性的，合法场景下可以用在无人值守物联网设备的数据回传，比如野外传感器、偏远地区的监测设备，不需要部署 SIM 卡或者有线网络，只要周边有苹果设备就能低功耗传输数据。但如果被滥用于涉密场景，就会对气隙系统的安全造成严重威胁。
当然这套方案也有明显的局限性。
首先传输速率极低，只能传递少量数据，不适合大文件传输。其次高度依赖周边的苹果设备密度，人烟稀少的区域没有足够的苹果设备，数据也就无法上传到苹果服务器。另外苹果随时可能调整协议或者加强异常检测，这类第三方设备随时可能失效，使用的账号也存在被封禁的风险。
hzgl-air-bridge 这类项目的价值，更多在于拓展了我们对网络边界的认知。物理隔离从来都不是绝对的安全屏障，当身边的智能设备密度足够高，完全离线的设备也可能通过意想不到的路径和外界产生连接。对于安全防护来说，了解这类攻击的原理，才能针对性地完善防护方案，比如加强涉密区域的蓝牙信号检测、严格管控外来电子设备，补上物理防护的漏洞。
everyday everynight _______
解答一下星球水友的提问
真的可以传数据吗？可以传，但有明确限制：
能传的：
小体积的自定义数据（当前项目主要实现的是环境传感器数据：温度、湿度、气压等）。
不接 BME280 传感器时，固件会广播 0 作为环境数据，但位置报告依然正常。
通过修改 custom.h 和固件里生成数据的那部分逻辑，理论上可以广播任意小体积自定义数据（例如短文本、状态码、简单传感器读数、甚至把小文件切成极小碎片慢慢传）。
不能高效传的：
大文件、图片、视频等。因为单次广播可用自定义空间极小，必须拆成大量碎片，传输速度极低（可能几小时甚至几天才能传几 KB）。
成功率还受附近 Apple 设备密度、广播间隔、Apple 服务器拉取频率等因素影响。
简单来说，这套方案本质是利用 Find My 的“位置上报外壳”来偷偷夹带小数据载荷，而不是一个通用高速数据通道。它非常适合低速、少量传感器数据或状态外泄，但不适合大容量传输。
从普通用户的视角看，Find My 确实只展示位置信息，但从协议底层和这个项目的实现逻辑来看，位置只是上报内容的一部分，广播包里还藏着可被利用的数据载荷空间，整套方案本质是借位置上报的外壳，把自定义数据偷偷夹带在广播包中透传出来。
苹果 Find My 网络的核心运行逻辑是盲转发。周边路过的苹果设备只会识别这是一个符合 Find My 协议格式的蓝牙 beacon 广播，不会校验广播内容是不是苹果官方设备生成的，也不会深度解析广播包里的具体载荷，只会把完整的广播原始数据，连同当前的位置坐标、上报时间一起匿名上传到苹果服务器。
普通用户打开查找 App 只能看到设备位置，是因为苹果官方的界面只提取和展示位置信息，原始广播载荷并没有对外展示，但它确实完整保存在苹果的上报记录里，用对应密钥拉取原始报告就能完整拿到。
hzgl-air-bridge 正是利用了这个特性。它在构造 Find My 广播包时，除了必要的设备标识字段，还把需要传输的自定义数据比如温湿度数值、文件碎片编码后塞进广播包的可用字节空间，整个广播包依然符合协议规范，在外界看来和普通苹果丢失设备的广播没有区别。
这些携带数据的广播被周边苹果设备捕获后，会连同位置一起上传到苹果服务器。后续服务端拉取报告时，既能拿到每一次上报的位置坐标，也能从每一条报告的原始广播载荷里提取出夹带的数据片段，再根据片段序号、时间容差也就是参数里的 spreadmins 把零散的字节拼接成完整的可读数据。
项目里的 custom_magic_key 参数，就是用来给数据片段做标识校验的，接收端靠这个特征值从大量上报记录里筛选出属于自定义数据的片段，排除无效干扰，确保拼接出来的数据准确。
声明：本文来自黑鸟，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
