Sentinel LDK Envelopeを使用した.NETアプリケーションの保護

この記事で説明するSentinel LDK Envelopeユーティリティは、Win32、Windows x64、.NETプラットフォームの実行可能モジュール（EXEおよびDLL）、およびJavaアプリケーション（JARおよびWAR）にヒンジ保護をインストールすることを目的としています。 保護は、アプリケーションコードをSentinelセキュリティキー（HASPキーの新世代）に「バインド」することによって実行されます。さらに、キーはハードウェア（HL）またはソフトウェア（SL）のいずれかです。 この方法で処理された実行可能モジュールは、必要なすべてのライセンスで必要なキーが存在する場合にのみ機能します。 キーの存在を確認することに加えて、アプリケーションに埋め込まれたセキュリティコードは、デバッグに対する積極的な抵抗力を提供し、静的コード分析を含むアプリケーションのリバースエンジニアリングを困難にします。



この記事の目的は、.NETアプリケーションの保護の方法と機能を検討し、保護インストールプロセスの最大限の自動化に重点を置くことです。 したがって、さらに、.NETアプリケーションの保護に関係するエンベロープ機能のみを検討します。



アプリケーションのセキュリティプロセスを自動化するという観点から見ると、Sentinel LDK API関数を使用してアプリケーションのソースコードレベルでセキュリティを実装するのが最良の選択肢です。 この実装では、開発者はこれまたはそのクラスまたはメソッドをどのように保護するかを独自に決定し、プロジェクトを再構築するときにソースコードに変更が加えられた場合、保護を実装するために以前に行われたすべての作業は、変更を必要とせずに自然な方法で自動的に考慮されます。 ただし、.NETプラットフォームの機能では、アプリケーションの実行中のコードの動的暗号化、コード整合性制御、ノイズ保護エンコードを使用したコード回復など、ネイティブコードで使用できる多くの保護手法を使用できません。 むしろ、これをすべて実現することは可能ですが、C＃での作業は快適ではない可能性が高くなりますが、より「強力な」言語でのシステムプログラミング、CILコードでの低レベルの作業、使用済みのメンテナンスと更新の必要性このプラットフォームの新しいバージョンがリリースされたときなど、.NET内で変更があった場合の作業方法。



一方、ヒンジ付き保護を使用できます。 これにより、実装に必要な時間が大幅に短縮され、開発者の資格はそれほど高くない場合があります（他のプログラミング言語の知識、CILの知識などは必要ありません）。 ただし、ここでもすべてがクラウドレスというわけではなく、保護のインストールを完全に自動化することは困難です。 最初に、通常の使用時のヒンジ付き保護の使用について詳細に検討し、その後、これらすべてを可能な限り自動化する方法について考えます。 Sentinel LDK APIを使用せずに最初は安全でないアプリケーションを作成し、Envelopeを使用してアセンブリを処理するとします。 この場合、安全なアプリケーションを作成する技術的なサイクルは次のようになります。

1）Visual Studioなどの開発環境での安全でないアセンブリの構築。

2）Envelopeとのインタラクティブな作業中に構築されたアセンブリの保護。

2番目の段階を詳しく見て、Envelopeが提供できるセキュリティ方法を見てみましょう。 保護プロセスは、次の操作で構成されます。

1. Envelopeを初めてダウンロードした後、空のプロジェクトが表示されます。 安全なアセンブリが機能するキーのシリーズをすぐに示します（図1を参照）。

図 1-キーシリーズコードの選択

2.保護の対象となるプロジェクトに含まれるすべてのアセンブリに適用される一般的な保護パラメーターを設定します（図2を参照）。

図 2-一般的なセキュリティ設定の設定

パラメータの目的は次のとおりです。

• 文字列の暗号化 -#USヒープに格納されているすべてのデータの暗号化。これには、開発者がソースコードで定義したすべての文字列がUNICODE標準に含まれています。 ここで、たとえば、.NET Reflectorでは、暗号化されていない文字列を含むコードは次のようになります。



