FairPlay 如何保护 iOS 应用二进制文件，以及一个账号级弱点

摘要

• FairPlay 会加密 iOS Mach-O 二进制文件中由 LC_ENCRYPTION_INFO 或 LC_ENCRYPTION_INFO_64 加载命令声明的区域。内核在缺页时按 4 KB 块解密该区域，并且不会把解密后的页写回文件。这就是过去分析 App Store 应用时要转储运行中内存的原因。
• 每个 IPA 还带有 SC_Info 许可证。SINF 记录封装一个 16 字节的应用专用工作密钥，SUPF 记录为每个 4 KB 页提供一个 16 字节的封装值和一个 16 字节的 IV。页密钥由工作密钥、页记录和文件内偏移派生。
• 公开工具 EthanArbuckle/fairplay-decrypt 表明，整个层级可归结为一个可复用的 16 字节凭据。凭据只需从越狱设备提取一次；之后解密完全离线、确定性执行，不再需要设备。
• 弱点不是密码学被攻破，而是承载式密钥（bearer key）设计：凭据解开每个应用各自的工作密钥，页密钥又从该工作密钥派生，并不是相互独立的秘密。因此，一个凭据可以解锁该账号或注册所拥有的所有应用。
• 第二个项目 DrWhax/unfairplay 从已注册的 Mac 恢复等效模型，并在 macOS 或 Linux 上解密多个 IPA。其 README 说明，模型绑定的是注册，而不是单个应用。
• 我们没有找到已分配的 CVE。2026 年 11 月 12 日对 NVD 的关键词搜索没有返回 fairplay 记录，CISA KEV 目录 2026.11.10 版也没有 FairPlay 条目。这是一种需要越狱设备或已注册 Mac 的 DRM 规避技术，不是远程漏洞利用。
• 请把凭据或模型当作账号秘密。若您为测试获取 IPA，请使用专用账号，加密保存凭据并记录访问，在任务结束后删除。若您开发应用，不要依赖 FairPlay 保守代码或长期秘密的机密性。

为什么需要解密 iOS 二进制文件

自动化 iOS 测试在第一步就会卡住：拿到二进制文件。静态分析、依赖检测、字符串提取和漏洞扫描都需要明文 Mach-O 可执行文件。App Store 交付的 IPA 是加密的，解密后的页只在应用运行时存在。

传统做法依赖越狱设备。分析人员启动应用，等待内核解密其页，然后转储进程内存。OWASP MASTG 关于获取和提取应用的页面描述了这种内存转储方法，并列出 frida-ios-dump。它需要为每次分析准备一台物理设备，依赖对应 iOS 版本的越狱支持，而且很难做到可重复、可审计。

离线路径改变了成本结构。一旦有了可复用凭据，解密就变成 IPA 和凭据的函数。设备只用于获取凭据，不用于逐个解密应用。这就是本文要说明的运营变化，也是账号级范围重要的原因。

Apple 公开了 FairPlay 的哪些内容

Apple 公开的是代码签名，不是应用代码的机密性。其 Platform Security 指南指出，在 iOS、iPadOS、tvOS、visionOS 和 watchOS 上，「these operating systems require that all executable code be signed using an Apple-issued certificate」（Apple，App code signing process，2024 年 12 月 19 日发布，指南 2026 年 8 月更新）。代码签名证明代码由谁构建、未被篡改。它不隐藏代码，重新签名应用也不会移除 FairPlay 加密。

我们查看的代码签名页面和运行时进程安全页面没有描述 FairPlay 或应用二进制加密。我们没有找到记录该机制的 Apple 页面。内核侧在 XNU 源码中公开，但密钥派生、SINF 和 SUPF 格式以及账号凭据属于社区逆向知识。下文每项主张都注明来源。

FairPlay 的三层保护

把 FairPlay 理解为职责不同的三层最合适。代码签名保护完整性。Mach-O 加密保护静态字节。SC_Info 许可证和设备上的 FairPlay 服务决定谁能解密哪个应用。

第一层：代码签名

代码签名是完整性层。它把二进制文件绑定到 Apple 签发的证书和团队标识符，内核拒绝执行验证失败的代码。它不说明读者能否恢复指令。复制 IPA 的攻击者仍然只有加密字节；移除签名的攻击者仍然面对 FairPlay 加密。

