PreEmptive Protection™ DashO™ は、アプリケーションが改ざんされたかどうかを検出するためのチェックをアプリケーションに差し込むことができます。 改ざんチェックでは、アプリケーションが DashO によって、あるいは DashO による処理に続く別のプロセスによって署名されている必要があります。 改ざんチェックとレスポンスの構成は、Checks - Tamper ページを使って、またはコード アノテーションを追加することにより行います。
改ざんチェック
改ざんを検出するには、アプリケーション内の 1 つ以上のメソッドに TamperCheck を設定します。 DashO は、コードが特定の証明書によって著名されていることを検証する、ランタイム チェックを実行するコードを追加します。 このチェックは、概要の説明に従って構成できますが、署名情報が必要になる場合もあります。
アプリケーションには、さまざまな用途の TamperCheck をさまざまな構成で含めることができます。 複数のチェックを使用したり、レスポンスを混合したりすることにより、アタッカーの侵入を妨げられるでしょう。
private static boolean tamperFlag;
@TamperCheck(action="@tamperFlag")
public static void main(final String[] args){
}
@TamperCheck(response=ResponseType.Hang)
private int computeResult(){
}
改ざんのレスポンス
TamperResponse アノテーションは、TamperCheck と情報をやり取りします。 このレスポンスは、概要の説明に従って構成できます。
private static boolean tamperFlag;
@TamperCheck(action="@tamperFlag")
public static void main(final String[] args){
}
@TamperResponse(source="@tamperFlag", response=ResponseType.Exit, probability=0.05f)
private int computeResult(){
}
@TamperResponse(source="@tamperFlag", response=ResponseType.Error, probability=0.1f)
private FileInputStream readInput(){
}
署名との相互作用
改ざんチェックは、実行時に、コードが特定の証明書によって署名されているかどうかを検証することにより実行されます。 結果として生じる jar ファイルへの署名に DashO が使われる場合は、これ以上の構成は必要ありません。 DashO を使って難読化した後、別のプロセスによって jar ファイルが署名される場合は、TamperCheck の追加属性を使用して、署名情報について DashO へ伝える必要があります。 これにより、DashO はランタイム改ざんチェックを行うために必要なキー情報を取得することができます。 指定された情報は、Output-Signing ページで見られる内容と同様です。
@TamperCheck(action="@tamperFlag", storepass="${master.psw}",
storetype="JKS", alias="ProdKey")
public static void main(final String[] args){
}
ユーザー インターフェイスを使用して storepass 値のパスワードを入力したとき、パスワードにプロパティ参照が含まれていない場合は、DashO は暗号化された形式でパスワードを格納します。
この場合、考慮すべきいくつかの特殊なケースがあります。
Android
Android の改ざんチェックは、アプリケーションのコンテキストへのアクセスを必要とし、チェックが差し込まれるクラスに getApplicationContext() メソッドの存在が必要です。 android.app.Activity、android.app.Application、android.app.Service のような android.context.Context を拡張するクラスは、getApplicationContext() を継承するので、追加の変更は不要です。 そうでない場合は、getApplicationContext() メソッドを追加して、適切な Context が返されることを確認してください。
改ざんチェックがライブラリに対して正しく機能するのは、ライブラリがアプリケーションにマージされていない場合、または、改ざんチェックで使用されるものと同じ証明書によってアプリケーションが署名されている場合のみです。 たとえば、改ざんチェックを備えた Android ライブラリ（AAR）は、アプリケーションが改ざんチェックで使用される証明書によって署名されていなければ、自身が Android アプリケーションにマージされるときに、改ざんされたかのように動作します。
鍵のローテーションを使用しており、アプリケーションが Android Pie（以上）を必要とする場合は、その鍵のローテーションでは最後の別名を使用するよう DashO を構成します。 それ以外の場合は、鍵のローテーションでは最初の別名を構成する必要があります。
Google Play App Signing（Google Play アプリへの署名）
Google Play App Signing（Google Play アプリへの署名）をオプトインしている場合は、Google Play ストアで提供されている Android アプリへの最終署名が Google によって管理されます。最終署名は、改ざんチェックを使用する場合には慎重に構成する必要があります。
このサービスを使用する場合には、2 つの署名キーが必要で、1 つはアップロード キー（アプリやアプリ バンドルの署名に使用してから Google に送信）で、もう 1 つの署名キーはアプリ署名キー（Google が APK を Google Play ストアでの配布用に署名するために使用）です。 Google Play App Signing で改ざんチェックを使用する場合は、アプリの署名にアップロード キーでなくアプリ署名キーが使用されていることをチェックするよう、改ざんチェックを構成する必要があります。
これを行うには、Google Play Console から app signing certificate（アプリの署名証明書）をダウンロードし、信頼できる証明書として証明書をキー ストアにインポートして、その証明書を使用するよう改ざんチェックを構成します。
メモ： このように改ざんチェックを構成した場合、アップロード証明書で署名されたアプリは、実行しようとすると、改ざんされたかのように動作します。 両方の証明書の別名をカンマで区切る（例：
alias="signingAlias,uploadAlias"）ことで、アップロード証明書もチェックするよう DashO を構成できます。
キーのアップグレード
Google Play では、署名するキーを 1 回のみアップグレードすることがきます。 以前にインストールされたアプリケーションは古いキーで署名され、新しいインストールは新しいキーで署名されます。 改ざんチェックが適切に動作するために、DashO では両方の証明書が必要です。 両方の証明書をキーストアにインポートし、両方の別名をカンマで区切って構成します（例：alias="newAlias,oldAlias"）。
コード生成
アプリケーションがコード生成を利用している場合は、改ざん検出を追加する前に、署名済みの jar ファイルで正しく動作しているかどうかを確認してください。 同じ証明書を使用してコードを生成する jar ファイルに署名する必要があるかもしれません。 たとえば、Spring ベースのアプリケーションでは、spring-core-4.0.1.RELEASE.jar（または類似する jar ファイル）に署名する必要があります。
クラスのカスタム読み込み
アプリケーションがカスタムのクラス ローダーを使用している場合は、署名証明書を読み込んでいるかどうかを確認してください。
たとえば、OSGI（Eclipse Equinox）ベースのアプリケーションでは、osgi.signedcontent.support を構成する必要があります。 少なくとも certificate を許可する必要があり、osgi.support.class.certificate を false に設定することはできません。