そして、暗号化されたものでは：



• 定期的なバックグラウンドチェック -指定された間隔でのキーのバックグラウンドポーリング。

• 圧縮の適用 -アセンブリで保護されているとマークされたクラスおよびメソッドの本体を配置するときの圧縮。 実際には、保護の抵抗には影響しません。たとえば、.NET Reflectorは、このオプションのパラメーターに関係なく、この圧縮ポイントが空白であることを認識しません。

• シンボルの難読化-クラス名、メソッド、フィールドなどのシンボリック情報を含む#Stringsヒープに格納されたデータの難読化 リソース名が変更されていない場合、完全な難読化または部分的な表示が可能です。

難読化前のプログラムクラス：



難読化後：





3. 1つまたは複数の既製のアセンブリをEnvelopeユーティリティのプロジェクトに含めます（図3を参照）。

図 3-プロジェクトへのターゲットファイルの追加

4.プロジェクトに含まれる各アセンブリに対して、パス（ソースファイルの取得場所と保護対象ファイルの配置場所）、キー、使用方法、使用するライセンスを設定します（図4を参照）。

図 4-アセンブリパラメーターの設定

5.必要に応じて、特定のアセンブリごとに、一般的なものと重複する独自の保護パラメーターを設定し（図5を参照）、保護メカニズムの動作をより詳細に構成できます（図6を参照）。

図 5

図 6

図のパラメーター 5はすでにパラグラフ2で検討されています。 図の関心のあるパラメータ（保護の観点から） 6、次のことに注意してください。

• LOCKING_TYPE-このアセンブリの保護が機能するキーのタイプを定義します。 可能なオプション：



ここで：

-HL-ハードウェアキー

-SL-UserMode-ドライバーなしで動作できるソフトウェアキー

-SL-AdminMode-ドライバーと連動するソフトウェアキー

-SL-SL-UserMode + SL-AdminMode



• MIN_CODE_SIZE -CILメソッドコードの最小サイズ（バイト単位）。グループ操作の場合、クラス全体が保護対象としてマークされている場合など、Envelopeによって保護されることから始まります。



6.作業の中で最も時間のかかる部分が残っています-保護するクラスとメソッドを決定し（図7-1）、選択したクラス/メソッドごとに、保護メカニズムのパラメーターを設定します（図7-2）：

図 7-メソッドとクラスの保護の管理

保護するクラスまたはメソッドを選択するには、ウィンドウ1で名前の横にあるチェックボックスをオンにします。同時に、ウィンドウ2には、選択したオブジェクトの現在の保護設定が表示されます。 保護パラメーターの割り当て：



• 機能ID-キーのライセンス番号。 異なるクラス/メソッドについては、それらが個別にライセンスされている場合、異なる場合があります。

• 頻度 -保護されたクラス/メソッドのキーがチェックされる頻度 。 可能なオプション：



ここで：

- プログラムごとに1回-アプリケーションの全期間に1回

- クラスインスタンスごとに1回- クラスのインスタンスを作成するたびに

- 毎回 -各コントロールパスで安全なコードを通過する



•シンボルの難読化-シンボル情報の難読化は、保護の対象としてマークされていない場合でも、メソッドに適用できます。 キーに関連付けられていません。 可能なオプション：



ここで：

- グローバル定義を使用 -シンボルの難読化パラメーターの現在の値が使用されます。2節および5節を参照してください。

- 有効 -グローバル設定に関係なく、難読化は常に実行されます。

- 無効 -グローバル設定に関係なく、難読化は実行されません。



• コードの難読化 -CIL コードの control_flow-obfuscationは、保護の対象としてマークされていない場合でも、メソッドに適用できます。 キーに関連付けられていません。 これは、IDAコードスニペットが難読化後にどのように見えるかです。





そして、これは難読化後の関数のコントロール転送グラフです：