第二层：Mach-O 中的加密页

Mach-O 头可以带有 LC_ENCRYPTION_INFO 或 LC_ENCRYPTION_INFO_64。该命令保存 cryptoff（加密区域的文件偏移）、cryptsize（大小）和 cryptid（适用的加密系统）；结构体定义在 Apple 的 Mach-O 加载器头文件中。cryptid 为 1 表示区域已加密；为 0 表示命令为空、区域未加密。SensePost 2011 年的 Decrypting iPhone Apps 展示了相同字段以及它们在早期 iOS 上促成内存转储的工作流。

Apple 公开了内核侧。mach_loader.c 中，parse_machfile() 在同一个分支处理两个加密命令并调用 set_code_unprotect()。若它返回 LOAD_DECRYPTFAIL，内核记录 EXEC_EXIT_REASON_FAIRPLAY_DECRYPT（「failed to load due to missing FP keys」），并用 SIGKILL 终止非 spawn 的 exec。vm_apple_protect.c 中，解密在外部内存管理器中运行，该管理器「handles memory from the encrypted sections of some executables protected by the DSMOS kernel extension」。缺页时它通过 page_decrypt 回调按 4 KB 块解密，源码说明「the decrypted pages will never be dirtied」：原始页保持干净，明文只存在于内存。

最后这一点解释了内存转储为何能流行多年。它也是离线解密工具复现的性质：计算相同的页密钥，把明文写入文件副本。

第三层：许可证与密钥材料

App Store 的 IPA 带有 SC_Info/ 目录。Noham 对破解 iOS 应用的分析把它描述为「Apple's FairPlay DRM stores iTunes Store licensing metadata」的位置，包含 Manifest.plist、.sinf、.supf、.supp 和 .supx 文件，并指出「Not much is documented publicly about the internal FairPlay file formats」。因此，下文角色来自公开工具和第三方分析，而不是 Apple 规范。

SINF 是 MPEG-4 风格的 atom 树。这里重要的字段是：

• user 和 key：两个 4 字节选择器，标识账号和许可证记录。
• iviv：一个 16 字节值，与应用名一起用于派生 IV。
• priv：一个 440 或 448 字节的记录，封装应用的 16 字节工作密钥。
• name 和 sign：应用名和签名。

SUPF 是页表。fairplay-decrypt 的 README 说明它支持版本 3 和 5 的 SUPF、448 字节和 440 字节的 SINF priv 记录，以及加密的 arm64 Mach-O 切片。代码中，版本 3 的 SUPF 有 32 字节的按架构头，版本 5 有 12 字节头；随后每个页得到一个 32 字节记录，由 16 字节封装值和 16 字节 IV 组成（core.py）。

许可证是账号与应用之间的桥梁。SINF 把应用绑定到账号和许可证选择器；SUPF 描述知道应用工作密钥后如何派生页密钥。下一节展示公开工具如何把这两个文件变成明文。

离线解密工具如何恢复应用密钥

工具分两个阶段。第一阶段从越狱设备提取可复用凭据。第二阶段用该凭据、SINF 和 SUPF 在普通主机上解密 IPA。本节是我们对公开代码的解读；Apple 没有公开这些内容。

第一阶段：从设备提取 16 字节凭据

credential-retrieval 组件支持 iOS 10 及更高版本，需要一台已配对、可 root SSH 的越狱设备，以及至少一个从该账号安装的应用（credential-retrieval README）。提取器会：

1. 用 task_for_pid() 附加到 fairplayd，并在 IOConnectCallStructMethod 上安装硬件断点（observer.c）。它保留其他调试器的观察点，并规避源码中提到的 XNU 8792 调试寄存器重载问题。
2. 运行触发器，映射一个加密可执行文件并调用 mremap_encrypted()，请求内核为该可执行文件建立 FairPlay 解密。触发器注释说它请求「FairPlay's first-use path without running or copying decrypted code」（trigger.c）。因此提取过程不需要执行目标应用。
3. 读取设备的 IC-Info.sidb，用从设备 UDID 派生的密钥解密它，并选择 SINF 的 user 和 key 记录（credential.c）。
4. 把 FairPlay 调用中观察到的 16 字节值、由 UDID、账号和密钥选择器派生的上下文，以及工具附带的 4 KB 字表组合起来，写入 credential.bin。

