Linux 客户端是如何完成注册的

Zerotistic 将 Apple 生态中通常对用户不可见的多个环节串联起来：

1. 完成账户认证。 客户端使用 Apple 的 GrandSlam 登录协议，先进行安全远程密码（SRP）交换，再完成双重认证，获得账户标识符以及一个短期有效的密码等价令牌（PET）。

2. 申请设备身份。 Linux 客户端生成 PKCS#10 格式的证书签名请求（CSR），其中包含 2048 位 RSA 密钥，并使用 SHA-1 签名。随后，它将 CSR 发送到 Apple 旧版的 authenticateDS 配置文件注册接口，换取 Apple Identity Services（IDS）证书。

3. 注册 IDS 设备。 凭借该证书及相关设备材料，Linux 可以向 IDS 注册，声明支持的加密类型，订阅所需的消息子服务，并取得 Apple 推送通知服务（APNs）的投递凭据。

4. 重现 Find My 同步流程。 客户端模拟原生 Find My People 的初始化、刷新以及 SubscribeAndFetch 请求，并使用 intent: distributeKeys 和 mode: proactive 参数。随后，Apple 要求已经同意共享位置的联系人设备，通过 IDS 和 APNs 向新注册的身份发送当前的位置密钥材料。

5. 在本地解密数据。 加密的 IDS 负载中包含关系标识符和 SearchParty 密钥材料。开源库 pypush 负责推送和 IDS 层的处理，FindMy.py 则查询并解密相应的 Find My 报告，提取坐标、时间戳和定位精度等信息。

因此，这更准确地说是协议仿真，而不是“破解 Apple 认证”。服务器仍然是在账户认证和设备注册流程完成后，向客户端签发相应凭据。

这说明了什么：信任可能建立在凭据和协议上

这次演示表明，在这条数据路径中，“仅限 Apple 设备”更像是产品策略和客户端实现限制，而不一定是不可替代的硬件加密要求。只要客户端能够提供服务器期待的账户凭据、设备身份、证书、能力声明和网络行为，Apple 服务器就可能将其视为另一个可信接收端。

这并不意味着任何人都能用一台匿名 Linux 电脑查询 Find My。Linux 客户端仍然必须通过 Apple 的账户认证和注册流程，并且只能接收该账户已经获得授权的数据。研究真正揭示的是：在这个场景下，服务器端的信任边界并没有完全绑定到 Apple 制造的硬件上。

IDS 负载揭示了怎样的密钥分发机制

SubscribeAndFetch 的行为显示，当一个新的设备加入已经存在的位置共享关系后，Apple 可以通过 IDS 向该设备分发当前的位置密钥材料。

这对设备更换和账户同步是实用的：用户新增一台设备时，不必要求每位联系人先停止、再重新开启位置共享。演示中收到的负载包括关系标识符、密钥索引、32 字节的哈希广告密钥，以及一个 85 字节的私钥表示。这些字段表明，Find My 位置报告的解密依赖于与具体共享关系和密钥版本相关的材料，而这些材料可以通过 IDS 重新分发。

不过，公开技术文章展示的是密钥同步和轮换行为，并没有证明 Apple 存在一个对所有场景都适用的固定密钥轮换周期。因此，目前能够确认的是“当前密钥状态如何被传递”，而不是 Apple 完整、公开的密钥管理时间表。

Linux 客户端能做什么，不能做什么

测试客户端的功能范围相当窄。它可以读取研究员 Apple 账户已经获准接收的位置共享，并在本地处理这些数据；地理围栏逻辑也在本地运行，而不是调用 Apple 服务器端的 Find My 功能。

根据 Zerotistic 的说明，客户端不具备以下能力：

• 发送新的位置共享邀请；
• 修改现有共享权限；
• 添加家庭成员；
• 创建由 Apple 托管的地理围栏；
• 向设备下发控制指令。

所以，这项成果应被理解为一个互操作性与信任边界问题，而不是远程追踪任意陌生人的漏洞。更现实的隐私风险在于 Apple 账户或可信设备遭到控制：如果攻击者接管了账户，或向账户中注册了未经授权的可信设备，那么该账户原本可以看到的位置共享数据就可能暴露。

