Androidの取得と解析

Androidデータを効果的に抽出するには、データがどこに存在するかを知る必要があります。

• /data/data/<package>/ — 各アプリのサンドボックス：データベース、shared_prefs、ファイル、キャッシュ。
• /data/media/0/ — ユーザーストレージ（写真、ダウンロード）。
• /data/system/ — アカウント、ロック設定、利用統計。

アプリの証拠の大半は、アプリごとのサンドボックス内にあるSQLiteデータベースとXML設定ファイルに保存されています。root権限またはバックアップ機構がなければ読み取れません。

Android Debug Bridge (ADB)は、主な論理取得手段です。USBデバッグが有効で、ホスト鍵が承認されている必要があります。

• デバッグが有効でなく、画面もロック解除されていない場合、ADBアクセスはブロックされます。
• 認証プロンプト自体がデバイスの状態を変更するため、記録してください。

まず接続を確認し、デバイスのプロパティを取得します：

adb backupは、アプリデータを含むバックアップ用の.abアーカイブを生成します。root権限を必要とせず広く利用できますが、多くのアプリがallowBackup=falseを設定しているため、制限があります。

• アプリデータ、APK（-apk指定時）、共有ストレージを取得します。
• バックアップをオプトアウトしたアプリや、削除済みレコードは取得できません。

分析用のバックアップを作成して変換します：

ファイルシステム抽出では、アプリのサンドボックスや、未同期のレコードを保持するSQLiteのWAL／SHMジャーナルファイルを含むディレクトリツリーをコピーします。

• root、フォレンジックエージェント、またはエクスプロイト／ブートローダー方式が必要です。
• -walおよび-shmファイルを保持します。最近の行がそこにしか存在しない可能性があるため、重要です。

SQLiteデータベースを取得するときは、必ずジャーナルの関連ファイルも取得してください：

物理イメージは、削除されたデータが残っている可能性のある未割り当て領域を含む、NANDのビット単位のコピーです。最新のAndroidでは、取得するのが最も困難です。

• FBE暗号化により、ユーザー鍵がなければraw NANDダンプは暗号文になります。
• 方法には、ベンダーのエクスプロイト、EDL／ブートローダーモード、チップオフ（最終手段であり、破壊的）が含まれます。
• 実用上、AFU状態でのファイルシステム抽出は、暗号化された物理ダンプよりも多くの利用可能なデータを得られることがよくあります。

物理取得は、必要性があり、復号が可能な場合にのみ選択してください。

Androidのアーティファクトの大半はSQLiteデータベースです。分析担当者はデータベースを直接クエリして、メッセージ、通話履歴、タイムスタンプを復元します。

• 証拠ファイルを変更しないよう、読み取り専用で開きます。
• タイムスタンプはUnixエポックのミリ秒であることがよくあります。

抽出データから連絡先データベースを調べます：

SQLiteで行を削除しても、ページ領域が空きとしてマークされるだけの場合があります。復元可能な断片は次の場所に残っています。

• フリーリストページと、.dbファイルの未割り当て領域。
• -walライトアヘッドログ。チェックポイント処理前の行のバージョンが保持されています。

カービングツールによって、これらのレコードを再構成できます。データベースに対して復元処理を実行します：

タイムラインを作成すると、アプリ間のイベントを関連付けられます。課題は、Androidが多くのタイムスタンプ形式を使用することです。

• Unixエポック（ms） — ほとんどのメッセージデータベース。
• Unixエポック（s） — 多くのシステムログ。
• WebKit／Chrome時間 — 1601年からのマイクロ秒（ブラウザ履歴）。

必ずUTCに正規化し、デバイスのタイムゾーンを記録してください。SQLiteでの変換例：

アプリデータだけでなく、Androidのシステムアーティファクトからも、ユーザーの行動やデバイスの使用状況が明らかになります。

• usagestats — どのアプリがいつ実行されたかを示します。
• accounts.db / accounts_ce.db — Googleアカウントやアプリのアカウントとの関連を示します。
• net stats / netpolicy — アプリごとのデータ使用量を示します。
• Wi-Fi config (WifiConfigStore.xml) — 既知のネットワークを示し、位置情報の状況把握に役立ちます。

これらを使うことで、誰がいつデバイスを使用したかという主張を裏付けたり、反証したりできます。

手動解析では規模に対応できません。ALEAPP（Android Logs Events And Protobuf Parser）はファイルシステム抽出データを取り込み、構造化されたHTML/CSVレポートを出力します。

• usagestats、最近のアクティビティ、通知、アプリの権限などを解析します。
• まずトリアージに使用し、その後、重要な発見事項を未加工のDBと手動で照合して検証します。

抽出データのディレクトリに対してALEAPPを実行します。

単一のツールだけを決して信用しないでください。自動出力をソースデータと照合し、さらに複数のツール間でも検証してください。

• sqlite3で重要なクエリを手動で再実行し、パーサーの結果を確認します。
• 反フォレンジックの兆候に注意します。たとえば、ログの消去、タイムスタンプの変更、安全な削除を行うアプリ、消えるメッセージの設定が有効なチャットアプリなどです。
• 分析の前後でイメージのハッシュが一致していることを確認します。

再現性と相互検証によって、所見を根拠のあるものとして提示できます。

チャットアプリのSQLiteデータベースを取得しています。最近送信されたメッセージを取りこぼさないために、どの関連ファイルも一緒に収集する必要がありますか。

これで、Androidの証拠を端から端まで取得・解析できるようになりました。

• アプリデータは、SQLite DBやXML設定としてアプリごとのサンドボックスに保存されています。
• ADB backupは簡単な論理取得、file-system extraction（root）はWALを保持し、physicalはFBE環境では最も困難な取得方法です。
• freelist pages and WALから削除されたレコードを復元します。
• タイムスタンプをUTCに統一し、epoch形式とWebKit形式をデコードします。
• ALEAPPでトリアージを行い、その後sqlite3で手動検証します。
• 反フォレンジックの改ざんに注意し、イメージのハッシュを再確認します。

次はiOSについて見ていきます。