App Storeからクローンへ：AIが.ipaファイルを設計図に変える方法 

AI – リバースエンジニアリングの加速

App Storeに公開するiOSアプリはすべてコンパイル済みのバイナリです。そこには、開発者のコ​​メント、変数名、アーキテクチャ図、ドキュメントなどがすべて削除されています。何十年もの間、このコンパイル工程は大きな障壁となっていました。リバースエンジニアリングは困難を極め、専門家、数週間の作業、そしてARMアセンブリ言語を読む忍耐力が必要でした。専門家は作業を開始する前に、GhidraとIDAのどちらを使うべきかについて何時間も議論しなければなりませんでした。 

その障壁はなくなった。 

この段落をAIモデルに書いてもらったところ、無料のAIサブスクリプションでiOSアプリケーションのリバースエンジニアリングを行う上級セキュリティ研究者を完全に代替できるという内容でした。まだそこまでには至っていませんが、コンパイル済みの小さなiOSアプリケーションから、数時間で同じ機能を持つ全く新しいソースコードとしてアプリケーションの完全なクローンを作成することに成功しました。  

このブログでは、それが具体的にどのように起こるのかを詳しく解説し、静的解析による保護がこのようなAIアプリのクローン作成に対して有効であることを示しています。   

AI支援型リバースエンジニアリングの仕組み 

脅威を理解するには、まずコンパイルされたiOSバイナリに何が含まれているかを理解する必要があります。 

iOSアプリは、.ipaアーカイブ内にMach-O実行ファイルとして配布されます。コンパイラはソースコードを削除しますが、すべてを削除できるわけではありません。SwiftおよびObjective-Cランタイムは、クラス名、メソッド名、プロパティ名、プロトコル準拠、型情報など、コンパイル後も保持されるメタデータに依存しています。さらに、APIエンドポイントURL、エラーメッセージ、キー名​​、ログ出力などの文字列が、バイナリデータセグメントにプレーンテキストで格納されます。リンクされたフレームワークは、ロードコマンドで確認できます。 

otool、strings、Ghidra、llvm-nmなどを含む従来のリバースエンジニアリングツールチェーンは、長年にわたって存在してきました。これらのツールが生成するのは、シンボルダンプ、逆アセンブリリスト、16進ビューといった生データです。専門家にとっては有用ですが、それ以外の人にとっては理解しにくいものです。逆アセンブリを扱うにはアセンブリ言語を読む必要があり、ほとんどのソフトウェア開発者はアセンブリ言語を読むことを好みません。 

AIレイヤーはモデルを変更します。エージェントはコマンドラインのリバースエンジニアリングツールを自動的に実行します。シンボル、文字列、アセンブリ情報を抽出し、動作に関する結論を導き出すことができます。エージェントはIPAファイルから直接設計ドキュメントにアクセスすることも可能です。その後、別のエージェントチームが設計ドキュメントを受け取り、アプリケーションを実装したり、コピーした機能をアプリケーションに追加したりできます。  

知的財産権侵害のリスク ― 実際に何が露呈しているのか 

ビジネスロジックはシンボル名にエンコードされています。クラス名、メソッド名、プロパティ名は、製品開発における意思決定を具体化したものです。これらは、アプリの動作、構造、解決する問題などを説明します。リリースビルドでは、これらの多くがそのまま残されます。独自のアルゴリズム、クライアントサイドAPI、重要なビジネスロジックは、最終アプリケーションに存在します。競合他社や模倣品は、あなたのソースコードを必要としません。  

事例研究：単一の.ipaファイルからジョブディスパッチャをクローンする 

これを具体的に示すために、Job Dispatcherという実際のiOSアプリにこの方法論を適用しました。これは、ログイン画面、技術者向けのタスク表示、天気表示、地図を開いて道順を調べる機能を備えたサンプルアプリの1つです。ソースコードは以下のリンクから入手できます。 https://github.com/digitalai-opensource/job-dispatcher また、このアプリを使ってGhidraを使ったリバースエンジニアリングも紹介しました。 https://digital.ai/catalyst-blog/ios-binary-modification/驚くべきことに、アプリ全体をクローンする方が、Ghidraを使って認証の一部を回避するよりも手間がかからなかった。   

