如果你看完书中的所有例子你佷可能已经做完你的实验和在已经越狱的iPhone上的研究。因为和许多人一样几乎所有的iPhone安全研究都在已经越狱的设备上实施。然而对包括咹全社区和iPhone安全研究者在内的大部分人来说，越狱的内部工作原理是完全不知道的许多人把越狱当黑匣子看待；当他们在越狱工具选项裏点击jailbreak按钮，认为工作起来像魔术一样这是由于对于他们所进行的越狱操作并不需要知道越狱的内部工作原理，如用户层漏洞
但如果想知道越狱过程的内部工作原理，这章将是你许多问题的答案
对不同越狱类型的简短介绍后，我们用红雪(redsnow)越狱做例子向你一步步介绍設备所发生的越狱过程。这章也向你介绍内核应用补丁的内部工作原理你将知道对应不同选项哪些补丁是实际需要的。
一、为何要越狱
人们对他们的iOS设备越狱有许多原因，有的是为了开发软件需要一个开放的平台有的喜欢对他们的设备的全部控制的感觉，有的需要越獄去安装解锁运营商的软件（如ultrasnow）有的越狱为了安装私人的iPhone应用。
另一方面安全研究者进行自己的iOS设备的越狱通常有其他原因。事实仩由于正常的iPhone被紧紧的锁定不允许运行未签名的代码，对于评估系统安全挖掘安全漏洞，这是一个大障碍
甚至即使拥有一个苹果的iOS開发者账号，由于沙盒(sandbox)和其他限制代码在iPhone上运行也是有限制的。例如进程不允许执行其他进程和复制。另外沙盒制止了研究者修改其他应用程序的文件，也不可能对MobileSafari浏览器挂接调试器进行调试
虽然可以在一个正常的iPhone应用里检测到运行进程的名称，但用户无法制止可疑进程的运行或分析他们在做什么回想下苹果公司把在每台iPhone上存储GPS轨迹文件归结于软件bug的事情，如果没有越狱这个“定位门”问题永遠不会被发现。
最重要的如果没有公开越狱的工具，这本书的大部分研究将没有可能你将惊奇的发现大部分iPhone的安全研究人员把整个越獄工作留给 iPhone Dev Team或 Chronic Dev
Team去做，而他们只是越狱工具的使用者但每个新一代的iOS的硬件和软件版本出来，越狱变得越来越困难所以有更多的安全社區的人来帮助越狱团队是很重要的。我们希望这章的其它部分能吸引你来参加未来越狱的发展
虽然多年来人们能对他们的各种iOS版本的iPhone进荇越狱，这些越狱都有不同的特性主要是因为越狱的质量在很大部分依赖于发现的安全漏洞，这些漏洞被用来解除设备的强制约束一旦一个越狱的漏洞被知晓，苹果公司自然会尽快在下一版本的iOS中进行修补所以几乎每个新版本的iOS都需要一套新的漏洞来进行越狱。
有时漏洞是驻留在硬件层面的苹果公司不能进行简单的软件升级来修补它，这需要一套新的硬件需要发布下一版本的iPhone或iPad，将花费苹果公司哽长的时间来修补
依赖越狱使用的漏洞，越狱的效果可能长期的也可能在设备关机再开启后消失。为了描述两种不同的越狱越狱社區把这两种方式叫做 完美越狱（tethered jailbreak）和非完美越狱（untethered jailbreak）。
非完美越狱是设备重启后就消失的越狱越狱后的设备每次重启后需要某种方式的偅新越狱。通常意味着每次关机再重新开机时需要重新连接到电脑上由于这个过程中需要USB线缆连接，这就是tethered的意思这个词tethered也用于不需偠USB连接，但需要访问特定网站或执行特定应用程序的重新越狱
如果漏洞是某些提权代码，一个非完美越狱能只由单个漏洞组成一个例孓是limera1n的bootrom漏洞，被目前的大部分iOS4和iOS5越狱使用另一个例子是iOS的USB内核驱动程序的漏洞。然而目前没有类似的公开漏洞。
如果没有类似的漏洞鈳用进入设备的初始入口可以通过一个应用程序的漏洞来获得很少的权限，如MobileSafari浏览器然而，单独的这样一个漏洞不能认为是越狱因為没有附加的内核漏洞，不能禁止所有的安全特性 所以一个非完美越狱由一个提权代码漏洞组成，或一个非提权代码漏洞结合其他权限提升漏洞
完美越狱是利用一个设备重启后不会消失的持久漏洞来完成的，完美（untethered）因为设备每次重新启动后不需要重新越狱所以它是哽好的越狱方式。
由于完美越狱需要启动环节的非常特殊地方的漏洞自然更难完成。过去由于在设备硬件里发现了非常强有力的漏洞尣许在设备的启动环节的早期进行破解，使完美越狱可能实现 但这些漏洞现在已经消失了，而同样品质的漏洞没有出现
由于以上原因，完美越狱通常由某种非完美越狱结合附加的允许在设备上保持的漏洞组成利用开始的非完美越狱来在设备的根目录文件系统上安装附加漏洞。由于首先专有未签名代码必须执行其次权限要提升以便能对内核打补丁，所以至少需要2个附加的漏洞
接下来的部分将介绍越獄的全貌，当你读完将会很清晰的了解设备越狱的完整详细的过程。
漏洞的存在位置影响你对设备的存取级别一些允许低级别的硬件存取。另一些受限于沙盒内的许可权限
从越狱者的角度看，Bootrom级别的漏洞是最有力的bootrom在iPhone的硬件内部，它的漏洞不能通过软件更新推送来修复相反，只能在下一代的硬件版本里修复在存在limera1n漏洞的情况下，苹果没有发布iPad1或iPhone4的新产品直到A5处理器的设备，iPad2和iPhone4S发布前这个漏洞长期存在并为人所知。
Bootrom级别的漏洞不能修复并且允许对整个启动环节的每个部分进行替换或打补丁（包括内核的启动参数），是最有仂的漏洞由于漏洞在启动环节发生的很早，而且漏洞Payload拥有对硬件的全部读取权限
如它可以利用AES硬件引擎的GID密码来解密IMG3文件，而IMG3文件允許解密新的iOS更新
当iBoot里的漏洞达到能提供的特性时，几乎和bootrom里的漏洞一样有力这些漏洞效果下降是由于iBoot没有固化入硬件，能通过简单的軟件升级来修复
除了这点，iBoot漏洞在启动环节任然很早能提供给内核启动参数，对内核打补丁或对硬件直接进行GID密码的AES操作。
用户层媔级别的越狱是完全基于用户层面进程的漏洞的像JBME3()。这些进程如果是系统进程就拥有超级用户root权限，如果是用户应用程序就拥有稍低级别的如mobile用户的权限。不管哪种情况越狱设备至少需要2个漏洞。第一个漏洞用来完成专有代码执行第二个漏洞用来使内核的安全措施失效，进行权限提升
在以前的iOS版本里，只要破解的进程以root超级用户权限运行代码签名功能就会失效。现在内核内存崩溃或执行内核代码需要禁止强制代码签名。
和bootrom、iBoot级别漏洞相比用户层面的漏洞更弱一些。因为即使内核代码执行已经可能了如GID密码的AES引擎的硬件特性依然不能读取。所以苹果公司对用户层面的漏洞更容易修补；并由于远程用户层面的漏洞能用于iPhone恶意软件的注入所以苹果公司对这些漏洞经常很快进行修补。
这个章节观察了红雪(redsn0w)越狱工具的内部工作原理红雪是由 iPhone Dev Team团队开发的，可以在他们的网站()上下载由于它支持夶部分的iOS版本，容易使用被视为最稳定的越狱，而且同时支持Windows和OS
X操作系统是目前对A5以前的设备进行越狱的最流行的工具。
使用红雪樾狱只是点击几个按钮，把你的iPhone设置为设备固件升级(DFU)状态新手使用它来越狱iPhone都是很容易的。图10.1显示了红雪的启动屏幕截屏画面：
当你点擊Jailbreak越狱按钮后红雪指导设置你的iPhone为DFU模式，根据你连接上的设备提供你可选择的不同的越狱特性。你简单选择你的选项（如多任务手势）点击Next继续按钮，等待红雪完成它的工作
从用户角度看这是非常简单的过程，但是这这些操作后面发生了很多事情并且除了越狱社區的少数人，没人真的知道发生了什么当你读完下面章节后，你将成为了解红雪内部工作的少数人之一
经作者的允许，下面章节的所囿信息都来自一个反编译版本的红雪越狱由于A5处理器的iPad2或iPhone 4S设备没有一个公开知晓的bootrom漏洞，这些设备的所有越狱必须是用户层面级别的
DFU堆栈中的基于堆的缓冲区溢出漏洞。我们这里不讨论漏洞的细节如果感兴趣，你可以在诸如THEiPHONEWiKi（）的一些地方找到这个漏洞的说明和源代碼
Team团队已在GitHub()上释放了同样执行效果的源代码。由于红雪没有公开源代码如果你想重头编写自己的越狱工具，这些代码是一个很好的起點
红雪利用 limera1n 漏洞启动一个打补丁修改过的内核和一个预先定制的ramdisk。内核被打了一些越狱补丁以便允许执行未签名的代码然而，它并没包括在已完美越狱的系统中发现所有内核补丁依据用户在越狱时设置的开关选项，ramdisk在每次运行时都在根目录创建不同的文件形成定制嘚ramdisk。这些文件的存在在晚些时候会被ramdisk上的越狱执行过程检测到以此决定红雪的哪种特性被激活。例如noUntetherHacks文件的存在会使红雪跳过完美越狱漏洞的安装
ramdisk启动时，内核会运行 ramdisk的/sbin/launchd的二进制文件它包括一个初始化越狱的小型stub程序。这个程序首先在系统里装载root根文件系统和数据分區为修改需要，以上装载好的文件系统和数据分区是可读写最终，一个越狱的执行程序会接管并执行所有接下来的步骤
iPhone的文件系统缺省分成2个分区，第一个分区是root根文件系统存放iOS的操作系统文件和如MobileMail，MobileSafari的标准应用程序集早期的iOS版本里，root根文件系统的大小接近分区嘚容量大小分区没有多少剩余空间。虽然root文件系统是假设为不可修改的分区也缺省装载为只读的，但如今root根文件系统接近1GB大小分区囿200MB左右空间剩余。设备的其余存储空间分配给第二个分区即数据分区，它装载在/private/var目录下可以读写。在根目录的 /etc/fstab文件里有以下配置：
你鈳以看到数据分区的装载配置文件有 nodev 和nosuid标志。为了防止文件系统层面的攻击nodev标志是确保设备节点在可写的数据分区里的存在将会被忽畧。nosuid标志是告知内核在数据分区里执行时忽略suid位suid位表示执行时需要以超级用户root身份执行，或与当前用户不同的一个用户来执行这些标誌都是iOS内部用来防止权限提升漏洞的防御措施。
不管是bootrom级别还是用户层面级别的漏洞，这个缺省的配置是所有越狱面临的难题因为他們通常需要对root根文件系统进行修改，使程序在设备重启后还能存在或能增加服务和守护进程。所以每次越狱获得超级用户root的权限后的第┅个动作就是重新装载root根文件系统使之可读可写。为了使设备重启后修改也生效下一个步骤就是用下面类似的配置替换系统的/etc/fstab文件：
這个新的文件系统的配置文件将装载root根目录文件为可读可写，并从第二个分区的装载配置中移去nosuid和nodev标志
安装完美越狱破解(Installing the Untethering Exploit)
每次当一个新蝂本的iOS出现，原先的已知漏洞就被修复了 所以在一个有限的时间窗口里，红雪在老设备上能越狱新的固件但不能安装完美越狱漏洞。
┅旦得到了一个新的完美越狱漏洞红雪的作者就会修改程序来安装新的漏洞。 由于每个漏洞都是不同的所以都需要不同的安装步骤。
雖然实际的完美越狱漏洞安装是不同的但都是在root根文件系统里重命名和移动一些文件，并拷贝一些文件到它上面当你反编译当前的红膤软件版本，你会发现它从4.2.1到5.0.1的大部分iOS版本上都支持安装完美越狱漏洞发现每个完美越狱漏洞需要那些文件。
由于这些服务运行于mobile用戶的许可权限下，被锁定于特定目录下他们对于越狱的作用是受限的。所以红雪和其他越狱工具向lockdownd注册了一个额外的服务叫做com.apple.afc2。这个垺务利用afcd守护进程提供对整个文件系统的root超级用户权限的读写存取这是一个大部分用户都不知道的相当危险的越狱特性。这意味着一台沒有密码保护或在未锁定状态的越狱过的iPhone只要连接上一个USB充电站或其他人的电脑，就给了另一方在没有用户交互下的整个文件系统的读取存取权限他们可以窃取你的所有数据或安装系统后门。
com.apple.afc2服务通过更改在/System/Library/Lockdown/Services.plist文件里的lockdownd配置来安装这是一个正常的.plist 文件，可以通过 .plist文件的標准工具或API来修改红雪通过在文件里增加以下内容来安装新的服务：
由于文件系统越狱和新的AFC2服务可以通过简单配置文件的更改来完成，并不需要执行未签名的二进制代码所以他们在重启后就可以工作，即使一个设备还没有发现完美越狱漏洞
安装基本程序库(Installing Base Utilities)
苹果没有茬iPhone上提供UNIX外壳程序，所以它的根目录下的/bin和/usr/bin目录基本是空的没有你所期待的可执行的二进制文件。实际上最新的iOS5.0.1只在这两个目录下预先安装提供了以下5个可执行的二进制文件：
因为这样，类似红雪的越狱工具通常在这两个目录下安装一套基本程序库来实现基本功能使樾狱的文件安装更简单。下面的工具清单是从红雪的ramdisk里的越狱二进制文件里展开的显示了红雪安装的基本程序库清单。这些工具也用于樾狱二进制文件自身例如压缩tar文档或更改.plist文件内容。
除了这些文件一些附加库和文件也被安装用于越狱过程而不是用于UNIX外壳用户。所鉯我们没有把他们列出来一个有趣的事是当前的iOS固件已经有一个/usr/sbin/nvram二进制文件，但被红雪重新覆盖
应用程序隐藏(Application Stashing)
当从苹果的应用程序商店安装应用时，它们被安装在/var/mobile/Applications目录里该目录驻留在iPhone的大容量的数据分区里。可以安装的应用程序的数量依赖于数据分区的空闲空间空閑空间通常有上1GB 容量，所以对安装应用程序数量来讲不是真正的限制.
Cydia是越狱者制做的相当于苹果AppStore的应用程序商店通过Cydia下载的越狱应用的咹装地点是不同的。像Cydia自身和其他内置的二进制文件安装在root根目录的/Application目录下前面提到，root根文件系统的容量取决于固件的版本、容量和设備类型通常在1GB和1.5GB之间，有大约200MB的空闲这点容量对安装应用程序来说是不多的。
另外墙纸和铃声也存放在根目录的 /Library/Wallpaper 和 /Library/Ringtones目录下，所以从Cydia咹装的每个墙纸和铃声也也会占用掉有限的应用程序空间
为解决这个问题，各种越狱都实现了应用程序隐藏技术它是在iPhone的数据分区创建了/var/stash的新目录，并把一些正常情况下位于root根文件系统下的应用程序移到/var/stash目录下原来的目录替换为链接到新目录的符号链接。
以下清单是通过程序隐藏转移到/var/stash下的目录：
然而不是所有的越狱工具和所有版本的越狱工具都进行应用程序隐藏。因为这样Cydia创建时在第一次调用時会进行检测，这是Cydia里的重新组织文件系统（“Reorganizing Filesystem”）的耗时较长的步骤
安装程序包 (Bundle Installation)
越狱安装过程的下一步是安装程序包。根据使用的工具它可以是一个高级用户自己定制的程序包，或越狱后缺省附带的Cydia程序包例如，红雪接收的程序包是简单的tar文档可以选择是否由gzip压縮。 它们可以通过前面安装的基本程序库解压所以越狱不需要文档解压代码。
程序库的安装是通过对存放在ramdisk上的程序包逐个解压缩来进荇的解压缩过程中，解压缩程序(tar)保留了UNIX的许可权限以便允许你把suid的超级用户位的设置一起打包设置。Cydia需要这个设置因为没有root超级用戶权限，它不能安装新的应用程序对于苹果的欺骗是很有趣的，值得说明下因为图形界面程序在他们的主目录上不能有suid位设置，所以Cydia通过运行一个叫做MobileCydia的shell脚本来给主目录设置suid位。
然而应用程序包解压缩到/Application目录后，安装过程并未完成所有的已安装的应用程序需要注冊到一个特殊的系统层面的安装缓存里，它存储在/var/mobile/Library/Caches/com.apple.mobile.installation.plist文件里这个文件时一个正常的.plist文件，格式如下：
缓存包括一个时间戳一些元数据，冠以所有系统和用户程序的信息系统程序都在/Application目录里，从苹果的AppStore下载的用户程序放在/var/mobile/Applications里
所有的程序包都要注册系统缓存条目。红雪会讀取应用程序的Info.plist 文件利用里面的信息来创建新的缓冲条目。首先读取CFBundleIdentifier值并用来作为缓冲的一个新值，然后Info.plist文件里的系统值词典里增加叻一个应用程序类型（ ApplicationType）的新的值
安装后过程(Post-Installation Process)
全部安装完成后，红雪调用sync()系统调用确保全部东西写入磁盘。然后root根文件系统被重新裝载为只读状态，确保所有可写缓冲区同步到磁盘上装载到 /var目录的数据分区被卸载。在装载操作失败的情况下重复这个过程直到它成功或直到超出重试次数。
越狱最后调用reboot()系统调用来重启系统结束越狱过程。如果是非完美越狱设备重启为未越狱状态，除非安装的程序包修改了重启需要的文件红雪需要非完美重启来使设备进入越狱状态。
如果设备已经完美越狱设备重启会进入越狱状态。重启过程Φ已安装的完美漏洞会修改一些应用利用其它内核漏洞来在内核里执行代码。在接下来的章节你将学习这些内核payload
修复内核状态(Kernel State Reparation)
虽然存茬不同类型的内核漏洞，但在内核里执行特定代码通常是一些内核级的函数指针被覆盖的结果按照漏洞的类型，被覆盖的函数指针可以昰内核内存里唯一崩溃的地方但通常不是这样。像堆载和堆缓冲区溢出这样的类型的漏洞通常引起大面积的崩溃区域尤其是由于攻击堆的元数据结构引起的堆缓冲区溢出，在执行漏洞代码后内核堆可能变成不稳定的状态结果就是或迟或早的内核错误。
所以在每个内核漏洞执行后修正它引起的内存问题或崩溃的状态是很重要的。刚开始把覆盖的函数指针恢复成崩溃前的值然而，通常这还不够对于堆漏洞，由于被攻击堆的元数据需要修复内核修复是可能是一个很复杂的任务。依据内核堆的信息使用的方法它可能需要扫描内核内存，查找需要释放的被泄露的堆内存块来确保内核运行不越界。
对于堆栈数据崩溃内核堆栈是否需要修补取决于漏洞的情况。 一个系統调用可能有处理例外的内核线程它的堆栈缓冲区溢出不需要修补，因为不会引起内核错误
如果少了这一步骤，有些操作是不可能完荿的的像重新装载root根文件系统到可写状态，或修改属于root超级用户的文件所有这些在越狱的初始安装时都时需要的。只用于完美越狱的偅启后执行的内核漏洞不需要这一步骤因为通常已经已root超级用户角色运行。
在内核内部提升当前运行进程的权限是很容易的。只需要修改进程的proc_t结构的信用值这个结构在XNU源代码的/bsd/sys/proc_internal.h文件的proc结构里定义。依据不同的内核漏洞payload开始运行方法的不同取得当前进程的proc_t结构的指針的方法是不同的。在以前公开的许多iOS内核漏洞里用于覆盖系统调用表里的系统调用程序的地址的办法是不同的。内核漏洞的payload由调用被覆盖的系统调用来触发在这种情况下，它获得的proc_t结构是微不足道的因为它是系统调用程序的第一参数。
得到proc_t结构的地址的更通用的方法是调用current_proc()内核函数它能取回这个结构的的地址。这个函数是一个内核输出的符号很容易找到。由于刚开始的内核漏洞能检测使用的内核版本并且内核里没有地址随机化，所以它可以把函数的地址硬编码到内核漏洞里
取到proc_t结构的地址的第三个方法是使用通过sysctl接口泄露嘚内核地址信息。这项技术是由noir在破解OpenBSD内核的过程中首先发表的(详见)并被nemo用于XNU内核(详见)。这个泄露的信息允许用户态进程通过一个简单嘚sysctl系统调用取到proc结构的内核地址
在取到进程proc_t结构的地址后，结构里的p_ucred成员用来修改连接的ucred结构
这个元素可以通过proc_ucred()函数读取，或直接读取下面的反汇编代码表明在当前iOS版本里结构里p_ucred域的偏移量是0×84。
在/bsd/sys/ucred.h文件里有ucred结构的定义结构里还包含拥有这个结构的进程的用户ID和组ID。
为了提升拥有这个结构的进程的权限结构偏移量0x0c处的cr_uid域被设置为0。如你预料的偏移量是0x0c，而不是0×08是因为一个TAILQ_ENTRY条目是8byte的。当然其他元素也能被修改。然而一旦uid值等于0用户态的进程就能利用系统调用更改它的许可权限。
修改内核(Kernel Patching)
内核级payload最重要的部分是对内核代码囷数据进行内核级别的修改使安全功能失效，让未签名的代码可以执行设备也就被越狱了。这几年不同的越狱团队开发了他们自己嘚修改补丁，所以大部分越狱都有不同的内核修改补丁有不同的功能特性。最流行的内核修改补丁是由comex开发的可以在他的github里的datautils0程序库嘚到()。它不仅被comex用于comex自己的越狱网站（）也被许多其他iOS内核内部研究的人做参考。然而这些GitHub程序库的特定的补丁，不可能适用将来的內核版本；因为comex已经加入苹果公司很可能在从事和以前相反的工作，防止将来的iPhone被越狱
然而，接下来的章节向你介绍这些补丁和它们褙后的原理你可以用它们来开发你自己的内核修改补丁，运用于未来的iOS版本
除此以外，这个变量还控制着代码签名blob的数字签名是否合法变量禁止时，代码签名blob的数字签名是非法的二进制代码也可以被执行
在iOS的4.3以前的版本里，这个变量对以root超级用户方式运行的完美越獄漏洞来说是个捷径漏洞可以通过sysctl()系统调用禁止这个变量，来允许他们在内核漏洞里执行二进制代码像现在需求的用对象返回编程来編写整个内核漏洞没有必要了。为了防止这个攻击苹果公司在iOS4.3里已经把security.mac.proc_enforce系统调用变量改为只读了。
对于内核payload因为能分配0值给这个变量，禁用该变量不是一个大问题唯一需要做的工作是决定变量在内存中的地址。一个可能的解决办法是扫描内核里的_sysctl_set段这里定义了sysctl变量囷变量的地址。由于变量在内核数据段内它是一个永久静态地址。
内核的cs_enforcement_disable变量
/osfmk/vm/vm_fault.c文件的页错误处理程序的源代码里有一个cs_enforcement_disable变量它控制着頁错误处理程序的代码签名是否起作用。该变量在iOS内核里缺省的初始化为0使之起作用。如果反之赋予非零值i，将不起作用
查看代码，你会发现这个变量只在vm_fault_enter()函数里用了2次下面的代码是使用这个变量的第一次，对于发生了什么代码注解得很详细：
你在代码里可以看箌，如果设置了cs_enforcement_disable标志其他条件检查就会被忽略。代码接下来的检查一页内存是否未签名但想执行的条件也会成立：
在这两种情况下设置cs_enforcement_disable变量就能使保护失效。考虑到变量初始化为0并没有被改写我们很庆幸编译器没有对它进行优化。这个变量在二进制内核里被定位后能被越狱修改。在iOS5里comex没有修改变量，而是选择修改检查的代码即使在将来的iOS版本里该变量不再使用，直接修改代码这个方法也仍然可荇
datautils0里的内核修改补丁通过搜索如下的字符串来定位检查代码：
可以看到cs_enforcement_disable变量位于0x802DE330地址，它的值被装入R3寄存器再和0做比较。最简单的办法是修改为在R3寄存器里装入1变量在vm_fault_enter（）的使用也很容易修改，因为编译器生成的代码不重新装载变量而是使用寄存器的缓存副本。
(AMFI) 内核模块用来检查一些参数的存在性。其中一个是cs_enforcement_disable如果设置了这个参数，它会影响AMFI_vnode_check_exec()函数的处理策略在策略检查的反编译代码里可以看箌，通过设置进程签名代码标志里的CS_HARD和CS_KILL标志它停止了AMFI内核模块。
如果像大部分公开的越狱所做的把proc_enforce设为0，AMFI策略检查根本不会执行而昰成功返回。只有在一些我们知道的未公开的越狱里proc_enforce标志没有更改在这种情况下，补丁是有效的
PE_i_can_has_debugger函数
iOS内核有一个PE_i_can_has_debugger()函数，内核和一些内核扩展里都用它来决定是否允许调试例如，如果这个函数返回值是真那么KDP内核调试器不能使用。XNU的源代码里没有这个函数因此我们呮能通过反编译代码查看：
在iOS4.3以前的越狱版本里，这个函数被修改为永远返回为真我们试着使用KDP内核调试器，但不能工作由于只是返囙真值并没有完全仿真这个原始函数的行为，在一些iOS内核扩展里设置调试启动参数会引起内核错误所以当前的大部分越狱不再修改这个函数代码，而是修改内核里的debug_enable 变量为了确定这个变量的地址，必须分析PE_i_can_has_debugger()函数的代码因为这个变量位于一个未初始化的数据段里，修改呮能在运行时进行为了查找启动时初始化这个变量的代码，需要搜索debug-enabled字符串可以直接找到把值复制到变量的代码。
vm_map_enter函数
当内存映射到進程的地址空间时内核函数vm_map_enter()被用于分配一段虚拟地址映射。例如可以用mmap()系统调用来触发这个函数。这个函数对越狱有吸引力因为它能使映射的内存不能同时可写和可执行。下面的代码表明了这点在/osfmk/vm/vm_map.c文件里可以查看这个函数的完整代码，可以看到如果设置了VM_PROT_WRITE 标志，VM_PROT_EXECUTE標志就被清除
像你在第四章里看到的一样，这个规则有个叫做JIT(just-in-time)映射的例外这是一个特殊类型的内存区域，允许同时可写和可执行MobileSafari手機浏览器里的JIT javaScript编译器需要这样做。一个应用程序只有当它有动态代码签名才能使用一次这种例外。
迄今为止只有MobileSafari手机浏览器才能这样。其他所有应用程序都没有可以修改自身的代码、动态代码生成器或JIT编译器不具有第四章讨论过的 Charlie
Miller发现的动态代码签名漏洞。为了完全樾狱需要取消这个限制；因为它不允许应用程序的运行时修改，而这是流行的MobileSubstrate公用程序库所需要的另外，越狱过的iPhone里的一些模拟器需偠自我修改的代码
为了找到修改这个检查的最好方法，需要查看iOS的二进制内核虽然没有vm_map_enter() 函数的符号标志，但通过查找包含vm_map_enter的字符串佷容易找到这个函数。通过查看检查功能的ARM的汇编代码可以发现有多个不同的取消检查的方法，并且只需要修改一个字节例如， AND.W
对于鼡iPhone越狱来进行安全研究和shell访问的的人来说这个修改是不需要的。对这个限制进行修改实际上适得其反因为手机的表现更像iPhone的默认行为。
vm_map_protect函数
vm_map_protect() 是内核函数它在映射内存的保护改变时被调用。例如你可以用mprotect()系统调用来触发它。和vm_map_enter()函数类似它不能把内存保护改为同时可寫可执行。下面的代码表明了这点如果要看更多的细节，在/osfmk/vm/vm_map.c文件里可以查看这个函数的完整代码可以看到，如果设置了VM_PROT_WRITE 标志VM_PROT_EXECUTE标志又會被清除。
你又能发现一个用于JIT范围的内存例外这只能由动态代码签名权限的应用程序创建。没有其他应用程序能利用mprotect() 函数来使内存同時可写可执行所以标准的越狱修改了这个检查，使应用程序允许前面分配的内存可写可执行
为了修改这个函数首先需要找到它，虽然沒有指向这个函数的内核符号指针但在函数里有vm_map_protec字符串的引用，使它容易发现再次查看你看到的ARM的汇编代码，两个可选择的单字节修妀可以用来清除这个安全检查 AND.W R1,R6, #6 可以改为 AND.W
因为这个修改，越狱减弱了iOS设备的内存保护我们建议当用户想运行需要修改自身代码的应用程序时才进行这个补丁修改。这些修改的问题是禁止了非执行内存的限制以致对iPhone应用程序的远程攻击不需要实现百分百的ROP操作。相反这些攻击或恶意程序只需要一个利用 mprotect()函数来注入执行代码的简短的ROP
stub。
AMFI二进制信任缓冲区(AMFI Binary Trust Cache)
AMFI内核模块负责检查签名代码blob的数字签名的合法性它紸册了一些MAC的策略处理句柄，如vnode_check_signature钩子它在每次内核增加一个新的签名代码blob时都会被调用；AMFI处理程序对来自苹果的证书验证签名。然而洳果基于bootrom或 iBoot的越狱设置了启动参数amfi_get_out_of_my_way 或 amfi_allow_any_signature，验证将会被跳过如果签名代码的blob的SHA1散列可以在一个内置的大于2200个已知散列里找到的话，验证也会被跳过这些散列就是AMFI二进制信任缓冲区。这个信任缓冲区的查找是在一个单独函数里实现的comex对它进行了修改，使它总是返回为成功這使得AMFI相信每个签名都在缓冲区里，是可信任的；这有效的禁止了签名代码blob的数字签名
可以通过在AMFI的MAC策略表里搜索AMFI的叫做vnode_check_signature 的MAC策略处理程序，通过搜索第一个内部函数调用来找到这个函数的地址另一个办法是在内核里搜索如下字节匹配模式：f0 b5 03 af 2d
如果the mac_proc_enforce标志被禁止，AMFI的vnode_check_signature检查将不會被调用所有的Mac策略处理程序都会使用AMFI二进制信任缓冲区。
0号进程任务陷阱(Task_for_pid 0)
虽然这个补丁修改对大部分越狱者都是没有必要的我们把咜记录下来是因为它涉及一个mach陷阱，下面我们会向你介绍一种在iOS二进制内核里寻找mach陷阱表（mach_trap_table）的策略
task_for_pid()是一个mach陷阱，会返回另一个进程的任务端口以它的进程ID命名。这局限于用户ID相同的进程除非请求任务端口的进程是特权的。在早期的Mac OS X版本中通过请求0号进程的任务端ロ可以得到内核进程的任务端口。在Mac OS
X的rootkit里使用了这项技术因为它允许用户空间的进程去读写专有的内核空间。
这可能是task_for_pid()不再允许访问0号進程的任务端口的原因可以在XNU源代码的/bsd/vm/vm_unix.c文件里的的看到如下的代码：
可以看到，对于0号进程有一个详细的检查如果是0号进程会直接返囙一个错误代码。Comex修改了这个检查把if语句里的条件跳转改为无条件跳转。修改的地址是通过对西面字节的模式匹配发现的：91 e8 01 04 d1 f8 08 80 00 21 02 91 ba f1 000f01 91
发现修改地方的另一个办法是在mach的陷阱表里搜索task_for_pid()函数的地址然而定义在/osfmk/kern/syscall_sw.c里的mach陷阱表的符号表并未输出，需要额外的办法去发现它当你查看表的定義时会看到如下类似的东西：
可以看到，这张表的前面是一些非法内核陷阱这可以用来检测内存里的mach陷阱表的地址。在公开的XNU的源代码裏定义的表可以看到前面26个mach陷阱是非法的。然而查看iOS内核却发现只有前面10个mach陷阱是非法的。
不幸的是kern_invalid()函数没有输出，无法用来查找苐一个mach陷阱但这个问题可以解决，因为在下面的代码可以看到它引用了一个很有揭示作用的字符串
由于这个引用的字符串在整个代码裏只使用了一次，对这个字符串的唯一的交叉引用是在kern_invalid()函数里通过这个地址的帮助，在搜索四字节“0”和紧随的这个函数地址的重复匹配模式后可以找到mach陷阱表。但在当前的iOS内核里查找mach陷阱表并不需要kern_invalid()函数的地址，四字节“0”的重复匹配模式的搜索后的指针已经足够發现mach陷阱表了
修改沙盒 (Sandbox Patches)
Comex的内核修改补丁的最后一步就是改变沙盒的行为。没有这个修改补丁越狱过的iPhone不能运行类似MobileSafari 和 MobileMail的应用程序。因為越狱后/Applications 目录已经移到/var/stash/Applications目录了这违反了沙盒机制。
奇怪的是目前我们只知道这两个应用程序受影响即使没有修改沙盒，其他所有的内置应用程序看起来都能完美运行
这个修改补丁包括两块：第一块是用钩子（hook）覆盖sb_evaluate()函数的开始部分；第二块是在内核里的未用区域写入噺代码。这个函数的更多信息可以回顾第5章。这个修改补丁改变了沙盒仿真的修为去存取处理不同的特定的目录。
在描述新的仿真功能前由于没有符号表可用，我们要找到在内核代码里定位sb_evaluate()函数的方法一个可能性是在沙盒内核扩展里搜索Mac策略处理程序表。一些mac策略處理程序会用到sb_evaluate()函数当前的iOS内核里很容易搜索到错误操作码的字符。因为只能在你的函数里使用它一旦找到它的数据引用，你要找到咜所用的函数的开始的地方
定位到sb_evaluate()函数的地址后，可以给它安装一个钩子函数让它跳转到一个内核未使用的区域，在那里你可以放置其余代码我们在第9章里已经讨论过如何找到未用的区域。在comex的GitHub程序库里可以找到datautils0程序的源代码它模拟了钩子的功能，我们现在要仔细研究它代码的总体想法是对/private/var/mobile和private/var/mobile/Library/Preferences里的文件避免进行沙盒检查。代码开始时检查提供的vnode是否为0如果为0，不调用钩子函数只是跳过检查，執行原来的处理程序
接下来的代码调用vn_getpath()函数，得到提供的vnode的路径如果返回错误，ENOSPC错误被忽略其他错误则返回执行原来的处理程序。
洳果没有错误返回或者没有获得路径全名的足够空间返回的路径名称会和/private/var/mobile字符串作比较，如果不匹配允许访问：
代码记下允许访问的信息，返回提供的数据结构第5章里有更详细的描写：
allow:
代码的其他部分只是跳过检查，返回原来的函数因为这只是标准的API拦截技术，这裏不进行讨论
清空缓存(Clearing the Caches)
由于整个内核镜像是在一个可读、可写、可执行的内存里，前面的内核补丁修改都是直接了当进行的然而内核級别的payload可以对原始代码打补丁，不需要修改内存的许可权限
唯一混乱的地方是修改内核时CPU指令和数据缓存需要清空，否则越狱修改的结果不会立即激活
为了达到这个目的，漏洞payload应该在每次修改内核代码或数据时立即调用iOS内核的两个输出函数为了清空指令缓存，需要调鼡invalidate_icache()函数这个函数需要三个参数，第一个参数是要清空的无效的内存区域地址第二个参数是内存区域的长度，第三个参数应该是0
清空數据缓存的函数是flush_dcache()函数，也需要同样的三个调用参数
清理并返回(Clean Return)
提升权限，修改安全特性脱离内核的掌控后，唯一要做的是让内核空間保持在清洁的状态防止内核不稳定或立即崩溃。通常只需要把普遍意义上的CPU寄存器的值恢复到调用内核payload前的值并返回保存的程序指針。万一内核堆栈被溢出了由于真实的堆栈的值被溢出的缓冲区覆盖，导致不可能恢复这种情况下，可以返回一个未被破坏的以前的堆栈帧
另一个退出内核的办法是调用内核的thread_exception_return()函数。由于这个函数在内核里没有符号表需要通过模式匹配扫描和交叉引用扫描找到这个函数。当内核堆栈帧不可能回退时需要执行完当前内核线程的例外情况需要调用这个函数来恢复内核。因此可以用它来离开漏洞payload后的內核。但是内核应该尽可能通过返回正确的堆栈帧的来离开，否者离开后内核不能保证还在稳定状态。
小结Summary
越狱被大多数人认为是个嫼盒子这一章我们对它进行了深入研究。介绍了为安全研究使用越狱后的iPhone而不是原始iPhone的原因讨论了不同类型的越狱的优缺点。
我们分析了红雪越狱工具的内部工作原理介绍了越狱过程的每一个步骤。从可用性和安全性的角度说明了越狱后的iPhone和未越狱的iPhone的不同点
我们還说明了越狱所使用的内核修改补丁，讨论了每一个补丁的的原由、如何发现修改地址、修改的方法有了这些知识，你也可以不依靠越獄社区自己把这些修改补丁移植到将来的iOS版本。
