analyzing-macos-binaries

macOS バイナリの分析

macOS のリバースエンジニアリングでは、Mach-O に加えて、コード署名、エンタイトルメント、サンドボックス、TCC によるプライバシー保護、プロセス間の XPC 通信という固有のセキュリティモデルを考慮します。バイナリからはコードが何をするかが分かります。一方、エンタイトルメントとロードパスからは、何をする「許可」があり、攻撃者がどこから侵入できるかが分かります。両方を確認してください。macOS の調査結果の多くは、この二つの隔たりにあります。

使用する場面

• macOS の .app バンドルや Mach-O 実行ファイル／dylib／フレームワークを分析する場合
• エンタイトルメント、Hardened Runtime のフラグ、公証、Gatekeeper の隔離状態を確認する場合
• XPC サービスや特権ヘルパーに認可の不備がないか監査する場合
• @rpath や脆弱な dylib を介した dylib ハイジャック／プロキシを調査する場合
• TCC によるプライバシー情報の漏えいリスクや、サンドボックスからの脱出につながる攻撃対象領域を検討する場合

使用しない場面

• iOS アプリ — IPA の復号、FairPlay（cryptid=1）、App Store のバイナリには analyzing-ios-binaries を使用してください。Mach-O 形式は同じですが、ツールチェーンと DRM が異なります。
• macOS 固有の要素を含まない、Mach-O 以外のバイナリやクロスプラットフォームのトリアージ — analyzing-binaries を使用してください。
• メモリ破損によるクラッシュからエクスプロイトを作成する場合 — exploiting-memory-corruption を使用してください。
• 読み取り可能になる前にパック／暗号化されている Mach-O — unpacking-protected-binaries を使用してください。

バイナリとバンドルのトリアージ

• ユニバーサルバイナリをスライスに分割します。 macOS では fat バイナリ（x86_64 + arm64）が使われます。lipo -thin（または一覧表示には lipo -archs）を使って、ツールが単一のスライスを扱えるようにします。
• Mach-O を読み取ります。 ロードコマンドには otool -l、リンクされた dylib とそのパスには otool -L、シンボルには nm を使います。後で重要になるロードコマンドとして、LC_RPATH、LC_LOAD_DYLIB／LC_LOAD_WEAK_DYLIB、コード署名に注目してください。
• バンドルの内容を確認します。 Contents/MacOS（バイナリ）、Info.plist（識別子、URL スキーム）、_CodeSignature、埋め込みの Frameworks/、バンドル内の XPCServices/ を確認します。バンドルの構成は、分析対象を把握するための地図です。

Objective-C と Swift の情報を復元する

• Objective-C は豊富なランタイムメタデータを保持します。class-dump（または dsdump）を使うと、クラス、メソッド、プロパティの宣言をバイナリから直接再構成できます。アプリの構造を把握する最も手早い方法です。
• Swift はより困難です。名前はマングルされ、メタデータから得られる情報も少なくなります。シンボルに swift-demangle を実行して読みやすい名前を取得し、Objective-C の場合よりも逆コンパイラー（Hopper、Ghidra、IDA）に頼ることを想定してください。
• アプローチを選ぶ前に、どちらの言語が中心かを確認してください。class-dump で得られる情報がほとんどない Swift バイナリはよくあることであり、失敗ではありません。

コード署名、エンタイトルメント、Gatekeeper

macOS 固有の権限が関わるのはここです。

• codesign -dvvv --entitlements :- <binary> を実行すると、署名とエンタイトルメント（OS が付与する機能）が出力されます。com.apple.security.get-task-allow（デバッグ可能）、無効化されたライブラリ検証、非公開の TCC エンタイトルメントなどは、特に重要な確認対象です。
• Hardened Runtime のフラグは、コードインジェクションとデバッグを制限します。有効かどうか、またライブラリ検証が無効化されているか（無署名の dylib をロードできるため、ハイジャックに直接関係します）を確認してください。
• 公証と Gatekeeper。 ダウンロードしたファイルには com.apple.quarantine 拡張属性が付与され、Gatekeeper は初回実行時に公証を確認します。何が実行されるか、またユーザーにどのような警告が表示されたかを検討する際は、隔離／公証の状態を把握してください。

