重现 Find My 同步流程。 客户端模拟原生 Find My People 的初始化、刷新以及 SubscribeAndFetch 请求,并使用 intent: distributeKeysmode: proactive
在本地解密数据。 加密的 IDS 负载中包含关系标识符和 SearchParty 密钥材料。开源库 pypush 负责推送和 IDS 层的处理,FindMy.py 则查询并解密相应的 Find My 报告,提取坐标、时间戳和定位精度等信息。
这次演示表明,在这条数据路径中,“仅限 Apple 设备”更像是产品策略和客户端实现限制,而不一定是不可替代的硬件加密要求。只要客户端能够提供服务器期待的账户凭据、设备身份、证书、能力声明和网络行为,Apple 服务器就可能将其视为另一个可信接收端。
这并不意味着任何人都能用一台匿名 Linux 电脑查询 Find My。Linux 客户端仍然必须通过 Apple 的账户认证和注册流程,并且只能接收该账户已经获得授权的数据。研究真正揭示的是:在这个场景下,服务器端的信任边界并没有完全绑定到 Apple 制造的硬件上。
这对设备更换和账户同步是实用的:用户新增一台设备时,不必要求每位联系人先停止、再重新开启位置共享。演示中收到的负载包括关系标识符、密钥索引、32 字节的哈希广告密钥,以及一个 85 字节的私钥表示。这些字段表明,Find My 位置报告的解密依赖于与具体共享关系和密钥版本相关的材料,而这些材料可以通过 IDS 重新分发。
不过,公开技术文章展示的是密钥同步和轮换行为,并没有证明 Apple 存在一个对所有场景都适用的固定密钥轮换周期。因此,目前能够确认的是“当前密钥状态如何被传递”,而不是 Apple 完整、公开的密钥管理时间表。
根据 Zerotistic 的说明,客户端不具备以下能力:
所以,这项成果应被理解为一个互操作性与信任边界问题,而不是远程追踪任意陌生人的漏洞。更现实的隐私风险在于 Apple 账户或可信设备遭到控制:如果攻击者接管了账户,或向账户中注册了未经授权的可信设备,那么该账户原本可以看到的位置共享数据就可能暴露。
两项研究针对的是 Find My 的不同部分,威胁模型也完全不同。
Zerotistic 研究的是 Find My People。 它复现的是一个已经存在且获得授权的位置共享关系的接收端。Apple 账户和设备必须获得 Apple 接受,同时联系人必须已经向该账户共享位置。
nRootTag 针对的是 Find My Network 和离线查找。 研究人员报告称,Apple 服务接受了超出预期的多种蓝牙地址类型。利用这一点,攻击者可以让一台支持蓝牙的电脑表现得像 AirTag 一样的追踪信标,再借助附近 Apple 设备中继位置,而不需要目标设备所有者知情或同意。
简单说,Zerotistic 的项目接收的是账户本来就有权限看到的数据;nRootTag 则试图制造未经授权的追踪能力。把两者混为一谈,会让 Linux 演示看起来比现有证据所支持的范围更强大。
Zerotistic 表示,项目最初的动机是基于同意的自动化。朋友已经同意向其 Apple 账户共享位置,于是研究员希望让一台 Linux 系统在本地维护地理围栏,并在对方到达或离开特定地点时,通过 Discord 发送通知。
研究员起初预计,这项工作可能只是调用一个经过认证的网页请求,大约“花一个晚上”就能完成。但实际逆向过程远比预期复杂。现有报道并没有给出完成整个项目所需的准确总时长,因此无法可靠地得出更精确的时间数字。
这项研究留下的核心启示是:把功能限制在某种硬件上,并不自动意味着硬件本身就是安全边界。如果服务器主要根据账户凭据、证书、能力声明和协议行为授予信任,那么只要客户端足够兼容,其他操作系统也可能跨过产品层面的限制——当然,它最终仍会受到账户权限以及合法取得的加密密钥约束。