我开发了一个工具，用于分析原始二进制程序（没有ELF、PE或Mach-O头的程序），以确定程序开始的文件偏移量以及程序在内存中映射的加载地址。该工具还可以识别常见平台的指令集架构。我花了很多精力使其尽可能易于使用，并提供了一个快速启动脚本，只需一个参数：原始二进制程序文件的绝对文件路径。
返回首页
一周热榜
我们运营着 ASO.dev，这是一个帮助开发者管理其应用商店元数据和可见性的工具。2025年5月3日，我们遇到了一个严重的问题：“使用 Apple 登录”对所有用户停止正常工作，导致三分之一的用户完全失去访问权限——具体来说，就是那些使用 Apple 私人中继邮箱的用户。
发生了什么？
• Apple 开始为现有的 Apple ID 返回一个全新的 userIdentifier，而用户并未进行任何更改。这实际上使用户身份验证变得不可能，因为我们无法将用户与其现有数据匹配。
• 电子邮件字段现在总是返回 null。虽然这种行为在后续登录中是典型的，但在这种情况下并不相关，因为 userIdentifier 本身发生了变化，导致无法识别现有账户。
• 之前发放的中继邮箱（@privaterelay.appleid.com）不再接收邮件——我们通过退信测试验证了这一点。
• 用户还报告说，我们的应用程序已从他们的 Apple ID 授权应用列表中消失。
重要背景：
• 我们大约一年前将 Apple 开发者账户从个人账户迁移到组织账户。
• 在2025年5月3日的更新之前，一切运作良好。
• 事件发生在 Apple 发布开发者控制台（账户、配置文件等）更新的当天。我们坚信，Apple 的这些内部变更引发了该问题。
后果：
• 每个用户都收到了一个新的 userIdentifier，这意味着我们的系统将回访用户视为全新用户，打破了与他们历史数据的链接。
• 三分之一的用户通过 Apple 的私人中继邮箱注册，现在完全无法联系：
• 我们无法与他们联系（邮件退回）。
• 我们无法恢复他们的访问权限（新 ID 与旧账户不匹配）。
• 我们已通过电子邮件向 Apple 发送了三次支持请求——尚未收到回复或确认，也没有升级途径或在线聊天支持。
——
我们很幸运，因为 ASO.dev 还支持另一种登录方式（使用一次性登录代码的电子邮件）。如果没有这个替代方案，我们将永久失去所有最初通过 Apple 登录的用户的访问权限。
——
我们公开分享这个故事是为了：
• 警告那些仅依赖 Apple 登录和中继电子邮件地址的开发者。
• 与面临类似问题的其他人联系——让我们分享经验。
• 吸引 Apple 对这个关键问题的关注——目前没有文档解决方案，也没有可用的支持。
永远不要仅依赖 Apple ID 身份验证。始终实施备用方法，因为即使是大型生态系统也可能会不可预测地失败。