macOS 固有の脆弱性領域

• dylib のハイジャック／プロキシ化。 @rpath から dylib を読み込むバイナリで、そのパスが書き込み可能な場所に解決される場合や、存在しない LC_LOAD_WEAK_DYLIB がある場合、攻撃者は悪意のある dylib を配置してアプリのコンテキストでコードを実行できます。アプリのエンタイトルメントも引き継がれます。読み込みパスを列挙し、攻撃者が書き込み可能か、ライブラリ検証で保護されていないかを確認してください。
• XPC サービスと特権ヘルパー。 XPC は、アプリとそのヘルパー（多くの場合、SMJobBless による root ヘルパー）間の mach ベースの IPC です。典型的なバグは、ヘルパーが PID でクライアントを認証することです。PID は競合状態の影響を受け、偽装も可能です。代わりに audit_token を使用すべきです。サービスが呼び出し元をどのように検証し、どのような特権操作を実行するかを追跡してください。検証が不十分であれば、ローカル権限昇格につながります。
• TCC のプライバシー制御。 TCC はカメラ、マイク、ファイル、自動化へのアクセスを制御します。アプリにどのエンタイトルメントが付与されているか、権限の低いプロセスのために混乱した代理人として動作させられる可能性があるか、またはインジェクションされた dylib が TCC の許可を引き継ぐかを確認してください。
• URL スキームと Info.plist ハンドラー は、他のアプリや Web からの入力を処理するアプリとして登録します。これは信頼できない入力のエントリーポイントです。

動的解析

Frida は実行時フックのために macOS プロセスにアタッチします。lldb は（get-task-allow／SIP の制約を受けながら）デバッグを行います。dtrace は、SIP が許可する範囲でシステムコールとライブラリ呼び出しをトレースします。バイナリだけから推測するのではなく、これらを使って XPC メッセージと dylib の読み込みをリアルタイムで監視してください。

退けるべき合理化

• 「署名も公証もされているので安全です。」 署名が証明するのは配布元であり、安全性ではありません。また、dylib のハイジャック経路や、呼び出し元の PID を信頼する XPC ヘルパーについては何も示しません。エンタイトルメントと読み込みパスを確認してください。
• 「class-dump ではほとんど何も出ませんでした。バイナリが strip されています。」 これは Swift バイナリでは通常の状態です。何も見るものがないと結論付けず、swift-demangle とデコンパイラーに切り替えてください。
• 「ヘルパーはクライアントの PID を確認しています。これは認証です。」 PID の確認は競合状態の影響を受け、偽装も可能です。信頼できるのは audit_token に基づく検証だけです。PID の確認自体が発見事項です。
• 「ライブラリ検証が悪意のある dylib を阻止します。」 有効になっている場合に限ります。読み込みが保護されていると決めつける前に、ライブラリ検証を無効にするエンタイトルメントと hardened-runtime の状態を確認してください。
• 「これは Mac 上の iOS プロセスにすぎません。」 DRM、ツールチェーン、セキュリティモデルは異なります。FairPlay IPA には analyzing-ios-binaries を、このスキルは macOS アプリとその XPC／TCC／dylib の攻撃対象領域に使用してください。

参考資料

• analyzing-ios-binaries — iOS IPA、FairPlay、モバイル向けツールチェーン
• analyzing-binaries — 一般的な Mach-O のトリアージとデコンパイル技術
• exploiting-memory-corruption — ここで見つかったネイティブバグの悪用
• unpacking-protected-binaries — Mach-O が最初にパック／暗号化されている場合