关于iOS 18 不活动重启最新消息

https://naehrdine.blogspot.com/2024/11/reverse-engineering-ios-18-inactivity.html

机翻，感兴趣的看原文吧，我觉得有点意思。

iOS 18 引入了一项新的不活动重启安全功能。它可以保护什么？它是如何工作的？这篇博文涵盖了内核扩展和安全区域处理器的所有细节。

首次解锁前的安全保护 / 首次解锁后的安全保护

您是否知道，手机启动后第一次输入密码与稍后输入密码解锁手机有很大不同？

首次输入密码时，这会解锁安全区域处理器 (SEP) 中的密钥存储，该密钥存储会对 iPhone 上的数据进行加密。

首次输入密码之前的状态也称为首次解锁前(BFU)。由于用户数据已加密，您的 iPhone 的行为与以后的解锁略有不同。您会发现 Face ID 和 Touch ID 不起作用，并且需要密码。但您可能会注意到更微妙的事情：由于 Wi-Fi 密码已加密，您的 iPhone 将无法连接到 Wi-Fi 网络。如果您的 SIM 卡未受 PIN 保护，您的 iPhone 仍将连接到蜂窝网络。这意味着，从技术上讲，您仍然可以接听电话。但是，如果您接到电话，即使该号码在您的联系人中，联系人姓名也不会显示，因为联系人尚未解密。同样，当您收到有关新消息的通知时，您会看到您收到了消息，但不会看到任何消息预览。您可以轻松地自己尝试一下！

在首次解锁后(AFU) 状态下，用户数据会被解密。您可以将其想象成一个在 iOS 运行时保持打开状态的密钥保险箱。即使您看到锁定屏幕，某些密钥仍可供操作系统使用。这样，即使您的 iPhone 已锁定，您也可以保持与 Wi-Fi 网络的连接并接收消息通知预览。

虽然 AFU 状态更方便，但更容易受到攻击。能够以某种方式绕过锁屏的攻击者可以访问 iPhone 上的解密数据。要绕过锁屏，攻击者不一定需要知道密码。iOS 中的安全漏洞可能允许攻击者执行代码并从 iPhone 中提取数据，即使它看起来处于“锁定”状态。

能够物理访问 iPhone 的攻击者有更多安全漏洞可供选择。攻击面更大，因为攻击者可以利用 USB 堆栈或无线协议（如 Wi-Fi、蓝牙或蜂窝）中的漏洞，甚至可以进行涉及打开设备的更具侵入性的硬件攻击。由于灰色市场上的供应量可能更多，因此这种更大的攻击面往往会使利用这些漏洞的成本更低。另一个使攻击成本更低的因素是时间——供应商公开且在较新软件版本中修补的漏洞不会解锁新 iPhone，但可以解锁长期处于 AFU 状态且未获得任何软件更新的 iPhone。

关于重启 iPhone 的谣言

在执法场景中，许多法医相关数据在 AFU 状态下可用。执法部门利用这一点，通常会让被扣押的 iPhone 保持开机状态，但与互联网隔离，直到他们能够提取数据。这段时间可能是等待漏洞可用或出于法律原因（例如获得搜查令）所必需的。

然而，窃贼和其他犯罪分子在窃取设备后也对获得这种访问权限感兴趣。这让他们能够访问银行账户和其他有价值的信息，远远超过 iPhone 本身的价值，或者可能用于勒索。人们经常重复使用密码，而获得 iCloud 帐户的访问权限可能会让窃贼重置设备的激活锁，从而提高转售价值。

404 media最近发表了一篇 新闻文章 （虽然是付费文章，但最重要的信息也包含在相关 推文中），报道了一份有关可疑 iPhone 重启的执法文件。该文件提出了两个有趣的主张：

1. 即使完全与无线网络隔离，搭载 iOS 18 的 iPhone 也会重新启动。

2. 搭载 iOS 18 的 iPhone 将以无线方式通知搭载较低 iOS 版本的其他 iPhone 重新启动！