難読化は、コードが1つの命令に従って文字通りに破損し、それらすべてが混在するという事実に明確に見られます。また、実行の前の順序を維持するために、各命令の後に、ジャンプ命令（opcode br）が目的のアドレスに追加で挿入されます。 明らかに、この方法で保護された関数の速度は大幅に低下する可能性があり、コードのサイズは大幅に増加する可能性があります。 したがって、この保護方法は注意して使用してください。



• コードの暗号化 -AESアルゴリズムを使用して、キーを介して選択したメソッドのCILコードを暗号化します。 この保護方法では、元のCILコードがメソッドの本体から抽出され、キーを使用して暗号化され、暗号化された形式でアセンブリリソースに配置されます。 代わりに短いアダプタが挿入され、ロード、復号化、動的コンパイル、および保護されたメソッドのコードへの制御の転送が提供されます。 メソッドの完了後、そのコードはメモリから削除されます。 これは、IDAの保護されたメソッドの本体フラグメントがどのように見えるかです。



クラス呼び出し命令[mscorlib] System.Reflection.Emit.DynamicMethodは、メモリ内でコンパイルされ、実行され、その後削除される動的メソッドを定義および表します。 命令callvirtインスタンスオブジェクト[mscorlib] System.Reflection.MethodBase :: Invokeは、メソッドが正常にコンパイルされると、メソッドに制御を渡します。 この保護方法は、実際には保護されたコードの速度に影響を与えず、かなりまともな耐久性を提供します。



7.必要なすべてのクラス/メソッドが保護対象としてマークされたら、作業結果をプロジェクトファイルとして保存し、[保護]ボタンをクリックするだけです。 その結果、安全なアセンブリが得られます。 仕事の終わり。



プロセスの自動化の問題に戻りましょう。 明らかに、私たちが行ったばかりの作業は不十分に自動化されています。 はい、私たちはプロジェクトの形式で行ったすべてを保存しました。次にアセンブリを保護する必要があるときは、すぐにEnvelopeにロードして使用できます。 ただし、以前のように、安全なアプリケーションを作成する技術サイクル全体は、異なるプログラムで実行される2つの疎結合ステージで構成されています。 それらを接続して、保護を開発者にとって透過的なプロセスにしてみましょう。 これを行うには、envelope.comと呼ばれるEnvelopeのコンソールバージョンを使用します（拡張子を恐れないでください。これは通常のexeファイルであり、古代のms-dosからの挨拶ではありません）。 したがって、–hスイッチで開始すると、次のことが通知されます。





Visual Studioの「構築後のイベント」段階で、-pスイッチを指定してユーティリティを使用します。 たとえば、次のことができます。





envelope.comでのすべての作業は、プロジェクトディレクトリにあり、次のコマンドを含むenvelope.cmdバッチファイルに転送されます。



..\..\LDK\VendorTools\VendorSuite\envelope.com -n --protect %1





move /Y %2.protect %2







すべてが正しく機能するためには、envelope.comユーティリティでディレクトリへの正しいパスを指定する必要があり（ここのように、相対パスではなく絶対パスを使用できます）、出力ファイルの拡張子を変更してEnvelopeの保護プロジェクトを少し変更する必要があります移動コマンドが正常に機能するように：





このユーティリティは、Visual Studioの出力ウィンドウのログで確認できます。





Visual Studio環境でアセンブリを作成するプロセスが完了すると、不要なジェスチャなしですぐに保護されたアプリケーションを受け取ります。

うまくいったようですが、アプリケーションのソースコードに大きな変更が加えられた場合はどうなりますか？ たとえば、保護する新しいクラス/メソッドが表示される場合、古いクラス/メソッドが削除されるか、既存のクラス/メソッドを保護する方法を変更する予定ですか？ 従来の方法では、セクション6で説明したように、保護プロジェクトをEnvelopeで開き、累積されたすべての変更を行う必要があります。これは悲しいことです。アプリケーションソースコードにわずかな変更を加えても、保護プロセスの自動化が終了するためです。

