FairPlayはiOSアプリのバイナリをどう守るのか、そしてアカウント単位の弱点

要点

• FairPlayは、LC_ENCRYPTION_INFOまたはLC_ENCRYPTION_INFO_64ロードコマンドが宣言するiOS Mach-Oバイナリの範囲を暗号化します。カーネルはページフォールトのたびにその範囲を4 KB単位で復号し、復号済みページをファイルへ書き戻しません。そのため、App Storeアプリを解析する従来の方法は、実行中のメモリをダンプすることでした。
• 各IPAはSC_Infoライセンスも持ちます。SINFレコードはアプリ固有の16バイトの作業鍵を包み、SUPFレコードは4 KBページごとに16バイトの包まれた値と16バイトのIVを提供します。ページ鍵は作業鍵、ページレコード、ファイル内のオフセットから導出されます。
• 公開ツールEthanArbuckle/fairplay-decryptは、鍵階層が1つの再利用可能な16バイト資格情報に集約されることを示しています。資格情報はジェイルブレイク済み端末から一度だけ抽出され、その後はオフラインで決定論的に復号でき、端末は不要です。
• 弱点は暗号の破綻ではありません。持ち運び可能な鍵（bearer key）の設計です。資格情報が各アプリの異なる作業鍵を解錠し、ページ鍵はその作業鍵から導出されるのであって、独立した秘密ではありません。したがって1つの資格情報が、そのアカウントまたは登録が持つ全アプリを解錠します。
• 2つ目のプロジェクトDrWhax/unfairplayは、登録済みMacから同等のモデルを回収し、macOSまたはLinuxで複数のIPAを復号します。READMEは、モデルが1つのアプリではなく登録に紐づくと説明しています。
• CVEは見つかりませんでした。2026年11月12日のNVDキーワード検索でfairplayのレコードは0件、CISA KEVカタログ2026.11.10版にもFairPlayの項目はありません。ジェイルブレイク済み端末または登録済みMacを必要とするDRM回避手法であり、リモートexploitではありません。
• 資格情報やモデルはアカウントの秘密として扱ってください。テスト用に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の3層構造

FairPlayは役割の異なる3層として理解するのが適切です。コード署名は完全性を守ります。Mach-O暗号化は保存時のバイト列を守ります。SC_Infoライセンスと端末のFairPlayサービスが、誰がどのアプリを復号できるかを決めます。

第1層：コード署名

コード署名は完全性の層です。バイナリをApple発行の証明書とチームIDに結びつけ、カーネルは検証に失敗したコードの実行を拒否します。読み手が命令を回収できるかどうかは示しません。IPAをコピーした攻撃者には暗号化されたバイト列が残り、署名を外した攻撃者にはFairPlay暗号化が残ります。

第2層：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」）を記録し、spawnでないexecをSIGKILLで終了します。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」と述べています。元のページはクリーンなままで、平文はメモリにだけ存在します。

この性質が、長年にわたりメモリダンプが機能した理由です。また、オフライン復号ツールが再現する性質でもあります。同じページ鍵を計算し、ファイルのコピーに平文を書き込みます。

第3層：ライセンスと鍵素材

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風のアトム木です。ここで重要なフィールドは次のとおりです。

• userとkey：アカウントとライセンスレコードを識別する4バイトのセレクター。
• iviv：アプリ名とともにIVを導出する16バイトの値。
• priv：アプリの16バイト作業鍵を包む440バイトまたは448バイトのレコード。
• nameとsign：アプリ名と署名。

SUPFはページテーブルです。fairplay-decryptのREADMEは、バージョン3と5のSUPF、448バイトと440バイトのSINF privレコード、暗号化されたarm64 Mach-Oスライスをサポートすると述べています。コードでは、バージョン3のSUPFは32バイトのアーキテクチャ別ヘッダー、バージョン5は12バイトのヘッダーを持ち、各ページに16バイトの包まれた値と16バイトのIVからなる32バイトのレコードが続きます（core.py）。

ライセンスはアカウントとアプリの橋渡しです。SINFはアプリをアカウントとライセンスセレクターに結びつけ、SUPFはアプリの作業鍵が分かった後にページ鍵を導出する方法を記述します。次の節では、公開ツールがこの2つのファイルを平文に変える方法を示します。

オフライン復号ツールはアプリ鍵をどう復元するか

ツールは2段階です。第1段階はジェイルブレイク済み端末から再利用可能な資格情報を抽出します。第2段階はその資格情報、SINF、SUPFを使って通常のホストでIPAを復号します。この節は公開コードの読み解きであり、Appleは何も公開していません。

第1段階：端末から16バイトの資格情報を抽出する

credential-retrievalコンポーネントはiOS 10以降をサポートし、ペアリング済みのジェイルブレイク端末、root SSHアクセス、そのアカウントからインストールされた少なくとも1つのアプリを必要とします（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を選び、 新しい形式のUDIDについてはiOS 16.3.1に紐づくコメントを持ちます。READMEはiOS 10以降と述べていますが、対象は動きます。fairplaydの変更は復号形式を変えずに回収ツールを壊し得ます。

