钻研Fairplay DRM（Digital Rights Management，即数字版权保护）最要害的两点是受权和加密。但长久以来，对于App DRM的钻研却很少，而就是在这样的前提下，Fairplay DRM又为iOS App的平安钻研叠加了一层“妨碍”。咱们通过剖析混同零碎的设计和实现过程中的问题，克服调试跟踪的阻碍，设计了多种动态和动静的反抗计划；同时通过大量的逆向工程，填补了平安钻研人员对macOS零碎机制中，对于Fairplay这一部分的认知空白。
什么是DRM？
DRM全称Digital Rights Management，即数字版权保护。苹果为了爱护App Store散发的音乐/视频/书籍/App免于盗版，开发了Fairplay DRM技术，并申请了很多相干的专利，比拟有代表性的如：
- US8934624B2: Decoupling rights in a digital content unit from download
- US8165286B2: Combination white box/black box cryptographic processes and apparatus
- ES2373131T3: Safe distribution of content using descifrado keys
长久以来，对于App DRM的钻研很少，而DRM的要害是受权和加密。破解Fairplay DRM加密的形式俗称“砸壳”，这是进行iOS App平安钻研的必要前提。自从2013年苹果引入App DRM机制当前，诞生了如Cluth、Bagbak、Flexdecrypt这样的经典“砸壳工具”，而此类“砸壳工具”通常须要越狱设施的反对，因而具备肯定的局限性。
2020年公布的M1 Mac将Fairplay DRM机制引入了MacOS，因为Mac设施的权限没有iOS严格，因而咱们得以在MacOS上摸索更多Fairplay DRM的原理，最终目标是使解密流程不受Apple平台的限度。上面，咱们先来聊聊Apple中是如何实现的？
Apple上DRM的实现：Fairplay DRM
LC_ENCRYPTION_INFO中的标记
加密的MachO含有LC_ENCRYPTION_INFO字段，其中cryptoff标识了加密局部在文件中的起始偏移，cryptsize标识了加密局部的尺寸，cryptid则表明了加密的办法。Fairplay DRM爱护下的App，其加密尺寸为4096的倍数，加密形式标识为1。
而负责解密Mach-O的组件次要包含：内核态的FairplayIOKit和用户态的fairplayd。
Fairplay的Open
MacOS的XNU Kernel中有text_crypter_create_hook这个导出符号，IOTextEncryptionFamily驱动则注册了这个Hook，并作为桥梁，将调用转发给了FairplayIOKit内核驱动。
最终负责解决的函数是：
com_apple_driver_FairPlayIOKit::xhU6d1( char const* executable_path, long long cpu_type, long long cpu_subtype, rp6S0jzg** out_handle)尔后，内核中的FairplayIOKit开始初始化，通过host_get_special_port中的unfreed port发送MIG调用到用户态的fairplayd，fairplayd开始解决SC_Info目录下的sinf和supp文件，并将解决的数据返回给内核中的FairplayIOKit。
注：用户态的fairplayd具体工作流程不在本文探讨范畴内。
其中MIG调用的构造如下：
struct FPRequest{ mach_msg_header_t header; mach_msg_body_t body; mach_msg_ool_descriptor_t ool; NDR_record_t ndr; uint32_t size; uint64_t cpu_type; uint64_t cpu_subtype;};struct FPResponse{ mach_msg_header_t header; mach_msg_body_t body; mach_msg_ool_descriptor_t ool1; //supf文件映射 mach_msg_ool_descriptor_t ool2; //unk，反比与加密内容的尺寸 uint64_t unk1; uint8_t unk2[136]; uint8_t unk3[84]; uint32_t size1; uint32_t size2; uint64_t unk5;};实现所有调用后，返回的构造rp6S0jzg*理论是一个uint32_t类型的handle，接下来则能够用这个handle来实现解密操作。
Fairplay的Decrypt Page
后面提到的Fairplay Open操作最终返回了一个pager_crypt_info的构造体，其中page_decrypt的Hook由IOTextEncryptionFamily驱动接管，并最终转发给FairplayIOKit。
最初，FairplayIOKit中负责解密的函数定义如下：
com_apple_driver_FairPlayIOKit::bvqhJ( rp6S0jzg *hanlde, unsigned long long offset, unsigned char const* src, unsigned char * dst)至此，Fairplay的解密逻辑实现调用。值得注意的是，在Fairplay DRM中，page的概念为4096bytes。
那么，用户态fairplayd解决的sinf和supp文件又是什么样子的呢？
SINF和SUPF文件
构造
用户态的fairplayd会读取随IPA携带的两个重要文件：SINF和SUPF，存储在App的SC_Info目录下。
其中SUPF文件和IPA一起散发，每个用户的IPA和SUPF文件都是统一的，其中SUPF文件中保留了加密Mach-O的密钥，然而密钥自身被另外的机制加密。而SINF文件则作为每个用户的DRM许可，记录了购买用户的标识符和姓名，以及解密SUPF须要的信息，因而在Sandbox策略下，App无奈读取本身的SINF文件，以避免其被作为惟一ID追踪用户。
SINF
SINF文件是一个LTV+KV构造的文件，它的字段如下所示：
sinf.frma: gamesinf.schm: itunsinf.schi.user: 0xdeadbeefsinf.schi.key : 0x00000005sinf.schi.iviv: 0x12345678901234567890123456789012sinf.schi.righ.veID: 0x000007d3sinf.schi.righ.plat: 0x00000000sinf.schi.righ.aver: 0x01010100sinf.schi.righ.tran: 0xdc64f80csinf.schi.righ.sing: 0x00000000sinf.schi.righ.song: 0x59a73c58sinf.schi.righ.tool: P550sinf.schi.righ.medi: 0x00000080sinf.schi.righ.mode: 0x00002000sinf.schi.righ.hi32: 0x00000004sinf.schi.name: User Namesinf.schi.priv: (432 Bytes Private Key)sinf.sign: (128 Bytes Private)SUPF
SUPF文件次要分为三个局部，咱们将其命名为Key Segments、Fairplay Certificate、RSA Signature，其中Key Segments能够含有多个子Segment，用来保留多个架构的解密信息。
KeyPair Segments: Segment 0x0: arm64, Keys: 0x36c/4k, sha1sum = e369546960d805dd1188d42e3350430c7e3a0025Fairplay Certificate: Data: Version: 3 (0x2) Serial Number: 33:33:af:08:07:08:af:00:01:af:00:00:10 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=Apple Inc., OU=Apple Certification Authority, CN=Apple FairPlay Certification Authority Validity Not Before: Jul 8 00:48:29 2008 GMT Not After : Jul 7 00:48:29 2013 GMT Subject: C=US, O=Apple Inc., OU=Apple FairPlay, CN=AP.3333AF080708AF0001AF000010 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (1024 bit) Modulus: 00:b0:01:16:4b:62:b2:37:8d:60:12:4f:02:15:15: a0:32:1b:e8:ed:44:ed:e9:17:5b:ec:9e:5d:11:24: 5a:66:2f:dc:a3:25:aa:52:70:e1:09:22:09:4b:65: 0f:67:f5:82:dc:af:78:9b:4c:45:f3:b4:f4:77:aa: fc:a3:b2:84:c3:8b:09:c6:2e:55:f5:14:85:07:ac: ae:0d:ff:ff:ca:41:3b:44:cb:52:b6:28:60:55:23: 35:8d:26:71:c6:12:a5:e0:72:58:09:3c:4a:9e:b6: 63:df:2a:91:94:27:eb:65:0a:b2:36:45:11:c1:91: 43:58:12:d9:e5:18:a1:ad:db Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment, Data Encipherment, Key Agreement X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: 7B:07:34:81:A5:75:D0:F6:11:BB:D2:36:3F:79:93:4B:A1:70:EB:CF X509v3 Authority Key Identifier: keyid:FA:0D:D4:11:91:1B:E6:B2:4E:1E:06:49:94:11:DD:63:62:07:59:64 Signature Algorithm: sha1WithRSAEncryption 06:11:4e:87:ed:b1:08:70:c2:0d:e4:d2:94:bb:7f:ee:50:18: c0:2a:21:34:0e:99:1f:bf:60:a2:58:d0:0c:28:3d:03:5b:ab: 4e:72:69:ba:41:52:45:b2:29:27:4a:c8:ba:7f:b5:9b:63:78: b1:68:41:40:59:3f:05:8a:57:74:c5:63:30:cc:f3:20:41:c0: 3c:65:d4:0d:22:47:f3:97:76:e6:d6:3c:eb:e7:20:78:10:59: fd:96:09:82:c3:41:f0:5f:d0:3e:91:44:6d:77:3f:a5:d9:da: f0:f7:53:ad:94:61:28:1c:4c:40:3b:17:2b:dd:e3:00:df:77: 71:22RSA Signature: 6aeb00124d62f75f5761f7c26ec866a061f0776be7e84bfad4b6a1941dbddfdb3bd1afdcc5ef305877fa5bee41caa37b1a9d4ce763cf7d2cb89efa60660a49dd5ddff0f46eee7cd916d382f727d912e82b6e0a62e8110c195e298481aa8c8162faac066ef017c6c2c508700d7adb57e0c988af437621e698946da1b09adf89e9上面，咱们来聊聊Fairplay DRM的混同原理和实现。
混同原理和一些实现
LLVM Pass
LLVM是一个低劣的编译器框架，其中，咱们能够将其大略的分为前端、中端、后端：
配图节选自CMU的CS 15-745课程：https://www.cs.cmu.edu/~15745。
前端负责将高级语言转化为LLVM IR；中端解决LLVM IR，实现一系列的剖析、优化工作，咱们称之为Pass，再次输入LLVM IR；后端则负责将LLVM IR转化为机器码。其中，中端的玩法特地丰盛，根本的优化工作：如死代码打消、常量折叠都在这一部分实现；Address Sanitizer、PC Sanitizer等编译器插桩也是在这里进行的；其余的混同框架如探讨的较多的ollvm以及Hikari，甚至包含苹果的混同机制，也都是基于此实现。
这一混同形式能够根本的分为控制流混同和数据流混同，除此之外的一些混同形式，比方VMP等，不在本文探讨范畴内。
makeOpaque
在编译器中，为了避免一些具体的表达式被优化，咱们会将表达式进行等价变动，咱们临时将这样的操作定义为makeOpaque（如Safari的JavascriptCore，其JIT组件B3就提供这样的机制），C++伪代码如下：
Expression* makeOpaque(Expression *in);不通明谓词（Opaque Predicate）
谓词（Predicate）在计算机中，指的是执行后为True或False的表达式。数论外面的一些论断能够作为咱们生成不通明谓词的根底，这些不通明谓词的后果恒为True或恒为False。比方下列表达式中，y执行的后果就恒为True：
uint32_t x = 0;bool y = ((x * x % 4) == 0 || (x * x % 4) == 1);不通明谓词利用到混同中的一个例子就是bogus CFG。
如源语句如下：
foo1();foo2();通过变换，咱们增加了一个虚伪的分支（即bogus CFG）
：
foo1();if ( false ) junk_code();else foo2();然而如果没有通过特地解决，编译器、反编译器的死代码打消就会将虚伪分支去除掉，因而咱们须要makeOpaque的引入，假如咱们引入了后面示例中的表达式：
foo1();uint32_t x = rand();bool y = ((x * x % 4) == 0 || (x * x % 4) == 1);if ( !y ) junk_code();else foo2();那么如果编译器、反编译器没有相应的辨认机制的话，这一部分的死代码就保留了下来，通过在死代码外面插入大量烦扰指令，能够为逆向的人员带来极大的困扰。经测试在-O2优化下，Clang 11曾经能够辨认这个规定，然而GCC 5.4无奈辨认。
可逆变换
这里咱们介绍一下目前混同技术中罕用的等价变换形式。
异或
异或规定是最常见的变换，这里不再赘述。
x ^ c ^ c = x;仿射变换（Affine transformation）
咱们先来看一下仿射函数。
上面咱们来看一下理论利用。
因为计算机中的运算属于隐式的模运算，因而会具备一些有意思的性质。如对于一个uint32上的运算，模运算逆元定义如下：
//对于uint32_t a, r_a;//如果满足(a * r_a) % UINT32_MAX == 1;//那么 a 和 r_a 互为模反元素对于互为模反元素的a和r_a（可通过扩大欧几里得算法求得），有这样的个性：
uint32_t x = rand();uint32_t y1 = a * x + c;//那么满足x == ra * y1 + (- ra * c)最初举个例子来阐明：
//对于互为模反元素的4872655123 * 3980501275，取uint32_t x = 0xdeadbeef;uint32_t c = 0xbeefbeef;//则 -ra * c = 0x57f38dcb，且((x * 4872655123) + 0xbeefbeef) * 3980501275 + 0x57f38dcb == x/*可在lldb中验证如下(lldb) p/x uint32_t x=0xdeadbeef; (uint32_t)(((x * 4872655123) + 0xbeefbeef) * 3980501275 + 0x57f38dcb)(uint32_t) $8 = 0xdeadbeef*/MBA表达式（Mixed Boolean-Arithmetic Expression）
MBA表达式是把算术运算（+，-，*，/）和位运算（&，|，~）混合在一起用以暗藏本来表达式的混同办法。它基于不同的数学原理存在多种形式，这里次要介绍多项式MBA，这是目前混同技术中最常遇到的模式。
相似的，在Fairplay混同中用到的MBA表达式为：
//OperationSet(+, -, *, &, |, ~)x - c = (x ^ ~c) + ((2 * x) & ~(2 * c + 1)) + 1;而应用MBA进行混同操作次要依附以下两个步骤：
不通明常量（Opaque Constant）
不通明常量是基于MBA混同的办法，用于暗藏数据流中的常量。它应用了置换多项式，是一种在无限域上的可逆多项式。
控制流平坦化
这一部分是逆向工程中探讨的最热门的话题，行将失常的控制流转换等价替换为一个状态机，从而烦扰动态的控制流剖析，业界也有较多的解决方案。同时因为Fairplay DRM中没有显著用到这种类型的混同，不再多探讨。
非间接跳转（Indirect Branch）
将一些基本块的起始地址保留在全局变量中，通过不通明常量的生成，使得反汇编工具和肉眼无奈间接获取到基本块跳转的指标，模型如下：
//记录基本块地址到全局查找表LUTLUT[i] = PC;//执行跳转jmp/call LUT[makeOpaque(i)]具体的实例：
这样，逆向人员就无奈间接获取跳转的指标函数、基本块了。同理，通过将判断语句的条件映射到跳转表，也能够实现对条件跳转的混同。
所以，在逆向被混同的Fairplay代码时，IDA Pro大多数时刻，只能辨认进去函数的第一个基本块，无奈剖析出函数的边界。
跨函数混同 + 调用约定混同
失常状况下，编程语言如C语言的参数传递遵循特定的调用约定，然而局部混同工具会对一些外部函数的调用约定进行批改，以Fairplay DRM为例：
咱们能够看到惯例的以寄存器和栈传递参数的形式被替换成了以堆传递参数的形式了，在结构好了构造体的状况下，这个参数传递的特色能够被清晰的看进去。同时，这里面对一些传递的参数进行了异或混同，在子函数外面再复原进去，使得咱们难以间接失去原始数据，而动态剖析的工具比方IDA Pro也不反对跨函数的数据流剖析。
更重大的是，一些影响子函数运行的重要依赖数据，被晋升到了父函数内，导致在没有复原调用关系前，咱们根本无法揣测子函数的运行流程。
那么，Fairplay DRM的破解之道就是要找到它的弱点。
Fairplay混同的弱点
通过前边的工作，咱们曾经能Fairplay失常的实现关上和解密工作了，通过一系列的动态剖析和追踪调试，咱们发现了这一套混同零碎的一些反抗计划。
这些问题的实质起因是：混同零碎在IR层面设计，对机器相干的局部操作没有混同，因而在生成的机器码外面，咱们能够推断失去混同前的一些特色信息。
函数边界辨认
后面提到，因为Fairplay用到了非间接跳转的混同技术，IDA Pro无奈间接剖析函数的边界。通过跟踪，咱们发现在arm64e设施下，该内核驱动中，同一个函数的所有基本块在运行到跳转指令时，均应用了同一个PAC Context，或者称之为PAC Modifier。
借由这个个性，咱们能够将函数的边界和基本块分组，只管目前为止这些基本块之间并不是连通的。
非间接跳转
对于无条件跳转，咱们通过设置断点跟踪执行流，就能够解决了。
再通过KeyPatch这样的工具，咱们能够将一些简略的函数复原到比拟易于了解的境地。
然而这里的难点在于复原混同外面的非间接跳转指令，如下图所示：
对于这个跳转指令，咱们能够生成如下的表达式：
//cmp x0, #0w10 = qword[x12 + (EQ * 0xB + w19) << 3]//0xB代表两个基本块的在LUT中的下标差通过CSET指令的模式，咱们曾经能够推断跳转指令应该是J.NE或者J.EQ了，通过咱们的调试器插件，咱们能够失去其中一个分支的跳转地址和本来的跳转指令，再通过表达式的信息，咱们能够很快推断出另外一个分支的地址。
再通过Keypatch，咱们能够失去混同前的分支语句构造：
至此，咱们曾经能够残缺地复原Fairplay的大多数控制流了。
数据流混同
这一部分在后面曾经提及到了一些，目前咱们曾经找到了MBA表达式的模式，但还没能找到Fairplay中生成不通明常量的残缺规定。其中MBA表达式的重写规定目前看起来仅有一个，即：
x - c = (x ^ ~c) + ((2 * x) & ~(2 * c + 1)) + 1;一些基于模式匹配的工具，比方D810曾经能够比拟好的解决这样的状况了。
结束语
目前，咱们曾经能够获取到解密每一段Mach-O的AES密钥了，通过大量的调试和反混同，咱们曾经得出了这些密钥生成的初步论断。咱们心愿最终的目标是不依赖Apple设施的前提下，实现Fairplay DRM加解密的钻研。
最初，附上源码，欢送大家进行参考和钻研。
参考文献
- Eyrolles, N. (2017). Obfuscation with Mixed Boolean-Arithmetic Expressions: reconstruction, analysis and simplification tools (Doctoral dissertation, Université Paris-Saclay)
- https://github.com/obfuscator-llvm/obfuscator
- https://github.com/HikariObfuscator/Hikari
- https://github.com/keystone-engine/keypatch
- https://eshard.com/posts/d810_blog_post_1
作者简介
吴聊、落落、朱米，均来自美团信息安全部。
浏览美团技术团队更多技术文章合集
前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试
| 在公众号菜单栏对话框回复【2020年货】、【2019年货】、【2018年货】、【2017年货】等关键词，可查看美团技术团队历年技术文章合集。
| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至tech@meituan.com申请受权。