这一步需要设备。关键在于之后：16 字节输出是独立值。解密不再调用设备、fairplayd 或 FairPlayIOKit。

提取代码包含版本相关知识。它根据 iOS 版本选择 FairPlay 选择器 9 或 21，并带有与 iOS 16.3.1 新 UDID 格式相关的注释。README 声明支持 iOS 10 及更高版本，但目标是移动的：fairplayd 的改动可能破坏提取器，却不改变解密格式。

第二阶段：离线派生工作密钥和所有页密钥

离线解密器是纯 Python，可在 macOS 和 Linux 上运行（README）。它把 IPA 当作 ZIP 打开，将每个 .supf 或 .v5.supf 与对应二进制和 SINF 配对，跳过没有加密 arm64 切片的二进制。对每个加密切片做三件事。

首先，从 SINF 的 priv 记录解出 16 字节工作密钥：

iv = MD5(name || iviv)
work = AES-CBC-decrypt(credential XOR bytes([0x30] * 16), iv, priv)[24:40]

代码检查解密记录以 itun 开头、在偏移 20 处包含 key、在偏移 44 处包含 iviv，然后取偏移 24 处的 16 字节密钥。凭据错误时标记检查失败，工具停止；不会尝试暴力破解（core.py）。

其次，为每个 4 KB 页派生页密钥。SUPF 记录给出 16 字节封装值和 16 字节 IV。代码用封装值和文件内绝对页偏移构造三个 16 字节块，分别用工作密钥做 AES-128-ECB 加密，再把三个 16 字节结果送入一个由 16 位加法、乘法和 XOR 组成的自定义混合函数。输出就是页密钥。页偏移是输入的一部分，因此把页记录移到另一个偏移会产生不同密钥。

最后，用该页密钥和 SUPF 的 IV 做 AES-128-CBC 解密，把明文写入输出副本，并把 cryptid 设为 0。结果是一个可执行页为明文的 IPA（core.py、decrypt.py）。

整个流程是确定性的。没有 Apple 提供的随机 nonce、服务器挑战、设备证明或每次启动的秘密。唯一的秘密输入是 16 字节凭据；其余都来自 IPA。

密钥层级在哪里失效

密钥层级在根部失效，而不是在密码算法。一个 16 字节凭据解开每个应用的工作密钥，工作密钥再派生该应用的所有页密钥。页密钥提供域分离：一个页的密钥不能解密另一个偏移的页。但它们都来自同一个工作密钥，因此不提供独立机密性。

三个性质把这张表变成账号级弱点。

一个凭据覆盖多个应用。 每个应用有自己的 SINF 和工作密钥，但同一个凭据能解开所有这些密钥。UnfairPlay 明确说明了后果：「One model can decrypt different IPAs personalized for the same enrollment. Each app still has its own key inside its personalized SINF.」按应用的密钥限制单个工作密钥泄露的损失，但不限制凭据泄露的损失。

派生是确定性的、离线的。 凭据存在后，IPA 包含其余一切：封装的工作密钥、页记录、IV 和偏移。解密时没有第二因素。笔记本电脑、CI runner 或备份中的凭据副本与原件等价。

凭据是承载式值。 仓库没有过期或吊销逻辑。Apple 是否在服务端使材料失效，公开代码无法确定。工具 README 警告凭据属于拥有 IPA 的账号，UnfairPlay 要求把模型保持私有，只备份到加密存储。这是正确的建议，也是对风险的描述：任何持有该值的人都能使用它。

什么不是弱点也很重要。AES-128-CBC 没有被攻破。MD5 调用从公开值派生 IV，不是机密性边界。自定义混合函数只是晦涩，不是安全证明，公开代码已经重新实现它。Apple 对 fairplayd 的混淆提高了提取成本：Nicolò Altamura 对 macOS 13.5.1 的静态分析描述了不透明谓词、控制流平坦化和混合布尔算术常量，认为不透明谓词较弱、控制流平坦化有效。混淆改变的是获取凭据的难度，不是获取后凭据能做什么。

一个凭据能走多远

第一步是一个应用。第二步是账号的库。第三步是自动化流水线。每一步都是同一设计的后果。