私は.ipaファイルだけから始め、最終的には同等のアプリケーションのSwiftソースコードをビルドすることを目標としました。数時間で、最小限の人的介入で目標を達成できました。もっと早く完了できたはずでしたが、エージェントが私のマシンのsrcディレクトリを検索して元のソースコードを見つけてしまったため、最初からやり直す必要がありました。 

方法論

1. コンパイル済みのバイナリファイルのみを使用してアーキテクチャ図を生成するよう促します。これにより6つの図が生成されますが、次の2つの例では重要な部分を示します。これらの図はかなり正確です。

2. promptを使用して、アプリケーションを再現するための仕様書を作成しました。これにより、詳細な要件定義書が作成されました。この要件定義書は、以下の「拡張製品要件定義書」セクションをクリックすることで展開できます。

生成されたドキュメントには、以下のような注目すべき推奨事項がいくつか含まれています。「本番環境のセキュリティ強化に関する実装上の注意事項（ベースライン後）：ローカル認証を実際のバックエンド認証と管理されたセッションライフサイクルに置き換える。該当する場合は、シークレットとセッションデータをキーチェーンに移行する。」

製品要件ドキュメントを展開する

製品要件定義書：ジョブディスパッチャーのクローン（リバースエンジニアリングによるベースライン）

1. 文書の目的

分析対象のiOSアプリを機能的なクローンとして再構築するための、完全かつ実装可能なPRD（製品要件定義書）を定義する。その際、ソースバイナリで定義されていない未知の要素と、確認済みの事実を明確に区別する。

2. 証拠の根拠

このPRDは、アプリ実行ファイルのMach-Oバイナリ解析、Info.plistからのアプリメタデータ、リンクされたフレームワークとシンボル、および抽出されたランタイム文字列とクラス/型名に基づいて作成されています。

ソースコードとバックエンド契約は入手できませんでした。一部の要件は推測に基づいており、不足事項としてマークされています。

3. カテゴリー別の確認済み要件

3.1スコープ

Job DispatcherというiOSアプリケーション。主な業務目的は、技術者の求人情報の配信、求人の受付状況（空き状況と終了状況）の表示、求人詳細の確認、地図上の経路案内と位置情報の表示、目的地の天気予報の取得です。

主なユーザー操作には、ログイン、求人リストの表示、求人詳細の表示、求人の地図とルートコンテキストの表示、および求人ステータスの開閉切り替えが含まれます。

3.2 UXフロー

アプリ起動時には、まずログイン画面が表示されます。有効な認証情報を入力すると、求人一覧画面に移動します。ユーザーは、募集中の求人と募集終了済みの求人を絞り込んだり、詳細を確認したり、地図機能を利用したり、天気情報を取得したりできます。

3.3アーキテクチャ

AppパターンとViewパターンを用いたSwiftUIアプリケーション構造。MapKit統合のためのUIViewRepresentableを介したUIKitブリッジ。専用のLocationManagerおよびMapViewCoordinatorオブジェクトが、デリゲート駆動型のマップ動作と可観測状態管理をサポート。

4. コアビュー

• ログインビュー: 認証情報の入力と認証検証を処理します。
• 求人一覧表示: オープンおよびクローズされたジョブコレクションを表示します。
• InfoView: 詳細な求人情報と天気予報を表示します。
• マップビュー: 地図上の経路案内、注釈、オーバーレイ、およびユーザーの位置情報を表示します。

5. 実施基準

MapKit、CoreLocation、URLSessionネットワーク、JSONデコード、weather.govの天気予報統合機能を使用して、iOS 14以降をターゲットとしたiOS SwiftUIアプリを構築します。

シード済みのJSONジョブ、ローカル認証検証、ルートレンダリング、目的地の天気情報の取得、およびログイン、ジオコーディング、天気情報、ネットワーク障害に対するエラー処理を実装します。