第2段階：作業鍵と全ページ鍵をオフラインで導出する

オフライン復号ツールは純粋なPythonで、macOSとLinuxで動作します（README）。IPAをZIPとして開き、各.supfまたは.v5.supfを対応するバイナリとSINFに結びつけ、暗号化されたarm64スライスがないバイナリを飛ばします。暗号化スライスごとに3つの処理を行います。

まず、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を与えます。コードは包まれた値とファイル内の絶対ページオフセットから3つの16バイトブロックを作り、それぞれを作業鍵でAES-128-ECB暗号化し、3つの16バイト結果を16ビットの加算・乗算・XORで構成された独自の混合関数に通します。出力がページ鍵です。ページオフセットは入力の一部なので、別のオフセットへ移動したページレコードは別の鍵を生みます。

最後に、そのページ鍵とSUPFのIVでAES-128-CBC復号し、平文を出力コピーに書き込み、cryptidを0にします。結果は実行ページが平文になったIPAです（core.py、decrypt.py）。

パイプライン全体は決定論的です。Appleからのランダムなnonce、サーバーチャレンジ、端末証明、起動ごとの秘密はありません。唯一の秘密入力は16バイトの資格情報で、それ以外はすべてIPAから得られます。

鍵階層はどこで破綻するか

鍵階層は暗号ではなく根元で破綻します。1つの16バイト資格情報が各アプリの作業鍵を解錠し、作業鍵がそのアプリの全ページ鍵を導出します。ページ鍵はドメイン分離を与えます。あるページの鍵で別のオフセットのページを復号することはできません。しかしすべて同じ作業鍵から来るため、独立した機密性は与えません。

3つの性質がこの表をアカウント単位の弱点に変えます。

1つの資格情報が複数アプリを覆う。 各アプリは独自のSINFと作業鍵を持ちますが、同じ資格情報がそのすべてを解錠します。UnfairPlayはその帰結を明確に述べています。「One model can decrypt different IPAs personalized for the same enrollment. Each app still has its own key inside its personalized SINF.」アプリごとの鍵は1つの作業鍵の漏えいの被害を限定しますが、資格情報の漏えいの被害は限定しません。

導出は決定論的でオフライン。 資格情報が存在すれば、IPAに残りすべてが含まれます。包まれた作業鍵、ページレコード、IV、オフセットです。復号時に第二要素はありません。ノートPC、CIランナー、バックアップ上の資格情報のコピーは、原本と同じ価値を持ちます。

資格情報は持ち運び可能な値。 リポジトリには有効期限や失効のロジックがありません。Appleがサーバー側で材料を無効化するかは、公開コードでは確定できません。ツールのREADMEは、資格情報がIPAを所有するアカウント用であると警告し、UnfairPlayはモデルを非公開にし、暗号化ストレージにのみバックアップするよう求めています。これは正しい助言であり、リスクの説明でもあります。値を保持する誰もが使えます。

弱点でないものも重要です。AES-128-CBCは破られていません。MD5呼び出しは公開値からIVを導出するもので、機密性の境界ではありません。独自の混合関数は難読化であって安全性の証明ではなく、公開コードが再実装しています。Appleによるfairplaydの難読化は抽出コストを上げます。Nicolò AltamuraのmacOS 13.5.1の静的解析は、不透明述語、制御フローの平坦化、混合ブール算術定数を説明し、不透明述語は弱いが制御フローの平坦化は有効と評価しています。難読化は資格情報の取得難易度を変えますが、取得後の資格情報の能力は変えません。

1つの資格情報はどこまで届くか

最初の一歩は1つのアプリです。次はアカウントのライブラリです。その次は自動化パイプラインです。各段階は同じ設計の帰結です。

• 1つのアプリから多数へ。 資格情報は、それが由来するアカウントまたは登録のアプリに有効です。通常のApp StoreアプリとApple Arcadeアプリは別の資格情報を使うとfairplay-decryptのREADMEは述べており、Arcadeライブラリには独自の抽出が必要です。同じクラス内では、資格情報はバンドル識別子に縛られません。
• iPhoneからMacへ。 UnfairPlayはジェイルブレイク済みiPhoneではなく、登録済みMacからモデルを回収します。READMEは、モデルがMac App Storeの登録に紐づき、同じ登録向けに個人化された他のIPAを復号できると述べています。復号はmacOSまたはLinuxで実行され、ネイティブのfairplaydはツールが起動しません。同じ信頼の集中を別の取得点から見たものです。
• 手作業からCIへ。 オフライン復号はIPAと資格情報の純粋関数です。コンテナで実行し、キューに入れ、再試行し、監査できます。セキュリティチームは端末を接続せずにアプリを解析でき、攻撃者は端末ファームなしで再パッケージできます。双方のコストが下がります。
• 平文から影響へ。 ページが平文になれば、アプリは通常のMach-Oです。解析者はエンドポイント、埋め込まれた鍵、機能フラグ、ライセンスロジックを読み、2つのバージョンを比較し、脆弱性を見つけ、チェックを書き換え、dylibを注入し、改変アプリを再構築できます。FairPlayは機密性の障壁であり、完全性の障壁ではありませんでした。コード署名はインストールに依然として重要ですが、回収したコードを再び秘密にはしません。
• 1つの資格情報からライブラリへ。 影響範囲はアプリではなくアカウントです。共有テストアカウント、転売アカウント、CIの秘密が大きなカタログを覆うことがあります。1つのcredential.binまたはモデルファイルの漏えいが、そのアカウントまたは登録が復号できる全アプリを解錠します。1つのバイナリを失うことと、コレクションを失うことの違いです。

