最近 DotNet 関連の資料を勉強していますが、sscli は本当に良いものです :P.
勉強しながら知識を総合してこの小さなツールを作りました。
保護原理は中国のremotesoftやmaxtocodeと似ています。暗号化されたプログラムは、リリース時にランタイム ライブラリを伴う必要もあります。
ただし、これら 2 つとは異なり、含まれるランタイム ライブラリは純粋なネイティブ DLL ではなく、C++/CLI ハイブリッド アセンブリです。
ツールが形になり、カーネル フレームワーク全体が完成しました。サンプルを暗号化するために使用され、正常に実行されます。
いくつかの側面では maxtocode を超えています。
1. Microsoft の ildasm および ilasm プログラムに依存しません。
IL 逆アセンブリと IL アセンブリは両方ともプログラムによって実装されます。
ネイティブ コードを含むアセンブリは暗号化できます。
2. 逆コンパイル防止ツールである maxtocode で暗号化されたアセンブリは、reflector で直接表示することはできませんが、プログラムを実行した後は pedumper を使用し、ダンプ後は、reflector を使用して構造を表示することはできます。
dnguard で暗号化されたアセンブリは予想よりも優れています。暗号化されたアセンブリはリフレクターでは表示できません。また、ダンプされたアセンブリはリフレクター プラグインでは表示できません。
同じようなソフトウェアである Disa# と Xenocode fox は、maxtocode と dnguard で暗号化されたアセンブリを開いて表示することがまだ少し弱いと感じています。
この目的のために、dnguard で暗号化されたアセンブリに構造難読化を追加しようとしました。これには影響がありました。つまり、Disa# と fox で構造を表示すると、クラス A の関数が表示される可能性があります。クラスBで。効果はあまり良くありません。問題を引き起こす可能性のある関数は各クラスにわずかしかありません。
3. Anti .Net 2.0 の新機能はそれほど強力ではありません。maxtocode 3.13 (内部バージョン) と同様の機能です。maxtocode が 3.14 をリリースしたと聞いています。 Jason のブログの返信では、3.13 と同じのようです)。 Max 3.12 は数バイトのパッチを適用するだけで使用できますが、リフレクションは 3.13 と大きな違いはなく、パッチに必要なバイト数は 3.12 よりもさらに少なくなります。
この点に関しては、効率に影響を与えることなく強度を大幅に高めることができる、より良い解決策が存在します。しかし、ダンプを完全に防ぐことはできません。
比較的完璧なアンチダンプ ソリューションもありますが、これは別の保護テクノロジと組み合わせて実装する必要があります。
DNGuard 暗号化シェルが完成したら、この側面について詳しく説明する予定はありません。その後、別の保護テクノロジを開始し、最終的に 2 つの保護を組み合わせる予定です。
4. ildasm および ilasm を使用して、アンチダンプ後にアセンブリを復元します。 anti .net 2.0 の新しいアンチダンプ機能に加えて、DNGuard には、私が初期に作成したダンパーである anti も追加されています。さらに、C++/CLI ハイブリッド アセンブリの機能は、ダンプ後の ildasm を防ぐためにも使用されます。ただし、これはそれほど強力ではなく、小さなアセンブリを簡単に修復して IL アセンブリを実装できます。
暗号化アルゴリズムはまだ解明されておらず、ランタイム ライブラリ自体の保護もまだ行われていません。純粋なネイティブ DLL 用の既製の保護ツール (thmida など) が見つかりました。これは非常に優れており、maxtocode のランタイム ライブラリはこのシェルを使用していますが、C++/CLI DLL 用の適切な方法を見つけることができませんでした。 。保護層は手動で追加するしかないようで、すでにテストを開始しています。次に、単純な暗号化シェルを追加します。これが完了したら、DNGuard のデモを配置します。
DNGuard がアセンブリを暗号化した後、リフレクターを使用して以下を表示します。
リフレクターを使用して、DNGuard 暗号化アセンブリ ダンプを表示します。
Maxtocode で暗号化されたアセンブリは Reflector で表示されます。
Maxtocode で暗号化されたアセンブリをダンプした後、Reflector で表示します。