• 从一个应用到多个应用。 凭据对来自其账号或注册的应用有效。根据 fairplay-decrypt 的 README，普通 App Store 应用和 Apple Arcade 应用使用不同凭据，因此 Arcade 库需要单独提取。在同一类内，凭据并不绑定到某个 bundle 标识符。
• 从 iPhone 到 Mac。 UnfairPlay 从已注册的 Mac 而不是越狱 iPhone 恢复模型。README 说明模型绑定 Mac App Store 注册，可以解密为同一注册个性化的其他 IPA。解密随后在 macOS 或 Linux 上运行，工具不会启动原生 fairplayd。这是同一信任集中问题的另一个捕获点。
• 从手工到 CI。 离线解密是 IPA 和凭据的纯函数。它可以容器化、排队、重试和审计。安全团队无需连接设备即可分析应用；攻击者无需设备农场即可重新打包。双方成本都下降。
• 从明文到影响。 页变成明文后，应用就是普通 Mach-O。分析人员可以读取端点、内嵌密钥、功能标志和许可证逻辑；比较两个版本；发现漏洞；修改检查；注入 dylib；或重建被修改的应用。FairPlay 是机密性屏障，不是完整性屏障。代码签名对安装仍然重要，但不会让恢复的代码重新变成秘密。
• 从一个凭据到一个库。 影响范围是账号，不是应用。共享测试账号、经销商账号或 CI 秘密可能覆盖大量目录。一个泄露的 credential.bin 或模型文件即可解锁该账号或注册能解密的所有应用。这是丢失一个二进制文件与丢失一个集合的区别。

账号级设计过去也以另一种方式失败过。Unit 42 2016 年的 AceDeceiver 报告描述了一个 FairPlay 中间人攻击，它重放存储的购买授权，在没有企业证书的情况下安装应用，并称其为「the first iOS malware we've seen that abuses certain design flaws in Apple's DRM protection mechanism」。Apple 于 2016 年 2 月 25 日从 App Store 下架了这三个应用。AceDeceiver 滥用的是安装授权，不是离线解密，因此它是账号级 FairPlay 设计问题的先例，而不是对这款工具的描述。

我们没有找到分配给解密设计的 CVE。2026 年 11 月 12 日对 NVD 的 fairplay 关键词搜索没有返回记录，CISA KEV 目录 2026.11.10 版也没有 FairPlay 条目。这与公开工具展示的设计属性一致，而不是有修复版本的厂商软件漏洞。

防御方和开发者应该做什么

如果您为授权测试获取 IPA，凭据现在是流水线中最敏感的文件。请把它当作账号秘密，因为它确实是。

• 为测试项目使用专用 Apple Account。不要复用个人账号、共享团队账号或持有生产购买的账号。
• 把 credential.bin 或 UnfairPlay 模型放入密钥管理器，静态加密，记录访问并指定负责人。不要放进仓库、构建日志或工单。
• 限制谁可以运行解密、哪些 IPA 进入队列。记录每次运行的账号、应用和日期，以便审计使用情况。
• 任务结束后轮换或停用账号。公开代码没有过期开关，因此运营控制就是停止使用凭据并删除它。
• 共享结果时移除账号数据。UnfairPlay 的 --strip-account-data 选项会删除 SC_Info 成员以及 iTunesMetadata.plist 中的 Apple ID 和购买者字段；但 README 仍指出，脱敏并不授权再分发。
• 不要在授权范围外共享 SINF、SUPF、SIDB、模型文件或解密后的 IPA。许可证文件会标识账号，模型可被复用。

如果您开发 iOS 应用，请假设有决心的分析人员最终能拿到二进制文件。FairPlay 提高成本，但不会让客户端代码成为秘密。

• 不要在应用中放入长期 API 密钥、私钥、服务器凭据或签名材料。把有价值的逻辑和秘密移到您控制的服务器。
• 在风险需要时，使用与用户和设备绑定的短期令牌、服务端授权和设备证明。Certificate pinning 提高拦截成本，但不保护已经在二进制文件中的秘密。
• 把客户端许可证检查当作用户体验，而不是安全边界。被修改的二进制文件可以绕过它们，解密后的二进制文件让修改更容易。
• 让服务器对权利、速率限制和付费功能保持权威。如果某项功能不能被复制，就在用户无法编辑代码的地方强制执行。