6. 受け入れ基準

• ユーザーはログインして求人一覧にアクセスできます。
• 進行中のジョブと完了したジョブが正しく表示されます。
• 地図画面は位置情報へのアクセス許可を要求します。
• 目的地の天気情報が正常に読み込まれました。
• エラー発生時には明確なフィードバックが現れる。

3. これらの図と仕様書の成果物を使って、空の iOS Swift アプリケーションで新しいセッションを開始します。私は、プロダクト マネージャー エージェントがビルダー エージェント、QA エージェント、デザイン エージェントを統括するエージェント チームを設定することにしました。この場合、UI のスクリーンショットは撮らなかったので、レイアウトは AI が選択する必要がありました。PM エージェントは仕様書とデザイン ファイルを受け取り、人間が提供した単一のプロンプトからクローン全体を構築しました。その後、エージェントは数時間にわたって実際のスクラム チームとして LARP を行い、最終的に Job Dispatcher の完全なクローンが完成しました。このプロセスで最も面白かったのは、PM エージェントが天気機能の実装に 2 週間かかると見積もったスプリント プランを作成する様子を見ることでした。AI も他の人と同じように作業量の見積もりが下手なことが分かって安心しました。

4. プロセスはたった3ステップしかないのですが、最終的にiOSシミュレータでアプリケーションを実行したところ、実際に動作したので驚きました。確かに、実装は本番環境で使用できるレベルには程遠いものでした。コードの大部分は1つの大きなファイルにまとめられており、実行中にコンソールに警告が表示され、ハードコードされた認証情報はtech/secretのようなより安全なものではなく、admin/passwordに設定されていました。

これが従来のリバースエンジニアリングよりも重要な理由 

明白な事実として、この攻撃は以前から可能だった。変わったのは、それを取り巻くあらゆる状況だ。従来のリバースエンジニアリングのワークフローでは、バイナリ形式、逆アセンブル、ランタイム動作に関する高度な専門知識が必要だった。AI支援のワークフローでは、ターミナルコマンドを実行してプロンプトを入力する能力があればよい。プロダクトマネージャー、ジュニア開発者、非技術系の創業者でも、競合他社のアプリに対して意味のあるリバースエンジニアリング分析を実行できるようになった。クローンアプリは迅速に市場に投入できる。SaaSソフトウェアは更新ではなく複製が可能になった（もちろん、私たちのソフトウェアは例外だが）。この攻撃は規模を拡大でき、新しいAIモデルやより優れたプロンプトによってさらに進化していくように思われる。  

防御策：静的解析による保護 

朗報は、上述の攻撃はバイナリの意味的な豊かさに完全に依存しているということだ。その豊かさを取り除けば、AIの推論連鎖は崩壊する。 

シンボル名の変更、文字列の暗号化、制御フローの難読化、および暗号化技術は、強力な防御層を構築します。AIは、設計図を作成するために、容易にアクセスできる文字列情報に大きく依存しています。以下は、制御フローの難読化と文字列リテラルの暗号化で保護されたJob Dispatcherのバージョンから得られた同様の図です。 

アプリの基本的なビューは認識しているものの、よくデザインされた求人情報アプリを幻覚として作り出してしまった。ハードコードされたパスワードはどこだ！？ハードコードされたパスワード 私の重要なビジネスロジックは このアプリのためだけに使うんです。他にどうやって劇的な攻撃ブログに使えるっていうんですか！それに、通信するジョブリストサーバーすら持っていないんですよ。 

結論 

モバイルアプリの知的財産に対する脅威モデルは、恒久的に変化しました。AIは新たな攻撃手法を生み出したわけではなく、既存の攻撃手法をよりアクセスしやすく、拡張性の高いものにしたのです。 

App Storeに公開するバイナリファイルは公開されています。顧客、競合他社、悪意のある人物など、あらゆる人が数秒でダウンロードできます。iOSの歴史の大半において、これは許容できるリスクでした。なぜなら、悪用された場合のコストが高かったからです。しかし、現在ではそのコストはごくわずかです。