はじめに
PreEmptive Protection - DashO は、Java、Android、および Kotlin アプリケーション用の、アプリケーションのセキュリティ強化および難読化のツールです。 DashO は、ライブラリやアプリを保護するためのいくつかの方法で機能します。 1 番目に、コンパイルされたコードを難読化します。静的技術を用いて、コードの分析がより困難になるようコードを変更します。 2 番目に、改ざんやデバッグの試みを検出して対応するためのコードを差し込んで、動的に分析するのを困難にします。3 番目に、改ざん、デバッグ、Android のルート化を検出し、標準またはカスタムのレスポンスを使ってこれらのイベントに対応する手段を提供します。
保護を行う理由
難読化は、リスクを軽減するための 1 つの手段です。 現代において、ソフトウェアには次のようなリスクがあります。
- さまざまな種類の窃盗(営業秘密やその他の知的財産)
- 収益の損失(違法コピーによる)
- データの暴露または損失(個人を特定できる情報など)
- 汚損およびブランド希釈(違法コピーによる)
製品やドメインに対する特定のリスクの適用性や重大度はさまざまですが、どんなリスクも伴わない製品はありません。
現代のソフトウェアは、孤立していることはまずありません。通常、より大きな相互接続システムの 1 つのコンポーネントとして機能します。 徹底的な防御には、システムの各層における保護が必要です。 DashO のセキュリティ強化は、安全保障戦略の重要な要素となります。 これには、改ざん検出を通じて、潜在的な攻撃ベクトルを完全に排除することが含まれます。 また、使用されていないコードを除去することで、攻撃対象領域を減らすことも含まれます。 さらに、米国では、営業秘密を難読化で保護する意向を示すことにより、ソフトウェアに法的保護が与えられる可能性があります。
DashO を使う理由
私たちは、Java 言語の最新機能、JVM 仕様、および Android 開発ランドスケープの頻繁な更新に合わせて、DashO を最新に保っていると自負しています。
DashO は、20 年以上にわたって開発されている成熟した製品です。 現場で Java プロジェクトの困難をずっと切り抜けてきています。この技術を使用する際の思わぬ障害の大半は既に発見され、解決されてきました(たとえば、Spring Framework、動的クラス読み込みなどがサポートされました)。
動作方法
グラフィカル ユーザー インターフェイス("GUI")を使用して、また任意でステップ バイ ステップ ウィザードを使用して、プロジェクト構成を作成します。 DashO は、Java の場合にはコンパイル後のビルド ステップで、Android の場合には Gradle ビルド内で、その構成をアプリケーションに適用します。 つまり、コードを変更しなくても、アプリケーションを完全に保護できるということです。
DashO のビルドは、GUI 内から直接実行したり、コマンド ライン インターフェイス("CLI")、Gradle、または Ant を使用して、継続的インテグレーション ビルドに統合したりすることができます。
難読化が完了すると、今後の参考のために調査または保持することができる、いくつかのファイルが生成されます。
- 削除された未使用のクラスおよびメンバーのレポート
- どのような名前変更が適用されたかを示すレポート
- 古い名前から新しい名前へのマッピングが記述されている、名前変更の割り当てファイル
- 文字列の暗号化方法が記述されている、文字列の暗号化割り当てファイル
作業の開始
DashO をまだ購入しておらず、試してみたいだけであれば、登録して評価版をダウンロードすることができます。 評価版をダウンロードすると、製品を実行できるようにするための期限付きシリアル番号が記載された電子メールを受け取ります。
インストールを行ったら、ステップ バイ ステップのウィザードを使ってプロジェクトを作成したり、ユーザー インターフェイスを使ってプロジェクトをゼロから作成したりすることができます。 また、サンプル アプリケーションを参考として利用することもできます。
準備が整ったら、お問い合わせいただき、販売とサポートに関する情報を入手してください。
機能
DashO の機能はすべて、GUI を介して構成できます。 また、チェック関連の機能は、自身の開発手法にとって便利であれば、コード アノテーションを使用して構成することもできます。 最終的に、必要に応じて、構成 .dox
ファイルを手作業で調整することができます。
難読化
DashO における難読化は、名前の変更、制御フロー、および文字列の暗号化の 3 つの技術から成っています。 さらに、わずかなコードの更新では、増分難読化が利用されることもあります。
名前の変更による難読化
DashO の名前の変更による難読化では、クラス、メソッド、フィールド、アノテーション、およびパッケージの階層の名前を変更できます。 ソース コードは、コンピューターと人間の、2 つの対象ユーザーによって読み取られるものです。 メソッド名などを含め、人間の読者にとってのみ有用なものの多くは、コンパイルされたバイトコードに保持されています。名前の変更は、バイトコードからこの情報をすべて取り除きます。意味のある名前は、別の意味のない一意の名前(たとえば、a
、b
など)に置き換えられます。
Java では、メソッド呼び出し foo(bar)
は、foo
の 2 つの異なるオーバーロードを参照することができます。たとえば、foo(int)
や foo(String)
などです。 bar
の型に基づく解決は、コンパイル時に行われます。 JVM は、1 つのクラスにある、名前は同じでパラメーター一覧が異なる 2 つのメソッドを無関係なものとして扱います。 DashO はこれを利用して、メソッドが異なるパラメーター一覧を持っている限り、それらのメソッドの名前を同じ名前に変更できるよう、オーバーロード誘導™ という機能を提供しています。 その結果、リバース エンジニアリングしようとするものは、コードを理解するためのヒントとしてメソッドのオーバーロードを利用することもできなくなります。
配置後、名前変更によって難読化されたアプリケーションが例外を見つけると、発行されるスタック トレースでは、名前変更されたパッケージ名、クラス名、およびメソッド名が使用されます。 DashO は、ビルドから保持されている名前変更の割り当てファイルを使用して、スタック トレースをデコードすることができます。 これは、DashO の GUI 内で行えるほか、スタンドアロンのコマンド ライン アプリケーション DashO Lucidator を使って行うこともできます。
制御フローの難読化
DashO の制御フローの難読化は、コードの働きを変えないで、理解しにくくなるようにコードを変更します。 これの目的の 1 つは、逆コンパイラがソース コードを再構築しようとするときに探すパターンを削除することです。 DashO は、任意で try/catch ブロックを追加したり、既存のブロックを分割したりすることができます。 これらの手段によって、逆コンパイラをさらに混乱させるための制御フローを追加します。
文字列の暗号化による難読化
ソース コード内の文字列は、コンパイルされた .class
ファイルの定数プールに格納されます。
DashO の文字列の暗号化による難読化は、これらを暗号化された値に置き換え、実行中のアプリケーション内で復号します。
機密事項に関連する文字列データが確実に保護されるようにするには、文字列の暗号化で除去を使用します。
DashO の既定の暗号化は、セキュリティとランタイム効率の点から見てバランスが取れていますが、任意で独自のカスタム暗号化アルゴリズムを提供してもかまいません。
増分難読化
アプリケーションが jar ファイルのコレクションとしてビルドされている場合は、各 jar ファイルを 1 つのライブラリとして別々に難読化し、個々の名前変更されていないパブリック インターフェイスをそのままにしておくことができます。 しかし、すべての内部メソッドの名前を変更する必要があるために、単一の DashO ビルドですべての jar ファイルを難読化したい場合もあります。 これらの依存関係のうちの 1 つだけを更新する必要があるとします。 DashO ビルドを再実行すると、すべての異なる名前と、有効でなくなっている可能性のある依存 jar ファイルの参照を選択することができます。
DashO は、増分難読化をオプションとして提供しています。 前回のビルドの名前変更割り当てと文字列の暗号化割り当てが DashO に渡され、再利用されます。 このようにして同じ暗号化アルゴリズムが使用され、新しく追加された識別子に対してのみ新しい名前が選択されます。 したがって、この例では、変更された依存関係を再コンパイルし、増分難読化を使って難読化した後、他の jar ファイルとは切り離して更新することができます。
ランタイム チェック
チェックは、実行環境で検出された条件に実行コードが対応できるようにします。 あらかじめ用意されたレスポンスを使用するか、または独自のカスタム動作を提供して、対応方法を構成することができます。 あらかじめ用意されたレスポンスには、フラグを設定する、アプリケーションを終了する、ランダムな例外で終了する、無期限にハングさせる、などがあります。
ランタイム チェックは、チェックが行われているコードの場所を隠す手段を提供します。 ほとんどのチェックで個別のレスポンス オブジェクトを使用できます。チェックとレスポンスは連携して機能します。 それらを異なるメソッド、さらには異なるクラスに差し込むことができます。 このため、アプリケーション内で、チェックに基づいて操作を実行する場所を、実行の必要性を判断する場所とは無関係な場所にすることができます。 また、確率のパーセンテージを指定して、レスポンスの動作の再現性を低くすることもできます。
これらの機能を組み合わせて使用できるため、アプリケーションは改ざんされていることを「認識」していても、その事実を攻撃者にすぐには明かさずにおくことができます。 実行の早い段階で 1、2 か所にチェックを配置します。次に、さまざまな機能を通じてレスポンスを散在させ、それぞれがアプリケーションを終了する確率を持つようにします。
チェックとレスポンスの構成は、ソース コードにアノテーションを追加して、または GUI でそれらを設定することにより行えます。
デバッグ チェック
DashO デバッグ チェックを使用して追加するコードにより、デバッガーで現在デバッグされていることを検出し、適切に対応することができます。
Java および Android の場合は、アプリケーションをデバッグするために、デバッグを有効にしてアプリケーションを起動する必要があります。 DashO デバッグ有効化チェックでは、実行中のプロセスにデバッガーがアタッチされていなくても、デバッグを有効にして起動されているようにコードで対応できます。
エミュレーター チェック
DashO エミュレーター チェックを使用して追加するコードにより、Android エミュレーターで実行されていることを検出し、適切に対応することができます。
フック チェック
DashO フック チェックを使用して追加するコードにより、Android デバイス上のフックを検出し、適切に対応することができます。
ルート チェック
DashO ルート チェックを使用して追加するコードにより、ルート化された Android デバイスで実行されていることを検出し、適切に対応することができます。
Shelf Life チェック
DashO Shelf Life チェックは、アプリケーションの特定のインスタンスの有効期限が切れていないかどうかを検証します。 相対的または絶対的な有効期限をビルド時に明示的に指定するか、またはトークンに基づいて設定することができます。 このトークンは、jar ファイル内のリソースとして、またはカスタム コードを介して任意の手段によってチェックに提供できます。 また、期限切れになる前の警告期間を提供するように、Shelf Life チェックを構成することもできます。 コマンド ライン ユーティリティ tokengenerator
を使用して、Shelf Life トークンを生成できます。
改ざんチェック
DashO 改ざんチェックは、jar 署名と連携して機能し、実行中のコードが、ビルドされた以降に改ざんされていないかどうかを検証します。 Android の場合も同様に、改ざんチェックは APK 署名と連携して機能します。
不要コードの除去
DashO 不要コードの除去は、使用されていないクラスとメンバーを除去します。 メソッドが分析されるにつれ、参照されるクラス、メソッド、およびフィールドは使用済みとマークされます。 使用済みとマークされていないものは、除去の候補になります。 エントリ ポイントを指定すると、DashO は未使用のものを正確に判断できるようになります。 ライブラリの場合は、使用されていないメンバーまたはクラスで、パブリックでないものだけを除去するように構成できます。 また除去は、デバッグ情報と不必要な属性を .class
ファイルから取り除きます。
DashO メソッド呼び出しの除去は、コードからメソッド呼び出しを除去します。これは、開発では適切であるが、運用環境にとっては望ましくない可能性がある呼び出しについて、非常に役立ちます。これを手作業で削除するのは実際的でないでしょう。これの最たる例は、Android ログの除去です。
最適化
DashO 最適化は、代数恒等式、強度減少、およびピープホール最適化などを実行することにより、結果としてバイナリ サイズを減らし、コードを高速化します。
PreMark
DashO PreMark によって、アプリケーションにウォーターマークを付けることができます。 ウォーターマークは、実行時の動作に影響を与えることなく、データをアプリケーションに目立たないように埋め込みます。 この技法を適用する方法は 2 とおりあります。
最初の手法では、ウォーターマークは GUI で構成され、DashO ビルドで適用されます。 このウォーターマークには、著作権などの情報を含めることができます。 DashO ビルド中に適用されると、表面上は、配布されたそのバージョンのアプリケーションのすべてのコピーに対し、単一のウォーターマークになります。
2 番目の手法では、ウォーターマークは、自動化可能なビルド後の処理の中で、スタンドアロンのコマンド ライン ユーティリティを使用して適用されます。 このウォーターマークには、シリアル番号やその他識別子を含めることができます。 これは、配布されたアプリケーションの各コピーが一意の識別子を持つようにすることを意図しています。 そうすることで、DashO のウォーターマークを利用して、ソフトウェアのソース コードの違法コピーを追跡できます。