ただし、ソースコードのこのような変更の更新を自動化することは可能です。 これは、アプリケーションのソースコードでカスタム属性を使用して実行できます。 カスタム属性を使用した保護のオブジェクトは、特定の属性セットの場所に応じて、メソッド、クラス、またはアセンブリ全体になります。 オブジェクト保護に使用可能な属性のリストは、セクション6で説明されているクラス/メソッドの保護パラメーターのセットを完全に繰り返しています。使用可能な属性のリストは次のとおりです。

• 保護 -タイプBOOL、可能な値-TRUE / FALSEは、キーを使用してオブジェクトを保護する必要があるかどうかを示します。

• FeatureId-タイプint、可能な値-[0; 65535]は、オブジェクトを保護するために使用されるライセンス番号（機能ID）を示します。 Protect == TRUEの場合にのみ受け入れられます。

• 暗号化 -タイプBOOL、可能な値-TRUE / FALSEは、オブジェクトのCILコードを暗号化する必要があるかどうかを示します。 Protect == TRUEの場合にのみ受け入れられます。

• CodeObfuscation-タイプBOOL、可能な値-TRUE / FALSE、オブジェクトCILコードのcontrol_flow難読化を行うかどうかを示します。 Protectの値に関係なく受け入れられます。 この保護方法は、保護されたコードの速度を低下させます。

• 頻度 -EnvelopeMethodProtectionFrequency列挙型は、保護されたオブジェクトのライセンスがチェックされる頻度を示します。 Protect == TRUEの場合にのみ受け入れられます。 可能な値：

-CheckOncePerApplicaton-アプリケーション操作中の単一チェック。

-CheckOncePerInstance-オブジェクトの各インスタンスの単一チェック。

-CheckEveryTime-コントロールがオブジェクトコードを通過するたびに確認します。

• SymbolObfuscation-列挙型EnvelopeSymbolObfuscationは、保護オブジェクト内のシンボル情報を難読化する方法を示します。 Protectの値に関係なく受け入れられます。 可能な値：

-ObfuscateSkip-すべての記号情報の難読化の完全な禁止。

-ObfuscateForce-すべてのシンボリック情報の強制難読化。

-ObfuscateDefault-パブリック名、および仮想修飾子と保護修飾子を持つオブジェクトを除く、すべての記号情報の難読化を実行します。



Envelopeがソースコードから属性を取得するには、usingディレクティブを使用して、Aladdin.HASP.EnvelopeおよびAladdin.HASP.EnvelopeRuntime名前空間を含める必要があります。 当然、これの前に、ファイルAladdin.HASP.Envelope.DLLおよびAladdin.HASP.EnvelopeRuntime.DLLをVisual Studioプロジェクトのリンクに追加する必要があります。 これらのファイルを保護されたアプリケーションと共に配布する必要はありません;それらはアセンブリに保護をインストールする段階でのみ必要です。 以下は、カスタム属性を使用したソースからの保護の例です。





一般的に、アセンブリ保護に関連するすべての変更は、2つのカテゴリに分類できます。

1.まれにしか発生しないグローバルな変更。 パラグラフ1から5で説明されているように、ソースコードからそれらを管理することは不可能です。

2.保護対象のクラス/メソッドの外観または削除に関連するソースコードの変更は、はるかに頻繁に発生します。 パラグラフ6で説明します。これで、Envelopeで保護プロジェクトを編集しなくても、ソースコードからそのような変更を完全に更新できます。



そして今、上記のすべてを要約すると、Sentinel LDK APIを使用する場合と同様に、開発者はソースコードからの保護を完全に制御していると言えます。 一連のキーの変更、アセンブリ名の変更、キーのバックグラウンドポーリングのバックグラウンドポーリングの設定など、グローバルな変更がある場合にのみ、セキュリティプロジェクトをEnvelopeにアップロードし、パラメーターを修正する必要があります。