アプリケーションの保護の手順に従って Dotfuscator Professional をセットアップすると、次の方法でアプリケーションが保護されるようになります。
上の既定値では最小限の努力でかなり強力な保護が提供されますが、アプリケーション実行中のアクティブな保護など、はるかに強力な保護を行うこともできます。
保護設定のカスタマイズ
Dotfuscator の保護は、プロジェクトの Dotfuscator 構成ファイル（既定ではプロジェクト ディレクトリの DotfuscatorConfig.xml）を編集することによりカスタマイズできます。 この構成ファイルを変更する方法は 2 つあります。
-
Windows では、構成エディターを使用して、グラフィカル インターフェイスでコードの構造と共に構成を表示して変更することができます。
-
すべてのプラットフォームで、テキスト エディターでプロジェクト ファイルを XML ドキュメントとして変更することができます。
このページでは、構成エディターを使用して構成ファイルの保護を強化する方法を中心に説明します。 構成ファイル リファレンスには対応する設定へのリンクが含まれているため、ここでの変更をテキスト エディターで適用することもできます。
構成エディターについて
構成エディターの使用を開始するには、Windows スタート メニューにある［Dotfuscator Pro Config Editor］ショートカットから起動します。 ［ファイル］>［開く...］コマンドを使用して構成ファイル（DotfuscatorConfig.xml など）を読み込みます。
構成エディターは、さまざまなタブに分かれています。 最初の［入力］タブは、保護対象となる入力アセンブリを示します。 このタブは、アプリケーションの保護の手順で採用したアプローチによって異なります。
-
推奨されるアプローチを使用した場合には、入力アセンブリは、自動入力管理と呼ばれる機能を通じて MSBuild ターゲットによって自動的に処理されます。
-
代替のアプローチを使用した場合には、入力アセンブリは［入力］タブを使用して手動で指定する必要があります。 （テキスト エディターで構成ファイルを編集する場合は、
inputassemblyセクションで入力アセンブリを構成します。）
どちらの場合も、このタブで入力アセンブリのノードを展開することにより、アセンブリ固有の設定を変更できます。
（テキスト エディターで構成ファイルを編集する場合、これは
input_management 設定に該当します。）保護設定を変更する場合は、保護するアプリケーションをテストする必要があります。その理由は、Dotfuscator の保護の特定の構成により、アプリケーションの実行時の動作が変更される場合があるためです。 構成ファイルの変更を保存（たとえば、構成エディターの［ファイル］>［保存］コマンドを使用）したら、通常のビルド処理（Visual Studio、MSBuild など）を使用して、新しい設定でアプリケーションをビルドする必要があります。
ビルド後、アプリケーションを実行します。 アプリケーションが期待したとおりに動作する場合は、構成エディターに戻り、保護の調整を続行することができます。 期待したとおりに動作しない場合は、ランタイム エラーを参照してください。
ビルド コマンドは、推奨される MSBuild ターゲットの使用時には利用できません。これは、ビルド システムでアセンブリを自動検出し、保護されたバージョンをプロパゲーションするために、Dotfuscator を通常の .NET プロジェクト ビルドの一環として実行する必要があるためです。
チェックの追加
Dotfuscator は、コードの逆コンパイルを阻止する以上のことを行うことができます。 また、アプリケーションを実行時に不正な使用から保護するチェックと呼ばれる有効な対策を差し込むこともできます。
たとえば、不正なアクターがお使いの実稼働アプリケーションに WinDbg などのデバッガーをアタッチすることで、機密データを公開したり操作したりする可能性があります。 Dotfuscator 構成にデバッグ チェックを追加することで、アプリケーションがその種の攻撃から簡単に防御できるようになるので、少ない労力ではるかに良くアプリケーションを保護することができます。
チェックは、構成エディターの［チェック］タブで構成します。 このページの表には構成したチェックがリストされますが、当初は空です。チェックを追加するには、チェックの特定の種類に対して、該当する［追加］ボタンをクリックします。
次はプラットフォーム別の例で、.NET Framework アプリケーションではデバッグ チェックを適用し、Xamarin Android アプリケーションでは改ざんチェックを適用します。
［デバッグ チェックの追加］をクリックすることで、アプリケーションにアンチデバッグ動作を追加できます。 構成エディターにより、新しいデバッグ チェックを構成するための独立したウィンドウが開きます。
このウィンドウは 2 つのセクションに分かれています。 ［チェック プロパティ］セクションでは、不正な使用に対応する方法など、チェックの設定を構成します。 また、このセクションでは、事前に作成したアクション（アプリケーションの終了など）をチェックで実行したり、カスタマイズした対応を行うアプリケーション コードの呼び出しをチェックで行ったりすることもできます。 ［場所］セクションでは、チェックが場所の検出と対応を行うのに使用するメソッドを選択できます。
最初のデバッグ チェックを構成するには、［Action］プロパティを "Exit" に設定し、アプリケーションのステートアップ メソッド（Main など）として "Location" を選択します。
チェックによってアプリケーションに新しい動作が導入されるので、不正な使用が行われた場合も行われなかった場合も、この新しい動作が期待したとおりのものになっているかどうかアプリケーションをテストする必要があります。 最初のデバッグ チェックをテストするには、変更を構成エディターに保存し、Visual Studio でプロジェクトをビルドします。 続いて、以下のように、不正なケース（デバッガーがアタッチされている）と名目的なケースを両方ともテストします。
-
Visual Studio の［デバッグ開始］コマンドを使って、不正なユースケースをテストします。 アプリケーションは起動したら直ちに終了する必要があります。
-
［デバッグなしで開始］コマンドを使って、名目的なケースをテストします。 アプリケーションは正常に動作する必要があります。
アプリケーションによって処理される機密データを保護するのにチェックを使用するケース スタディについては、MSDN マガジンの記事、セキュリティ - 未承認の開示と使用からデータとアプリを保護するを参照してください （この記事では Dotfuscator Community を使用していますが、チェックを使用するための最適な方法は Dotfuscator Professional でも同じです）。
テキスト エディターで構成ファイルを編集する場合、チェックの構成は extattributes セクションで行います。
名前の変更による難読化の改善
Dotfuscator の既定の構成では名前の変更による難読化が可能ですが、保護をカスタマイズして、より多くのコード要素の名前を変更できるようにしたり、複数の要素で同じ名前を共有できるようにしたりすることもできます。
ライブラリ モードの無効化
Dotfuscator のライブラリ モードでは、保護するアセンブリのパブリック コントラクトを保持することで、Dotfuscator で処理されない外部コードがそれらのアセンブリを引き続き参照できるようにします。 これに対し、外部コードで参照されないことがわかっているアセンブリの場合は、ライブラリ モードを無効にすることができます。 これにより、名前が変更される項目の数が増加するので、保護が強化されます。
アセンブリに対してライブラリ モードを無効にするには、［入力］タブでアセンブリのノードを展開し、［ライブラリ］チェック ボックスをオフにします。
テキスト エディターで構成ファイルを編集する場合、ライブラリ モードは library 入力アセンブリ オプションによって制御されます。
拡張オーバーロード誘導の有効化
Dotfuscator の名前の変更による難読化では、特許を取得しているオーバーロード誘導（Overload Induction™）技術を使用することで、同じ新しい名前が付けられるコード要素の数を増やします。 この技術の効果を増大させるには、拡張オーバーロード有効を有効にします。
拡張オーバーロード誘導は、［名前の変更］タブの［オプション］サブ タブで有効にすることができます。
テキスト エディターで構成ファイルを編集する場合、拡張オーバーロード誘導は enhancedOI 名前変更オプションによって制御されます。
制御フローの難読化の改善
Dotfuscator の既定の構成では、制御フローの難読化が有効になっています。 この保護を強化するには、Mono との互換性を無効にすると共に Visual Studio の逆コンパイル機能を抑制するよう、Dotfuscator を構成します。
Mono との互換性の無効化
アプリケーションを Mono 上で実行することを意図していない場合は、Mono との互換性を無効にすることで、Dotfuscator がより強力な制御フローの難読化を適用できるようになります。
Mono との互換性を無効にするには、［設定］タブの［オプション］画面の［高度］で［Mono 互換の変換のみを使用する］を "いいえ" に設定します。
テキスト エディターで構成ファイルを編集する場合、Mono 互換は monocompat グローバル オプションによって制御されます。
Visual Studio の逆コンパイルの抑制
最近のバージョンの Visual Studio（15.6 以降）では、アセンブリを逆コンパイルして C# のコードにすることができます。 Dotfuscator により、アセンブリに対して Visual Studio がこの機能を使用しないようにすることができます。これにより、公式の .NET の逆アセンブラーも停止されます。 ただし、この設定はサード パーティ製のツールには影響しません。
Visual Studio の逆コンパイル機能を無効にするには、［設定］タブの［オプション］画面の［高度］で［Ildasm を抑制する］を "はい" に設定します。
テキスト エディターで構成ファイルを編集する場合、この抑制は suppressildasm グローバル オプションによって制御されます。
文字列の暗号化による難読化の有効化
文字列の暗号化による難読化では、アセンブリのメソッド内の文字列リテラルが暗号化されるので、攻撃者が機密データを抽出したり、コードのどの部分が特定のアクションを実行するのかをより理解したりするために、検索ツールでそのような文字列リテラルを簡単に見つけられないようになります。
文字列の暗号化は既定では無効になっています。 文字列の暗号化を有効にするには、［設定］タブの［オプション］画面の［機能］で［文字列の暗号化を無効にする］を "いいえ" に設定します。
文字列の暗号化による難読化は、この保護の対象となるよう特に構成したメソッド内の文字列リテラルにのみ適用されます。 文字列の暗号化による難読化により、機密事項に関連する文字列を暗号化できるだけでなく、実行時に機密事項に関連しない文字列の復号が必要になることによるパフォーマンスへの影響を回避できます。
保護するメソッドは、［文字列の暗号化］タブ（サブ タブは［対象］の 1 つのみ）の［対象とする項目のチェック ボックスをオンにします:］ツリー ビューで選択します。
アセンブリの全メソッド内の文字列リテラルを保護するには、まずアセンブリのノードをチェックします。 ツリー ノードを展開し、文字列の暗号化の対象とする名前空間、型、およびメソッドを個々に選択するという、より特化したアプローチもあります。
const）フィールドとして宣言された文字列は使用時にインラインで定義されるため、これらのフィールドを参照するメソッドに対して［文字列の暗号化］を有効にすると、それら使用される文字列も暗号化されます。 ただし、定数フィールド自体は暗号化されないままのため、アセンブリからこれら暗号化されない不要な値を削除するには、除去を有効にする必要があります。テキスト エディターで構成ファイルを編集する場合、文字列の暗号化は stringencrypt セクションで制御されます。
除去の有効化
Dotfuscator は、アセンブリから使用されていないコードとメタデータを除去することで、攻撃対象領域を最小限にします。
除去は既定では無効になっています。 文字列の暗号化を有効にするには、［設定］タブの［オプション］画面の［機能］で［除去を無効にする］を "いいえ" に設定します。
テキスト エディターで構成ファイルを編集する場合、除去は removal セクションで制御されます。
DotfuscatorAttribute の除去
Dotfuscator がアセンブリを保護する場合、既定では DotfuscatorAttribute をアセンブリに追加します。 アセンブリに対しこの属性をチェックして Dotfuscator がそれらを保護していることを検証できます。また、 サードパーティ製のビルド ツールはその属性を使用して、保護されたアセンブリを処理する方法を制御することもできます。 ただし、この属性はサードパーティ製の逆コンパイラに、アセンブリを保護するために Dotfuscator が使用されたことも通知します。
以下に示すように、nodotfuscatorattribute を構成ファイルのグローバル オプションのリストに追加することによって、Dotfuscator が DotfuscatorAttribute をアセンブリに挿入しないようにすることができます。
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE dotfuscator SYSTEM "http://www.preemptive.com/dotfuscator/dtd/dotfuscator_v2.5.dtd">
<dotfuscator version="2.3">
<global>
<!-- ...その他のグローバル オプション... -->
<option>nodotfuscatorattribute</option>
</global>
<!-- ...その他のタグ... -->
</dotfuscator>
DotfuscatorAttribute および nodotfuscatorattribute グローバル オプションの詳細については、構成ファイル リファレンスを参照してください。
保護されたアセンブリを調べる
構成エディターで変更を保存し、Visual Studio でアプリケーションをビルドしたら、新しく保護したアセンブリを逆コンパイルすることで、Dotfuscator 構成ファイルの変更がどのように保護に影響したかを確認できます。 これを行う方法の詳細については、逆コンパイルを参照してください。
たとえば、Dotfuscator の保護を強化する前と後におけるサンプル アプリケーション GettingStarted 内のメソッドを逆コンパイルしてみましょう。
| 既定の保護（抜粋） | 強化された保護 |
|---|---|
 |
 |
難読化が推し進められた結果、逆コンパイル ツールがクラッシュするようになりました！ 自動リバース エンジニアリング ツールが停止されるため、アセンブリのリバース エンジニアリングには法外なコストがかかるようになったのです。
保護されたアプリをリリースする前に
保護されたアプリまたはライブラリをリリースする前に、リリース チェックリストを見直してください。 このチェックリストでは、保護されたソフトウェアのリリースの一環として考慮すべきトピックをすべてまとめています。