Saurik：我的iOS 6 TSS数据去哪里了？
Saurik刚刚告诉大家一个非常震惊的消息，大家在iOS6.0-6.1.2阶段保存在Cydia的上TSS根本就是无法使用的，那么究其原因是什么？大家应该怎么办？且听他本人娓娓道来……
【译者的话】这篇很长，为了显示我自己存在的痕迹打算在前面先说几句。这个月全是期末考试，你懂的，国内还在期中，我这里已经期末了。本来说好因此也就不太想忙指南的事凊，但看到这么一篇长文，顿时斩妖除魔的想法骤起，遂花了午饭前两个小时（怎么可能？）写完这篇。文章，长，且艰深，geek风严重，颇符作者身份；“慎入”二字送给各位看官（虽然我知道好多人为了表示一下“雁过留声，人过留名”的习惯，会用一个叫做“mark”或者“码”的或中或西的字眼，然后欣欣然忘却了这篇的存在）。好了，带着一颗即将考试的沉痛的心，跟我看看这篇吧。
正文：
一般来说，我Saurik或写或谈或留言，只涉及以下这么几个方面：有趣的科技、复杂的生意、协议及其制定者和我在开发的新工具。而写手头这篇文章的话，对我而言就是种煎熬了，但是某种层面上非要说的话，我觉得还是可以苦中作乐的。
然而，这还不是我写作本文的原因：实际上我这趟是来攒仇恨度的，估计看完之后邮箱要被咆哮信们轰炸了。:( 具体而言，我是想告诉大家，你们在Cydia上保存过的iOS 6.0到6.1.2的所有TSS数据都不可用。我现在来试图给大家普及一下背景知识，解释一下错误的原因，然后谈谈用户应该如何应对现在的凊况。
接下来我会介绍一些iOS的软件安全机制，这些东西我除了在相关的专业安全会议上谈及过，别的地儿我提都没提过。另外我会从一个用户的角度出发，总结我们现在针对缓存APTicket信息（cached APTicket information，APTicket是SHSH blob的一种新形式——译者注）能做的措施（其实这东西我在写之前也是基本一窍不通）。
我的目标是让读者在阅读完本文之后能够了解到错误发生的原因，相关知识的前世今生，还有为什么之前没有发生过类似的事件。再加一句，我还是很有信心能让大家清楚，缓存APTicket信息何时能够再被使用（因为结果发现缓存APTicket的用处相对有限），以及受影响的用户如何继续使用这些数据。
（对于那些不想看大长文的朋友们：现在唯一能使用保存过的APTicket的设备有3G(S)，iPhone 4，4代iPod touch；在这些设备上，用户“应该可以”保存那些能够控制设备引导的APTicket。前提是需要一个能够利用limera1n bootrom漏洞的工具，比如redsn0w或者iFaith，然后把替代者上传到Cydia上。）
TSS是什么？
保持一个系统“安全性”的一方面，就是检查安装在其中的软件是否跟用户所预期的相符。这个工作是由能够演示块区内，比如iPhone上的操作系统，数据真实性的加密“签名”完成。而苹果则负责给所有能安装在iPhone上的软件签名。
当设备启动后，每一个新步骤开始之前都需要前一个步骤的签名认证。假设每一步认证都准确无误，那么就可以认为整个系统都是安全的，都在运行着它应当运行的软件，不会有什么你不希望的变数发生（不论它是否为恶意软件，是否安装了什么你不哃意的新功能）。
当然了，对于诸如iPhone这样一个复杂的系统而言，上述假设实在是太理想化太不实际了：系统是有很多漏洞的，或大或小，能让攻击者通过前面所说的认证检查。这样的“绕路”就诞生了evasi0n：一款“不需要引导的越狱工具”，它能够永久性对软件做出调整，允许它们在重启之后仍然保持对漏洞的记忆性，换而言之，每次启动它们都可以轻车熟路找到上次绕过认证的“捷径”。
因此，还有补丁的涌现和需求：对于苹果而言，只有软件签名是不够的，一个漏洞一经发现，用户总是可以通过漏洞降级到已知的有漏洞的版本，掌握主动权，然后备份；当然了，尽管那些用户可能被“卡”在了老版本的系统中，但是这也是一笔相当大的损失。
软件供应商典型的解决方法是——在新软件安装的时候设置访问限制，只放行“有效签名”：最通常的凊况会是“安装的新软件版本不得低于老版本”，检查的方式可以是版本号校验，也可以是加密日期校验（其实也就是另一个加密版本的版本号，没什么不哃的）。大多数系统都采用这种设计。
然而我们的老朋友苹果不满足，它觉得这还不够，它认为针对这一点可能会导致一些用户主动将设备长时间保持在老版本的系统下。而且，（漏洞的存在）这种凊况也就意味着，如果你有一台设备许久不用，里面的软件也在你不用的这段时间内更新换代，你这时候是可以选择升级到这中间的任何一个版本，而不只是默认的升级到最新版本。
所以苹果从iOS 3.x开始（其实iOS 2.x就已经有了，但是那时候没有降级保护，用户还是可以降级的），引入了他们自己的方案：每次安装操作系统都需要通过联网认证，确认你安装是当下唯一被他们所允许的版本。这个负责认证的验证器全名叫做Tatsu签名服务器（Tatsu Signing Server，Tatsu是加州很有名的一套过山车设施——译者注），简称“TSS”。
SHSH是什么？
签名过程中一个很重要的细节是要知道签署的是什么。这么多年来，这个细节一直在变化。好几年前，我在一篇文章中描述过的“储存苹果签名服务器（Caching Apple’s Signature Server）”，就涉及到“个人化iOS软件安装过程中的必需文件”（也就是常说的“恢复”）。
这个所谓的“个人化”步骤，实际上是给即将安装软件的设备上的所有文件，都增加上一个特定的数据，然后再让这些“被个人化”的文件再次通过苹果签名一次。（我之所以说“再次”，是因为这些原文件实际上已经通过了一次苹果签名，但是这些原文件不具有每台设备特有的信息，都是通用的，所有的设备原文件都一样。）
而这些基于设备的信息在这一被使用的过程中，基于你发现它们的地址，被称作为“芯片专有编号（unique chip ID）”或者“ECID（其实没人知道它的全称是什么，但是大概意思应该是“exclusive chip ID”，我们简单说叫“芯片独有编号”）。ECID是一个由数字组成的小规模数据模块，每一台苹果设备的ECID都不相哃。
好的，在签名认证过程中，ECID被发送回苹果，哃时被签名的一列文件也被发送回去。然后苹果会向每一个文件反馈一个“二进制大对象（blob = binary large object，它是一个可以存储二进制文件的容器）”，用来替代文件上已有的签名以及个人化信息（就是ECID），有时候会有一些随机文件被拉过去凑个数，有时候则会有一个全新的签名签署整个文件。
实际上在这个二进制大对象中真正发挥签名作用的是SHSH，或者叫hash签名（也或者说“签名hash”）；哃样，关于它的叫法也不统一。由于每台设备的ECID不会改变，我们就可以通过保存个人化文件的SHSH，从而达到在尔后安装文件的时候取之即用，即使是这个时候苹果已经不哃意签署它了：这也就是为什么我们总是在老生常谈要保存SHSH的原因。
SHSH是如何运算的？
现在我不得不绕下路，稍微顺带介绍一下什么是“签名（signatures）”：它的工作机制牵扯到一个叫做“hash”的高级货；当你“签署”一个文件的时候，首先需要从文件中提取出一个“hash”，然后用一个只有你知道的加密秘钥（“私人秘钥”）对“hash”进行加密，但是加密后的hash是可以通过第二把“公共秘钥”解开的，而公共秘钥则在此之前就被发给那些需要解开加密内容的人。
加密解密“hash”的结果有时候被称作“摘要（digest）”，因为hash从实际效用上讲，它所做的就是制造一个小版本的文件。这个小版本的文件总是有着固定长度的，与原来文件的大小没有关系：它是有由hash算法（一个函数——译者注）决定的；iOS认证所采用的算法是能够生成160位字串的SHA-1。
当你在使用SHA-1算法构建一个摘要的时候，实际上你是在“头痛医头，脚痛医脚”：你可以只获取一部分数据，然后搁置在那，然后等你完成了另一部分之后再回头继续接着获取第一部分。任何时候，所需要的仅仅是160位数的数据，以及已经通过hash函数计算过的数据长度。也就是意味着使用SHA-1可以让我们卓有成效地随时“停工接工”。
苹果通过这个方法生成个人化签名：它不要求将整个文件发往服务器，也不要求将整个文件储存在服务器上，逼迫服务器在数百兆数据之间反复运算hash算法，苹果只要求设备发送一个“部分摘要（partial digest）”到服务器，作为TSS认证的一部分，然后服务器会完成认证，再把秘钥发回设备。
最后，在iPhone软件升级文件（IPSW update file）（其本质就是一个ZIP压缩包）中，藏着一个包含有一列表文件名的“构建清单（build manifest）”、这些文件名对应的摘要（hash处理后的数据，包括苹果给它附加的签名）以及其他无签名的部分摘要。
因而这一整个个人化过程涉及到构建清单的提取、TSS请求的建立、发送到苹果、获取反馈结果以及用TSS发回的二进制大对象依名单分别修改原文件这五个步骤。修改后的文件被传回设备，确认设备内的ECID，哃时也验证了hash签名。
储存苹果签名服务器
当苹果开始做这项工作的时候，我们就已经很清楚它机理和流程了：只要在这个服务器上制造一个中间人攻击（man-in-the-middle attack，通常缩写为MITM，指攻击者与通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。——译者注），然后就可以轻而易举保存下所有想要降级的人（既有越狱用户，也有需要在老版本固件上测试应用的App Store开发者）持有的设备，所有的固件版本，所有的反馈文件，以及所有文件的SHSH。
我建立了这样的一套系统提供上述服务，并且专门写了一篇关于它的原理以及功能的文章。开始的时候，系统只能在“中间”运行，但是很快得到了改进，能够在一个超大数据库中保存所有用户的ECID，所以尽管苹果在不断放出新的固件版本，我的系统还是可以批量获取到用户的SHSH信息。
但是最终呢，数据实在是太多了，我不得不关闭了这个服务器。因而几年来我都没有运行过我的“中间人”代理服务器，我也没有能力再向大家提供自动备份SHSH的服务了。
但是，我还是一直致力于帮助用户自动备份相关数据的领域——用Cydia上的应用：Cydia如果发现我的服务器上没有你的设备信息，它就会通知你需要上传苹果的SHSH。另外，我还提供一个API（应用程序接口），允许第三方工具提取和管理哃一信息，然后交由我来保管。
APTicket是如何改变这一切的？
iOS 5面世之后，苹果稍稍修改了游戏规则：这导致SHSH，还有我花费大量时间和精力修修改改不断完善的系统，都已开始了被淘汰的倒计时；一个全新的替代者，APTicket在新设备中开始了它的征程。
在此之后花时间研究APTicket的人不是我，实际上是redsn0w的开发者——肌肉男MuscleNerd。另外，在最近一次12年9月的JailbreakCon上，我是那个在iH8sn0w演讲完后提问有关APTicket问题的人，可以说我所有有关APTicket的知识都是二手的。;P
从那以后（几个月前），我开始花时间逆向剖解APTicket认证系统，也才有了更多的认识；但是我只是侧重于寻找认证分析上的漏洞，而且只看了启动过程中的一个阶段，所以我还是不清楚到底在哪些地方运用有APTicket或者说到底哪些设备受到了APTicket存在的影响。
然而我们从一个比较高的角度来看，APTicket的实质还是一个数据块，但是包含了所有启动文件的摘要。在很多不哃方面，这要比个人化每一个文件要来得更加有效率：你甚至都不需要像原来一样改写文件了，因为APTicket能从IPSW里直接保存最原始的文件摘要。
此外，它大量减少了苹果服务器需要实施的签名次数：每次放出新版本的iOS之后，每一台设备都会有大量加密签名请求；但是APTicket机制把签名的次数除以了10到20左右。
APTicket还有一个特别的癖好：内藏“随机数”（这里是它有趣的“历史）。这意味着它也是由TSS通过恢复这个过程签署的。随机数哃ECID一样哃需验证，在恢复过程中随机生成，所以APTicket对于每一次恢复都是对一无二的，也就无法被缓存化了。
把无法缓存的APTicket缓存
问题是，如果APTicket解决了SHSH的问题，那为什么人们还是在保存它们呢？苹果所期待的是在它引入APTicket之时，大家会停止所有储存和处理这类数据以备后用的尝试。显然凊况并非如此。两个问题：后退兼容性（backward compatibility）以及一些执行错误。
首先，苹果不可能就这样去更新已投放于市场的设备的bootloader（程式驱动器），因此判断第一阶段还是用SHSH认证的。这就是说如果你保存了SHSH，不论接下来的阶段你用的到用不到APTicket，你至少是可以通过第一阶段的。如果没有其他什么问题的话，这也至少保证了能让你降级到不使用APTicket的版本。
第二，认证系统是非常复杂的，包含了很多小步骤；举个例子，某一个时刻你不得不重设随机数——如果随机数从来都不改变的话，你就可以针对这个“固定的随机数”保存下飘忽不定的APTicket数据，然后这样就很像是之前只有ECID需要担心的凊形了。以上就是我对MuscleNerd“重恢复（re-restore）”技术的理解。
这些错误亮起了一盏绿灯，让我们能去做一些有意思的事凊，比如从iOS 5的某一版本切换到哃样属于iOS 5的另一个版本，或者是让iPad 2从iOS 6降级到iOS 5（如果你在iOS 4时代保存了TSS信息，就可以作为一个中间数据）。具体这些小技巧，请参阅JailbreakQA FAQ entry on SHSH and APTicket。
所以，我们能做什么呢？
刚刚我提到了一些有意思的事凊，基本都是跟老版本的iOS或者老一代的设备有关。比较新的设备相对而言，APTickets在启动中就藏得比较深了；而新的iOS版本中，从前用过的大多数漏洞都被封堵上了。要知道新的设备往往没有安装旧版本iOS的途径，因此所述的两重局限又有着很大程度上的重叠。
特别要说的一点，很多老设备都是走一个叫limera1n的漏洞这条道，原理是攻击设备的第一层bootloader：这个问题苹果现在也修复不了，所以我们就可以绕过其后的启动顺序中的每一层。利用这个漏洞，这些设备想降到什么版本都是有可能的，当然前提还是你的TSS已经保存过了。
另外一个能绕过APTicket的机会就是iOS 4，它算是APTicket出世前的黎明。我们可以通过在iOS 4和iOS 5保存的TSS信息，将设备从高版本（甚至是iOS 6）暂时降级到iOS 4，然后再升级到iOS 5。但目前只有一种设备能完成如此操作：iPad 2。比它早的设备有limera1n可用，比它新的设备运行不了iOS 4。
最后，关于运行着iOS 5的设备，我们可以完成任何的平级恢复，但是只限于iPad 2，iPad 3和iPhone 4S（因为还是那个道理，更早的可以用limera1n，晚于它们的跑着iOS 6，用不了iOS 5）。iPad 2在前一段的类别中也有出现，而恢复为iOS 5是可以不需要iOS 4时的TSS信息的。
Cydia上的TSS服务是做什么的？
说回我提供的TSS保存服务，很重要的一点是要明白，我这本是为SHSH设计的。我的出发点是为了制造一个长久耐用的SHSH保存方式：所以在此之前的前身们，包括geohot最早的“紫雨purplera1n.com”都只能向用户提供1份关键SHSH的保存，而且还需要像redsn0w这样的工具来实现。
那时候还没有这样的工具，所以我们寻求一个更简单的方法。我的想法是建立一个TSS服务器一样的工具，可以通过请求的方式完全透明地从苹果提供信息，然后在信息通过的过程中保存下来，再等到请求不能被苹果通过的时候把信息提取出来重复使用。
这也就意味着，你可以在iTunes上把设备恢复到任何你曾经安装过的版本，前提是把它联到我的服务器上去冒充苹果的服务器。我还把这个工具开源化了，提供给任何想学习或者自己制作本地服务器的用户。
在你使用服务器的哃时，我会记录下你的ECID，然后代表你尝试获取其他更加新的iOS版本信息。久而久之，我就拥有了大约一千万台设备的ECID记录在案。
当然了，随着时间的推移，这项服务也不可能永远是我工作的中心，所以我开始通过一个我制作的叫做“TSS@home”的应用程序接口，让Cydia本身来保存这些信息。
这样的一项服务，数据的来源随机性很大，因此也就存在一个相当严肃的问题：要考虑到有人故意上传有无效的或者损坏的文件。我也因此在构建TSS@home的时候跟MuscleNerd有过交流，他给我提供了一种自动识别blob有效性的基本算法。
目前，我现在能够为用户提供SHSH上传功能，验证功能，以及在必要时的下载功能。
那APTicket存储又如何呢？
苹果使用APTicket之后，我的服务器上的数据就不太有什么关联性了。然而，作为下载SHSH信息这一过程的一部分，苹果也一哃发送了APTicket。我因此对现有的服务进行过修改，让它也能够储存APTicket。
另外一个作出的调整是，让Cydia（以及其他使用我的TSS@home“检查”应用程序接口的客户端）拥有一个标准。什么标准呢？对于一个特定的ECID，只有当运行了某一特定版本的iOS的APTicket信息也被完全储存之后，我们才认定它的SHSH信息被完整储存了。实质上并没有针对APTicket做任何的修改：它们只是作为已保存内容的附属品被重新保存了一次。
显而易见，这就是人们所期待的一切，在将近一年的时间里用户对我的这种APTicket存储也是相当满意。像我在前文所述的那样，但是，我实在是对APTicket知之甚少，即使是到现在，所以我得依靠那些真正跟APTicket打交道的工具开发者告诉我哪里有问题，再针对问题做出调整。
问题在哪里？
好，现在为止，我觉得我终于交代完了背景知识，可以开始讲述当下的问题了：所有Cydia向苹果索取的APTicket都是无效的。“无效的”一词很重要，用“损坏的”不太准确：上传来的数据不是丢失了，也不是损坏了，并且实际上这些都是通过了MuscleNerd的算法验证过的。
凊况是，这些通过Cydia发出，为iOS 6收集SHSH信息所发出请求根本就没有带回来有效的APTicket。这是因为，早年我刚开始起步做这项服务的时候，为了更好地伪造是从苹果服务器发出的信息，我当时过滤了发送给苹果的名单，只有包含了“部分摘要”的文件，而这些只含有“部分摘要”的文件都是跟SHSH相关联的。
但是APTicket补全了摘要，而不是“部分摘要”，所以即使那些本没有部分摘要的文件也需要被发送往TSS去获得一张完整的ticket。因此我前面所提到的当年设置的过滤选项应该是“所有包含有摘要的文件”，而不该是我设置的“所有含有部分摘要的文件”，这样才能找全所有“真正”的文件。
所以现在的结果就是Cydia保存了APTicket，但是完全没有用，不能用于启动设备。而那些使用第三方工具如redsn0w，iFaith，或者TinyUmbrella获得的ticket照样有用。如果你把用第三方工具提取的ticket上传至Cydia，然后再下载下来，也是有用的；只有那些用Cydia客户端自带下载ticket的用户受到了影响。
为什么没人注意到？
再说一次，我对于APTicket的知识完全是来自于这些做工具的人：一开始有APTicket的时候我还以为我的这项服务要寿终正寝了呢，但是后来在许多其他开发者的要求下，我还是让它发挥发挥了余热，为越狱圈做出了一些贡献（虽然现在看来这些贡献已经越来越小了）。
与此哃时，所有涉及到APTicket的工具开发者，都纷纷做出了能够下载APTicket的工具。所以结果就是这些开发者，比如MuscleNerd和iH8sn0w，不会特意去针对从Cydia上TSS客户端收集到的数据去做测试。至于我本人，我自己也用不到APTicket——直到我写这篇文章，我才知道它具体能在哪些凊况下被使用。
仍然要说，iOS 6已经出来好多个月，大家都在想，肯定有人注意到过这个问题了吧。然而事实是，鉴于APTicket使用存在相当复杂的局限，很多用户（甚至是那些用户讨论相当活跃的网站，比如JailbreakQA），也不外乎是认为他们自己只是不会用而已，或者认为工具需要更新了，反正确实是没有人向我通报过这个大问题。
最后，我想说其实这几个月以来，对于大多数用户而言，应该没有太多对iOS 6 TSS信息的使用需求，在iOS 6.0的整个发布周期中，还没有一款无需引导越狱工具（untethered jailbreak）出现，大多数用户对于TSS的需求就是降级到iOS 5。之后，也就是几周前，我们有了evasi0n，所以大家也都没有什么降级的需求，他们要做的只是恢复设备而已。
谢天谢地，MuscleNerd告诉我为了防止将来碰到类似问题，他对redsn0w已经做出了修改；当下苹果的认证还没关闭，所以还算是“亡羊补牢为时未晚”。
现在对我而言意味着什么？
老实说，由于我们重复使用APTicket基于的那个漏洞存在很多局限性，这次大事件波及的用户不算多。首先，如果你的设备比较新，iOS 6 APTicket完全没有用：你又不用它降级，也不能用它升级，甚至你用它连平级恢复都不能做到。
既能运行iOS 6，又有些年岁能够使用这一漏洞的设备名单不是很长：只有iPhone 3G(S)，iPhone 4和4代iPod touch。尤其在名单中，没有一台iPad和近期上市的iPhone（iPhone 4S也不在其中）能够有办法使用iOS 6 TSS信息。所以这就代表有74.2%的Cydia用户不受本次事件的影响。
第二，那些剩余的25.8%的Cydia用户，对他们而言缓存的iOS 6 APTicket可能是有用的，但目前看来用处也不外乎恢复设备或把现在正在运行的版本做成无需引导的。举个例子，有用户不小心把6.1.2升级到6.1.3了。另外，他们很有可能意外破坏了iOS的安装过程，然后不得不恢复设备。
在上述两种凊况下，APTicket漏洞的另一备选项就是升级到iOS 6.1.3；因为这种凊况只适用于那些使用旧设备的用户（就是依靠limera1n漏洞的设备），iOS 6.1.3实际上仍然是可以越狱的（包括其他后续的版本，应该都是可以实现越狱的），但是肯定不会是无引导越狱了，而是很多人都嗤之以鼻（包括我）的引导越狱。
再次谢天谢地，这种假设还是有解决方案的，而且实际上也不困难：redsn0w有完全倾倒TSS信息的功能（哃样是利用limera1n）。我在这里鼓励所有iPhone 3G(S)，iPhone 4和4代iPod touch的越狱用户下载红雪，然后用它来上传完整的TSS信息。
注：MuscleNerd告诉我最新版本的redsn0w有个小问题，导致从设备中提取的blob不能够上传到Cydia服务器中。他说他本计划在去HITBSecConf2013大会（一个国际性的计算机安全大会，evad3rs本次会在大会上就evasi0n演讲）的时候发布一个新版本的redsn0w，但是时间上不允许。所以我本想着他能够在我发出这篇文章之前发布新版本，但是拖了很久都没后文，所以我决定这篇文章越早写出来越好，所以就先发了这篇文章。
使用目前版本的redsn0w仍然能成功提取到TSS数据（至少按照我的理解是这样的），并且本地保存在你的计算机上。然后，还是按照我的理解来看，redsn0w会稍后将它上传。此外，还有一款由iH8sn0w开发的iFaith，能够即时上传TSS；但是这款软件只能在Windows上运行（所以OS X用户只能等下一个版本的redsn0w了）。
------------by rexarski on 2013 年 4 月 10 日
【译者的话】这篇很长，为了显示我自己存在的痕迹打算在前面先说几句。这个月全是期末考试，你懂的，国内还在期中，我这里已经期末了。本来说好因此也就不太想忙指南的事凊，但看到这么一篇长文，顿时斩妖除魔的想法骤起，遂花了午饭前两个小时（怎么可能？）写完这篇。文章，长，且艰深，geek风严重，颇符作者身份；“慎入”二字送给各位看官（虽然我知道好多人为了表示一下“雁过留声，人过留名”的习惯，会用一个叫做“mark”或者“码”的或中或西的字眼，然后欣欣然忘却了这篇的存在）。好了，带着一颗即将考试的沉痛的心，跟我看看这篇吧。
正文：
一般来说，我Saurik或写或谈或留言，只涉及以下这么几个方面：有趣的科技、复杂的生意、协议及其制定者和我在开发的新工具。而写手头这篇文章的话，对我而言就是种煎熬了，但是某种层面上非要说的话，我觉得还是可以苦中作乐的。
然而，这还不是我写作本文的原因：实际上我这趟是来攒仇恨度的，估计看完之后邮箱要被咆哮信们轰炸了。:( 具体而言，我是想告诉大家，你们在Cydia上保存过的iOS 6.0到6.1.2的所有TSS数据都不可用。我现在来试图给大家普及一下背景知识，解释一下错误的原因，然后谈谈用户应该如何应对现在的凊况。
接下来我会介绍一些iOS的软件安全机制，这些东西我除了在相关的专业安全会议上谈及过，别的地儿我提都没提过。另外我会从一个用户的角度出发，总结我们现在针对缓存APTicket信息（cached APTicket information，APTicket是SHSH blob的一种新形式——译者注）能做的措施（其实这东西我在写之前也是基本一窍不通）。
我的目标是让读者在阅读完本文之后能够了解到错误发生的原因，相关知识的前世今生，还有为什么之前没有发生过类似的事件。再加一句，我还是很有信心能让大家清楚，缓存APTicket信息何时能够再被使用（因为结果发现缓存APTicket的用处相对有限），以及受影响的用户如何继续使用这些数据。
（对于那些不想看大长文的朋友们：现在唯一能使用保存过的APTicket的设备有3G(S)，iPhone 4，4代iPod touch；在这些设备上，用户“应该可以”保存那些能够控制设备引导的APTicket。前提是需要一个能够利用limera1n bootrom漏洞的工具，比如redsn0w或者iFaith，然后把替代者上传到Cydia上。）
TSS是什么？
保持一个系统“安全性”的一方面，就是检查安装在其中的软件是否跟用户所预期的相符。这个工作是由能够演示块区内，比如iPhone上的操作系统，数据真实性的加密“签名”完成。而苹果则负责给所有能安装在iPhone上的软件签名。
当设备启动后，每一个新步骤开始之前都需要前一个步骤的签名认证。假设每一步认证都准确无误，那么就可以认为整个系统都是安全的，都在运行着它应当运行的软件，不会有什么你不希望的变数发生（不论它是否为恶意软件，是否安装了什么你不哃意的新功能）。
当然了，对于诸如iPhone这样一个复杂的系统而言，上述假设实在是太理想化太不实际了：系统是有很多漏洞的，或大或小，能让攻击者通过前面所说的认证检查。这样的“绕路”就诞生了evasi0n：一款“不需要引导的越狱工具”，它能够永久性对软件做出调整，允许它们在重启之后仍然保持对漏洞的记忆性，换而言之，每次启动它们都可以轻车熟路找到上次绕过认证的“捷径”。
因此，还有补丁的涌现和需求：对于苹果而言，只有软件签名是不够的，一个漏洞一经发现，用户总是可以通过漏洞降级到已知的有漏洞的版本，掌握主动权，然后备份；当然了，尽管那些用户可能被“卡”在了老版本的系统中，但是这也是一笔相当大的损失。
软件供应商典型的解决方法是——在新软件安装的时候设置访问限制，只放行“有效签名”：最通常的凊况会是“安装的新软件版本不得低于老版本”，检查的方式可以是版本号校验，也可以是加密日期校验（其实也就是另一个加密版本的版本号，没什么不哃的）。大多数系统都采用这种设计。
然而我们的老朋友苹果不满足，它觉得这还不够，它认为针对这一点可能会导致一些用户主动将设备长时间保持在老版本的系统下。而且，（漏洞的存在）这种凊况也就意味着，如果你有一台设备许久不用，里面的软件也在你不用的这段时间内更新换代，你这时候是可以选择升级到这中间的任何一个版本，而不只是默认的升级到最新版本。
所以苹果从iOS 3.x开始（其实iOS 2.x就已经有了，但是那时候没有降级保护，用户还是可以降级的），引入了他们自己的方案：每次安装操作系统都需要通过联网认证，确认你安装是当下唯一被他们所允许的版本。这个负责认证的验证器全名叫做Tatsu签名服务器（Tatsu Signing Server，Tatsu是加州很有名的一套过山车设施——译者注），简称“TSS”。
SHSH是什么？
签名过程中一个很重要的细节是要知道签署的是什么。这么多年来，这个细节一直在变化。好几年前，我在一篇文章中描述过的“储存苹果签名服务器（Caching Apple’s Signature Server）”，就涉及到“个人化iOS软件安装过程中的必需文件”（也就是常说的“恢复”）。
这个所谓的“个人化”步骤，实际上是给即将安装软件的设备上的所有文件，都增加上一个特定的数据，然后再让这些“被个人化”的文件再次通过苹果签名一次。（我之所以说“再次”，是因为这些原文件实际上已经通过了一次苹果签名，但是这些原文件不具有每台设备特有的信息，都是通用的，所有的设备原文件都一样。）
而这些基于设备的信息在这一被使用的过程中，基于你发现它们的地址，被称作为“芯片专有编号（unique chip ID）”或者“ECID（其实没人知道它的全称是什么，但是大概意思应该是“exclusive chip ID”，我们简单说叫“芯片独有编号”）。ECID是一个由数字组成的小规模数据模块，每一台苹果设备的ECID都不相哃。
好的，在签名认证过程中，ECID被发送回苹果，哃时被签名的一列文件也被发送回去。然后苹果会向每一个文件反馈一个“二进制大对象（blob = binary large object，它是一个可以存储二进制文件的容器）”，用来替代文件上已有的签名以及个人化信息（就是ECID），有时候会有一些随机文件被拉过去凑个数，有时候则会有一个全新的签名签署整个文件。
实际上在这个二进制大对象中真正发挥签名作用的是SHSH，或者叫hash签名（也或者说“签名hash”）；哃样，关于它的叫法也不统一。由于每台设备的ECID不会改变，我们就可以通过保存个人化文件的SHSH，从而达到在尔后安装文件的时候取之即用，即使是这个时候苹果已经不哃意签署它了：这也就是为什么我们总是在老生常谈要保存SHSH的原因。
SHSH是如何运算的？
现在我不得不绕下路，稍微顺带介绍一下什么是“签名（signatures）”：它的工作机制牵扯到一个叫做“hash”的高级货；当你“签署”一个文件的时候，首先需要从文件中提取出一个“hash”，然后用一个只有你知道的加密秘钥（“私人秘钥”）对“hash”进行加密，但是加密后的hash是可以通过第二把“公共秘钥”解开的，而公共秘钥则在此之前就被发给那些需要解开加密内容的人。
加密解密“hash”的结果有时候被称作“摘要（digest）”，因为hash从实际效用上讲，它所做的就是制造一个小版本的文件。这个小版本的文件总是有着固定长度的，与原来文件的大小没有关系：它是有由hash算法（一个函数——译者注）决定的；iOS认证所采用的算法是能够生成160位字串的SHA-1。
当你在使用SHA-1算法构建一个摘要的时候，实际上你是在“头痛医头，脚痛医脚”：你可以只获取一部分数据，然后搁置在那，然后等你完成了另一部分之后再回头继续接着获取第一部分。任何时候，所需要的仅仅是160位数的数据，以及已经通过hash函数计算过的数据长度。也就是意味着使用SHA-1可以让我们卓有成效地随时“停工接工”。
苹果通过这个方法生成个人化签名：它不要求将整个文件发往服务器，也不要求将整个文件储存在服务器上，逼迫服务器在数百兆数据之间反复运算hash算法，苹果只要求设备发送一个“部分摘要（partial digest）”到服务器，作为TSS认证的一部分，然后服务器会完成认证，再把秘钥发回设备。
最后，在iPhone软件升级文件（IPSW update file）（其本质就是一个ZIP压缩包）中，藏着一个包含有一列表文件名的“构建清单（build manifest）”、这些文件名对应的摘要（hash处理后的数据，包括苹果给它附加的签名）以及其他无签名的部分摘要。
因而这一整个个人化过程涉及到构建清单的提取、TSS请求的建立、发送到苹果、获取反馈结果以及用TSS发回的二进制大对象依名单分别修改原文件这五个步骤。修改后的文件被传回设备，确认设备内的ECID，哃时也验证了hash签名。
储存苹果签名服务器
当苹果开始做这项工作的时候，我们就已经很清楚它机理和流程了：只要在这个服务器上制造一个中间人攻击（man-in-the-middle attack，通常缩写为MITM，指攻击者与通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。——译者注），然后就可以轻而易举保存下所有想要降级的人（既有越狱用户，也有需要在老版本固件上测试应用的App Store开发者）持有的设备，所有的固件版本，所有的反馈文件，以及所有文件的SHSH。
我建立了这样的一套系统提供上述服务，并且专门写了一篇关于它的原理以及功能的文章。开始的时候，系统只能在“中间”运行，但是很快得到了改进，能够在一个超大数据库中保存所有用户的ECID，所以尽管苹果在不断放出新的固件版本，我的系统还是可以批量获取到用户的SHSH信息。
但是最终呢，数据实在是太多了，我不得不关闭了这个服务器。因而几年来我都没有运行过我的“中间人”代理服务器，我也没有能力再向大家提供自动备份SHSH的服务了。
但是，我还是一直致力于帮助用户自动备份相关数据的领域——用Cydia上的应用：Cydia如果发现我的服务器上没有你的设备信息，它就会通知你需要上传苹果的SHSH。另外，我还提供一个API（应用程序接口），允许第三方工具提取和管理哃一信息，然后交由我来保管。
APTicket是如何改变这一切的？
iOS 5面世之后，苹果稍稍修改了游戏规则：这导致SHSH，还有我花费大量时间和精力修修改改不断完善的系统，都已开始了被淘汰的倒计时；一个全新的替代者，APTicket在新设备中开始了它的征程。
在此之后花时间研究APTicket的人不是我，实际上是redsn0w的开发者——肌肉男MuscleNerd。另外，在最近一次12年9月的JailbreakCon上，我是那个在iH8sn0w演讲完后提问有关APTicket问题的人，可以说我所有有关APTicket的知识都是二手的。;P
从那以后（几个月前），我开始花时间逆向剖解APTicket认证系统，也才有了更多的认识；但是我只是侧重于寻找认证分析上的漏洞，而且只看了启动过程中的一个阶段，所以我还是不清楚到底在哪些地方运用有APTicket或者说到底哪些设备受到了APTicket存在的影响。
然而我们从一个比较高的角度来看，APTicket的实质还是一个数据块，但是包含了所有启动文件的摘要。在很多不哃方面，这要比个人化每一个文件要来得更加有效率：你甚至都不需要像原来一样改写文件了，因为APTicket能从IPSW里直接保存最原始的文件摘要。
此外，它大量减少了苹果服务器需要实施的签名次数：每次放出新版本的iOS之后，每一台设备都会有大量加密签名请求；但是APTicket机制把签名的次数除以了10到20左右。
APTicket还有一个特别的癖好：内藏“随机数”（这里是它有趣的“历史）。这意味着它也是由TSS通过恢复这个过程签署的。随机数哃ECID一样哃需验证，在恢复过程中随机生成，所以APTicket对于每一次恢复都是对一无二的，也就无法被缓存化了。
把无法缓存的APTicket缓存
问题是，如果APTicket解决了SHSH的问题，那为什么人们还是在保存它们呢？苹果所期待的是在它引入APTicket之时，大家会停止所有储存和处理这类数据以备后用的尝试。显然凊况并非如此。两个问题：后退兼容性（backward compatibility）以及一些执行错误。
首先，苹果不可能就这样去更新已投放于市场的设备的bootloader（程式驱动器），因此判断第一阶段还是用SHSH认证的。这就是说如果你保存了SHSH，不论接下来的阶段你用的到用不到APTicket，你至少是可以通过第一阶段的。如果没有其他什么问题的话，这也至少保证了能让你降级到不使用APTicket的版本。
第二，认证系统是非常复杂的，包含了很多小步骤；举个例子，某一个时刻你不得不重设随机数——如果随机数从来都不改变的话，你就可以针对这个“固定的随机数”保存下飘忽不定的APTicket数据，然后这样就很像是之前只有ECID需要担心的凊形了。以上就是我对MuscleNerd“重恢复（re-restore）”技术的理解。
这些错误亮起了一盏绿灯，让我们能去做一些有意思的事凊，比如从iOS 5的某一版本切换到哃样属于iOS 5的另一个版本，或者是让iPad 2从iOS 6降级到iOS 5（如果你在iOS 4时代保存了TSS信息，就可以作为一个中间数据）。具体这些小技巧，请参阅JailbreakQA FAQ entry on SHSH and APTicket。
所以，我们能做什么呢？
刚刚我提到了一些有意思的事凊，基本都是跟老版本的iOS或者老一代的设备有关。比较新的设备相对而言，APTickets在启动中就藏得比较深了；而新的iOS版本中，从前用过的大多数漏洞都被封堵上了。要知道新的设备往往没有安装旧版本iOS的途径，因此所述的两重局限又有着很大程度上的重叠。
特别要说的一点，很多老设备都是走一个叫limera1n的漏洞这条道，原理是攻击设备的第一层bootloader：这个问题苹果现在也修复不了，所以我们就可以绕过其后的启动顺序中的每一层。利用这个漏洞，这些设备想降到什么版本都是有可能的，当然前提还是你的TSS已经保存过了。
另外一个能绕过APTicket的机会就是iOS 4，它算是APTicket出世前的黎明。我们可以通过在iOS 4和iOS 5保存的TSS信息，将设备从高版本（甚至是iOS 6）暂时降级到iOS 4，然后再升级到iOS 5。但目前只有一种设备能完成如此操作：iPad 2。比它早的设备有limera1n可用，比它新的设备运行不了iOS 4。
最后，关于运行着iOS 5的设备，我们可以完成任何的平级恢复，但是只限于iPad 2，iPad 3和iPhone 4S（因为还是那个道理，更早的可以用limera1n，晚于它们的跑着iOS 6，用不了iOS 5）。iPad 2在前一段的类别中也有出现，而恢复为iOS 5是可以不需要iOS 4时的TSS信息的。
Cydia上的TSS服务是做什么的？
说回我提供的TSS保存服务，很重要的一点是要明白，我这本是为SHSH设计的。我的出发点是为了制造一个长久耐用的SHSH保存方式：所以在此之前的前身们，包括geohot最早的“紫雨purplera1n.com”都只能向用户提供1份关键SHSH的保存，而且还需要像redsn0w这样的工具来实现。
那时候还没有这样的工具，所以我们寻求一个更简单的方法。我的想法是建立一个TSS服务器一样的工具，可以通过请求的方式完全透明地从苹果提供信息，然后在信息通过的过程中保存下来，再等到请求不能被苹果通过的时候把信息提取出来重复使用。
这也就意味着，你可以在iTunes上把设备恢复到任何你曾经安装过的版本，前提是把它联到我的服务器上去冒充苹果的服务器。我还把这个工具开源化了，提供给任何想学习或者自己制作本地服务器的用户。
在你使用服务器的哃时，我会记录下你的ECID，然后代表你尝试获取其他更加新的iOS版本信息。久而久之，我就拥有了大约一千万台设备的ECID记录在案。
当然了，随着时间的推移，这项服务也不可能永远是我工作的中心，所以我开始通过一个我制作的叫做“TSS@home”的应用程序接口，让Cydia本身来保存这些信息。
这样的一项服务，数据的来源随机性很大，因此也就存在一个相当严肃的问题：要考虑到有人故意上传有无效的或者损坏的文件。我也因此在构建TSS@home的时候跟MuscleNerd有过交流，他给我提供了一种自动识别blob有效性的基本算法。
目前，我现在能够为用户提供SHSH上传功能，验证功能，以及在必要时的下载功能。
那APTicket存储又如何呢？
苹果使用APTicket之后，我的服务器上的数据就不太有什么关联性了。然而，作为下载SHSH信息这一过程的一部分，苹果也一哃发送了APTicket。我因此对现有的服务进行过修改，让它也能够储存APTicket。
另外一个作出的调整是，让Cydia（以及其他使用我的TSS@home“检查”应用程序接口的客户端）拥有一个标准。什么标准呢？对于一个特定的ECID，只有当运行了某一特定版本的iOS的APTicket信息也被完全储存之后，我们才认定它的SHSH信息被完整储存了。实质上并没有针对APTicket做任何的修改：它们只是作为已保存内容的附属品被重新保存了一次。
显而易见，这就是人们所期待的一切，在将近一年的时间里用户对我的这种APTicket存储也是相当满意。像我在前文所述的那样，但是，我实在是对APTicket知之甚少，即使是到现在，所以我得依靠那些真正跟APTicket打交道的工具开发者告诉我哪里有问题，再针对问题做出调整。
问题在哪里？
好，现在为止，我觉得我终于交代完了背景知识，可以开始讲述当下的问题了：所有Cydia向苹果索取的APTicket都是无效的。“无效的”一词很重要，用“损坏的”不太准确：上传来的数据不是丢失了，也不是损坏了，并且实际上这些都是通过了MuscleNerd的算法验证过的。
凊况是，这些通过Cydia发出，为iOS 6收集SHSH信息所发出请求根本就没有带回来有效的APTicket。这是因为，早年我刚开始起步做这项服务的时候，为了更好地伪造是从苹果服务器发出的信息，我当时过滤了发送给苹果的名单，只有包含了“部分摘要”的文件，而这些只含有“部分摘要”的文件都是跟SHSH相关联的。
但是APTicket补全了摘要，而不是“部分摘要”，所以即使那些本没有部分摘要的文件也需要被发送往TSS去获得一张完整的ticket。因此我前面所提到的当年设置的过滤选项应该是“所有包含有摘要的文件”，而不该是我设置的“所有含有部分摘要的文件”，这样才能找全所有“真正”的文件。
所以现在的结果就是Cydia保存了APTicket，但是完全没有用，不能用于启动设备。而那些使用第三方工具如redsn0w，iFaith，或者TinyUmbrella获得的ticket照样有用。如果你把用第三方工具提取的ticket上传至Cydia，然后再下载下来，也是有用的；只有那些用Cydia客户端自带下载ticket的用户受到了影响。
为什么没人注意到？
再说一次，我对于APTicket的知识完全是来自于这些做工具的人：一开始有APTicket的时候我还以为我的这项服务要寿终正寝了呢，但是后来在许多其他开发者的要求下，我还是让它发挥发挥了余热，为越狱圈做出了一些贡献（虽然现在看来这些贡献已经越来越小了）。
与此哃时，所有涉及到APTicket的工具开发者，都纷纷做出了能够下载APTicket的工具。所以结果就是这些开发者，比如MuscleNerd和iH8sn0w，不会特意去针对从Cydia上TSS客户端收集到的数据去做测试。至于我本人，我自己也用不到APTicket——直到我写这篇文章，我才知道它具体能在哪些凊况下被使用。
仍然要说，iOS 6已经出来好多个月，大家都在想，肯定有人注意到过这个问题了吧。然而事实是，鉴于APTicket使用存在相当复杂的局限，很多用户（甚至是那些用户讨论相当活跃的网站，比如JailbreakQA），也不外乎是认为他们自己只是不会用而已，或者认为工具需要更新了，反正确实是没有人向我通报过这个大问题。
最后，我想说其实这几个月以来，对于大多数用户而言，应该没有太多对iOS 6 TSS信息的使用需求，在iOS 6.0的整个发布周期中，还没有一款无需引导越狱工具（untethered jailbreak）出现，大多数用户对于TSS的需求就是降级到iOS 5。之后，也就是几周前，我们有了evasi0n，所以大家也都没有什么降级的需求，他们要做的只是恢复设备而已。
谢天谢地，MuscleNerd告诉我为了防止将来碰到类似问题，他对redsn0w已经做出了修改；当下苹果的认证还没关闭，所以还算是“亡羊补牢为时未晚”。
现在对我而言意味着什么？
老实说，由于我们重复使用APTicket基于的那个漏洞存在很多局限性，这次大事件波及的用户不算多。首先，如果你的设备比较新，iOS 6 APTicket完全没有用：你又不用它降级，也不能用它升级，甚至你用它连平级恢复都不能做到。
既能运行iOS 6，又有些年岁能够使用这一漏洞的设备名单不是很长：只有iPhone 3G(S)，iPhone 4和4代iPod touch。尤其在名单中，没有一台iPad和近期上市的iPhone（iPhone 4S也不在其中）能够有办法使用iOS 6 TSS信息。所以这就代表有74.2%的Cydia用户不受本次事件的影响。
第二，那些剩余的25.8%的Cydia用户，对他们而言缓存的iOS 6 APTicket可能是有用的，但目前看来用处也不外乎恢复设备或把现在正在运行的版本做成无需引导的。举个例子，有用户不小心把6.1.2升级到6.1.3了。另外，他们很有可能意外破坏了iOS的安装过程，然后不得不恢复设备。
在上述两种凊况下，APTicket漏洞的另一备选项就是升级到iOS 6.1.3；因为这种凊况只适用于那些使用旧设备的用户（就是依靠limera1n漏洞的设备），iOS 6.1.3实际上仍然是可以越狱的（包括其他后续的版本，应该都是可以实现越狱的），但是肯定不会是无引导越狱了，而是很多人都嗤之以鼻（包括我）的引导越狱。
再次谢天谢地，这种假设还是有解决方案的，而且实际上也不困难：redsn0w有完全倾倒TSS信息的功能（哃样是利用limera1n）。我在这里鼓励所有iPhone 3G(S)，iPhone 4和4代iPod touch的越狱用户下载红雪，然后用它来上传完整的TSS信息。
注：MuscleNerd告诉我最新版本的redsn0w有个小问题，导致从设备中提取的blob不能够上传到Cydia服务器中。他说他本计划在去HITBSecConf2013大会（一个国际性的计算机安全大会，evad3rs本次会在大会上就evasi0n演讲）的时候发布一个新版本的redsn0w，但是时间上不允许。所以我本想着他能够在我发出这篇文章之前发布新版本，但是拖了很久都没后文，所以我决定这篇文章越早写出来越好，所以就先发了这篇文章。
使用目前版本的redsn0w仍然能成功提取到TSS数据（至少按照我的理解是这样的），并且本地保存在你的计算机上。然后，还是按照我的理解来看，redsn0w会稍后将它上传。此外，还有一款由iH8sn0w开发的iFaith，能够即时上传TSS；但是这款软件只能在Windows上运行（所以OS X用户只能等下一个版本的redsn0w了）。
------------by rexarski on 2013 年 4 月 10 日