iOS和iPadOS设备启动到打开App

一、设备启动过程

启动过程每个步骤包含的组件都经 Apple 加密签名以启用完整性检查，因此只有在验证信任链后，启动才能继续；
这些组件包括引导载入程序、内核、内核扩展项和蜂窝网络基带固件；
这一安全启动链的设计旨在验证软件的最底层不被篡改；
iOS 或 iPadOS 设备开机后，其应用程序处理器会立即执行只读内存（称为 Boot ROM）中的代码；
BootROM是设备的处理器在首次启动时所执行的第一个代码；
作为处理器不可分割的一部分，Apple 或攻击者均无法修改；
这些不可更改的代码（称为硬件信任根）是在制造芯片时设定的隐式受信任代码；
Boot ROM 代码包含 Apple 根证书颁发机构 (CA) 公钥，该公钥用于验证 iBoot 引导载入程序是否经过 Apple 签名，以决定是否允许其载入；
这是信任链中的第一步，信任链中的每个步骤都会检查下一步骤是否已经过 Apple 的签名；
iBoot适用于所有 Apple 设备的 2 级启动载入程序；
载入 XNU 以作为安全启动链一部分的代码；
iBoot 可由底层引导载入程序载入或直接由 Boot ROM 载入，具体取决于片上系统 (SoC) 的版本；
iBoot 完成任务后，会验证和运行 iOS 或 iPadOS 内核；
对于搭载 A9 或更早 A 系列处理器的设备，Boot ROM 还会载入和验证底层引导载入程序 (LLB)，之后会依次载入和验证 iBoot；
LLB在具有两步启动架构的 Mac 电脑上，LLB 包含由 Boot ROM 调用的代码，该代码随后会载入 iBoot，成为安全启动链的一环；
无法载入或验证以下阶段时，处理方式因硬件而异：
Boot ROM 无法载入 LLB（较旧的设备）：设备固件升级 (DFU) 模式，即设备的 Boot ROM 代码在等待通过 USB 进行恢复时所处的模式；
在 DFU 模式下，设备为黑屏，但在连接到运行 iTunes 或“访达”的电脑时，会出现以下提示：“iTunes（或‘访达’）检测到一个处于恢复模式的（iPad、iPhone 或 iPod touch）。用户必须先恢复此（iPad、iPhone 或 iPod touch），然后才能将它与 iTunes（或‘访达’）配合使用；
LLB 或 iBoot：恢复模式，该模式用于在无法识别用户设备的情况下恢复许多 Apple 设备，使用户可以重新安装操作系统；
出现任一情况时，设备都必须通过 USB 连接到“访达”（macOS 10.15 或更高版本）或 iTunes（macOS 10.14 或更低版本），并恢复为出厂默认设置；
安全隔区使用启动进程寄存器 (BPR) 来限制不同模式中对用户数据的访问，在进入以下模式前会对 BPR 进行更新：
BPR是一组片上系统 (SoC) 硬件旗标，软件可使用其跟踪设备进入的启动模式，如设备固件更新 (DFU) 模式和恢复模式；
启动进程寄存器旗标经设定后就不可清除；
这样就允许后续软件获得系统状态的可信指示；
DFU 模式：由搭载 Apple A12 或后续型号 SoC 的设备上的 Boot ROM 设定；
恢复模式：由搭载 Apple A10、S2 或后续型号 SoC 的设备上的 iBoot 设定；
对于可接入蜂窝网络的设备，蜂窝网络基带子系统使用已签名的软件以及由基带处理器验证的密钥来执行额外的安全启动过程；
安全隔区还会执行安全启动过程来检查其软件 (sepOS) 是否已经过 Apple 验证和签名。

二、App代码签名过程

在 iOS 和 iPadOS 中，Apple 会通过强制性代码签名和严格的开发者签名等方式确保 App 安全性。

强制性代码签名

iOS 或 iPadOS 内核启动后，它将控制哪些用户进程和 App 可以运行；
为帮助确保所有 App 均来自批准的已知来源并且未被篡改，iOS 和 iPadOS 要求所有可执行代码均使用 Apple 颁发的证书进行签名；
设备附带的 App（如“邮件”和 Safari 浏览器）由 Apple 签名；
第三方 App 也必须使用 Apple 颁发的证书进行验证和签名；
强制性代码签名将信任链的概念从操作系统扩展至 App，并帮助防止第三方 App 载入未签名的代码资源或使用经 App 自身修改代码。