尤其是第二个说法如果属实，那将意义重大。如果有人搞清楚了它的工作原理，他们就可以为 iPhone 打造一个大型 TV-Be-Gone，通过无线方式同时强制数百台 iPhone 重启。苹果真的会在 iPhone 中内置这样的功能吗？

了解了 Apple 无线生态系统后，我的兴趣被激发了，我必须深入研究一下！

发现不活动重启

当 Apple 添加新功能时，他们通常不会很好地隐藏这一点。Apple 软件包含大量调试字符串，这些字符串暗示了新功能。Blacktop 维护着iOS 中字符串的git 存储库，其中保存了很好的版本历史记录。我决定做我能想到的最省力的事情：只需搜索“重启”。

宾果，第三个结果看起来不错：“inactivity_reboot”。它位于keybagd中，这一点很有趣：此守护进程与第一次解锁时解锁的密钥存储相关。

第二次搜索“仅不活动重启”显示该字符串开始出现在 iOS 18.1 和 iOS 18.2 中。在 iOS 18.2 中，该字符串从“inactivity_reboot”更改为“inactivity_reboot_enabled”，暗示最新的 iOS 18.2 测试版中可能会有更多变化。

当时我还不清楚的是：不活动重启需要多长时间才能触发？  404 媒体的一篇新文章 声称需要 3-4 天。所以我将 SRD 更新到最新测试版并制作了延时录像。

事实证明，不活动重启恰好在 3 天（72 小时）后触发。尽管已连接到 Wi-Fi，iPhone 仍会这样做。这证实了我的怀疑，即此功能与无线连接无关。

逆向工程 不活动 重启

让我们逆向分析一下到底发生了什么变化！它提供了哪些安全保障？

以下是我发现的高级概述：

• 安全区域处理器 (SEP) 会跟踪您手机的上次解锁时间。如果上次解锁时间超过 3 天，SEP 会告知AppleSEPKeyStore内核模块已超过解锁时间。

• AppleSEPKeyStore内核模块通知用户空间启动重启。然后SpringBoard将正常终止所有用户空间进程。这可以防止重启时可能的数据丢失。

• 如果AppleSEPKeyStore内核模块发现 iPhone 在本应重新启动后仍处于开机状态，内核将崩溃。这种情况绝不会发生，除非有人试图篡改非活动重新启动。

• AppleSEPKeyStore内核模块写入一个 NVRAM 变量aks-inactivity。iPhone 重启后，keybagd会读取此变量，如果已设置，则会向 Apple 发送分析事件，包括 iPhone 未解锁的时间长度。

这篇文章的剩余部分展示了我如何解决这个问题以及底层设计有哪些安全隐患。

Sysdiagnose 中的指标

通过我在 ipsw-diffs 中的搜索，我知道有一些日志消息在重启时打印出来。当我开始静态查看它们时，我知道我必须亲自查看它们的实际记录。

三天后，我的手机重启后，我进行了系统诊断并搜索了这些消息。自己做这件事时，请确保在进行系统诊断之前解锁了设备。否则，重启之前的事件将会丢失。

在 AppleSEPKeyStore 消息中，有以下与不活动重启有关的条目：

默认2024-11-17 01:35:14.341697 +0100内核“AppleSEPKeyStore”:3846:0：通知用户空间不活动重新启动默认2024-11-17 01:35:14.341766 +0100内核“AppleSEPKeyStore”:12598:31：操作失败（sel：35 ret：e00002f0）默认2024-11-17 01:35:14.342053 +0100内核“AppleSEPKeyStore”:12598:31：操作失败（sel：35 ret：e00002f0）默认2024-11-17 01:35:34.958218 [重新启动发生] +0100内核“AppleSEPKeyStore”：331：0：正在启动（构建时间：2024 年 10 月 26 日 08:16:35）（“正常”变体🌽，1827.60.43）默认2024-11-17 01:35:34.958381 +0100内核“AppleSEPKeyStore”：476：0：_sep_enabled = 1

有关更多背景信息，这些是在启动重新启动之前未过滤的日志消息：

