Android セキュリティテストスイート開発キット（STS SDK）

セキュリティテストスイート Trade Federation（sts-tradefed）は、Android Trade Federation テストハーネスの上に構築されており、互換性テストスイートにフォールバックしないセキュリティパッチテストですべての Android デバイスをテストします。これらのテストは、共通脆弱性識別子（CVE）に関連付けられている（または関連付けられる予定の）修正専用のテストです。

この SDK により、Android Studio または標準の Android SDK を使用して、Android ソースツリーの外部で STS テストを開発できます。この SDK には、STS テストのビルドと実行に必要なすべてのユーティリティが含まれています。

最新の STS SDK を入手する

前提条件

64 ビット Linux PC。
Android Studio（ディストリビューションのパッケージマネージャーからインストールすることもできます）。
Android プラットフォームツール（adb、fastboot）を $PATH にインストールしておく（コマンドラインから adb を実行する必要があります）。プラットフォームツールをインストールする最も簡単な方法は、ディストリビューションのパッケージマネージャーを使用することです。
- スタンドアロンプラットフォームツールではなく Android Studio の SDK Manager を使用している場合は、SDK の platform-tools ディレクトリを $PATH に必ず追加してください。
aapt（ディストリビューションのパッケージマネージャーからインストールすることもできます）。

Android Studio の使用を開始する

アーカイブを展開した後、Android Studio で既存のプロジェクトとしてディレクトリを開きます。assembleSTSARM または assembleSTSx86 ビルドターゲットを実行し、ターゲット Android デバイスのアーキテクチャに応じてスケルトンテストをビルドします。runSTS ビルドターゲットを実行し、接続されたデバイスでスケルトンテストを実行します（ADB を承認する必要があります）。

Gradle の使用を開始する

アーカイブを展開した後、Gradle プロジェクトのルートにある local.properties ファイルで sdk.dir プロパティを設定し、assembleSTSARM Gradle タスクを実行してスケルトンテストをビルドします。ビルドが完了したら、build/android-sts/tools に移動（cd）して sts-tradefed ラッパーを実行することにより、テストを実行できます。

$ echo 'sdk.dir=/home/<myusername>/Android/Sdk' > local.properties
$ ./gradlew assembleSTSARM
$ cd build/android-sts/tools
$ ./sts-tradefed run sts-dynamic-develop -m hostsidetest

STS テストを作成する

STS テストには以下の 3 つの部分があります。

ホスト側の Tradefed テスト。これは sts-test サブディレクトリで ADB を介してデバイスとやり取りします。
ネイティブ概念実証攻撃（任意）。これは adb push を介してデバイスにプッシュされ、native-poc サブディレクトリでホスト側のテストにより実行されます。
アプリまたはサービス APK（任意）。これは adb install を介してデバイスにインストールされ、さらにホスト側のテストにより起動されます。アプリまたはサービスには、ホスト側のランナーに報告される JUnit アサーションの独自のセットを含めることもできます。これは test-app サブディレクトリにあります。

一般的な STS テストフローは、次の 2 つのパターンのいずれかで進行します。

ネイティブ概念実証:
1. ホスト側のテストは、デバイス上でネイティブ実行可能ファイルをプッシュして起動します。
2. ネイティブプログラムがクラッシュするか、特定の終了コードを返します。
3. ホスト側のテストは、クラッシュをチェックするか、logcat バックトレースを確認するか、特定の終了コードを調べて、攻撃が成功したかどうかを判定します。
インストルメンテーションテストアプリ:
1. ホスト側のテストは、アプリまたはサービスで構成された APK をデバイスにプッシュします。
2. ホスト側のテストは、runDeviceTest() を介して、APK にバンドルされているデバイス側の JUnit テストを開始します。
3. デバイス側の JUnit テストは、ボタンをタップして UIAutomator によりアプリを監視するか、セキュリティの脆弱性を明らかにするような方法で Android システムにアクセスします。
4. デバイス側の JUnit テストの成功または失敗がホスト側のテストに返されます。これにより、テスト結果が合格かどうかを判断できます。

上記の 2 つのパターンを組み合わせる（たとえば、デバイス側のテストと同時にネイティブプログラムを実行する）こともできます。他のなんらかのインストルメンテーションフレームワーク（frida-inject など）も使用できます。詳しくは、セキュリティテストスイートのリファレンスドキュメントと Tradefed のリファレンスドキュメントをご覧ください。

概念実証攻撃にテストアプリやネイティブ実行可能ファイルは不要である

ほとんどのテストでは、デバイス側のアプリとネイティブ実行可能ファイルの両方は必要ありません。

デバイス上のアプリやサービスを使用しないテストの場合は、test-app サブディレクトリを削除します。同様に、ネイティブ実行可能ファイルを使用しないテストの場合は、native-poc サブディレクトリを削除してから、プロジェクトを Gradle 同期します。これらのモジュールが存在しない場合は、モジュールのビルドを自動的にスキップするようプロジェクトが設定されています。

概念実証攻撃に 2 つ目のアプリやサービスが必要である

まず、2 つ目のアプリまたはサービス用に新しいモジュールをプロジェクトに追加し、他の APK と同じように書き込みます。

次に、このディレクトリのルートで build.gradle を編集して、copyArtifacts、assembleStsARM、assembleStsx86 の手順に沿ってモジュールを追加します。これにより、コンパイルされた APK が STS の出力ディレクトリにコピーされ、テストで新しいアプリのインストールや呼び出しが可能になります。

最後に、プロジェクトを Gradle 同期します。

STS テストを送信する

zipForSubmission タスクを実行します（Android Studio を使用するか、コマンドラインで Gradle を使用する）。新しいファイル codesubmission.zip が、プロジェクトのルートの build ディレクトリに作成されます。このファイルと提出物の両方を Android 脆弱性報奨金プログラムにアップロードします。