平台侧的修复是设计变更，不是我们可以引用的补丁。厂商可以在每次启动时把页密钥绑定到设备持有的秘密，签发短期许可证材料并在服务端轮换，让账号凭据无法从安全硬件导出，并检测调试器或异常端口对 fairplayd 的附加。任何在用户控制的设备上解密代码的方案，最终都必须把密钥交给该设备；目标是让密钥按启动、按设备、短期有效，而不是假装客户端解密可以做到绝对安全。

对用户来说，实际建议更有限。为 Apple Account 启用双重认证，不要共享账号，不要安装来源不可信的 IPA。本文的主要风险是应用代码的机密性和共享账号的影响范围，而不是锁定手机的远程入侵。

哪些内容无法验证

• Apple 对 App Store 二进制文件的精确密钥派生方案，以及 SINF priv 工作密钥是按应用、按账号还是按交易唯一。公开工具的行为是证据；Apple 没有发布规范。
• Apple 是否在服务端轮换或吊销账号凭据。公开代码没有过期或吊销逻辑，但无法从仓库排除服务端失效。
• 在当前 iOS 版本上的行为。提取器 README 声明 iOS 10 及更高版本，代码包含 iOS 16.3.1 专用注释，但我们没有在设备上测试。fairplayd 的改动可能破坏提取，却不改变离线格式。
• UnfairPlay 模型恢复的内部实现。我们阅读了其 README 和公开保证，没有阅读全部恢复代码。
• 工具支持范围之外的 SINF 和 SUPF 精确布局：版本 3 和 5 的 SUPF、440 和 448 字节的 priv、arm64 切片。可能存在其他版本。
• 使用中的账号、应用或凭据数量。没有公开遥测，仓库的 star 和 fork 数衡量的是兴趣，不是利用。
• FairPlay Streaming 视频是否使用相同密钥层级。Rafi、Shepherd 和 Markantonakis 2023 年的学术调查涵盖包括 FairPlay 的移动 DRM，但重点是流媒体内容，不是 App Store IPA 二进制文件；因此它是背景，不是这条路径的证据。

常见问题

FairPlay 应用解密有 CVE 吗

我们没有找到。2026 年 11 月 12 日对 NVD 的 fairplay 关键词搜索没有返回记录，CISA KEV 目录 2026.11.10 版也没有 FairPlay 条目。公开工具及其展示的设计没有被登记为 CVE。

这是越狱漏洞利用吗

不是。它不利用内核内存破坏漏洞。它需要越狱设备上的 root 访问权限来附加到 fairplayd 并观察 FairPlay 调用。解密本身是离线的，不需要越狱。

一个凭据能解密世界上所有 IPA 吗

不能。凭据限定于产生它的账号或注册，每个应用的 SINF 都为该范围个性化。根据 fairplay-decrypt 的 README，Apple Arcade 应用需要与普通 App Store 应用不同的凭据。弱点是单个账号内的广度，不是全球密钥。

它会影响 FairPlay Streaming 视频吗

尚未确定。公开工具针对 App Store IPA 二进制文件及其 SINF/SUPF 许可证。FairPlay Streaming 是独立的媒体路径，涵盖它的 2023 年调查只是背景，不能证明同一凭据能解密视频。

Apple 能修复吗

Apple 可以改变设计：在每次启动时把密钥绑定到设备秘密，缩短许可证寿命，在服务端轮换材料，让凭据无法导出，并加固 FairPlay IPC。任何客户端解密都必须把密钥交给播放内容的设备；实际目标是缩短密钥的寿命和范围，而不是在绝对意义上让它无法提取。

它是否已在野利用

截至 2026 年 11 月 12 日，项目或已审查来源中没有报告使用该工具的攻击。该日期仓库有超过 2,400 个 star 和 370 个 fork，UnfairPlay 有超过 1,100 个 star。这些数字表明关注度，而不是利用。

参考资料