对SEPKeyStore内核扩展进行逆向工程

可以使用以下ipsw命令下载最新的 iOS 内核：

ipsw 下载 appledb --设备 iPhone17,3 --os iOS --版本'18.2 beta 2' --内核

这将下载并解压内核。为了进一步分析，我将整个内核缓存加载到 Binary Ninja 中。ipsw还支持将内核拆分为其模块（在 iOS 上称为“扩展”）。最新版本的Ghidra也对 iOS 内核提供了很好的支持。因此，有很多工具可供选择进行此分析。

我还下载了一个旧内核，其中 Apple 意外地包含了符号，并手动比较了这些版本，重点关注与不活动重启相关的代码。内核有三个与该功能相关的字符串：

“通知用户空间不活动重新启动”是我们从 sysdiagnose 中已经知道的字符串。它属于函数AppleKeyStore::handle_events，该函数在后台轮询 SEP 事件。以下屏幕截图在逆向工程和一些函数重命名后显示了更多上下文。

第一个字符串“max inactivity window expired, failed to reboot the device”是当 iPhone 无法重启时，内核崩溃的情况。

有关更多上下文，恐慌是由函数 AppleKeyStore::handle_device_state_return调用的。有多个路径通过多个抽象层调用此处理程序，这些路径与 UserClient 以及 SEP 状态有关。

通过calltree插件，我们可以看到该函数的所有传入调用。

现在来看最后一个字符串“aks-inactivity”。我们可以看到，这是在 IORegistry 中设置的属性。

它的对应部分位于用户空间的keybagd中。初始化keybagd时，它会检查此变量，发出分析事件，然后将其删除。此分析事件可能有助于 Apple 优化时间窗口，但我们可以忽略它以实现核心功能。

尽管我知道是 72 小时，但我在内核中找不到这个特定的时间窗口。我找不到任何与 72 小时相匹配的数字。那么手机如何知道何时重启呢？

虽然SEPKeyStore内核扩展中有一些与时间相关的功能的引用，但这些引用都没有将值与 72 小时进行比较。这些引用很容易找到，并且与没有不活动重启的旧内核版本没有太大区别，因此似乎没有在此处添加该功能。

但是，SEPKeyStore与 SEP 协处理器进行通信。在我识别的函数中，重启与某些 SEP 状态有关。可能是 SEP 本身检查了时间？

对安全区域处理器进行逆向工程

SEP 是苹果最严密保护的秘密之一。与 iPhone 上的大多数其他固件不同，SEP 的固件是加密的。

幸运的是，@nyan_satan最近泄露了iOS 18.1 beta 6 的 SEP 固件加密密钥，就在 Apple 推出不活动重启功能时。（谢谢！！🎉 Apple，如果您正在阅读这篇文章，为什么不发送未加密的 SEP？）使用ipsw，我们可以按如下方式下载 SEP 固件：

ipsw 下载 appledb --device iPhone16,1 --os iOS --version '18.1 beta 6' --pattern "sep-firmware.d83.RELEASE.im4p"

利用泄露的密钥，我们可以解密固件：

pyimg4 im4p 提取 --iv 6705fb216080e19667dbcf71f532ae73 --key 4ea9db4c2e63a316a6854c83e2f5c81fd102ad40160b8998b5f9b16838b7116e -i sep-firmware.d83.RELEASE.im4p -o sep-firmware.d83.RELEASE.im4p.e

将其加载到 Binary Ninja 中有点棘手。我们可以猜测该架构是 64 位 ARM 小端。但是没有固件必须加载到的元数据。由于懒惰并且不想花时间编写固件加载程序，我使用 Binary Ninja 的 Triage 功能自动检测最可能的地址。请注意，固件似乎有多个片段，并且有多个潜在的加载地址。我选择了 0x80090000ffc80000，这对我来说很有效。

关于 SEP 的信息很少。我能找到的最好的信息是2016 年的一份演示文稿——但总比没有好！值得一提的是，SEP 固件是按应用程序构建的，所以我猜分类找到的其他基地址可能对应于其他应用程序的地址空间。与 SEPKeyStore 通信的应用程序称为sks（参见演示文稿的第 86 张幻灯片）。信息不多，但足以开始逆向工程！