与 2025 年 nRootTag 研究有何不同

两项研究针对的是 Find My 的不同部分，威胁模型也完全不同。

Zerotistic 研究的是 Find My People。 它复现的是一个已经存在且获得授权的位置共享关系的接收端。Apple 账户和设备必须获得 Apple 接受，同时联系人必须已经向该账户共享位置。

nRootTag 针对的是 Find My Network 和离线查找。 研究人员报告称，Apple 服务接受了超出预期的多种蓝牙地址类型。利用这一点，攻击者可以让一台支持蓝牙的电脑表现得像 AirTag 一样的追踪信标，再借助附近 Apple 设备中继位置，而不需要目标设备所有者知情或同意。

简单说，Zerotistic 的项目接收的是账户本来就有权限看到的数据；nRootTag 则试图制造未经授权的追踪能力。把两者混为一谈，会让 Linux 演示看起来比现有证据所支持的范围更强大。

最初目标：为 Discord 通知搭建本地地理围栏

Zerotistic 表示，项目最初的动机是基于同意的自动化。朋友已经同意向其 Apple 账户共享位置，于是研究员希望让一台 Linux 系统在本地维护地理围栏，并在对方到达或离开特定地点时，通过 Discord 发送通知。

研究员起初预计，这项工作可能只是调用一个经过认证的网页请求，大约“花一个晚上”就能完成。但实际逆向过程远比预期复杂。现有报道并没有给出完成整个项目所需的准确总时长，因此无法可靠地得出更精确的时间数字。

Apple 是否已经回应

现有引用报道确认了这次演示，但没有提供 Apple 针对该 Linux Find My People 实现的、经过核实的公开回应，也没有确认 Apple 已修复相关问题或向研究员支付漏洞赏金。

这项研究留下的核心启示是：把功能限制在某种硬件上，并不自动意味着硬件本身就是安全边界。如果服务器主要根据账户凭据、证书、能力声明和协议行为授予信任，那么只要客户端足够兼容，其他操作系统也可能跨过产品层面的限制——当然，它最终仍会受到账户权限以及合法取得的加密密钥约束。

Linux 客户端是如何完成注册的

Zerotistic 将 Apple 生态中通常对用户不可见的多个环节串联起来：

1. 完成账户认证。 客户端使用 Apple 的 GrandSlam 登录协议，先进行安全远程密码（SRP）交换，再完成双重认证，获得账户标识符以及一个短期有效的密码等价令牌（PET）。

2. 申请设备身份。 Linux 客户端生成 PKCS#10 格式的证书签名请求（CSR），其中包含 2048 位 RSA 密钥，并使用 SHA-1 签名。随后，它将 CSR 发送到 Apple 旧版的 authenticateDS 配置文件注册接口，换取 Apple Identity Services（IDS）证书。

3. 注册 IDS 设备。 凭借该证书及相关设备材料，Linux 可以向 IDS 注册，声明支持的加密类型，订阅所需的消息子服务，并取得 Apple 推送通知服务（APNs）的投递凭据。

4. 重现 Find My 同步流程。 客户端模拟原生 Find My People 的初始化、刷新以及 SubscribeAndFetch 请求，并使用 intent: distributeKeys 和 mode: proactive 参数。随后，Apple 要求已经同意共享位置的联系人设备，通过 IDS 和 APNs 向新注册的身份发送当前的位置密钥材料。

5. 在本地解密数据。 加密的 IDS 负载中包含关系标识符和 SearchParty 密钥材料。开源库 pypush 负责推送和 IDS 层的处理，FindMy.py 则查询并解密相应的 Find My 报告，提取坐标、时间戳和定位精度等信息。

因此，这更准确地说是协议仿真，而不是“破解 Apple 认证”。服务器仍然是在账户认证和设备注册流程完成后，向客户端签发相应凭据。

这说明了什么：信任可能建立在凭据和协议上

这次演示表明，在这条数据路径中，“仅限 Apple 设备”更像是产品策略和客户端实现限制，而不一定是不可替代的硬件加密要求。只要客户端能够提供服务器期待的账户凭据、设备身份、证书、能力声明和网络行为，Apple 服务器就可能将其视为另一个可信接收端。

