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