アカウント単位の設計は別の形でも過去に失敗しています。Unit 42の2016年のAceDeceiver報告は、保存された購入認可を再生してエンタープライズ証明書なしにアプリをインストールするFairPlay man-in-the-middleを説明し、「the first iOS malware we've seen that abuses certain design flaws in Apple's DRM protection mechanism」と評しています。Appleは2016年2月25日に3つのアプリをApp Storeから削除しました。AceDeceiverはインストール認可を悪用したのであり、オフライン復号ではありません。アカウント単位のFairPlay設計問題の前例ではありますが、このツールの説明ではありません。

復号設計にCVEは見つかりませんでした。2026年11月12日のNVDのfairplayキーワード検索は0件で、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の2要素認証を有効にし、アカウントを共有せず、信頼できない提供元のIPAをインストールしないでください。本記事の主なリスクはアプリコードの機密性と共有アカウントの影響範囲であり、ロックされた端末のリモート侵害ではありません。

検証できなかったこと

• App Storeバイナリに対するAppleの正確な鍵導出方式、およびSINF privの作業鍵がアプリごと、アカウントごと、取引ごとのどれで一意か。公開ツールの動作が証拠であり、Appleは仕様を公開していません。
• Appleがアカウント資格情報をサーバー側でローテーションまたは失効させるか。公開コードに有効期限や失効のロジックはありませんが、サーバー側の無効化をリポジトリから排除はできません。
• 現在のiOSでの動作。回収ツールのREADMEはiOS 10以降と述べ、コードにはiOS 16.3.1固有の注記がありますが、端末でテストしていません。fairplaydの変更はオフライン形式を変えずに回収を壊し得ます。
• UnfairPlayのモデル回収の内部。READMEと公表された保証を読み、回収コード全体は読んでいません。
• ツールがサポートする範囲を超えたSINFとSUPFの正確なレイアウト。バージョン3と5のSUPF、440バイトと448バイトのpriv、arm64スライスです。他のバージョンが存在する可能性があります。
• 使用中のアカウント、アプリ、資格情報の数。テレメトリは公開されておらず、リポジトリのスターとフォークは関心を示すもので、悪用を示しません。
• FairPlay Streamingの動画が同じ鍵階層を使うか。Rafi、Shepherd、Markantonakisの2023年の学術調査はFairPlayを含むモバイルDRMを扱いますが、焦点はストリーミングコンテンツであり、App Store IPAバイナリではありません。この経路の証拠ではなく文脈です。

FAQ

FairPlayアプリ復号にCVEはあるか

見つかりませんでした。2026年11月12日のNVDのfairplayキーワード検索は0件で、CISA KEVカタログ2026.11.10版にFairPlayの項目はありません。公開ツールとそれが示す設計はCVEとして追跡されていません。

これはジェイルブレイクのexploitか

いいえ。カーネルのメモリ破壊脆弱性を悪用しません。ジェイルブレイク済み端末のrootアクセスでfairplaydにアタッチし、FairPlay呼び出しを観測する必要があります。復号自体はオフラインで、ジェイルブレイクを必要としません。

1つの資格情報ですべてのIPAを復号できるのか

いいえ。資格情報はそれを生成したアカウントまたは登録に限定され、各アプリのSINFはその範囲に個人化されています。Apple Arcadeアプリは通常のApp Storeアプリとは別の資格情報を必要とするとfairplay-decryptのREADMEは述べています。弱点は1つのアカウント内の広さであり、グローバルな鍵ではありません。

FairPlay Streamingの動画に影響するか

確定していません。公開ツールはApp Store IPAバイナリとそのSINF/SUPFライセンスを対象にします。FairPlay Streamingは別のメディア経路であり、それを扱う2023年の調査は文脈であって、同じ資格情報が動画を復号する証拠ではありません。

Appleは修正できるか

Appleは設計を変えられます。起動ごとに鍵を端末の秘密に結びつけ、ライセンスの寿命を短くし、サーバー側で材料をローテーションし、資格情報をエクスポート不可にし、FairPlayのIPCを強化できます。クライアント側の復号は、コンテンツを再生する端末に鍵を渡す必要があります。実務上の目標は鍵の寿命と範囲を縮めることであり、絶対的に抽出不能にすることではありません。

実際に悪用されているか

2026年11月12日時点で、プロジェクトや確認した情報源にツールを使った攻撃は報告されていません。同日時点でリポジトリは2,400以上のスターと370以上のフォーク、UnfairPlayは1,100以上のスターを持っていました。これらの数字は関心を示すもので、悪用を示しません。

参考資料

• 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キーワード検索、0件：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日確認）