这并不意味着任何人都能用一台匿名 Linux 电脑查询 Find My。Linux 客户端仍然必须通过 Apple 的账户认证和注册流程，并且只能接收该账户已经获得授权的数据。研究真正揭示的是：在这个场景下，服务器端的信任边界并没有完全绑定到 Apple 制造的硬件上。

IDS 负载揭示了怎样的密钥分发机制

SubscribeAndFetch 的行为显示，当一个新的设备加入已经存在的位置共享关系后，Apple 可以通过 IDS 向该设备分发当前的位置密钥材料。

这对设备更换和账户同步是实用的：用户新增一台设备时，不必要求每位联系人先停止、再重新开启位置共享。演示中收到的负载包括关系标识符、密钥索引、32 字节的哈希广告密钥，以及一个 85 字节的私钥表示。这些字段表明，Find My 位置报告的解密依赖于与具体共享关系和密钥版本相关的材料，而这些材料可以通过 IDS 重新分发。

不过，公开技术文章展示的是密钥同步和轮换行为，并没有证明 Apple 存在一个对所有场景都适用的固定密钥轮换周期。因此，目前能够确认的是“当前密钥状态如何被传递”，而不是 Apple 完整、公开的密钥管理时间表。

Linux 客户端能做什么，不能做什么

测试客户端的功能范围相当窄。它可以读取研究员 Apple 账户已经获准接收的位置共享，并在本地处理这些数据；地理围栏逻辑也在本地运行，而不是调用 Apple 服务器端的 Find My 功能。

根据 Zerotistic 的说明，客户端不具备以下能力：

• 发送新的位置共享邀请；
• 修改现有共享权限；
• 添加家庭成员；
• 创建由 Apple 托管的地理围栏；
• 向设备下发控制指令。

所以，这项成果应被理解为一个互操作性与信任边界问题，而不是远程追踪任意陌生人的漏洞。更现实的隐私风险在于 Apple 账户或可信设备遭到控制：如果攻击者接管了账户，或向账户中注册了未经授权的可信设备，那么该账户原本可以看到的位置共享数据就可能暴露。

与 2025 年 nRootTag 研究有何不同

两项研究针对的是 Find My 的不同部分，威胁模型也完全不同。

Zerotistic 研究的是 Find My People。 它复现的是一个已经存在且获得授权的位置共享关系的接收端。Apple 账户和设备必须获得 Apple 接受，同时联系人必须已经向该账户共享位置。

nRootTag 针对的是 Find My Network 和离线查找。 研究人员报告称，Apple 服务接受了超出预期的多种蓝牙地址类型。利用这一点，攻击者可以让一台支持蓝牙的电脑表现得像 AirTag 一样的追踪信标，再借助附近 Apple 设备中继位置，而不需要目标设备所有者知情或同意。

简单说，Zerotistic 的项目接收的是账户本来就有权限看到的数据；nRootTag 则试图制造未经授权的追踪能力。把两者混为一谈，会让 Linux 演示看起来比现有证据所支持的范围更强大。

最初目标：为 Discord 通知搭建本地地理围栏

Zerotistic 表示，项目最初的动机是基于同意的自动化。朋友已经同意向其 Apple 账户共享位置，于是研究员希望让一台 Linux 系统在本地维护地理围栏，并在对方到达或离开特定地点时，通过 Discord 发送通知。

研究员起初预计，这项工作可能只是调用一个经过认证的网页请求，大约“花一个晚上”就能完成。但实际逆向过程远比预期复杂。现有报道并没有给出完成整个项目所需的准确总时长，因此无法可靠地得出更精确的时间数字。

Apple 是否已经回应

现有引用报道确认了这次演示，但没有提供 Apple 针对该 Linux Find My People 实现的、经过核实的公开回应，也没有确认 Apple 已修复相关问题或向研究员支付漏洞赏金。

这项研究留下的核心启示是：把功能限制在某种硬件上，并不自动意味着硬件本身就是安全边界。如果服务器主要根据账户凭据、证书、能力声明和协议行为授予信任，那么只要客户端足够兼容，其他操作系统也可能跨过产品层面的限制——当然，它最终仍会受到账户权限以及合法取得的加密密钥约束。