iOSやmacOSのアプリを開発していると、Xcodeが自動的に生成する.carファイルという存在に気づくことがあります。Asset Catalogをビルドすると作られるこのバイナリファイル、実は中身がどうなっているのか公式ドキュメントにはほぼ記載がないんですよね。

今回は、最近Hacker Newsでも話題になった.carファイルフォーマットのリバースエンジニアリング研究をもとに、その内部構造を解説してみます。セキュリティリサーチや独自ツール開発に興味がある方には、かなり面白い内容だと感じました。

Apple .carファイルとは何か

SwiftでUIImage(named: "MyImage")と書くと、内部ではCoreUIフレームワークがアプリのAssets.carファイルを開いて、デバイスの画面解像度やダークモードの状態に応じた適切な画像を取得しています。

CARという拡張子は「Compiled Asset Record」の略だと考えられていて、XcodeのIBFoundationフレームワーク内のメソッド名から推測されたものです。普段は意識することがないファイルですが、すべてのAppleプラットフォームアプリに含まれている基盤的な存在なんですよね。

BOMStoreという土台

.carファイルをバイナリエディタで開くと、先頭に「BOMStore」というマジックバイトが見えます。BOM（Bill of Materials）はmacOSのインストーラパッケージでも使われている古いフォーマットで、.carファイルはこのコンテナを流用して作られています。

BOMファイルには2つの基本的なデータ構造があります。ひとつはBlockで、数値インデックスでアクセスするバイナリデータの塊です。もうひとつはTreeで、B+木構造による順序付きキーバリューストアとして機能します。

ヘッダーは32バイトの固定サイズで、バージョン情報やブロックインデックスのオフセットなどが格納されています。ここはビッグエンディアンで読む必要がある点に注意が必要です。

.carファイル固有のデータブロック

通常のBOMファイルがインストーラのマニフェストを格納するのに対して、.carファイルはアセット管理用に独自のブロックとツリーを定義しています。

主要な名前付きブロックとしては、以下のようなものがあります。

  • CARHEADER（436バイト）: バージョン情報、レンディション数、UUIDなどを保持
  • KEYFORMAT: キーの属性順序を定義するブロック
  • EXTENDED_METADATA（1028バイト）: ビルドツールやプラットフォームの詳細情報

また、B+木構造のツリーとしてはRENDITIONS（アセットキーからCSIデータへのマッピング）、FACETKEYS（アセット名からトークンへのマッピング）、APPEARANCEKEYS（ダークモード対応）などが存在します。

CSI（Core Structured Image）フォーマット

実際の画像データは、CSIと呼ばれる構造化フォーマットで格納されています。ピクセルフォーマットを示すマジック値（ARGB、JPEG、HEIFなど）と、TLV（Type-Length-Value）形式のメタデータが組み合わさった構造になっているのが特徴的です。

圧縮にはLZFSEやzlibが使われていて、CELM/MLECラッパーやKCBCチャンク形式など、複数の圧縮アーキテクチャが重なっている点が興味深いところです。パフォーマンスとファイルサイズのバランスを取るためにAppleがかなり工夫していることが伺えます。

レンディションの種類

.carファイルは画像だけでなく、さまざまなタイプのリソースを格納できます。

  • CUIRawDataRendition: 生のバイナリデータ（JSONやPlistなど）
  • CUIRawPixelRendition: JPEGやHEIF形式の画像
  • CUIThemeColorRendition: カラーアセット（ダークモード対応色など）
  • CUIThemePixelRendition: ARGB形式のピクセルデータ

デバイスのコンテキスト（画面スケール、外観モード、サイズクラスなど）に応じて適切なレンディションが選択される仕組みです。これがUIImage(named:)の裏側で行われている処理の本質だと言えます。

開発者にとっての実用的な意味

この知識が役立つ場面はいくつかあります。まず、iOS 27のようなプラットフォームアップデートでアセットカタログの仕様が変わった際に、内部構造を理解していると問題の切り分けが早くなります。

また、セキュリティリサーチの観点では、悪意のある.carファイルがパーサーの脆弱性を突く可能性があるため、フォーマットの理解は防御側にとっても重要です。Apple公式のUIImageドキュメントだけでは見えない部分を把握できるのは大きなメリットだと感じました。

独自のビルドパイプラインを構築する場合にも、Xcodeに依存しない.carファイルの生成・解析が可能になります。実際に元の研究者はWebAssemblyベースのパーサーをブラウザ上で動かすデモを公開しています。

リバースエンジニアリングの手法

この研究では、CoreUIフレームワークのディスアセンブルと、実際の.carファイルのバイナリ解析を組み合わせたアプローチが取られています。Ghidraのようなリバースエンジニアリングツールを使った経験がある方なら、この手法に親近感を覚えるかもしれません。

フォーマットの仕様が公開されていない以上、こうしたリバースエンジニアリングによるコミュニティの貢献は非常に価値があります。オープンソースの既存のパーサー実装も参考になりますが、今回の研究はそれらを大幅に上回る詳細さで、.carフォーマットの全体像を明らかにしています。

まとめ

Apple .carファイルは、見えないところでiOS/macOSアプリのアセット管理を支えている重要なバイナリフォーマットです。BOMStoreベースのコンテナに、B+木構造のインデックスとCSI形式の画像データが格納されているという構造は、パフォーマンスを重視したAppleらしい設計だと感じます。

普段の開発で直接触る機会は少ないかもしれませんが、こうした「裏側」を知っておくことで、トラブルシューティングやツール開発の幅が広がるのではないでしょうか。興味がある方は、Appleの最新動向とあわせてチェックしてみてください。