[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f39olgbpkdg8lo":3},{"code":4,"message":5,"data":6,"timestamp":35},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":26,"summary_md":27,"topic":28,"github_topics":31,"license":32,"homepage":32,"updated_at":33,"history":34},"EthanArbuckle\u002Ffairplay-decrypt",16,"Offline FairPlay App Store IPA decryption with independent key derivation","C",1959,304,349,5,[16,22],{"id":17,"title":18,"points":19,"comments":20,"posted_at":21},50203519,"Offline FairPlay DRM Decryption",24,2,"2026-10-23",{"id":23,"title":9,"points":24,"comments":25,"posted_at":21},50210834,6,0,"用账号凭据在本地离线解密 App Store 的 FairPlay 加密 IPA。","## 解决什么问题\n\n安全研究、逆向和第三方 App 审计经常需要检查 App Store 应用的真实二进制，但商店发下来的 IPA 里 arm64 切片是 FairPlay 加密的，只靠包本身拿不到可分析的代码。常见做法是越狱后用 frida-ios-dump、Clutch 之类的工具在设备内存里把解密后的镜像 dump 出来，这既要求物理接触设备，也要在目标进程里注入代码。这个项目换了个思路：拿到拥有该 IPA 的账号的 16 字节凭据后，用 IPA 自带的 SINF 和 SUPF 记录推导页密钥，在 macOS 或 Linux 上离线解密 arm64 页面，整个过程不需要设备参与。\n\n## 有什么不同\n\n和 frida-ios-dump、Clutch 这类在设备上拦截内存镜像的方案相比，它把工作搬到了宿主机，解密是一个可脚本化的本地批处理任务；代价是能力被收窄——只支持 version-3\u002Fversion-5 SUPF、448 字节和 440 字节的 SINF priv 记录，以及加密的 arm64 Mach-O 切片。它仍然需要有效凭据，配套的 credential-retrieval 工具还要从受支持的越狱设备上提取。所以它的取舍是：把设备上的动作压缩成一次性凭据提取，而不是一整轮 crack 会话。\n\n## 适合谁\n\n适合已经有越狱设备能取凭据、并且希望在工作站上离线、可复现地解密 IPA 的安全团队、DRM\u002F密钥推导研究者和逆向工程师。只是想在没有越狱的手机上看看字符串的人不适合，凭据这一关绕不过去；Windows 用户，或者手中 IPA 只带非 arm64 切片的场景，也应该另找方案。\n\n## 上手成本\n\n需要 Python 3.9+ 和 requirements.txt 里的依赖；macOS 上构建 credential-retrieval 还需要 Xcode 和 ldid。越狱设备是获取凭据的硬性前提。项目才 5 天，README 很短、范围写得很克制，而且没有声明许可证——如果要商用或再分发，这是实打实的问题。合法性和 App Store 条款需要自行评估，README 里对此只字未提。\n\n## 点评\n\n这是一个全新项目，谈不上成熟：创建 5 天、约 1,944 stars，首个追踪周期日均新增约 357 stars。它没上过每日 trending 榜，Hacker News 也只有 24 分的讨论，热度更像是话题和新奇感驱动的短时冲高。技术路线干净、边界清晰，但未声明许可证、依赖越狱设备且单一平台、时间记录极短，意味着它适合放在沙箱里评估，而不是直接依赖。",{"slug":29,"name":30},"security","安全",[],null,"2026-10-24T22:35:35Z",[],1792898642]