rootlessJB – 11.0-11.3.1

让我们记住我们即将要做的事情

多年来，“越狱”的含义略有变化，从解锁运营商到获取文件系统访问权限等。然而，它的核心仍然保持不变。现代任何一种越狱都需要具备以下基本要素:

• 未签名代码执行: 让系统安静下来，停止要求为我们想要执行的每个操作进行证书签名
• 提权，通常为以root（最高特权）用户身份执行代码和减少沙箱限制
• 对文件系统根目录的读写访问权限

从技术上讲，直到iOS 10.3.3（不包括Meridian）的所有越狱都通过修补内核来实现这些功能。对于未签名代码执行，他们会修补AMFI（AppleMobileFileIntegrity）以允许伪签名二进制文件（未经有效证书签名的文件）运行，他们会修补沙箱操作以允许任何进程能够查看和加载调整（Tweak），通过修复文件访问和内存映射限制，然后他们必须进行一个挂载修补程序，以允许将根分区重新安装为读写模式。有不同的方法来重新安装根分区。为了帮助理解这一点，我们必须了解我们稍后将讨论的检查过程。

我们能做什么和不能做什么

首先让我们考虑自iOS 9以来最大的敌人：KPP（Kernel Patch Protection）。 KPP每隔几分钟检查内核是否发生更改，当设备处于空闲状态时。这种“偶尔检查”的安全措施听起来并不好，实际上Luca Todesco发布了一个完全绕过它的方法，它涉及到设计缺陷。 KPP并不能阻止内核修补；它只是不断地检测修补，并在捕获到修补时恢复内核。然而，既然我们仍然可以进行修补，这就为竞争条件提供了机会。如果我们足够快地执行操作并撤消，KPP就不会知道任何事情。

简而言之，对于每个内核修补，聪明的Luca Todesco会创建内核页面的副本，并将执行重定向到那里，进行修补并让KPP检查未经修改的原始页面！（有关更详细和详细的说明，请查看Jonathan Levin的文章）

然而，当这个绕过方法发布时，苹果已经克服了这个问题，他们引入了KPP的弟弟：KTRR（Kernel Text Read-Only Region）。注意“只读”，苹果摆脱了常规检查，他们在硬件层面上添加保护，将某些内存映射为只读。这一次没有竞争的能力，KTRR根本不会让你写任何东西。同样的Luca Todesco发布了一个部分绕过方法，但很快就被修补了，在iOS 10.2中。

那现在该怎么办呢？没有绕过方法？没有内核补丁。但是确切的补丁是什么呢？嗯...是的，KPP和KTRR应该保持内核不变，但是如果程序的内存100％静态，它能够工作吗？无法写入内存=无法存储任何类型的可变数据。因此，明显的结论是这些机制仅保护内核的特定部分，它们保护执行的代码和常量数据，这些数据不需要更改，但它们保留了可变数据的可写性。

偏移量

在内核中，我们必须手动计算结构体的偏移量。这可以通过多种方式完成。我们可以手工计算它们，我们可以反汇编引用这些结构成员的函数，或者我们还可以从XNU源代码中获取头文件（需要感谢苹果公司开源），并尝试将它们包含到可编译的项目中，在那里只需使用内置函数'offsetof(struct type, member)'即可。

＃反汇编

• 在XNU开源功能中找到所需的struct成员的引用
• 使用Apple File Conduit“2”或Cyberduck从设备上获取kernelcache，然后使用lzssdec对其进行解压缩（更新：在iOS 12中，您需要从ipsw / OTA软件包中获取它；不再具有对kernelcache的读取访问权限）
• 将其放入Hopper等反汇编器中
• 找到相同的开源函数（如果找不到，则不是所有内容都已标记，查找另一个）
• 找到相同的引用，这种情况下不会像“struct.member”或“struct->member”那样，而是像我在以前的示例中展示的那样，使用指针，就像这样“*（struct+offset）”

＃手动查找偏移量：

• 首先，按苹果公司的要求导航到XNU源代码
• 找到所需的头文件
• 计算目标之前的所有内容的大小
• 如果有一种类型您实际上不认识，您需要找到该类型的定义位置，通常只需使用google搜索“typedef unknown_type”即可:P
• 这是您的偏移量

＃包含标头

• 创建一个标头，并从XNU源代码的标头中复制结构定义，
• 还添加您可能会在其他标头中找到的所有类型定义（-_-）
• 在项目中包含标头，然后执行offsetof（struct，member）

让我们开始自己打补丁...

因此，您可以开始的最基本的事情是获取root权限。我们所有的进程信息都存储在所谓的“proc structs"中（如XNU头文件中所示）。获得root权限将被认为是一项简单的任务，我们只需要在内核中覆盖用户ID。不要迷失方向，p_uid成员并不重要，实际使用的用户ID存储在另一个结构体中，即存储凭据的“struct ucred”（头文件）中。

ucred结构体本身是proc结构体的一个成员（对“struct ucred”的指针也称为“kauth_cred_t”）。

因此，简而言之：

• 在内核中找到我们的proc结构https://opensource.apple.com/source/xnu/xnu-2422.1.72/bsd/sys/proc_internal.h
• 从那里计算ucred结构
• 计算其中的cr_uid（以及存储我们用户ID副本的所有内容）（如果您想要“wheel”组ID，则可以选择cr_gid）
• 将它们中的所有内容写入0

为了在内核中找到proc结构，我们可以使用补丁查找或符号查找（_kernproc符号）来找到“allproc”或“kernproc”。从那里开始迭代并检查pid。

如果我们选择第一种方式：

• 找到allproc
• 从中读取8个字节
• 结果是最新生成的进程的proc结构
• 从那里开始遍历所有结构。proc结构的第一个成员（与结构本身位于同一地址）将指向先前生成的进程。
• 如果pid==getpid()，则我们找到了我们的proc结构。 pid可以从proc结构的偏移量0x10（16字节）处找到

如果我们选择第二种方式：

• 找到_kernproc符号（更新：在iOS 12上，某些设备获得了0个符号，因此这可能不是未来的选项）
• 从中读取8个字节
• 结果是内核proc结构，即第一个进程
• 从那里开始遍历所有结构。proc结构的第二个成员（因为64位指针占用8个字节，第二个成员在结构的地址+第一个成员的大小处；因此地址+8个字节）将指向下一个进程。
• 如果pid == getpid()，则我们找到了我们的proc结构。