iOS-代码签名--苹果代码签名的格式

1，代码签名

验证代码的“正确性”是计算机科学中最难的问题之一，目前没有“完美”办法能够分析任意一段代码，确定它是否是恶意的，而目前通常对代码验证的方法是数字签名。

目前数字签名用于验证

验证代码来源：由签名者的私钥进行签名，其他使用者可以用公钥进行验证。

验证代码的真实性：对代码的任何修改都有可能破坏数字签名。

代码签名不是苹果独创的，其他开发语言都在使用它，比如java。但是苹果对于整个代码签名的解决方案在许多方面是相当具有创新性的，其中最重要的是与授权的整合、对额外的资源的签名和确保在整个应用的生命周期中保持代码的完整性。

2，代码块中签名

苹果公司代码块格式是Mach-O，首先说明的是目前做数字签名的算法是我们熟知的算法，主要是sha1，sha256等摘要算法。这些算法做摘要运算，算出散列值。

如果是要计算的代码块比较小，则会很快计算出签名值。但是如果代码块超级大，这时候对整个二进制文件计算散列值来验证代码签名，可能很耗费性能的操作。而且实际上整个代码块在运行时，并不是一起映射到内存中的，而可能是只映射一部分。苹果在代码块目前采取分页处理(因为分页，所以也就有着管理这些分页的代码目录)，所以此时计算散列值是以每一个二进制页来计算的。

如何计算--->使用sha1等摘要算法计算出散列值，然后再对散列值求散列值

如何存储--->计算出的散列值一般位于文件的末尾，更进一步散列值由代码目录pagesize字段指定，并放置在代码插槽中

如何验证--->苹果定义LC_CODE_SIGNATURE的加载命令，该加载命令遵循_LINKEDIT加载命令架构体，该结构体仅仅指向代码签名的位置和大小

codesign -d -vvvvv /xxx

可以用这个命令来查看代码签名，/xxx表示你要查看的代码块Mach-O文件

从macOS10.12/iOS11开始，苹果是用sha256算法，取代了之前的sha1

3，其他资源的签名

苹果除了保护代码块外，其他plist、nib等资源也做了保护。

首先可以思考总结的是，姑且不管每个代码页计算出的散列值具体怎样存储在一个代码插槽中的，但是基础的原理咱们可以明晓。这个散列值大小加位置的结构体，肯定存放在代码页中的，按照苹果4096的代码分页最起码插槽是存在这4096个字节中的。

但是其他资源不同于代码块，比如一个nib资源，它本质不是代码资源，也就是说上面那一套代码插槽存储散列值是不行的。是以苹果为了做这些资源文件的保护，设计出了特殊插槽。

特殊插槽：资源文件用了本身不具有的代码插槽。

特殊插槽具体的特殊性：

1，特殊插槽的索引都是负数的，正常的代码插槽索引都是正数的。这是苹果为了资源文件设计一种主动“溢出”的特殊索引，解决非代码插槽的问题。

2，特殊插槽的数量是限定的，5个。正常的代码插槽数量不固定，理论上没有上限。但是特殊插槽不是，数量只有5个。而且这5个索引，每一个都有固定意义，比如-1索引绑定的是资源文件信息plist，-3是资源文件的散列值，-5嵌入在代码签名中的授权。

在特殊插槽中任何未使用的索引，都会用NULL进行填充

4，伪签名ad-hot

如上面所说，苹果可以完全控制iOS中每一个二进制文件，因此完全可以编译一个封闭的各个二进制文件的散列值列表，并将其硬编码到内核中，特别是AppleMobileFileIntegrity.kext的“信任缓存”中。而这种签名被称为“ad-hot”签名.

ad-hot签名对持有证书的CMS二进制块做了留空，通俗地说就是没有证书了。因为上述的代码签名的散列值存储在缓存的内核扩展中，消除了对证书的需求，因此这些二进制验证只需要找散列值就行。

ldid工具在tweak开发中通过用户伪签名。