开发者如何给其 App 签名

开发者可通过证书验证（通过 Apple 开发者计划）给其 App 签名；
他们还可以在其 App 中嵌入框架，并使用 Apple 颁发的证书（通过团队标识符字符串）对代码进行验证；
证书验证：若要在 iOS 或 iPadOS 设备上开发并安装 App，开发者必须向 Apple 注册并加入 Apple Developer Program（Apple 开发者计划）；
Apple 首先验证每个开发者（无论是个人还是企业）的真实身份，然后再颁发证书；
开发者可使用该证书对 App 进行签名，并将其提交至 App Store 进行分发；
因此，App Store 中的所有 App 都是由身份可识别的个人或组织提交的，由此防止恶意 App 的创建；
此外，这些应用程序都经过 Apple 的严格审核，帮助确保它们通常可以按照所述的方式运行，并且没有明显的错误或其他明显的问题；
除了已经讨论过的技术，这一处理过程还会让用户对所购 App 的品质更加放心；
代码签名验证：iOS 和 iPadOS 允许开发者将框架嵌入其 App 中，使它可被 App 本身使用，也可被 App 中嵌入的扩展项使用；
为保护系统并防止其他 App 在其地址空间中载入第三方代码，系统将为启动时所有链接到进程的动态资源库执行代码签名验证；
此验证过程通过团队标识符 (Team ID) 完成；
团队标识符提取自 Apple 颁发的证书，是由 10 个字符组成的字母数字串，例如 1A2B3C4D5F；
程序可链接到系统自带的任何平台资源库，也可以链接到代码签名中具有与主可执行文件相同团队标识符的资源库；
因为作为系统一部分发布的可执行文件不具有团队标识符，所以它们只能链接到随系统本身发布的资源库。

验证企业内部专有 App

符合条件的企业也可以编写供组织内部使用的企业内部专有 App，并将其分发给员工；
企业和组织可以申请加入 Apple Developer Enterprise Program（ADEP，Apple 开发者企业计划）；
有关更多信息以及若要检查资格要求，请参阅 Apple Developer Enterprise Program（Apple 开发者企业计划）网站；
组织成为 ADEP 的成员后，便可以注册以获得一个预置描述文件，该描述文件允许企业内部专有 App 在其授权的设备上运行；
用户必须安装预置描述文件才能运行这些 App；
这有助于确保只有组织的目标用户能够将 App 载入到其 iOS 和 iPadOS 设备上；
通过移动设备管理 (MDM) 安装的 App 为隐式受信任 App，因为组织与设备之间的关系已经确立；
否则，用户必须在“设置”中批准 App 的预置描述文件；
组织还可以限制用户批准来自未知开发者的 App；
任何企业内部专有 App 首次启动时，设备必须收到 Apple 的肯定询证，表明允许该 App 运行。

App Store中的App签名验证

开发者将App上传到Apple服务器后，Apple会使用私钥对App进行数字签名；
用户从App Store下载到设备后，设备会使用Boot ROM中的公钥验证签名确定App是否经过Apple认证且未篡改。

Xcode安装的App签名验证

可以通过钥匙串从CA生成一对公私钥，申请为Apple developer后，可以在开发者后台上传CertificateSigningRequest文件（Mac本地生成的公钥文件），Apple会使用私钥对Mac公钥进行签名并生成一个证书（Mac公钥和签名信息），在开发阶段，App安装到设备上时，Xcode使用Mac私钥对App进行签名，App包内的数据包括App原始数据、Mac私钥对App的签名信息、包含Mac公钥的证书，设备会使用Boot ROM中的公钥会解密包含Mac公钥的证书获得Mac公钥，再通过Mac公钥验证App签名，两次验证通过则通过Apple的允许。

二、App启动过程

解析Info.plist

加载相关信息，例如如闪屏；
沙箱建立（内存欺骗）、权限检查。

Mach-O（可执行文件）加载

寻找合适当前CPU架构的部分；
加载所有依赖的Mach-O文件（递归调用Mach-O加载的方法）；
定位内部、外部指针引用，如字符串、函数等；
执行声明为__attribute__((constructor))的C函数；
加载类拓展Category中的方法；
C++静态对象加载、调用ObjC的+load函数。