• EthanArbuckle/fairplay-decrypt，README，2026 年 10 月 19 日创建，最后提交 2026 年 11 月 8 日：https://github.com/EthanArbuckle/fairplay-decrypt （2026 年 11 月 12 日查看）
• core.py，SINF priv 解包、SUPF 解析、页密钥派生和 cryptid 清零：https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/core.py （2026 年 11 月 12 日查看）
• decrypt.py，IPA ZIP 处理和逐二进制计划：https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/decrypt.py （2026 年 11 月 12 日查看）
• credential-retrieval/README.md，iOS 10 及更高版本、Apple Arcade 凭据分离和设备要求：https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/README.md （2026 年 11 月 12 日查看）
• credential.c，SIDB 解密、user/key 选择和凭据派生：https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/credential/credential.c （2026 年 11 月 12 日查看）
• observer.c，task_for_pid()、硬件断点和 XNU 8792 规避：https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/credential/observer.c （2026 年 11 月 12 日查看）
• trigger.c，mremap_encrypted() 首次使用请求及其注释：https://github.com/EthanArbuckle/fairplay-decrypt/blob/main/credential-retrieval/trigger/trigger.c （2026 年 11 月 12 日查看）
• DrWhax/unfairplay，README，注册模型、多 IPA 范围、macOS/Linux 解密和 --strip-account-data：https://github.com/DrWhax/unfairplay （2026 年 11 月 12 日查看）
• Apple，App code signing process in iOS, iPadOS, tvOS, visionOS, and watchOS，2024 年 12 月 19 日发布：https://support.apple.com/guide/security/app-code-signing-process-sec7c917bf14/web （2026 年 11 月 12 日查看）
• Apple，Security of runtime process in iOS, iPadOS, and visionOS，2024 年 12 月 19 日发布：https://support.apple.com/guide/security/security-of-runtime-process-sec15bfe098e/web （2026 年 11 月 12 日查看）
• Apple XNU，bsd/kern/mach_loader.c，set_code_unprotect()、LOAD_DECRYPTFAIL 和 EXEC_EXIT_REASON_FAIRPLAY_DECRYPT：https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/mach_loader.c （2026 年 11 月 12 日查看）
• Apple XNU，osfmk/vm/vm_apple_protect.c，外部内存管理器和 4 KB page_decrypt 循环：https://github.com/apple-oss-distributions/xnu/blob/main/osfmk/vm/vm_apple_protect.c （2026 年 11 月 12 日查看）
• Apple XNU，EXTERNAL_HEADERS/mach-o/loader.h，encryption_info_command 字段：https://github.com/apple-oss-distributions/xnu/blob/main/EXTERNAL_HEADERS/mach-o/loader.h （2026 年 11 月 12 日查看）
• SensePost，「Decrypting iPhone Apps」，2011 年 10 月 24 日，cryptid 字段和内存转储方法：https://sensepost.com/blog/2011/decrypting-iphone-apps/ （2026 年 11 月 12 日查看）
• Noham，「Anatomy of an iOS crack」，2026 年 5 月 15 日，SC_Info 文件和 SINF 字段布局：https://noh.am/en/posts/rev-dylib/ （2026 年 11 月 12 日查看）
• pwn0rz，fairplay_research，FairPlayIOKit/fairplayd 流程和硬件 AES 阶段：https://github.com/pwn0rz/fairplay_research （2026 年 11 月 12 日查看）
• Nicolò Altamura，「Analysis of Obfuscation Found in Apple FairPlay」，2023 年 8 月 28 日，macOS 13.5.1：https://nicolo.dev/en/blog/fairplay-apple-obfuscation/ （2026 年 11 月 12 日查看）
• Unit 42，Claud Xiao，「AceDeceiver: First iOS Trojan Exploiting Apple DRM Design Flaws to Infect Any iOS Device」，2016 年 3 月 16 日：https://unit42.paloaltonetworks.com/acedeceiver-first-ios-trojan-exploiting-apple-drm-design-flaws-to-infect-any-ios-device/ （2026 年 11 月 12 日查看）
• NVD 对 fairplay 的关键词搜索，零记录：https://nvd.nist.gov/vuln/search/results?query=fairplay&search_type=all （2026 年 11 月 12 日查看）
• CISA，Known Exploited Vulnerabilities 目录，2026.11.10 版，无 FairPlay 条目：https://www.cisa.gov/known-exploited-vulnerabilities-catalog （2026 年 11 月 12 日查看）
• Amir Rafi、Carlton Shepherd 和 Konstantinos Markantonakis，「A First Look at Digital Rights Management Systems for Secure Mobile Content Delivery」，arXiv:2308.00437，2023 年 8 月：https://arxiv.org/abs/2308.00437 （2026 年 11 月 12 日查看）