从字符串来看，自 2016 年以来，在 SEP 内部运行的应用程序架构似乎没有太大变化。与SEPKeyStore相关的应用程序仍然称为sks：

SEP 几乎没有调试字符串，因此很难对其进行逆向工程。以下是经过一些手动注释后SEPKeyStore的初始化函数的样子（“sth” 代表“某事”——我没有太深入地了解这里的具体细节）：

在其主函数中，我们可以找到在服务工作循环启动之前执行的多个其他函数。但是，代码很多。我们如何关注与不活动重启相关的内容？

让我们回想一下，我们正在寻找类似于 72 小时的东西。在内核中，时间通常以秒或微秒为单位。例如，72 小时是 259200 秒 (0x3f480)。但在二进制文件中查找此值（或 259200000000，以微秒为单位，或任何其他合理单位）不会返回任何匹配项。

使用编译器资源管理器，我们可以看到原因：优化......

我们不是按相反的字节顺序查找完整的字节时间，而是寻找将时间跨度的部分加载到寄存器中的汇编指令。

Binary Ninja 知道如何逆转这种优化，并允许我们在中间表示中进行搜索，而不是查找原始字节。在我们的例子中，我们知道我们正在寻找一个常量。

 

我们仅找到两个匹配项：

这就是它——一个比较各种时间（包括 3 天）的函数，它与sks应用程序的主函数相关。此时间比较的结果用于创建一条消息，该消息可能会发送到SEPKeyStore内核扩展。创建一个新的枚举使其更具可读性：

枚举时间：uint32_t

{

   _3_天 = 0x3f480，

   _2_天 = 0x2a301，

   _1_天 = 0x15181，

   `_2.5h` = 0xe11

};

此函数在上下文中用于初始化结构，该结构可能是从 SEP 发送到内核扩展的消息。

我最终没有对 SEP 进行更多的逆向工程，但这似乎证实了 SEP 确实会跟踪手机未解锁的时间。这种设计对我来说很有意义，因为 SEP 参与了每次解锁，并且即使使用针对主内核的漏洞，也能防止篡改，因此它是锚定此类缓解措施的好地方。

仅针对警察的缓解措施？

虽然媒体报道到目前为止将这一缓解措施主要针对执法部门，但它也是防盗方面一项巨大的安全改进。过时的执法设备经常以相当便宜的价格出现在 eBay 和其他类似平台上。然而，窃贼没有财力和法律手段在获得 iPhone 后 3 天内获取最新的漏洞来解锁它们。这也是保持设备更新很重要的另一个原因！

另一方面，执法部门可以而且必须调整其流程，并比以前更快地采取行动。第一批取证工具公司已经宣布他们能够在 24 小时内协调这些步骤！（请注意，这也表明他们只拥有针对 AFU 状态的漏洞……🤡）

关键要点

此功能与无线活动完全无关。执法文件得出的重启是由于手机之间进行无线通信而导致的结论是不可信的。iOS 18 之前的旧款 iPhone 可能是由于其他原因重启的，例如软件错误。

重启的时间测量和触发都在 SEP 中，它与SEPKeyStore内核扩展进行通信以执行重启。使用通过互联网或蜂窝网络提供的外部时间源来篡改计时可能不会影响 3 天计时器。

从安全角度来看，这是一种非常强大的缓解措施。攻击者必须执行内核代码才能阻止非活动重启。这意味着取证分析师可能能够延迟重启以进行实际数据提取，但初始漏洞利用必须在前三天内运行。

不活动重启将改变窃贼和法医分析师的威胁形势，但这种改变是不对称的：虽然执法部门面临着更大的时间压力，但它很可能完全阻止犯罪分子访问您的数据以进入您的银行账户和存储在您的 iPhone 上的其他有价值的信息。

原文始发于微信公众号（独眼情报）：关于iOS 18 不活动重启最新消息